[gmx-developers] Proposal for sandbox branches

[Mark Abraham]

Hi,

As you may have noticed if you pulled branches from gerrit.gromacs.org, I
have recently made a branch called sandbox-puregpu. As previously
described, we intend that to be a place for us to collaborate on code from
which we will stage functionality to master branch via gerrit patch sets in
the usual way. The branch just gives us a place to have a working prototype
available in the same repository, to create context for the review process.
It has a modified README file that sets out how to use the branch and
collaborate with it, so do check that out if you are interested.

As a shared branch, it won't be rebased, but updates to master branch will
come in periodically via merges. It will not merge into master branch, and
will eventually be removed when it has served its purpose.

Currently git.gromacs.org and gromacs.github.com mirror it. We don't intend
to do that in the long term. However we will need a version update to the
gitolite server for the former and a configuration change (+restart) of
gerrit for the latter before I can block the replication. I will do the
latter some time when gerrit isn't having its usual daily traffic!

Alan, please feel free to push as you see fit.

Several other projects are also interested in such branches - I'll make
those once we've ironed out the wrinkles, and made some docs so we don't
have single points of failure in administration time!

Mark

On Tue, 22 Jan 2019 at 11:02 Mark Abraham <mark.j.abraham at gmail.com> wrote:

> 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/20190313/5ab2e80d/attachment.html>