httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: End of Life Policy
Date Sun, 21 Nov 2004 17:14:20 GMT
On Sat, 20 Nov 2004 13:11:16 -0700, Paul Querna <chip@force-elite.com> wrote:
> Jeff Trawick wrote:
> 
> 
> > On Sat, 20 Nov 2004 11:45:31 -0700, Paul Querna <chip@force-elite.com> wrote:
> >
> >>William A. Rowe, Jr. wrote:
> >>
> >>>If we simply leave 2.0 as no-features / critical bugfixes / security
> >>>bugfixes / any other nice patches someone wants to craft and get
> >>>votes for - that would be sufficient.
> >>
> >>That is how I would want to leave it.
> >>
> >>The problem is, this does not set *any* expectations for how long we
> >>will provide these fixes.
> >
> >
> > The PMC would have to be willing to specifically forbid maintenance of
> > 2.0 in order to determine such a date.
> 
> No, I do not want to make it forbidden.  Rather, I would like a set date
>  where we do not provide _any_ implied support as the HTTPd project.
> 
> If people continue back porting changes, thats great, but I would like a
> time line to help support our users.  It is not fair to them to leave
> the branch with an indeterminate status.

I have to plead continued confusion ;)

"people ... backporting changes" and then doing a release *is*
something done by the HTTPd project.

May I suggest that we ignore 2.0 stagnation/freeze/whatever as part of
plans for 2.2 adoption, and instead concentrate on positive aspects? 
There is a set of features which will entice early adopters; these
same early adopters will prove (painfully or not) that 2.2 is
production ready, and more and more folks will join the bandwagon as
modules become available and they see that 2.2 is where most developer
focus lies.

It is time to prominently advertise "What's coming with Apache httpd
2.2" on http://httpd.apache.org.  Besides new features, documentation
on some other items could aid support of 2.2:

* how to get involved with testing
* porting modules from 2.0 to 2.2
* supporting 2.0 and 2.2 in same module source
(many folks have no choice in the matter; let 'em know it is okay and
we still respect them)
* porting modules from 1.3 to 2.2
(this is an opportunity to do a better job helping folks move off of
1.3, but this time move them directly to 2.2)

Mime
View raw message