[vtk-developers] VTK code review / testing / integration workflow

[Berk Geveci]

Vanilla Gerrit workflow:

This workflow is based on reviewing individual commits. Merging also
happens at individual commit level. Discussions and voting happen per
commit.

This workflow is almost entirely driven by a Web interface. Discussions
happen almost entirely in the Web tool.


On Sat, Aug 23, 2014 at 8:04 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Github / Bitbucket / Gitlab style workflow:
>
> 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.
>
> This workflow is almost entirely driven by a Web interface. Discussions
> happen almost entirely in the Web tool.
>
>
> On Sat, Aug 23, 2014 at 7:58 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Hi folks,
>>
>> It is time for us to look at our options to replace our current Gerrit
>> instance (review.source.kitware.com).
>>
>> Here is some background information: review.source.kitware.com 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.
>>
>> 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.
>>
>> Here I'll list some requirements that I thought are important in no
>> particular order:
>>
>> - Maintain an open and "democratic" review process, a la Gerrit voting
>> support.
>>
>> - 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.
>>
>> - Workflow needs to scale with the community size.
>>
>> - Support for cdash @ home style testing of code under review before
>> integration.
>>
>> - Support for arbitrary server side checks beyond cdash @ home before
>> integration.
>>
>> - 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.
>>
>> I will follow up with a few initial workflow suggestions. Please send
>> your workflow suggestions or requirements.
>>
>> Best,
>> -berk
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140823/3fbeba42/attachment-0002.html>