[petsc-dev] testing before merging to master

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:
>   Jed and I may disagree on this but I believe that if your branch is 
>
> 1) done (that is would be useful for users)
>
> 2) is completely clean in next
>
> 3) satisfies PETSc coding standards 
>
> then it should be merged into master and not just “hang around” in
> next for days. 

My reservation is that if you are not confident about the test suite
being complete, or if a corresponding change for a dependent package
(like petsc4py) is in the works, it is nice to leave it in 'next' for a
bit longer.

> On the other hand if
>
> 1) standalone it is not yet useful for others since more has to written on it
>
> 2) it is not clean in next or
>
> 3) does not satisfy PETSc coding standards 
>
> 4) it has a bunch of ugly commits with changed codes or comments that should be rebased then
>
> it should not be moved over to master. 
>
> Jed, it would be nice if we could somehow mark each merge of a branch into next as either 
>
> 1) I just want this tested with everything but it is not ready for master or
> 2) this is ready for master if it tests clean in next 
>
> then anyone could easily keep track of the two types of merges and
> they could be handled properly without requiring someone to remember
> something. Is there anyway to do this?

How about if the person merging to 'next' pastes the TODO list for the
incomplete branch into the commit message.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131124/4d9e9ef2/attachment.sig>