[petsc-dev] 'master' RESET after bad merge! - 'tisaac/thplex' was based on 'next'

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

> On Thu, 4 Sep 2014, Jed Brown wrote:
>
>> We have way bigger problems if people are skipping (1).  Branches need
>> to be reviewed before merging.
>
> This reminds me - is there a way to disable 'merge' button on the pull
> request page? That basically skips the whole workflow..

Not really, but GitHub suggests using their API to run a "test server"
that advises against clicking the merge button.

> My view is - pull request workflow is same as feature-branch workflow
> with one of the itegrators takes ownership for it. [how does one take
> ownership?]
>
> - create a local branch for the pull request.
> - merge it to next for testing
> - when satisfied - merge to master [or maint - whichever is appropriate]
>
> The 'merge' button on the pull request looks attractive.
> - lets us skips creating a local branch for it
> - lets us skip merging locally and rely on merging remotely.
>
> But this skips the whole workflow of testing.. Yeah some of
> us are recommeding a pull request to 'next' - but I think thats
> still broken. [it shortcuts the merge to next - but one still
> has to create a local branch to merge to master].
>
> And I suspect this is seen as encouraging feature branchs should start
> off next..
>
> So I think its best to remove the 'merge' button [if we can]. And
> never use it. And not recommend pull request to 'next'. They should
> only be to 'master' or 'maint' [bitbucket should not even offer any
> other branch for a pull request..]

Sounds fine to me, but bitbucket doesn't offer such fine-grained policy
enforcement.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140904/8fd64510/attachment.sig>