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:[email protected]> Sent: 9/12/2014 7:08 PM To: For users of the development version of PETSc<mailto:[email protected]> 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
