<div dir="ltr"><div>Hi Berk,</div><div><br></div>After giving this a bit of thought I would prefer the Github/Bitbucket/Gitlab style of workflow.<div><br></div><div>To me the key requirements for a review/testing/integration system are:<br>
</div><div><div><br></div><div>A) The system itself:</div><div>- A simple to use (and pretty) web interface that is relatively intuitive. Casual users shouldn't be daunted by the interface. We need their input to enhance the code base.</div>
<div>- The enterprise (Kitware) should be able set up and host on its own internal sites.</div><div>- Integration of bug/issue reporting would be nice. Currently the Mantis system is completely separate.</div><div>- Branch level access control is essential e.g the VTK Master 6.x and the older VTK 5.10 branch.</div>
<div>- Users: Granularity is essential e.g anyone can submit modifications but only a select few have rights to perform merges with the master or designated branches like VTK 6.1 etc. This is just the sandbox principle ... making sure that the code won't break the main release/development branches.</div>
<div>- Users: Users should be validated - personally I don't see anything wrong with users providing their real name.</div><div>- The system itself should be well maintained and responsive to requests for changes. In other words the review/testing/integration code base should be using its own system.</div>
<div><br></div><div>B) Reviewing and merging code:</div><div>- Code definitely needs to be verified by something like cdash@home.</div><div>- Merges to the master (or a particular branch) only be done after review.</div><div>
- Merges be done by small number of designated personnel that have these rights.</div><div>- Audit trails are essential.</div><div><br></div><div>C) Conclusion</div><div>So I guess I lean towards the Github/Bitbucket/Gitlab style of workflow with possibly Gitlab being able to fulfill all of these requirements (but I not an expert - I have only used Github and Bitbucket, and have just done some reading up on Gitlab). Another key reason to go this way is that a lot of our users in the medical, science and research fields are familiar with the web interface/usage paradigm and they are busy people. Having a web interface that is easy to use allows them to check in when they can and make modifying/adding code and bug submissions etc. easy for them.</div>
<div><br></div><div>With respect to the other two workflows:</div><div>The vanilla gerrit: possibly too complex for the casual user and is missing a nice web interface and bug reporting system.</div><div>The email workflow: whilst it works with the Linux kernel, we need the user to interact in their own time and place, hence the web interface is much better in this respect. I think you would also need a dedicated mailing list for this, which would reduce the usability for a lot of casual users.</div>
</div><div><br></div><div>Regards</div><div> Andrew</div><div><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>---------- Forwarded message ----------<br>From: Berk Geveci <<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>><br>To: VTK Developers <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>><br>
Cc: <br>Date: Sat, 23 Aug 2014 20:13:27 -0400<br>Subject: Re: [vtk-developers] VTK code review / testing / integration workflow<br><div dir="ltr">E-mail workflow (similar to Linux kernel):<div><br></div><div>In this workflow, discussions on commits/branches happen on the mailing list. This workflow could be augmented by Web tools such as Github and Gist. However, merge requests and discussions happen on the mailing list.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Aug 23, 2014 at 8:07 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Vanilla Gerrit workflow:<div><br></div><div>
This workflow is based on reviewing individual commits. Merging also happens at individual commit level. Discussions and voting happen per commit.</div>
<div><div><br></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">This workflow is almost entirely driven by a Web interface. Discussions happen almost entirely in the Web tool.</span><br></div></div></div><div>
<div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sat, Aug 23, 2014 at 8:04 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Github / Bitbucket / Gitlab style workflow:<div><br></div><div>This workflow is based on pull requests. A process through which anyone with an account can request a particular branch be merged to the original repository. There is usually support for discussion of individual pull requests and possibly support for approving of requests by community members (Bitbucket for example). This workflow supports branches with arbitrary numbers of commits. Diffs for the whole branch and individual commits are provided. The discussion usually happens around the diff of the whole branch.</div>
<div><br></div><div>This workflow is almost entirely driven by a Web interface. Discussions happen almost entirely in the Web tool.</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sat, Aug 23, 2014 at 7:58 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi folks,<div><br></div><div>It is time for us to look at our options to replace our current Gerrit instance (<a href="http://review.source.kitware.com" target="_blank">review.source.kitware.com</a>).</div>
<div><br></div><div>
Here is some background information: <a href="http://review.source.kitware.com" target="_blank">review.source.kitware.com</a> runs a fork of the Gerrit code base from quite a while ago. The main feature of the fork is the support for topics (branches). The original Gerrit only supports reviewing of individual commits (changes) and has no concept of branches. The lack of support for branches is an issue for us from both automated testing and review point of view. So we extended Gerrit to support branches. Alas, our changes have not been accepted upstream and we are not interested in putting more effort in maintaining the fork as Gerrit code advances. So we can not make use of new Gerrit features and more importantly security fixes. So it is time to move on.</div>
<div><br></div><div>I would like to start this process with a discussion of workflows (rather than tools). Let's first figure out one or more ideal (and reasonable) workflows. Then we can discuss tools to achieve these workflows and make a decision.</div>
<div><br></div><div>Here I'll list some requirements that I thought are important in no particular order:</div><div><br></div><div>- Maintain an open and "democratic" review process, a la Gerrit voting support.</div>
<div><br></div><div>- The workflow needs to be distributed and not require a single (or a few) maintainer to integrate code. A la our Gerrit's review and merge support.</div><div><br></div><div>- Workflow needs to scale with the community size.</div>
<div><br></div><div>- Support for cdash @ home style testing of code under review before integration.</div><div><br></div><div>- Support for arbitrary server side checks beyond cdash @ home before integration.</div><div>
<br>
</div><div>- Support for "audit trail". There needs to be way of getting to the original discussion and reviews that led to the acceptance of a particular branch.</div><div><br></div><div>I will follow up with a few initial workflow suggestions. Please send your workflow suggestions or requirements.</div>
<div><br></div><div>Best,</div><div>-berk</div><div><br></div><div><br></div><div><br></div><div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div><div class="gmail_extra"><br></div></div><div class="gmail_extra">-- <br>___________________________________________<br>Andrew J. P. Maclean<br><br>___________________________________________
</div></div></div>