[syslog-ng] versioning and maintenance

[Balazs Scheidler]

On Mon, 2011-04-25 at 14:09 +0200, Gergely Nagy wrote:
> Balazs Scheidler <bazsi at 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