[Lazarus] Release schedule and policy

[Marco van de Voort]

On Mon, Oct 25, 2010 at 10:19:42PM +1100, Alexander Klenin wrote:
> >
> > 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.

No doubt. But I doubt random shuffling 

> There should be no need for more than one person to do the release.

So you have machines and installs for all platforms, contacts with
fedora,debian,fink, follow the Mac lists about new news etc?

Sure, centralizing it in one person makes for shortest communication lines,
but it is not a practical solution.

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

The testsuite is run  nightly for a decade or so?

> > 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 ;-)

Not purely a joke. Feedback has been on an alltime low.
 
> > 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.

I think so. The other main distros are hosted at companies with huge
buildclusters that have dedicated admins.

On the otherhand, when I do a major release, I have to dust of some machines
with older freebsds, sometime fix the hardware etc.
 
> Another, maybe more relevant case study is a Per 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

Do they actually _do_ releases, or do they only release an source archive?

Keep in mind that unlike many other projects, we need to do the _full_
release engineering. Distro maintainers are unlikely to dive into Pascal.