[vtk-developers] VTK code review / testing / integration workflow
Berk Geveci
berk.geveci at kitware.com
Mon Aug 25 10:53:53 EDT 2014
Bill, David: Can you provide some details on which parts of the Vanilla
Gerrit workflow you like? I'd like to understand if these are unique to the
Gerrit tool. As far as I can tell, things that are somewhat unique to this
workflow are:
1. Encouragement of very short branches, single changesets preferred,
2. Voting (although bitbucket has something like this too),
3. Assignment of multiple reviewers,
4. Keeping around all revisions of a changeset that were created during the
review for future audit (Github does not have this, not clear if others
have it)
Did I miss anything? Which of these are important to prefer Gerrit over
other tools?
Best,
-berk
-berk
On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:
> I prefer Vanilla Gerrit. I always liked single commits. And, ITK is
> using pretty much the vanilla workflow.
>
>
> On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
> > Hi David,
> >
> > From what I can tell, you can't even get the order of changesets in a
> topic
> > in vanilla Gerrit. You can search by a topic but that seems to be it for
> > topic support. Also, I don't think that there is any way of merging an
> > entire topic. That's changeset based too.
> >
> > So based on what I see, I disagree with " topics in vanilla gerrit really
> > aren't that bad" :-) If we were to use Gerrit, I think that we would
> have to
> > require that branches are squashed to 1 commit except unusual
> circumstances.
> >
> > So a clarification to what I meant by vanilla Gerrit workflow: for the
> most
> > part, the workflow would require branches of single or at most a few
> > commits. Longer running branches with 10s of commits would be a major
> pain
> > to manage in Gerrit and would probably require special handling.
> >
> > -berk
> >
> >
> > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>
> >> I'm all for sticking with gerrit. I'll be sad to lose the topic
> >> review interface, but topics in vanilla gerrit really aren't that bad.
> >> We'll still be able to push topics and we'll be able to see all the
> >> changes that make up a topic. I believe that what we lose is 1) the
> >> ability to do a topic-level review and 2) the ability to browse by
> >> topic.
> >>
> >> The only thing that annoys me with gerrit is that when you click
> >> "review", it hides all of the previous review comments until you're
> >> done. Hopefully the new gerrit has fixed this.
> >>
> >> The things I'd like to see in a code review system are:
> >>
> >> - Tight integration with the bugtracker.
> >>
> >> - Some kind of incentive for reviewers, even if it's just gold stars
> >> or a "top reviewer" list.
> >>
> >> Or we could be draconian and enforce a review/submit ratio, just like
> >> the old BBS's enforced upload/download ratios.
> >>
> >> - David
> >
> >
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >
> >
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140825/2e1b5bce/attachment-0002.html>
More information about the vtk-developers
mailing list