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
