<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 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:0 0 0 .8ex;border-left:1px #ccc 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>