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

[Andrew Maclean]

Hi Berk,

After giving this a bit of thought I would prefer
the Github/Bitbucket/Gitlab style of workflow.

To me the key requirements for a review/testing/integration system are:

A) The system itself:
- 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.
- The enterprise (Kitware) should be able set up and host on its own
internal sites.
- Integration of bug/issue reporting would be nice. Currently the Mantis
system is completely separate.
- Branch level access control is essential e.g the VTK Master 6.x and the
older VTK 5.10 branch.
- 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.
- Users: Users should be validated - personally I don't see anything wrong
with users providing their real name.
- 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.

B) Reviewing and merging code:
- Code definitely needs to be verified by something like cdash at home.
- Merges to the master (or a particular branch) only be done after review.
- Merges be done by small number of designated personnel that have these
rights.
- Audit trails are  essential.

C) Conclusion
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.

With respect to the other two workflows:
The vanilla gerrit: possibly too complex for the casual user and is missing
a nice web interface and bug reporting system.
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.

Regards
   Andrew



> ---------- Forwarded message ----------
> From: Berk Geveci <berk.geveci at kitware.com>
> To: VTK Developers <vtk-developers at vtk.org>
> Cc:
> Date: Sat, 23 Aug 2014 20:13:27 -0400
> Subject: Re: [vtk-developers] VTK code review / testing / integration
> workflow
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140825/5baf6bec/attachment-0002.html>