[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)

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.

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.


-------------- 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