[Lazarus] Release schedule and policy

[Marco van de Voort]

On Mon, Oct 25, 2010 at 09:42:47AM +0100, Lukasz Sokol wrote:
> > being able to put in a lot of time into the project on a regular, guaranteed
> > basis, which is hard if they are not at least partially fulltime.
> > 
> 
> I know the FULL Linux workflow won't fit - but what if it was scaled to our 
> needs and manpower ?
> 
> One production (stable) tree.
> One devel tree.

We already have that. (except when migrating from one stable to the next,
then there are a few more on paper, though usually the "old" stable branch
is then quite inert)

> Peoples' private trees where the maintainer(s) of devel tree can pull from.

I don't see that need. That puts only strain on the maintainer to keep track
of private trees. 

Currently there are private branches to do major development. I don't see a
reason to scale this up for all kinds of minor development, if this can be
communicated using a patch in mantis.

> Communication between developers to let each other know what each branch contains.

There is no reason for this, until we really start multiple levels of stable
branches. But even then, hardly any private branches come into the picture,
just people merging back features from the more liberal stable branch to the
more conservative stable branch.

The whole idea of private branches is that core does not need to know about
it, IOW delegation. When it is finished, people supply cleaned up patches in
mantis, and it doesn't matter if these patches come from a private repo, or
that sb ran DIFF of an old checkout with a new one.

> Regression fixes always applied to top of both trees.
> Top of devel tree periodically becomes merged to stable tree.

This is all that already happens today (and for about a decade). Since
mergetracking was initiated, it is a bit easier to keep track of patches to
merge  (http://www.stack.nl/~marcov/fpctomerge.txt is a list generated by
SVN of trunk patches not in fixes)

During release times, there is another branch/tag, of the upcoming release
that is likewise connected to fixes. (so merge order is
trunk->fixes->release)

> Juha's idea is actually exactly that if you read it carefully.

The whole point of the others is that the current setup already strains
resources, specially during release preparation times.

Maintaining any extra branches (e.g. splitting trunk into "more stable" and
"less stable") requires a management effort, which is why it is not done.
(and it could be perfectly done with SVN. It is the work and the management
that is the problem, not the tool)

Maybe I am misunderstanding the discussion, but that is because all these
proposals are very vague, rely on workflow of external projects, and the
people don't seem to have a clue about the current FPC/Lazarus workflow, and
where the bottlenecks are.