httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Release procedures was Re: Interesting Apache 2.0 project...
Date Wed, 13 Feb 2002 17:04:21 GMT
On Wed, Feb 13, 2002 at 11:32:46AM -0500, Padwa, Daniel wrote:
> > It could be a chicken-and-egg problem.  If the developers of those tools
> don't have a
> > lot of users asking for Apache 2.0 support, what is their motivation for
> providing it?  > They are probably like us, with lots of other things on
> their to-do lists.  If we had a > golden release, perhaps that would help
> change the situation.
> Really not trying to throw out flamebait, but.......
> I think Greg hit the nail on the head here.    There hasn't been much
> visibility to anyone not following this list (or even to many following it)
> of a timeline or roadmap to gold on 2.0.   Do people know that all the major
> interfaces are stable?    Are they?

Nope.  We can only know that the major interfaces are stable by
receiving feedback.  Seeing how the input filters worked dictated
(in my mind) that we needed to change that interface.  However, I'm
hopeful that we won't encounter anything in the future.  As we get
more developer feedback, we can tweak the APIs.  However, once
we've decided on a GA release, our APIs should be fairly consistent.

> Is there yet a consensus on a timetable for getting this to gold, or is it
> still a "when it is ready" approach?   If the latter, it's going to be hard
> to get people very excited about even kicking the tires on the betas.

Well, true.  My emphasis is switching from development to getting
this to GA quality.  I'm probably not going to be adding new features
at this point.  Each developer will have to make that call on their
own.  My goal is now to see a stable GA-quality release hit rather
soon.  Personally, I've been using Apache 2.0 for my own websites
for a few months and haven't encountered any major issues.

> It's going to be really hard to build momentum towards a release without a
> release target and active release management.  According to the latest
> STATUS, we've had only one tag/roll event (2.0.31) in the last three months.

I believe .30 would have gone beta except for the fact that we
ran into a problem running it on daedalus.  .31 got hit by some
input filtering problems and Win32's brokenness.  And, .32 is far
better than .28 is.

> It's also confusing to customers when at least two vendors are distributing
> Web servers that are "based on 2.0" when 2.0 is still not fully baked.

Heh.  You're not the only one who finds it amusing that commercial
companies are distributing products based on something that we often
have trouble calling beta.  I blame it on the fact that we have
higher standards when there is no money to make off of it.  =)

> Justin's work on coordinating the .32 release has been extremely positive in
> this regard (way to go Justin!).   A few more releases like this can
> probably get 2.0-gold out the door.  Without that kind of focus on and
> ownership of releases, it's going to be really hard to ship this thing.

Hopefully, .32 will go out.  We can then get constructive feedback on
what's wrong and then move forward.  .32 would have been out sooner if
Win32 wasn't borked.  I felt that it was definitely worth the wait for
a beta to have functional Win32 support.  That was my call - I know
that some people would have made a different call.  So, it goes.

> PS> A simple roadmap and timeline, like the one that Subversion has at
>, would go a very long way
> towards addressing these issues.

I suggested this a long time ago and got beaten down for it (I think
I referred to how Tomcat does it).  The majority of our developers
don't like the idea of enforcing timelines on a true group of
volunteers (those people who get paid are balanced out by the
different companies they work for).  SVN is a bit different because
the core contributors all work for the same company.  They have a
mandate from above to complete the task.  Over here, we're not that
structured where any one person has unquestioned pull over the group.

Our release procedures are like stabbing in the dark, but I can't
seriously come up with an alternative that works for our situtation.
The only thing I can do is take the RM responsibility and try to
shepherd a release out.  Hopefully, the rest of the group can keep
focused enough not to curtail my efforts.  -- justin

View raw message