httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: cvs commit: apachen STATUS
Date Fri, 09 Jan 1998 00:28:42 GMT
On Thu, 8 Jan 1998, Jim Jagielski wrote:

> Funny, but this all started because I recall SOMEBODY saying,
> when we started putting STATUS in CVS, that maybe putting the
> actual patches there as well might make things easier. Was it
> Randy? Rob?

wasn't me.

Some personal thoughts.

We've released very few major revisions to Apache.

 For some people that's just fine because the product we released
 12 months ago is still pretty damn good and if you're not trying
 to do anything too fancy then an old server is good enough for
 years to come. We serve these people well.

 Other people are constantly pushing things to the limit, need new
 features, ever faster code, conformance to newer specs etc. Unless
 these people are willing to jump into the development tree they
 are stuck waiting for the next stable release. I don't think we're
 serving these people as well as we could.

 Shortening the time between releases helps the latter class of folks
 while the former class aren't affected - they can dip into Apache as
 and when they're ready to upgrade.

Why is the frequency of releases so slow ?

 ..because we let it get that way.

 I bet almost everyone here on new-httpd dips into the source tree far
 more often than the release frequency. We do that to take advantage of
 new feature and fixes. Everyone outside of new-httpd remain blissfully
 unaware of when they could update their server for optimal timing.

The release frequency needs to be improved

 I think everyone who writes on this subject moans that we're too slow, we
 let too many things sidetrack and delay a release. We've discussed this
 issue in the past. Whatever it was that was decided (I can't remember) it
 either got ignored or wasn't feasible.


 We currently have a 1.2 and a 1.3 branch. For me, 1.2 is only needed
 because of failures in the way 1.3 has developed. Watching people work
 on 1.3 and ocassionally on 1.2, my opinion is that the 1.2 work has been
 effort wasted - not a criticism of the work or those who did it but ideally
 1.2 should be dead and unsupported by now.

 In the past there's been talk of a 2.0 and a 1.x branch. Also a 1.4 and
 1.3 being developed concurrently. I've supported a branch in the past
 but no longer think it can work.

What system can work ?

 Who knows until we experiment and find out. My gut feeling at the moment
 is that we should change to a time based release schedule.. keep the
 cvs repository rolling with changes and periodically roll the contents
 (if they are stable) into a public release.

 1.3 is taking an age to finalise because we know it's going to be on the
 shelf for months. If instead we knew the sell-by-date for 1.3 was say 2
 months then there'd be less paranoia and we wouldn't be so anal about
 resolving every last bug and issue before rolling the tarball. If NT
 wasn't 100% ready then too bad, NT users are told to wait 2 months and
 hope the next release is ok.

 Radical changes to the code can go in with #ifdef's until they prove
 stable. A radical change should not interrupt a release if it's clear
 that it won't be "ready" in time for a release.

Using cvs

 There are good arguments on both sides of the review-then-commit and
 commit-then-review debate. Clearly there has to be a compromise or the
 flames will never die down. I prefer the idea of review-then-commit
 but if I'm not doing any/much reviewing then I've no right to say we
 should keep it.

 Many of us have lost interest in the review process. I've never stopped
 to wonder why that is. Now's a good time to think about it. I've stopped
 reviewing changes for a number of reasons; I'm too busy with other stuff,
 I trust the committers and other reviewers enough these days not to
 be too concerned with what's going in, and also a lot of the inner workings
 of Apache are beyond me these days - you have to keep your mind fresh on
 this stuff because it's easy to forget how things did work let alone
 how they work now. I glance at the commit log messages at most these days.
 In recent months I've done very little testing - something I can and
 will do IF THERE'S SOMETHING INTERESTING (to me) TO TEST...  These days
 I only find those changes happening over on the mod_perl list. mod_perl
 is fluid while these days Apache is very static (for me).

 At the moment I think the people doing the bulk of the committing appear
 very aware of what the others are committing. I've seen enough cases of
 hard to spot typos being pointed out within hours of a commit. Now you
 might all be excellent at parsing code without absorbing the overall
 need for changes, but I doubt it, so I have confidence that *currently*
 the commit-then-review approach is working and can work. For that reason
 I'd be happy to flip from review-then-commit to commit-then-review if
 we can experiment with a time based release schedule. Changing the review
 policy without addressing the release schedule problem won't work IMO. It
 would result in more and more people losing interest because the deadlines
 are too far away.

Now what?

Are the ideas above worth voting on ?


 Dean mentioned the apache-core mailing list. The intention was to
 work out how to incorporate Apache to protect the group's interests.
 While most if not all think it's a good idea there's severe apathy
 towards resolving the issues involved in proceeding with a non-profit
 incorporation. The same apathy meant that the mailing list was never
 announced. The list has been taken over now by sensitive security issue
 discussions. If anyone feels left out for not being on that list,
 believe me, you've missed nothing.

Rob Hartill                              Internet Movie Database (Ltd)   .. a site for sore eyes.

View raw message