[Trilinos-Users] [EXTERNAL] Re: Patch submission process

Bartlett, Roscoe A rabartl at sandia.gov
Mon Aug 29 11:51:56 EDT 2016


All,

The problem with the standard GitHub PR model is that if you rebase the commits onto the 'develop' branch, then there is nothing remaining to link the commits to the PR conversation.  That is, there is no "tracability" of code changes to requirements:

   https://github.com/trilinos/Trilinos/wiki/Productivity-Initiative

Therefore, what we are considering is a recommended workflow that has the steps:

1. Create GitHub Issue (communicate about the requirements and design)
2. Create Pull-Request against 'develop' (each commit references the GitHub Issue ID)
3. Perform Code Review (perhaps adding new commits to address issues)
4. Accept Pull-Request (merge/rebase and push the branch to 'devleop')

That way, when/if the commits get rebased and pushed (without an explicit merge commit), then you can trace each of the commits back to the GitHub Issue ID.

Anyone have an objection to this workflow?

Cheers,

-Ross

> -----Original Message-----
> From: Trilinos-Users [mailto:trilinos-users-bounces at trilinos.org] On Behalf Of
> Nate Roberts
> Sent: Friday, August 26, 2016 2:57 PM
> To: <trilinos-users at trilinos.org>; Carlos Reyes
> Subject: [EXTERNAL] Re: [Trilinos-Users] Patch submission process
> 
> Thanks, Carlos.  That was quite helpful.  I've now issued my first two pull
> requests.
> 
> For anyone else who might be new to this, here was my process:
> 1. Create my own fork of Trilinos in GitHub.
> 2. Create a new branch within the fork, corresponding to a single pull request.
> 3. Apply changes.
> 4. Create a pull request (using "compare across forks"), with the official Trilinos
> repo as base, and my fork as head.
> 
> I submitted to Trilinos's "master" branch, but I think the better thing would have
> been to submit to "develop," based on Denis Ridzal's comment on one of the
> pull requests.  (I may end up closing and recreating to submit to develop.)
> 
> Best regards,
> Nate
> 
> > On Aug 26, 2016, at 11:21 AM, Carlos Reyes <carlos at stellarscience.com>
> wrote:
> >
> > The standard method on GitHub to submit patches to a project is by using a
> pull request. General documentation on the subject can be found here:
> >
> > https://help.github.com/categories/collaborating-on-projects-using-issues-
> and-pull-requests/
> >
> > You can find a list of the pull requests for Trilinos awaiting processing here:
> >
> > https://github.com/trilinos/Trilinos/pulls
> >
> > Individual projects often have an additional set of requirements before they
> will consider incorporating the code patches contained in a pull request. I did not
> see a specific set of guidelines for Trilinos, but it won't hurt to familiarize
> yourself with the project policies:
> >
> > https://github.com/trilinos/Trilinos/wiki/POLICIES
> >
> > Carlos Reyes
> > 1-505-206-1569 (mobile)
> >
> > On 08/25/2016 10:07 AM, Roberts, Nathan V. wrote:
> >> Hello all,
> >>
> >> Before the transition to the GitHub repo, there was a documented process
> for submitting patches.  A couple patches I submitted this way seem to have
> gotten lost in the transition.  So, I'd like to resubmit these, as well as a couple
> new ones.
> >>
> >> Is the process for submitting patches to the GitHub repo documented
> somewhere?
> >>
> >> Thanks,
> >> Nate
> >> _______________________________________________
> >> Trilinos-Users mailing list
> >> Trilinos-Users at trilinos.org
> >> https://trilinos.org/mailman/listinfo/trilinos-users
> >
> >
> > _______________________________________________
> > Trilinos-Users mailing list
> > Trilinos-Users at trilinos.org
> > https://trilinos.org/mailman/listinfo/trilinos-users
> 
> _______________________________________________
> Trilinos-Users mailing list
> Trilinos-Users at trilinos.org
> https://trilinos.org/mailman/listinfo/trilinos-users


More information about the Trilinos-Users mailing list