httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: cvs commit: apachen STATUS
Date Fri, 09 Jan 1998 07:05:07 GMT
Rob Hartill wrote:
> 
> We've released very few major revisions to Apache.
> 
	:
>  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.

Agreed.

> Why is the frequency of releases so slow ?
> 
>  ..because we let it get that way.

Indeed.  See below.

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

At the end of the summer, Jim and I tried to put some teeth into the
release manager's position wrt dates, deadlines, and freezes, and were
hammered pretty furiously as I recall.  Not being anal about dates and
deadlines I can see as being a Good Thing, but freezes are something
else again.  I think we need an RM, and we need to empower the position
with some decisions-are-final abilities.  As Jim has pointed out, it's
currently a meaningless position with no authority and an excess of
grief.

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

There has been repeated discussion about renaming apache to apache-1.2 and
apachen to apache-1.3 (not necessarily those names), but months have passed
and nothing has happened.  What's required to make it happen?  The 1.2/1.3
branch was semi-goodness, I think, up until the massive divergence of the
directory structures - at which point it turned to a millstone.  (Or an
albatross.)

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

I'm in favour of experimenting, as I've expressed several times already
to-day.

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

We've had this discussion before, too.  If we could always have a stream
open into which features could be committed I think a lot of frustration
would evaporate.  Much of mine, anyway - I have another slew of things
I want to propose/develop/implement but can't because there's no open
stream for features.  I suspect others are frustrated by this, too.
And this is *before* the 2.0 rewrite.  A major problem is forward-porting
fixes from the frozen stream, but that's common to many software projects
(and I don't have a preferred solution).

> 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 too like the review-then-commit model, but I don't do much reviewing
because my current environment makes it a major pain.  I'd be able to
do more reviewing (and thus vote more often) if Jim's patches-in-CVS
proposal was implemented.  I can see from whence Dean is coming, though,
and I'd be willing to try commit-then-review - as long as there was a
clear understanding that it was experimental, and no noses would become
unjointed if it was determined that the experiment was a failure.

#ken	P-)}

Mime
View raw message