[Trilinos-Users] [EXTERNAL] Re: Patch submission process
csiefer at sandia.gov
Mon Aug 29 12:14:35 EDT 2016
If you're intending this to be more than just as a recommended practice for non-developer submissions, then this is something that should be discussed
at TUG on developer day before adoption.
From: Bartlett, Roscoe A
Sent: Monday, August 29, 2016 10:06 AM
To: Siefert, Christopher; Nate Roberts; <trilinos-users at trilinos.org>; Carlos Reyes
Subject: RE: [Trilinos-Users] [EXTERNAL] Re: Patch submission process
> What exactly do you intend this workflow for? Is this for code submitted by
> people who are not Trilinos developers?
I think that you can argue, for higher maturity software in Trilinos, that nearly every non-trivial change should have a GitHub Issue ticket for every major feature you are adding (or bug you are fixing) and the commit messages should reference that GitHub Issue ID. I think that is central to the idea of "tractability":
Otherwise, how can you trace code changes back to requirements?
This would be true for core Trilinos developers with direct push access to 'develop' as well. The PR should be used to conduct a code review. But if you are not going to be doing a code review, then you don't need the PR if you can directly push to 'develop'. In that case, if you do a post-push-to-'develop' code review, you can conduct that directly in the GitHub Issue ticket.
But for external collaborators who don't have direct push access to 'develop', they have to go through a PR (but I would like to see that some users/collaborators could directly push new temp branches to the main repo to simplify updates to the branch in a more collaborative way).
Does that make sense?
Trilinos Users and Collaborators,
Does this seem reasonable?
> From: Trilinos-Users <trilinos-users-bounces at trilinos.org> on behalf of Bartlett,
> Roscoe A <rabartl at sandia.gov>
> Sent: Monday, August 29, 2016 9:51 AM
> To: Nate Roberts; <trilinos-users at trilinos.org>; Carlos Reyes
> Subject: Re: [Trilinos-Users] [EXTERNAL] Re: Patch submission process
> 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:
> Therefore, what we are considering is a recommended workflow that has the
> 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?
> > -----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-i
> > > ssues-
> > 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
> Trilinos-Users mailing list
> Trilinos-Users at trilinos.org
More information about the Trilinos-Users