[petsc-dev] bitbucket pull requests
Balay, Satish
balay at mcs.anl.gov
Sat Sep 13 00:23:29 CDT 2014
Some additional thoughts.
WRT: bitbubket RFEs would be
1. Config to remove merge button and suggest a copy/pasteable git fetch cmd
2. Config to suggest only maint and master branches for pull requests.
And on our(integrator) side we create a better tractable branch name - perhaps:
Pull#-integrator/contributor/feature (or a better encoding)
Satish
________________________________
From: Balay, Satish<mailto:balay at mcs.anl.gov>
Sent: 9/13/2014 12:35 AM
To: Smith, Barry F.<mailto:bsmith at mcs.anl.gov>; For users of the development version of PETSc<mailto:petsc-dev at mcs.anl.gov>
Subject: RE: [petsc-dev] bitbucket pull requests
I don't consider (2) as an problem of pull request. The issues mentioned are artifacts of our current workflow.
The primarily difference between new feature by us vs by pull request is the way feature branch is created and populated.
By us:
git checkout -b branch; edit; git commit
Pull request:
git fetch URL branch
The remaining workflow is exactly same for both.
the tracking issues are primarily issues with workflow.
And the pull request contributors are required to know the workflow. I.e know when to create new branch off maint vs master - this in turn determines the pull request submitted for next vs master.
Again this is the artifact of the workflow.
We could decide not to burden contributions with understanding the workflow - and transfer the burden to integrators. I.e if a request is a new branch off master but it should go into maint - we (integrators) would do an appropriate rebase. (we would do something equivalent if the contribution came in as a patch file)
But so far we have been requiring contributors to know the workflow.
Satish
________________________________
From: Barry Smith<mailto:bsmith at mcs.anl.gov>
Sent: 9/12/2014 7:08 PM
To: For users of the development version of PETSc<mailto:petsc-dev at mcs.anl.gov>
Subject: [petsc-dev] bitbucket pull requests
The Bitbucket pull request system isn’t that great for our needs.
1) the damn Merge button
2) Users should always request merging to master or maint but the integrators need to first merge to next and then check the tests and then merge to master (and maint) several and there is not a good way of tracking that. It would be nice if each pull request tracked if it had been merged to next etc
BTW: people have done a good job in the last couple of days of cleaning up the pull requests but there is still some old stuff in there that needs cleaning.
Barry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140913/827bd3b4/attachment.html>
More information about the petsc-dev
mailing list