<div dir="ltr"><span id="docs-internal-guid-c32a4879-17a5-96d5-8fc5-f380a5eb95bb"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Here is my two cents/pence, I apologize if I am rehashing already discussed topics, I am a little late to the party. In no particular order …</span></p>
<br><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">The development process should be enforced and supported by the review tool rather than people and documents. No one wants to be the  ‘enforcer’ and documents often go unread. </span></p>
</li><li dir="ltr" style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">GitHub/GitLab PR workflow works well with projects that have a ‘benevolent dictator’ and relatively small teams, I’m not sure it scales so well when you have a larger number of people with merge access where more coordination is necessary. </span></p>
</li><li dir="ltr" style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">As well as indicating approval, it is just as important to be able indicate that you don’t want something to be merged, for example a work in progress branch or you don’t agree with how something should be implemented. The likes of GitHub/GitLab tend to have an all or nothing approach here, if I have merge privileges I can merge any PR in the project and no one can stop me short of removing my privileges. </span></p>
</li><li dir="ltr" style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">In my opinion no one should have push access to master, all merging should be done automatically. My understanding with GitHub/GitLab is if you can merge in the UI you can push to master. I have been in projects where developers have push to master by mistake, it happens.</span></p>
</li><li dir="ltr" style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Long running topic with lots of commits should be the exception rather than the rule. Topics that have a lot of commits are hard to review, in my opinion these could be treated differently as the usefulness of the review tool breaks down here. For VTK the mean number of changes in a topic: 1.88 and the median number of changes in a topic: 1. This to me indicates that topic branch support is a nice to have rather than a necessity. </span></p>
</li><li dir="ltr" style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">I feel that as a part of the open source community we should be using open source tools where possible. So I would add being open source as a nice to have.</span></p>
</li><li dir="ltr" style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent"><span style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Finally I think supporting PR from GitHub is important, it's a familiar workflow for many developers. However, this doesn't mean that GitHub has to be our review tool. Integration is possible with other tools, for example Gerrit has a GitHub plugin. I have contributed to projects that use SVN through GitHub PRs :-)</span></li>
</ul><div><font color="#000000" face="Arial"><span style="font-size:15px;white-space:pre-wrap"><br></span></font></div><div><font color="#000000" face="Arial"><span style="font-size:15px;white-space:pre-wrap">Regards, </span></font></div>
<div><font color="#000000" face="Arial"><span style="font-size:15px;white-space:pre-wrap"><br></span></font></div><div><font color="#000000" face="Arial"><span style="font-size:15px;white-space:pre-wrap">Chris</span></font></div>
</span></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 4:25 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Berk,<br>
<br>
I think we need to reach out to potential developers. Especially those<br>
outside of Kitware(and their paying customers) and the long term VTK<br>
developers outside Kitware. Those communities can adapt to anything.<br>
We need to focus on is how can we can attract new developers. In the<br>
past, new processes were adopted and adapted by Kitware, their<br>
customers and hard core VTK developers with very little input from the<br>
broader community of potential developers.<br>
<br>
ITK is going through the same issues but addressing the issues not<br>
through process change. They are looking at outreach and better<br>
documentation of the current process. Matt McCormick at Kitware has<br>
been leading this effort.<br>
<br>
I think there are lots of non-process improvements possible. But I<br>
don't have a silver bullet for attracting new developers. Perhaps VTK<br>
is too old school for today's developers. Stuck with an old<br>
architecture, old graphics architecture, old and complex languages. I<br>
honestly don't know what the root causes are. If we only include the<br>
old-timers in theses discussion then we will not attract a younger set<br>
of devleopers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Bill<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Aug 26, 2014 at 4:09 PM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>> wrote:<br>
> I was addressing the first requirements list. Ease of use is subjective.<br>
><br>
> On Tue, Aug 26, 2014 at 4:04 PM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>> wrote:<br>
>> I disagree. Gerrit does not support any of the "nice to have"s in a<br>
>> straightforward way. Neither does vanilla Gerrit properly support "branch /<br>
>> topic based workflow" in a straightforward way. It supports a changeset<br>
>> based workflow and "branch / topic" based workflows have to be shoehorned<br>
>> into it if a "branch / topic" has more than 1 changeset. Also to support<br>
>> automated testing of branch tips, we would have to create custom scaffolding<br>
>> since vanilla Gerrit has no such concept.<br>
>><br>
>> Gerrit, with a little help from cdash @ home does a decent job of the<br>
>> following:<br>
>><br>
>> - Automated testing before merge (required to pass)<br>
>> - Assign reviewers to topic<br>
>> - Review / approval before merge (required to pass)<br>
>> - Ability to go back to discussion leading to merge (audit trail)<br>
>> - Automatic notification on change<br>
>> - Ability to comment on the code (Web GUI preferred)<br>
>><br>
>> It clearly doesn't do any of this:<br>
>><br>
>> - Tight integration with issue (bug) tracking and release process<br>
>> - Integration with Wiki<br>
>> - Easy documentation / Markdown /rST support<br>
>> - Easy way to generate single view of all changes in the Web GUI<br>
>><br>
>> In my opinion, it does a very poor job of these:<br>
>><br>
>> - Branch / topic based workflow<br>
>> - Ease of use<br>
>><br>
>> The other requirements and nice-to-haves are independent of tools and can be<br>
>> achieved using whatever tool. However, Mantis is also not the easiest tool<br>
>> so replacing it is also a good idea.<br>
>><br>
>> In my opinion, the biggest weaknesses of Github and Gitlab are:<br>
>><br>
>> - Assign reviewers to topic<br>
>> - Review / approval before merge (required to pass)<br>
>> - Ability to go back to discussion leading to merge (audit trail)<br>
>><br>
>> They don't have a clear voting system and are based on more a general<br>
>> discussion workflow. We would have to create some guidelines on how to<br>
>> achieve these in those tools. For example, someone doing a pull request<br>
>> would have to add a comment mentioning potential reviewers with the @name<br>
>> syntax to "assign reviewers". The reviewers would have to use some<br>
>> previously agreed upon language to approve a topic in the discussion.<br>
>> Something like "Approved for merge".<br>
>><br>
>> Github is far superior to Gerrit in these:<br>
>><br>
>> - Branch / topic based workflow<br>
>> - Automated testing before merge (required to pass) - tight integration with<br>
>> Travis and demonstrated integration with cdash @ home through custom hooks<br>
>> - Automatic notification on change - much finer notification control<br>
>> - Ability to comment on the code (Web GUI preferred) - go check it out if<br>
>> you don't believe me<br>
>> - Tight integration with issue (bug) tracking and release process<br>
>> - Ease of use<br>
>> - Integration with Wiki<br>
>> - Easy documentation / Markdown /rST support<br>
>> - Easy way to generate single view of all changes in the Web GUI - this is<br>
>> impossible in Gerrit even for a single changeset<br>
>><br>
>> Best,<br>
>> -berk<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> +1 and Gerrit seems to support them all.<br>
>>><br>
>>><br>
>>> On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>><br>
>>> wrote:<br>
>>> > Here is a summary that I came up with from the discussion so far. Does<br>
>>> > this<br>
>>> > look good?<br>
>>> ><br>
>>> > Requirements:<br>
>>> ><br>
>>> > - Branch / topic based workflow<br>
>>> > - Automated testing before merge (required to pass)<br>
>>> > - Assign reviewers to topic<br>
>>> > - Review / approval before merge (required to pass)<br>
>>> > - Ability to go back to discussion leading to merge (audit trail)<br>
>>> > - Automatic notification on change<br>
>>> > - Ability to comment on the code (Web GUI preferred)<br>
>>> > - All reported bugs should be assessed and assigned<br>
>>> ><br>
>>> > Nice to have:<br>
>>> ><br>
>>> > - Tight integration with issue (bug) tracking and release process<br>
>>> > - Stakeholders for particular pieces identified / in the loop / easy or<br>
>>> > automatic assignment of<br>
>>> > reviewers<br>
>>> > - Ease of use<br>
>>> > - Incentive for reviewers (goal being encouraging more reviews)<br>
>>> > - Integration with Wiki<br>
>>> > - Easy documentation / Markdown /rST support<br>
>>> > - Easy way to generate single view of all changes in the Web GUI<br>
>>> > - Lightweight proposal process for large changes<br>
>>> > - Way to track performance regression<br>
>>> ><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Unpaid intern in BillsBasement at noware dot com<br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Unpaid intern in BillsBasement at noware dot com<br>
<br>
<br>
<br>
--<br>
Unpaid intern in BillsBasement at noware dot com<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br></div>