[gmx-developers] submitting to gerrit

[Mark Abraham]

Hi Chris,

On Tue, Jul 17, 2018 at 10:08 PM Mirabzadeh, Christopher (
mira2978 at vandals.uidaho.edu) <mira2978 at vandals.uidaho.edu> wrote:

> I have a completed project that was tested and has been working since
> GROMACS 5.1.4. I cloned the newest repo from gerrit and would like to try
> an include my code in the next code release. I understand that my code will
> have to fit the changes since 5.1.4.
>

Great. We love getting contributions of useful and well written code :-)
Don't hesitate to drop into our fortnightly developer roundtable telcos.
I'd offer to set up a specific chat with you, but I'm shortly going on my
summer holidays! So perhaps others can carry on the discussion.

Question 1: Is it too late to include my code in the upcoming release? I
> remember getting an email from the group about the next release but got
> distracted by work and home and I may have missed the deadline.
>

No, it's not too late, but it very soon will be. Reviewable, tested code
will need to be in gerrit by early September if we're to integrate it along
with all the others things for GROMACS 2019. Do check out the advice in the
latest version of the developer guide at
http://jenkins.gromacs.org/job/Documentation_Nightly_master/javadoc/dev-manual/contribute.html.
We definitely need to hear some more details from you about what you
propose so we can see if it's feasible.


> Question 2: I have no idea how to use gerrit. I’m familiar with git, but
> gerrit looks foreign to me. In the write-up on gromacs.org, there is no
> mention of creating a local working branch and creating pull requests which
> is the workflow that I’m familiar with. Is that still the process with
> gerrit? Is there a workflow to follow that I missed? Further guidance would
> be appreciated.
>

We don't use a pull-request workflow. We haven't made a how-to for the
mechanics of contributing, but all proposed patches (even from regular
developers) are structured as a patch series based on the current HEAD of
the master branch, and after testing and review get rebased on the new HEAD
and get submitted. The history ends up linear. Working out how to organize
the code so it isn't an unmanageable lump of 20k lines can be a bit of
work. But we'd need to know more to have specific suggestions.


> Question 3: If I have completed code for review, that incorporates a new
> algorithm, does a publication have to be included? The context being, what
> is the process for explaining the algorithm to a reviewer?
>

That will go a fair way to helping the code review process go smoothly, but
do be aware that there will need to be other documentation for both users
and developers, plus tests so that we can continue to keep the code working
as we modernize the code base for future needs.

Mark

Cheers,
>
> -ChrisM
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20180719/3af0d2db/attachment.html>