[vtk-developers] VTK code review / testing / integration workflow
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Mon Aug 25 13:24:31 EDT 2014
As I was reading this I tried to mull on why I don't like our current
gerrit to see if that'd help me figure out what my vote would be.
We want to adopt the same workflow for ParaView too, and I'm afraid
squashing all commits into a single commit just doesn't work the several of
changes which are core and critical to the evolution of the software. Thus
for my personal sake, squashing to a single commit is a non-starter.
For the most part, VTK-gerrit does everything I'd want it to do. All my
complaints are really user-interface related -- I'm sure everyone has run
into them so there's no point hashing those out here. I started looking
around for what other gerrit review users are doing and I was pleasantly
surprised, on the face. I see that most other gerrit pages look much nicer
and cleaner than ours.
e.g.
https://codereview.qt-project.org/#/q/status:open,n,z
https://review.openstack.org/#/q/status:open,n,z
http://review.couchbase.org/#/q/status:open,n,z
https://gwt-review.googlesource.com/#/q/status:open
As I understand, we're using a very old version of gerrit since we had to
add support for topic branches. Several of the UI issues do indeed stem
from interacting with topic branches. Looking for topic branches in gerrit,
I found this:
https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches
Looking at openstack gerrit, we do see support for topic branches too!
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z
The notable difference seems that you can't "review" a topic, you "review"
commits in a topic", but in essence that's what we do on VTK-gerrit too,
anyways.
Utkarsh
On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci <berk.geveci at kitware.com>
wrote:
> 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
>>
>
>
> _______________________________________________
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140825/4b6d9c8f/attachment-0002.html>
More information about the vtk-developers
mailing list