[petsc-dev] testing before merging to master

[Barry Smith]

On Nov 24, 2013, at 2:47 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 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,

    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.

  Barry