<div dir="ltr">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.<div><br></div><div>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.<br>
</div><div><br></div><div>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.<div>
e.g.</div><div><br></div><div><a href="https://codereview.qt-project.org/#/q/status:open,n,z">https://codereview.qt-project.org/#/q/status:open,n,z</a><br></div><div><a href="https://review.openstack.org/#/q/status:open,n,z">https://review.openstack.org/#/q/status:open,n,z</a></div>
<div><a href="http://review.couchbase.org/#/q/status:open,n,z">http://review.couchbase.org/#/q/status:open,n,z</a><br></div><div><a href="https://gwt-review.googlesource.com/#/q/status:open">https://gwt-review.googlesource.com/#/q/status:open</a><br>
</div><div><br></div><div>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:</div>
<div><a href="https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches">https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches</a><br></div><div><br></div><div>Looking at openstack gerrit, we do see support for topic branches too!</div>
<div><br></div><div><a href="https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z">https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z</a><br>
</div><div><br></div><div>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.</div>
<div><br></div><div>Utkarsh</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<div>
<br></div><div>1. Encouragement of very short branches, single changesets preferred,</div><div>2. Voting (although bitbucket has something like this too),</div><div>3. Assignment of multiple reviewers,</div><div>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)</div>
<div><br></div><div>Did I miss anything? Which of these are important to prefer Gerrit over other tools?</div><div><br></div><div>Best,</div><div>-berk</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>
<br></div><div><br></div><div><br><div><br>
</div>
<div>-berk</div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I prefer Vanilla Gerrit. I always liked single commits. And, ITK is<br>
using pretty much the vanilla workflow.<br>
<div><div><br>
<br>
On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>> wrote:<br>
> Hi David,<br>
><br>
> From what I can tell, you can't even get the order of changesets in a topic<br>
> in vanilla Gerrit. You can search by a topic but that seems to be it for<br>
> topic support. Also, I don't think that there is any way of merging an<br>
> entire topic. That's changeset based too.<br>
><br>
> So based on what I see, I disagree with " topics in vanilla gerrit really<br>
> aren't that bad" :-) If we were to use Gerrit, I think that we would have to<br>
> require that branches are squashed to 1 commit except unusual circumstances.<br>
><br>
> So a clarification to what I meant by vanilla Gerrit workflow: for the most<br>
> part, the workflow would require branches of single or at most a few<br>
> commits. Longer running branches with 10s of commits would be a major pain<br>
> to manage in Gerrit and would probably require special handling.<br>
><br>
> -berk<br>
><br>
><br>
> On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>> wrote:<br>
>><br>
>> I'm all for sticking with gerrit. I'll be sad to lose the topic<br>
>> review interface, but topics in vanilla gerrit really aren't that bad.<br>
>> We'll still be able to push topics and we'll be able to see all the<br>
>> changes that make up a topic. I believe that what we lose is 1) the<br>
>> ability to do a topic-level review and 2) the ability to browse by<br>
>> topic.<br>
>><br>
>> The only thing that annoys me with gerrit is that when you click<br>
>> "review", it hides all of the previous review comments until you're<br>
>> done. Hopefully the new gerrit has fixed this.<br>
>><br>
>> The things I'd like to see in a code review system are:<br>
>><br>
>> - Tight integration with the bugtracker.<br>
>><br>
>> - Some kind of incentive for reviewers, even if it's just gold stars<br>
>> or a "top reviewer" list.<br>
>><br>
>> Or we could be draconian and enforce a review/submit ratio, just like<br>
>> the old BBS's enforced upload/download ratios.<br>
>><br>
>> - David<br>
><br>
><br>
><br>
</div></div><div><div>> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
Unpaid intern in BillsBasement at noware dot com<br>
</font></span></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
<br></blockquote></div><br></div>