On Sun, Nov 24, 2013 at 6:02 PM, Barry Smith <[email protected]> wrote:
> > On Nov 24, 2013, at 2:47 PM, Jed Brown <[email protected]> wrote: > > > 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, > > Hanging around in next is not going to make a test suite magically > become better!!!! So I would put that in the category of 1) the branch is > not done because part of its test suite is missing (note that the test > suite is suppose to be part of a complete branch). > > > or if a corresponding change for a dependent package > > (like petsc4py) is in the works, > > Again 1) the branch is not complete. > > >> > >> 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. > > Ok, let’s formalize this and you tell us how to automate finding the > “TODO” list for these branches: > > 1) What is the format of the “TODO” list? For example > “Todo-before-merge-to-master: ….” ? > > 2) What git command do I use to list all branches merged into next (but > not master) with todo lists and what is in each todo’s list? > > For example, I run gitmyaliasforfindingincompletebranchesinnext > and it produces > > barry/cool-new-newthing : todo - test suite that handles 5 > dimensional case > satish/a-feature : todo - provide options database options for > this feature > jed/c-feature : todo - use feature in SLEPc > > Now we have no way of tracking all this stuff and that is bad. I think we need a better automated way to notify people that checked in something that a build failed since there a bunch of builds to check. Can we get the branches merged since the last build and on any failure/warning we send the brnach owner an email? Matt > > Barry > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
