[petsc-dev] Long running development

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

> Okay, so that way I make sure that stuff is not breaking is always to merge
> into next.
>
> However, it  still appears that the model for publishing features has the
> costs
> above. Maybe I do not see how you want it to go. Here is my situation:
>
>   I have a knepley/pylith branch. I have this branch because I anticipate
> that
>   new things required by PyLith will not come out in 'master' fast
> enough.

What exactly is the purpose of 'knepley/pylith'? Is it to develop new
features specifically for PyLith or is it to certify some combination of
recent states that should work with PyLith? If it is to certify states,
then I suggest just having 'knepley/pylith' mark a snapshot of 'next'
that has been tested with PyLith. Your workflow would look like this:

  finish my feature
  (next) $ git pull         # get changes from upstream
  (next) $ git merge knepley/new-feature-for-pylith

run tests with PyLith, then

  (next) $ git push origin next next:knepley/pylith

That is, you're pushing your local branch 'next' (that you just tested)
to both 'next' and 'knepley/pylith'.

PyLith then follows 'knepley/pylith', which is just marking the state of
'next' the last time you tested it with PyLith. Since it's always
marking a point on 'next', it will fast-forward, so the PyLith user just
clones PETSc, then

  $ git checkout knepley/pylith

and from then on, they will get your latest tested state with

  (knepley/pylith) $ git pull


Note that in the above, your workflow is exactly the same as if PyLith
didn't exist, except that you add 'next:knepley/pylith' to pushes when
you want to certify that a state in 'next' works with PyLith.

Instead of 'knepley/pylith', you might call it 'next/pylith'.

> However,
>   all things in here should eventually go into master.
>
> If master was integrated frequently, I have no problem. I will just use
> that, but
> that was not my impression. The alternative seems to be to pull in each
> branch
> individually that went into 'next', and which we think will go to master.
> But what if
> I am wrong and merge something that does not go into master?

This would be a lot of work and would defeat the purpose.