[syslog-ng] versioning and maintenance

[Balazs Scheidler]

Hi,

First of all, sorry for being absent from this forum for the past couple
of weeks. I've tried to focus here too sometimes, but due to health
issues, I sometimes simply have too little time to do too much.

But anyway, I haven't stopped thinking about the way forward, and I've
thought I'd share my thoughts about those with you.

Please note that this is not an official announcement, but rather a way
to gather feedback on my plans. Everything can be changed, and after we
get to an agreement, an "official" announcement will be sent out on the
conclusions.

First of all, some status information:
======================================

* syslog-ng 3.0, 3.1 and 3.2 have all produced stable versions, and were
all maintained in parallel.

* syslog-ng 3.3 is in development, with the primary aim at scaling
syslog-ng to multiple CPUs. It has produced two alpha releases so far.

* syslog-ng team in BalaBit is busy merging the OSE and PE editions of
syslog-ng, in order to use a common core.

* the team is basing their work on OSE 3.3, which has been available as
two alpha releases and the git tree, also their tree is also published
as a git repository.

* while they were porting the PE functionality, they were also busy
porting the new core to new platforms and also of course fixing bugs,
they've found.

* I've been helping the team in case they've found something that
affected the open source edition as well.

Then some news about my future plans on syslog-ng versions:
===========================================================

* I feel that maintaining 3 releases while doing development of a 4th
one is too much for me.

* I originally planned to employ the same stable/feature release
structure that BalaBit's commercial products are using. There, a stable
release is maintained for a longer time (similar to Ubuntu LTS), while
incremental feature releases are published, with shorter support periods
(e.g. like normal Ubuntu releases).

* The stable/feature release breakdown would mean, that 3.0 is a long
term release, and 3.1 & 3.2 are short term releases.

* However, this doesn't match real-life expectations, distributions use
newer versions (and I really applaud this), but this also means that
dropping support for versions included in major Linux distributions
would cause disruptions.

* I'm really happy that distributions can move faster, and I'd really
like to speed up syslog-ng development. Instead of sticking to an old
release and stuffing in bugfixes and minor features; publish a major
release more often, so that features don't cause problems in stable
releases.

* Therefore, I plan to abandon the feature/stable release breakdown
altogether. One release will be the same as the other. I'm pledging
support for major releases as long as:
    - there's only one release to be maintained in parallel to the
      development tree.
    - I plan to support a given major release for about a year.

* This means, that syslog-ng support for OSE 3.0 & 3.1 will be
discontinued, in the not too distant future. I'm planning on a 3 month
period, in order to let people have time to prepare for the upgrade.
E.g. I'd like to announce that these versions are going to be supported
until 31th July, 2011.

* The definition of "support" is of course vague, I can't provide SLAs
or anything, but I'll do my best to help anyone who has issues with
those versions.

* Also, if a distribution which carries this version has an issue, I'll
try to help, even past that EOL date, but general questions and problems
found in those versions by users, will be advised to upgrade to a newer
release, or to backport a specific fix themselves.

Going forward:
==============

* I plan to announce a feature freeze for 3.3 and publish a beta
version. And at the same time open the 3.4 branch for integrating all
the stuff which has accumulated on the mailing list.

* Hopefully we can have a stable 3.3 by the time the previous two
releases hit their end-of-life in July.

What if you disagree:
=====================

* Until now, I didn't really publish "hard" EOL dates for syslog-ng OSE,
simply because there were not that many of the parallel branches.
However with the increase in development pace, I simply cannot keep up,
and I hate to do a substandard job. Backporting fixes to 3 branches, is
simply too much effort.

* I'm happy to help building up the proper infrastructure outside of
BalaBit if someone wants to help in maintenance, and release
engineering. But this requires real effort from members of the
community.

Now, having written this down, please give your feedback, and I'm trying
to work down my backlog and start integrating patches.

Thanks for listening.

-- 
Bazsi