[petsc-dev] Long running development

[Jed Brown]

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').