httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r.pl...@t-online.de
Subject Re: Thoughts on Future Versions/Backporting
Date Sun, 21 Aug 2005 12:08:03 GMT


Paul Querna wrote:

[..cut..]

> 
> This also means that most "new features" would wait for the "next
> stable" version to be released.  If the "next stable" isn't a 3 year
> cycle like 2.0->2.2, I believe this could be acceptable.
> 
> I believe that we should have more stable branches, more often.  I
> believe that we should try to only backport bugfixes and security issues
> to these branches, and attempt to avoid adding many new features.
> 

In general I agree that we should have more stable branches, more often, but
regarding the timeline of this more often I think we should consider the following
things:

1. I think a notable number of users uses Apache in conjunction with 3rd party modules
   (whether commercial or not). And a new branch does not guarantee API stability.
   This means that more or less big changes are needed to these 3rd party modules.
   Furthermore it will take some time until these new versions are tested and stable again.
   Especially for the commercial 3rd party modules we are currently in the situation
   that vendors tend to say that they support everything from 2.0.Y onwards because the
   API remains stable. If we branch too often I think commercial vendors are likely to skip
   branches in their support, because they regard the user base for this branch as too
   small compared to their efforts in adjusting and testing their module. I would like
   to avoid this.

2. I think one important thing is that we keep on supporting the branches with bug and
   security fixes. I know no one promised to do this, but it is currently done for 1.3 and
2.0
   and users are used to it. If we branch more often, there are more branches to maintain
   and thus more backports to do, even if we reduce the scope of backports as Paul
   suggested. Well someone could say this is no problem, because if someone is interested
in
   a backport this person should just write it and sent it to the dev list to get the votes.
   This is true. But the more backport work is needed the more load we put on the people with
   binding votes to review these patches, because the stable branches are RTC (as Paul I
   don't intend to start a CTR / RTC war again).

Apart from finding a good balance from branching more often and but not too often I could
see
the following approaches to ease 1. / 2.:

1. Maybe we could group the API in different areas and could say: Ok the new branch changes
   group A and B of the API but group C remains stable. That would ease things for third party
   module authors. Ok, I know the tricky thing is to find a good grouping for the API, because
   on the other hand people could say we already have that because each API function is its
own
   group and just look to the CHANGES file to find out. But I think it might be possible to
make
   this easier to find out for third party module authors.

2. It may make sense to give additional people binding votes on specific stable branches.
Thus
   we might be able to reduce the load on the PMC members. Of course I think there should
be
   some rules that these new binding voters should obey like that the API must remain stable
   and so on.


Comments/Thoughts?

Regards

RĂ¼diger

Mime
View raw message