httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: Whither 1.3? Patches, feature freeze, etc...
Date Wed, 10 Sep 1997 18:07:38 GMT
I wouldn't have bothered writing the piped logs patch this week if I
didn't think it was going to be accepted.  I have permission from back in
August to get this one feature in after feature freeze.  I'm busy enough
as it is. 

I honestly think 2 betas would be a miracle.  We've had one NT test
release that perhaps 50 people actually were able to build and test.  As
far as I know nobody has really looked at NT security yet.  I won't
mention reliability 'cause I don't think that was one of the goals ... but
an insecure server is somewhat worse than no server.  Some of this won't
be resolved until we have binary releases in the hands of a lot of folks. 

After one beta cycle I'd be more happy with predictions as to the number
of betas we'll need.  Right now there's so many unknowns. 

What is holding up 1.3b1?  I've said many times that in my opinion it
could go out.  Is it just Alexei's -1 'cause of docs?  That's a pretty
lame reason imho, not very well quantified, and something for which we've
never waited for before.  Sure a final release should be delayed because
of lack of documentation, but to delay a much-needed beta ... 

Dean

On Wed, 10 Sep 1997, Jim Jagielski wrote:

> Dean Gaudet wrote:
> > 
> > My piped log patch can wait for 1.3b2.  My scoreboard fixes patch (fixes
> > bugs I introduced during the 1.3 alpha dev cycle) can also wait for 1.3b2
> > ... back a month ago I asked for an exception to get the piped logs thing
> > in after the freeze.  We can't propose new features for 1.3.1 ... unless
> > you define piped logs as a bug fix (I can easily see this :). 
> > 
> 
> Why _can't_ we add new features for 1.3.1? Because it's a sub-minor-#
> upgrade? 
> 
> In any case, adding new features for 1.3b2 goes against my main
> point of getting 1.3.0 out asap. What I'd like to see is 1.3b1
> out, some _bug_ reports come in, we fix those, release 1.3b2, we
> get the all-clear and then release 1.3.0. By NOT introducing
> new features during the beta releases we can assure ourselves that
> 1.3.0 gets out soon. As soon as 1.3.0 is out, we can work on 1.3.1b1
> which adds new features. If we want to call it 1.4 well....
> I don't see that. I don't think everytime we add a new feature
> we need to up the minor version number (for X.Y.Z I call 'X' the
> major number, 'Y' the minor and 'Z' the sub-minor... We've
> never really considered it, officially, a "patch" level) but
> this is all details. Someone once said that language/English is
> our servant, not our master. We can make the version number mean
> whatever we want.
> 
> Nonetheless, it is high-time for 1.3.0 to be out. The only way
> to do this in the near future is for someone to dig their heels
> in and say no more new features, otherwise we run into a continual
> beta-release->add-stuff->test-in->another-beta-release cycle.
> -- 
> ====================================================================
>       Jim Jagielski            |       jaguNET Access Services
>      jim@jaguNET.com           |       http://www.jaguNET.com/
>             "Look at me! I'm wearing a cardboard belt!"
> 


Mime
View raw message