<div dir="ltr">I encourage everyone to think in terms of the workflow(s) that we prefer rather than tools. If we start with "can we live with vanilla gerrit", the answer is going to be yes for most people. However, this is only part of the picture. Some folks mentioned bug tracker integration, others support for rich content such as markdown etc. Integration with cdash @ home is an obvious one. These are good examples of what we want in workflows. Once we have a decent understanding of what people want the workflow to be, we can discuss tools more deeply.<div>
<br></div><div>So I am interpreting Utkarsh's email as "<span style="font-family:arial,sans-serif;font-size:13px">Thus for my personal sake, squashing to a single commit is a non-starter". And yes, we can manage multiple changeset topics in Gerrit. But we can also satisfy Utkarsh's workflow requirements using pretty much any other tool be it Github/Gitlab/Bitbucket or even mailing list.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">Since we have to migrate, let's use it as an opportunity and think about upgrading our overall workflow.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">-berk</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 1:24 PM, Utkarsh Ayachit <span dir="ltr"><<a href="mailto:utkarsh.ayachit@kitware.com" target="_blank">utkarsh.ayachit@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">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" target="_blank">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" target="_blank">https://review.openstack.org/#/q/status:open,n,z</a></div>
<div><a href="http://review.couchbase.org/#/q/status:open,n,z" target="_blank">http://review.couchbase.org/#/q/status:open,n,z</a><br></div><div><a href="https://gwt-review.googlesource.com/#/q/status:open" target="_blank">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" target="_blank">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" target="_blank">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>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Utkarsh</div><div><br></div><div><br></div></font></span></div></div><div class="HOEnZb"><div class="h5"><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><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><div><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>
</div></div></blockquote></div><br></div>