[Lazarus] Release schedule and policy

[Alexander Klenin]

On Mon, Oct 25, 2010 at 21:58, Marco van de Voort <marcov at stack.nl> wrote:
> On Mon, Oct 25, 2010 at 08:10:18PM +1100, Alexander Klenin wrote:
>> > What I haven't seen:
>> > - the problem
>>
>> Lazarus project is unable to do releases in a timely manner.
>
> Major or minor?

Neither.

>> > - the solution
>> Make a releases time-based, as suggested at the start of the thread.
> This has been discussed many times, and as current release manager of FPC
> I've tried to do this. (6 months).
>
> The problems are always that people only start moving when release building
> is already upon them. And then these people have no time, and then those.

This indicates a problem with the release process.
There should be no need for more than one person to do the release.
Much less in FPC, where, unlike Lazarus,
a more-or-less comprehensive regression testing should be possible.
(Yes, I am discussing "ideal world" here, but every modern
language/compiler does this, so clearly it is possible).

> Then other people are discussing GIT on the maillist instead of testing
> 2.4.2-rc1.
True, I will now go and test it some more ;-)

>> > which is the problem with all the GIT noise. Much throwing in gratituous
>> > principles, little practical implementation.
>>
>> While it is true that git may help, time-based releases can be practiced
>> using subversion too. All that is needed is to avoid Debian trap
>> of striving for unattainable goal of the "perfect" release.
>
> I hate the debian situation too, but there is a reason for this: both FPC
> and Debian are entirely volunteer driven efforts.

This may be the cause, but not the reason.

Another, maybe more relevant case study is a Perl project.
A couple of years ago it was in the position very similar
to the current FPC one:
outdated, unextensible code base,
fear of changes due to backwards compatibility burden,
glacial release process,
rapidly losing ground to competing languages,
even endless process-oriented flamewars
instead of technical discussions in the mailing list ;-)

Perl porters managed to overcome most of the problems
(except, of course, language competition)
and seriously invigorate Perl development by
1) Streamlining release process, so a single person
  can do a release in a single day.
2) Mandating time-based releases
3) Moving to a better SCM

It should be noted that FPC problems are worsened
by the lack of tests, while Perl's test suite is one of
the best among the language implementations.

-- 
Alexander S. Klenin