Re: Three questions for using Review Board 1.0.6
On Thu, Oct 28, 2010 at 12:28 PM, J Arrizza cppge...@gmail.com wrote: Andrew, I am still new to RB, and we are looking for something similar as well. We have an SCR in our defect tracking system that aggregates all work for change. Developers create a series of changesets and then tag each of those with the SCR. When it's time to do a code review, we'd like to have one code review for the entire SCR. So if I'm not mistaken, we are looking for the same thing you are (review request being for a series of changesets). Here are my thoughts (FWIW) on this: There needs to be a way add multiple changeset ids or revision numbers or whatever on the command line. Currently we handle it through a manual process: use hg log to a list of changesets make a list of the changeset revision ids for the SCR, say (88, 89 and 93) starting with the oldest revision (88), create the review using hg postreview 88 (the mercurial-postreview allows this, don't know if the others do) say the new review is id 33 add the remaining revisions one by one from oldest to newest: postreview -e 33 89 postreview -e 33 93 when you go into RB GUI, the three changesets show up as three revisions 1, 2, and 3 where 1-revision88, 2-revision89 and 3-revision93. Cons: - manual steps are error prone - if you screw up and add a revision you shouldn't have, not possible to remove that from the review - if you screw up and forget to add a revision, not possible to insert that into the existing review - the multiple revisions in the code review are confusing to the reviewers. - During a review, it's not possible to tell if a problem in the code in revision x is actually fixed later on in revision y. Also, as far as I can tell, the spirit of multiple revisions in ReviewBoard is that each changeset replaces the previous changeset and may be a response to a previous changeset. It would be nice to be able to post 5 changesets that are logically one review request, have them get reviewed, then post 5 new changesets that replace the original 5 changesets and address issues found in review. The GUI would allow the user to diff between the original changeset 2 and the new changeset 2, for instance. So, in short, the extensions I'd like to see are: - the manual part of the review request automated. Perhaps it's as simple as allowing multiple changesets to be put on the command line. Or it may have to get more complicated (e.g. list the revisions for the developer through some gui and allow them to select the ones they want from that list) We use hg postreview as well. I'm fairly certain that the automation you're mentioning would be straightforward to implement, as the codebase for the postreview plugin to mercurial is relatively small and self-contained. You could suggest it to Gilles Moris at code.google.com/p/*mercurial*-* reviewboard*/ or to mdelagra at http://bitbucket.org/mdelagra/mercurial-reviewboard/ to see if either of them would be interested in the feature. We are currently only using reviewboard for single-changeset review requests, so we don't have a high need for this feature. - have a rollup mechanism. As the additional revisions are added, the changes are rolled up into one aggregate diff. (I assume this would be very complicated code and so might not be doable without significant risk) What do you mean? I'm not sure if there are other options available... John On Tue, Oct 26, 2010 at 7:25 PM, Andrew Schwartz aschwa...@gmail.comwrote: I think that what I'm talking about is the same thing that Eduardo called Remodelling diff versioning. Does that seem right to you? On Tue, Oct 26, 2010 at 7:17 PM, Andrew Schwartz aschwa...@gmail.comwrote: Christian, Sorry for letting this thread slide for so long. I'm talking about a review request being for a series of changesets. In our case, we often will split a single feature change into small, easily reviewed changesets. It would be nice to be able to put all of these changesets into a single review request. Does that make sense? -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.comreviewboard%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com
Re: Off-line Usage.
Just wanted to express some support for this feature. Would be fairly nice. Perhaps some of the new HTML5 Offline features could be used. On Dec 23 2008, 2:18 am, Christian Hammond chip...@chipx86.com wrote: Hi Blake. I'd like to someday add support for Google Gears for offline support, but this would be after we add Extensions support to Review Board. So, certainly not right away. There's a lot that would have to be taken into consideration and we just really have too much on our plates for this right now. If you'd like to file a feature request, it'll help us to keep it in mind in the future, and if someone wants to take on this work, I'd be for that. Christian -- Christian Hammond - chip...@chipx86.com VMware, Inc. On Fri, Dec 19, 2008 at 1:20 PM, Blake Winton bwin...@latte.ca wrote: Hi, I think I'm probably going to start using Review Board in the coming months, and I've got a question. One of my developers isn't able to connect to the Internet full time. (She's on the wrong side of a PPP link.) Is there any sort of offline/batch tool she could use to interact with Review Board without having to be online all the time? Thanks, Blake.- Hide quoted text - - Show quoted text - -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: Three questions for using Review Board 1.0.6
N On Tue, Jul 27, 2010 at 4:05 PM, Eduardo Felipe eduardofelip...@gmail.comwrote: Sure! I am working on making the support for DVCS better by implementing the following: Remote branch tracking: Based on the notion of feature branches one could build around the notion of long lived reviews that could be updated as the code is updated, all in the Web UI, without having to post another review and lose the context information. As such reviews could be used to document coding decisions before a branch is integrated in the main line, and could be automatically closed once the branch is merged back. My implementation focus mainly on Git for the time being, but it will also support Mercurial before it's ready to go. Remodeling diff versioning: Currently when a new review is created on Review Board, it takes the uploaded patch, infer the oldest committed version referenced by the patch and applies the patch on top of it, creating a new version. It then goes ahead and mark that patch as version one. If the user uploads a new patch, version two is created, and with that the possibility of seeing just what changed between the two versions, therefore reviewing the part, not the whole. With the new workflow upon submitting a patch to be reviewed, instead of just loading the submitted patch and marking it as version one, Review Board would fetch the diff for every incremental revision from the oldest version present in the diff to the newest, apply it on top of the head and mark that as a version of the patch, in practice creating a version containing all changes from the base up to that point. It would also store information about which commits formed that partial patch to display later. If the repository that holds the commits is not accessible to ReviewBoard then in order to take advantage of this feature you'll have to use post-review from the command line, so it can create a bundle containing all the information necessary for this view. Sounds promising. If a review response involves creating a new set of changesets to replace the old set of changesets, will there by a concept of sub-versions? For instance: Say A is the head of the current master repository. I'm submitting three related changesets for review, B, C and D. Then, as a result of the review, I now want to update the diffs with B', C' and D'. Will there be any mechanism for doing this and easily seeing that B' is related to B, etc.? I expect this code to be done by the second week of August (that's when the Summer of Code ends), and to be integrated on a new version when Christian agrees with everything I've done, hehehe. Cheers, Eduardo. On Tue, Jul 27, 2010 at 4:37 PM, Christian Hammond chip...@chipx86.com wrote: Eduardo, can you give a summary of what you're working on? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Tue, Jul 27, 2010 at 12:33 PM, Andrew aschwa...@gmail.com wrote: Hi all. Please let me know what's going on with DVCS and Review Board. I know that there are ways to make it work (as we are in my organization), but it would be nice for it to be better integrated in the project with reviewing multiple changesets, etc. Thanks. On Jul 20, 5:40 pm, Andrew aschwa...@gmail.com wrote: I'm wondering if there has been any progress on theDVCSfront. I'd be very interested in the current design. Is one of the GSOC students actively working on this? On Jun 2, 6:08 pm, Christian Hammond chip...@chipx86.com wrote: Hi James, Today, each logical change is meant to have its own review request. If you have three things that are related but are separately worked on, each should be put up for review separately. There's no notion of a review request that encompasses several different changes. I personally think this is good, as it keeps it organized and keeps things smaller. Where things may change over the next several months is how diffs are handled when used with aDVCSlike Git. In those cases, it makes sense to be able to have a review request for one change but with several iterative diffs leading up to that one change. It would still be one logical change, but with multiple diffs instead of one big diff. I don't know how well this concept would really apply in the SVN guess. I suspect it wouldn't. Now, I'm not fully sure I understand how your project is organized. Is each Java component in a different repository? If not, can't one diff be generated that has all the changes to all the components, and then put that up as one review request? If they are indeed in different repositories, then what you'd need is a way to have one review request that spans repositories. This is something that, for many reasons, we
Re: Multiple diffs in the same review request
Which part? #1 or #2? On Fri, May 7, 2010 at 5:01 PM, Jeff Andros j...@seguetonowhere.com wrote: How is this different from the update diff option that's currently there? On Fri, May 7, 2010 at 5:00 PM, Andrew aschwa...@gmail.com wrote: Hi guys. I've been playing with the multiple revisions support in ReviewBoard. I was wondering what people think about these two suggestions: 1. It would be nice to be able to compose changesets. For instance, if I have one changeset under review, it then gets reviewed, then I post a second changeset that is based on the first changeset, it would be neat to be able to see the diff from pre-first diff to post-second diff. I understand that currently, it is possible to see the diff from post-first diff to post-second diff. 2. Given that #1 is not currently a feature, I am instructing all of my users to update review requests with changesets that are based on the same initial revision. This way, the reviewer can see what's new in the second revision, as well as the full second revision. I'm wondering whether it would be worth optionally enforcing this as a feature, or warning the user if the different revisions have different parents. My question #2 may be related to my other question at http://groups.google.com/group/reviewboard/browse_thread/thread/aefd7a770dca771a Thanks. -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.comreviewboard%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.comreviewboard%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: Multiple diffs in the same review request
Thanks Christian. That certainly addresses my question #1. I am using a DVCS (Mercurial). Let me restate and add to my #2: - would it be possible to warn the user and/or the reviewer if the parent of two diffs in the same review request are different? - would it be possible to show in the interface the diff's parent revision? Currently, it seems to show the parent diff's parent revision. - The user interface when there are multiple revisions of a diff is slightly unintuitive. For instance, see http://demo.reviewboard.org/r/1688/diff/4/ . It would be slightly more intuitive if the 4 in the Changes between r4 and line were deleted. As-is, the user interface seems to indicate that we are currently looking at Changes between r4 and 4, which is not what we are looking at (Changes between r4 and 4 would represent an empty diff). On Fri, May 7, 2010 at 5:49 PM, Christian Hammond chip...@chipx86.comwrote: Hi Andrew, Today, a single review request represents a single change represented by a single diff. Additional changes for a feature should be separate review requests. If you're using the diff functionality as intended, then any particular diff should be pre-first-diff to post-second diff, because each diff is based off a certain change. The diff revisions are not meant to be used as patches in a series. If you're working with a DVCS setup where you might have two changes, one requiring the other, then you can use post-review with the --parent option to generate a diff against a parent branch or change. This doesn't change the model above, though. The current model for review requests is not likely to change, with the exception being the newly drafted DVCS support. One of our Summer of Code students this year is working on improved DVCS support that would allow a review request to be able to have multiple diffs instead of a single diff that represents that change. The intent is still that a review request represents one logical change, but this one change may be broken up into separate smaller diffs instead of being one large diff, in order to ease review. This is still in the design phases, but the idea is that it could maybe go in for 1.6, if it's in a good state by then. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Fri, May 7, 2010 at 5:00 PM, Andrew aschwa...@gmail.com wrote: Hi guys. I've been playing with the multiple revisions support in ReviewBoard. I was wondering what people think about these two suggestions: 1. It would be nice to be able to compose changesets. For instance, if I have one changeset under review, it then gets reviewed, then I post a second changeset that is based on the first changeset, it would be neat to be able to see the diff from pre-first diff to post-second diff. I understand that currently, it is possible to see the diff from post-first diff to post-second diff. 2. Given that #1 is not currently a feature, I am instructing all of my users to update review requests with changesets that are based on the same initial revision. This way, the reviewer can see what's new in the second revision, as well as the full second revision. I'm wondering whether it would be worth optionally enforcing this as a feature, or warning the user if the different revisions have different parents. My question #2 may be related to my other question at http://groups.google.com/group/reviewboard/browse_thread/thread/aefd7a770dca771a Thanks. -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.comreviewboard%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.comreviewboard%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
