[petsc-dev] testing before merging to master

[Barry Smith]

   PETSc developers,

      The current nightly compile builds of both next and master are almost completely clean (master will be the same as next in tonight’s tests). This means it is easy to check if branches you recently added to next are clean and can be merged into master.  The log files can always be found in

http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/next.html   and  http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/master.html

 Remember the workflow is 

1) have a clean build and don’t break examples in your branch then

2) either 

    a) If the change is large and you want comments before putting into next make a pull request into next at the bitbucket.org/petsc/petsc site

    b) If the change is small or you are confident it satisfies all PETSc source code standards then merge into next

3) after the branch is merged into next, check the results of the nightly build the NEXT day and make sure your changes didn’t introduce any warnings or errors in any of the next builds. You should do this the day after the branch was merged into next so warnings/errors you may have introduced don’t get jumbled up with other peoples introduced warnings/errors, 

   a) if there are warnings/errors fix them in your branch and merge it again into next and go back to 3) otherwise 

   b) if you’re change is large or you feel it might violate some PETSc source code standards then post a pull request of the branch into master, otherwise
 
   c) merge your branch into master

4) check the nightly builds the next day and make sure you did not break anything in master, if you did fix the branch and merge it back into next and master


  The most important thing is to remember to ALWAYS check the nightly builds of next or master the day after you merged into the branch; if you did break something then fix the branch and remerge quickly. This is the only way to ensure your branch didn’t break some obscure thing on some odd machine. It is also the only way to make sure warnings/errors don’t accumulate in either next or master making it impossible to see if your new branch broke something since so much is already broken.

 Jed sent out this useful command to find all branches in next but not in master, I use it as 

alias gitmasternotupdated='comm -12 <(git branch -r --merged next | sort) <(git branch -r --no-merged master | sort) | grep barry’

so I can quickly see what branches are in next but not yet merged so I know I should check the nightly next tests.

  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. 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?


   Barry