httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: cvs commit: apachen STATUS
Date Fri, 09 Jan 1998 02:04:04 GMT
On Fri, Jan 09, 1998 at 12:28:42AM +0000, Rob Hartill wrote:
> 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.

Nor I.

> Some personal thoughts.

Excellent feedback Rob.

> 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.

Doesn't public cvsup access solve that for some?

> Branching
>  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.

Agreed. This past branch has really strained the efforts of this group

> 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.

#ifdef'd code is a good suggestion for developing code. We've resisted
this for some reason but I strongly support doing this when possible.

> 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.

I would agree with this. I like the idea of review-then-commit because
it involves those who choose to be involved. I too have not been holding
up my end of that method though...

>  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).

I agree with all of this. IMO, 1.3 went to code freeze way to early.
Not enough has changed lately to hold me interest. I suspect Dean is
frustrated by some of the same issues.

>  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.

I'm agreeable to this change provided that the commiters are still
involving the group in discussion about design, etc.

> Now what?

I would like us to review the state of the NT port and itemize the
outstanding issues on this port. I'm prepared to spend more time on
this, but need to get a better picture of where we are at. Given the late 
stage of development that 1.3 is seeing, it would help to have a more
clear picture of when we could be comfortable enough with the NT port to
release before we turn anyone loose on adding many more changes into
the existing 1.3 tree.

> Are the ideas above worth voting on ?


View raw message