Results 1 to 4 of 4

Thread: Developers and contributors unable to see reviewboard links in bugs

  1. #1
    storm's Avatar
    storm is offline Advanced Member
    Join Date
    May 2006
    Location
    London, UK
    Posts
    178
    Rep Power
    9

    Default Developers and contributors unable to see reviewboard links in bugs

    As part of vmware, Zimbra has clearly adopted reviewboard as part of the development process. This is probably very helpful.

    However, in an increasing number of bug reports, designs, code, or other (unspecified) documents are being referred to from within the reviewboard system.

    External developers and contributors have no access to this system.

    Even more frustratingly, links to reviewboard documentation is often given with no explanation of the content. The development process is thus at risk of becoming opaque and hidden, in addition to the potential burden of developers being frequently asked to explain what is in the referred-to reviewboard documents.

    In the spirit of open collaboration and efficiency, could you please review the usage of reviewboard, and how this fits in with external collaborators, developers, and contributors and bugzilla users, and devise a policy to deal with this.

    Many thanks,
    Störm

  2. #2
    mmorse's Avatar
    mmorse is offline Moderator
    Join Date
    May 2006
    Location
    USA
    Posts
    6,242
    Rep Power
    21

    Default

    Swore I answered this already (not showing up), sorry for the 2nd email/commenting again in case anyone else should land on the thread - anyways you brought up a good discussion, let me explain from another viewpoint though (other side of the fence/once employee):

    In short: At the moment Review Board usage is meant to improve quality by having another dev or two check the code. (Collaboration is another benefit but wasn't the primary motivator as far as public wise goes.) ReviewBoard (sorry it's using an internal-only VMware instance right now) supports both pre-commit and post-commit to repository reviews.


    Thus it can be used:

    A: In lieu of internal developer communication (which you wouldn't see anyways).

    B: For someone to double check after it's committed, or before integrate to another more stable branch (in which case the public sees it once synced from the perforce-zimbra-depot.z > codes.z).

    If it's being used for pre-commit (and the dev decides to paste it in as a public comment for whatever reason - by mistake or maybe to let people who are waiting impatiently know it's being worked on) should you want to see it urgently to help contribute, just ask. I'm sure they can get it posted up somewhere for you to examine or pastebin etc.

    But for the most part it's not any 'different' since it's just in place of intra communication about how to solve going on in the bug/emails/im/in person regardless. They'll still ask publicly if they need your help tracking it down, if a proper behavior needs to be decided, or want to map out what features should to be added for enhancements, etc.

    ~

    Old process:
    dev workstation > dev collaborates via whatever method > dev checks a few self test cases to make sure the suggested change won't break things > submits to internal depot.z main > public sees the sync to codes.z > depending on what their working on may then need to integrate to another branch like GNR on depot.z > public sees the sync to codes.z

    If obvious major regression causing or build failure issues > bunch hunt for the cause > hound dev involved to fix (or fix themselves) > breathe again.


    New process:
    dev workstation > dev self tests > submits to reviewboard for collaboration > approved by dev2 > dev1 submits to depot.z main > etc etc

    New process 2:
    dev workstation > dev self tests > submits to reviewboard for collaboration AND submits to depot.z main at the same time > dev2 reviews > etc etc

    ~

    Basically there's at least another pair of eyes taking a look before (or soon after) the code goes out and negatively affects many developers (both employees and external contributors). While they can all view the changelist & accompanying emails, the more devs intimately/higher level aware of the change right away, the faster any issues with it can be solved.

    Thus I don't think it's hurting too much in turn around time and public contributions wise, compared to the proposed stability it intends to bring. Yes, in some cases it could delay external viewing of code by a day or two, but if a dev was unsure of their change it wouldn't be submitted for you to see anyways - hence it just seems slower since you now are given privy to the fact that a dev is actively working on it.

    Give them some breathing room to hash out a version 1 (too much back & forth on the bug would get nuts anyways) - if the solution's not to your liking just say so after the first public sync.


    Big picture discussion:
    Treat Review Board like an extension of a workstation area. It's purely unfesable & unrealistic in logistics/traffic/security to allow the whole world to see every developers entire desktop storage space on every open source project out there right? Other projects have sub-teams, and I guarantee you every last communication between those team's devs is not up for public reading. Plus if it was, probably wouldn't serve much benefit since it's not their final thing they want to present to the world yet. Could somone theoretically save time by interjecting their awesome thoughts on how something is progressing earlier in the process? Yes, but would it be always welcome to the devs involved on the other end - probably not - they'll solicit feedback (via whatever means) once they do some work on their own & are ready.

    That said, of course I think Zimbra could benefit from it's own pastebin and review board instance tied into bugzilla.z for better public contributions/interaction/quality control - however doing so (and the actual urgency on that) is not up to me presently.
    Last edited by mmorse; 10-02-2010 at 12:44 PM.

  3. #3
    storm's Avatar
    storm is offline Advanced Member
    Join Date
    May 2006
    Location
    London, UK
    Posts
    178
    Rep Power
    9

    Default

    Thank you for the expansive response on this Mike, it is very helpful.

    Now I comprehend better the system, and thus I apologise if my original post was a tad hasty (though to be fair, prior to your explanation of the system it was frustrating and not immediately obvious to users).

    However, my main contention stands to an extent: thus, I would urge Zimbra developers to ensure that when they refer to any substantive documents, diagrams, graphics or designs within a bug that they should seriously consider adding it as an attachment to a bug, rather than referring to them on reviewboard. If that's not appropriate they should at the very least explain very loosely and briefly what they are referring to/about - rather than just posting an inexplicable link to an inaccessible reviewboard page.

    (Bearing in mind that many development participants won't have access to reviewboard - or have a clue as to what is being referred to.
    Last edited by storm; 10-03-2010 at 04:00 AM.

  4. #4
    LMStone's Avatar
    LMStone is offline Moderator
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,367
    Rep Power
    10

    Default

    Mike,

    I very much support the peer review process for development. Some years back I headed a $5 million software development effort in NYC; we used Extreme Programming (now typically called "Agile Development") which has at its core a peer review process. It really helped us get better quality code into production faster!

    Peer review works well in other industries too: in the publishing business there is an old saying that "Every author benefits from a good editor."

    I'll gladly accept the occasional obscure, and to me, undecipherable reference in a bugzilla post if I am confident the end result will be better code.

    All the best,
    Mark

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •