[Lazarus] Release schedule and policy

[Marco van de Voort]

On Mon, Oct 25, 2010 at 11:28:20AM +0100, Lukasz Sokol wrote:
> > The whole point of the others is that the current setup already strains
> > resources, specially during release preparation times.
> 
> I.e you needed a volunteer to step up and propose himself to do this,
> and somebody did. (i.e. Juha, Vincent)

No, we would need heaps of volunteers. Since this only covers the release
prepations, but also a lot more builds need to be done by the respective
platform maintainers.

> Is the current workflow described somewhere detailed enough that comments can be made?

Currently there is a trunk where major development goes into. Committers
doing largescale development that could break trunk for long stretches do
this in private branches. These are then merged back to trunk (using SVN, or
manually, or by different means, e.g. by doing it in phases.)

Non-committers communicate via patches in the bugtracker, or more informal
means.

Before a major release, the trunk is branched to a fixes branch from which
releases are made (currently 2.4), and each release is branched from this
fixes branch.

Bugfixes and features are then merged back from trunk to the fixes branch.

In general most library features are merged, except the ones related to new
compiler features. Patches to compiler/ (whether fixes, features new targets
etc) are much more selectively merged. This is because these are more likely
to upset the "stable" aspect of the reulease branch.

Before a release there is always at least one release candidate. This is
mostly to flex the packaging muscles. In this stage usually many problems
are detected (like a new windows version getting popular and causing UAC
problems), and in general in this stage effectively release oriented
development is done and merged back. 

Usually the month after a release sees some release-engineering commits
(often more definitive solutions to quick fixes), and then the line goes
flat.  release engineering fixes are almost never externally supplied, and
are always done by core members and platform maintainers (then I define core
a bit loosely as everybody having commit access on the tree, including many
lazarus devels)

In the past doc building has been a bottleneck, but due to recent interest
in fpdoc, improvements in fcl-xml, and less trouble with the latex2html
conversions, this is not as bad as it used to be.

Often platform developers really only start test-building releases when the
final deadline for a RC is due. One can continue without the other then of
course, but one could wonder what good a release with only OS/2 and FreeBSD
(real life 2.4.2 example) would do.

This also demonstrates what is needed hardest to accelerate releases: 3rd
party involvement in release engineering. All resources are open to my
knowledge, and there is quite some info in the wiki, and more than enough
people willing to answer questions.

Interested users could start testbuilding releases, and keep release
engineering alive outside the typicaly release building intervals.

Specifically:
- building rpms (and testing them on both fedora and Suse (Mandriva?)). 
   Maybe even splitting rpm releasing from one general RPM to one per
   distro?
- same for .deb (debian ubuntu)
- windows installer (each release a few issues are wrinkled out, but it is 
   still far from perfect)
- doc building
- the integration of GDB into libgdb sometimes is a problem too, specially
   for the linux distros.

So the question can be short: do any of the people in this thread actually
tried to build a FPC or Lazarus release?