[gmx-developers] Proposal for sandbox branches

[Mark Abraham]

Hi,

After discussion with a few interested parties, we are proposing a broader
approach for helping get external code integrated in GROMACS.

New functionality will still be integrated into the GROMACS master branch
by constructing manageable patches that pass Jenkins and code review.
There's no magic fairies who will take a large pile of code from a
long-running development effort and effortlessly integrate it into master
:-)

Often people have developed a lot of code testing a new approach before
they reach the point where the broader developer community can agree that
integration and shared maintenance is a good idea. When they extract a
piece of that approach to propose for review, it is often tricky for
reviewers to see the big picture into which that proposal fits. The primary
way to solve that is for the proposing developers to document the intent
and implementation details on Redmine, at developer telcos, and/or
otherwise. Once integrated into master, the code will often be in a
different form than the proposing developers originally had, and their work
needs to be modified for the new context. Doing that for large rebases of
successive commits is quite time consuming.

We propose to permit feature branches in the gerrit git repository, to help
with the above issues.
* Those branches exist only to demonstrate a working prototype of the
functionality intended to be integrated.
* Such branches will only be made when there is already active interest
from developers willing to integrate and review. We won't make them for
code that doesn't yet exist, or for which there is no developer-reviewer
team with time and responsibility to integrate.
* There will be a point of contact responsible for the good order of each
such branch
* Those branches will never be merged into master, and their history is of
no interest. Those associated with the branch could choose to implement
support for Jenkins to build the code (and/or docs) in such a branch (for a
very small number of configurations), so that reviewers of patches proposed
for master branch can see the larger context.
* It is expected that Gerrit patch sets targeting such branches would go to
Gerrit in the usual way. Each branch can have its own lightweight policy
for who may push and when it can be submitted (Gerrit supports this).
However, we need any such changes to be integrated onto those branches (or
abandonded) extremely quickly (<24 hours). Gerrit will become unusable if
there is lots of code only of interest for sub-teams lying around at the
top of the "recent activity on open patches" lists. Gerrit itself does not
have support for visibility permissions on branches, etc. other than drafts.
* As code on master changes, and in particular as pieces of code from
branches are integrated into master, developers responsible for each branch
will likely wish to merge from master into those release branches, so that
preparation of the next set of code to propose will go smoothly.
* Those branches on gerrit will not be pushed to git.gromacs.org
repositories, or the main GROMACS mirror on GitHub. The place for forks is
an external repository.
* If a branch falls further behind master than about six months, then it
can be presumed to be an inactive fork and the maintainers of
infrastructure will be free to close the branch and anything that is
supporting it. "I hope to recruit someone to work on it" means it is
inactive.
* By default, nobody will look at anything in the feature branch. In
particular, its existence does not imply that people are obliged to help
integrate it. If we see that nobody is working on integrating one, we will
remove them.

So far we propose to name branches like "sandbox-nameoffeature" so that
alphabetical sorting of branch names will be useful. Examples of feature
branches we might have now are
* working prototype of gmxapi (e.g. sandbox-gmxapi)
* working prototype pure-GPU support implemented by NVIDIA (e.g
sandbox-puregpu)

Feedback is warmly invited, before I write up a more formal policy. Might
this work for your project? Is there something that we should consider
changing?

We are also going to propose some new code paths within mdrun, on master
branch, that will be controlled by feature flags such as environment
variables, but that is a topic for another day!

Mark Abraham
GROMACS development manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20190122/1702a337/attachment.html>