[petsc-dev] Long running development

[Matthew Knepley]

On Sat, Mar 16, 2013 at 9:16 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Matthew Knepley <knepley at gmail.com> writes:
>
> > I think the model of long-running development, which is also the model
> > being used by the integrator (Jed) to master, is not suitable for a
> > community nor scalable.
>
> Any of us can integrate.
>
> > I am developing in knepley/pylith, which is the branch I tell PyLith
> people
> > to look at. I know I need to keep up-to-date with other changes because I
> > eventually want to get into the release, and don't want one big hairy
> > merge. However, I can't merge with 'next' because that stuff is not going
> > in the release. The current model says that I know about what everyone
> else
> > is doing in all other branches, and pull those branches which interact
> with
> > my changes in. That is a huge load on an individual developer, and
> > impossible to know everything that will matter. And how will I know which
> > of these is going to make it master?
>
> Why do you want to depend on all that stuff? If a topic is not in
> 'master' yet, then by definition, we're not confident that it is (a)
> complete enough to be useful and (b) stable and portable.
>
> You will find out about any potential conflicts when you merge your work
> into 'next'. It is not helpful to make your topic depend on theirs just
> to find out if it conflicts.
>
> > This is exactly how merges to master will also happen. Someone with
> control
> > issues will find every branch that should be merged in and will do that.
> It
> > sounds totally unscalable, and would fall apart if that person is not
> > there. Linus likes making himself indispensible. This sounds like that.
>
> Anyone can integrate, typically either the author of a branch or the
> reviewer of a pull request. The branching model does not imply hierarchy
> of _people_, just that branches have distinct purposes.
>
> 'next': test and disseminate in-progress stuff to interested users and
>     see how topics interact
>
> 'master': starting point for new features, integration point for
>     releases, and stable combination of recently-completed features
>
> topic branches:
>     fix bugs and develop new features to a point that is stable enough
>     to graduate to 'master'
>
>
> The philosophy of not constantly merging other features into your branch
> is that you don't know what you're getting, and it needlessly makes your
> topic depend on theirs (you can't graduate until they do).
>
> In our old model, with constant merging/rebasing to a single shared
> branch, everything depended on everything else *by default*. That is
> fundamentally non-scalable, made development hard to follow, and
> explained the relative instability of petsc-dev. With topic branches,
> your topic depends on *nothing else* by default, but is still tested in
> combination with everything else (by merging to 'next').
>

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

I did not have this problem with the old PETSc model. I could just pull
petsc-dev
and be alright.

   Matt

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130316/aca6d501/attachment.html>