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

[Berk Geveci]

E-mail workflow (similar to Linux kernel):

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.


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

> 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/a28634ea/attachment-0002.html>