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
Sounds like a good plan to me Bazsi and makes perfect sense. I never understood why there were so many different versions and don't see how you supported all of those at once. On Fri, Apr 22, 2011 at 4:15 AM, Balazs Scheidler <bazsi@balabit.hu> wrote:
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
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html
On Sat, 2011-04-23 at 10:50 -0400, Fred Connolly wrote:
Sounds like a good plan to me Bazsi and makes perfect sense. I never understood why there were so many different versions and don't see how you supported all of those at once.
thanks. any other opinions?
On Fri, Apr 22, 2011 at 4:15 AM, Balazs Scheidler <bazsi@balabit.hu> wrote:
-- Bazsi
Balazs Scheidler <bazsi@balabit.hu> writes:
On Sat, 2011-04-23 at 10:50 -0400, Fred Connolly wrote:
Sounds like a good plan to me Bazsi and makes perfect sense. I never understood why there were so many different versions and don't see how you supported all of those at once.
thanks. any other opinions?
I'm on the same opinion as Fred, mostly at least. The one thing I'd ask about is the stable branches in the future. Stable branches are of course great and needed, but what would be the policy for getting code into stable? Bugfixes only, or would some minor/trivial features be allowed aswell? The main reason I ask this, is because if the syslog-ng team at Balabit will base their work on the stable branch, then wouldn't it be easier to delegate the stable branch's maintainance to them? (Or to the support team, since they'll be fixing stuff reported by Balabit clients anyway; backporting fixes from the devel branch to stable is - in my opinion - not that huge of an additional task, either.) That way, you could focus on development, and leave the boring maintainance to those who already do something similar. :) This only works though, if the stable branch is bugfix-only.
* 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.
(Imagine cute puppy eyes here:) Would it be possible to get the value-pairs() & afmongodb updates in before the feature freeze? O:) -- |8]
On Mon, 2011-04-25 at 14:09 +0200, Gergely Nagy wrote:
Balazs Scheidler <bazsi@balabit.hu> writes:
On Sat, 2011-04-23 at 10:50 -0400, Fred Connolly wrote:
Sounds like a good plan to me Bazsi and makes perfect sense. I never understood why there were so many different versions and don't see how you supported all of those at once.
thanks. any other opinions?
I'm on the same opinion as Fred, mostly at least.
The one thing I'd ask about is the stable branches in the future. Stable branches are of course great and needed, but what would be the policy for getting code into stable? Bugfixes only, or would some minor/trivial features be allowed aswell?
Bugfixes only. I've done minor/trivial features thing in the past, but all it does is that it stalls development: * first, there's no reason to open a new development branch, as small stuff gets integrated * but, then bigger scale changes are not included there, and sometimes languish, simply because a development branch is not opened for a single feature. * not to mention that even the small stuff causes breakage every now and then.
The main reason I ask this, is because if the syslog-ng team at Balabit will base their work on the stable branch, then wouldn't it be easier to delegate the stable branch's maintainance to them? (Or to the support team, since they'll be fixing stuff reported by Balabit clients anyway; backporting fixes from the devel branch to stable is - in my opinion - not that huge of an additional task, either.)
I wouldn't want to do this, syslog-ng Open Source Edition is an independent project, and the Premium Edition is based on that. It's easy to find conflicts of interest if the same set of guys are trying to work on both the OSE and the PE versions. That's why I try to remain an outsider for the BalaBit team, and do everything out in the open. Of course as you know, we're working with the team to make their work more public, but that's not always easy.
That way, you could focus on development, and leave the boring maintainance to those who already do something similar. :)
This only works though, if the stable branch is bugfix-only.
* 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.
(Imagine cute puppy eyes here:) Would it be possible to get the value-pairs() & afmongodb updates in before the feature freeze? O:)
I've started integrating value-pairs(). I started doing simple cosmetic things here & there, and I'm afraid I got into too large-scale changes. It all started with my desire to remove the dependency on GlobalConfig, so I blame that. I usually try to do much smaller changes to patches, and sorry if I spoil your joy. I'll post the patch if I have that ready, I still need to work some on the unit tests. -- Bazsi
Balazs Scheidler <bazsi@balabit.hu> writes:
On Mon, 2011-04-25 at 14:09 +0200, Gergely Nagy wrote: I wouldn't want to do this, syslog-ng Open Source Edition is an independent project, and the Premium Edition is based on that. It's easy to find conflicts of interest if the same set of guys are trying to work on both the OSE and the PE versions.
That's why I try to remain an outsider for the BalaBit team, and do everything out in the open.
Of course as you know, we're working with the team to make their work more public, but that's not always easy.
Aye, understandable. Was just an idea. :)
That way, you could focus on development, and leave the boring maintainance to those who already do something similar. :)
This only works though, if the stable branch is bugfix-only.
* 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.
(Imagine cute puppy eyes here:) Would it be possible to get the value-pairs() & afmongodb updates in before the feature freeze? O:)
I've started integrating value-pairs(). I started doing simple cosmetic things here & there, and I'm afraid I got into too large-scale changes. It all started with my desire to remove the dependency on GlobalConfig, so I blame that.
I'm curious what you've made out of it.
I usually try to do much smaller changes to patches, and sorry if I spoil your joy.
If a patch deserves to be rewritten, so be it. At least I could provide a base to build on! :) (The fun is in writing the stuff anyway, seeing it integrated in one form or the other is just the icing on the cake, but the cake's delicious even without that - so to say) -- |8]
On Mon, 2011-04-25 at 19:26 +0200, Gergely Nagy wrote:
Balazs Scheidler <bazsi@balabit.hu> writes:
On Mon, 2011-04-25 at 14:09 +0200, Gergely Nagy wrote: I wouldn't want to do this, syslog-ng Open Source Edition is an independent project, and the Premium Edition is based on that. It's easy to find conflicts of interest if the same set of guys are trying to work on both the OSE and the PE versions.
That's why I try to remain an outsider for the BalaBit team, and do everything out in the open.
Of course as you know, we're working with the team to make their work more public, but that's not always easy.
Aye, understandable. Was just an idea. :)
That way, you could focus on development, and leave the boring maintainance to those who already do something similar. :)
This only works though, if the stable branch is bugfix-only.
* 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.
(Imagine cute puppy eyes here:) Would it be possible to get the value-pairs() & afmongodb updates in before the feature freeze? O:)
I've started integrating value-pairs(). I started doing simple cosmetic things here & there, and I'm afraid I got into too large-scale changes. It all started with my desire to remove the dependency on GlobalConfig, so I blame that.
I'm curious what you've made out of it.
I usually try to do much smaller changes to patches, and sorry if I spoil your joy.
If a patch deserves to be rewritten, so be it. At least I could provide a base to build on! :)
(The fun is in writing the stuff anyway, seeing it integrated in one form or the other is just the icing on the cake, but the cake's delicious even without that - so to say)
Hi, Although I'd have liked if I have a little more time on the subject, but I have to leave now, and I'm not sure when I can work on this again. The latest incarnation of my patch is on git master. I wanted to describe what I've changed and why, but I'm already late. -- Bazsi
participants (3)
-
Balazs Scheidler
-
Fred Connolly
-
Gergely Nagy