Barry Smith <[email protected]> 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.
pgpd0Iu2tdNRf.pgp
Description: PGP signature
