<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 3, 2013 at 12:29 PM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">New developers are usually willing to adapt to the workflow of the project anyways, particularly if it follows established 'best practices'. 'Compile cleanly at high warning levels' is one of them, so we are not proposing something radically new.</blockquote>
</div><br>With the widespread adoption of DVCS and tools like github and bitbucket, the concept of contributing to a project without direct push access is now completely mainstream. We already (slightly) scaled back push access in favor of mailing list review and the quality of patches went way up.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">As core project members, organizing our own work to be more reviewable and so that pushes are more complete makes the project easier for people to contribute to without direct push access.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>Note that in many "dictatorships", all patches, even "obviously correct" ones written by the dictator go through the same branch and subsequent merge. It doesn't really take more time, but it makes the project more transparent and makes it easier to keep track of what is happening.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>A very good system from a review and opportunity-to-comment perspective is for urgent fixup patches to be committed directly on 'dev' (or 'release'), but to have all new features or refactors committed in a branch, with a pull request when they are ready, to be merged by the reviewer. This way, suggestions identified in review can be fixed up-front so that they are coherent in the history. It also means that any bug caught at that stage never affects users.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Kernel-style workflow merges those topic branches to a throw-away integration branch called 'pu' (proposed updates) so that all the interesting patches can be tested together and people developing other stuff can check whether their work conflicts with anything that anyone else is working on. When something passes review, it "graduates" to 'next' (more testers), and eventually to 'master' (which is supposed to always be "as stable as a release" and is what most people base their patches on).</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style><a href="http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html">http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html</a> (more detail)</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>The main downside of this workflow is not time required by skilled participants (your "productivity"), but the level of education/familiarity with tools to make it work. The advantage is that 'master' is very stable all the time, everything has a chance for review before becoming permanent history, it's very easy to tell what is being actively developed and to identify provenance for each feature.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Note that contributors don't need to know that much to contribute. They just base their patches on 'master', submit a pull request when they think it's ready, fix up as requested by the reviewer, and they'll see it in 'master'. It's much less intimidating to submit a pull request than to push to a shared repository, and it means that if something needs repairing, more than one person shares some part of the blame.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>I'm not saying that PETSc should adapt the full workflow described above, but I think we should at least recognize the benefits it provides and cherry-pick those aspects that can improve our quality, reviewability, etc. Organizing patches into coherent feature development with semantically meaningful merges is one step in that direction.</div>
</div>