Mailing List Archive

> Hmm.. I'm not sure what you mean... do you want 0.8.15 to be 1.0?

that is what I was offering as a suggestion.

> I'm not even sure if we're going to include the OS/2 stuff.... if that is
> the same, then I'm against going with 1.0. If we're not I'll consider it...
> but am not crazy about it.

If the OS/2 patches were accepted in the time available (which I
seriously doubt), then they would be part of 1.0

I get the impression that we've settled into a routine of fixing minor
problems, and that nobody has said "X needs fixing before 1.0". The minor
problem fixes will probably continue to come in at a similar rate for some
time to come.

As has been said before, the "1.0" tag is psychologically advantageous.
We're not selling anything, so I see no reason to wait any longer unless
people can give good reasons for doing so.

I'd bet that 0.8.14 has far fewer bugs than many other 1.0 servers that have
been released, whether they are commercial products or freebies like ours.

Once we have 1.0, we can continue to patch it at a similar rate to what we do
now with 0.8.*


If someone can give good reasons why we're not ready for 1.0, then I have
no problem accepting a delay, but all calls so far for such reasons have
produced nothing from what I remember.


We could take 0.8 to 0.8.99 as things stand.

So who is and who isn't ready ?


rob

At 01:06 PM 9/27/95 MDT, you wrote:
>
>Once we have 1.0, we can continue to patch it at a similar rate to what we do
>now with 0.8.*

That sounds right to me.

>
>
>If someone can give good reasons why we're not ready for 1.0, then I have
>no problem accepting a delay, but all calls so far for such reasons have
>produced nothing from what I remember.

>So who is and who isn't ready ?
>

I'm in...

<Aram>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

At 11:53 PM 9/27/95 +0100, you wrote:
>> Since no one else has steped forward to take the votes, I'll do it again
>> if no one has any objections.
>>
>> Right now we have the following patches:
>>
>> 01_http_config.0.8.14.patch
>> 02_DBMGroupCoreFix.0.8.14.patch
>
>I have two problems with this one. One is I don't understand what it is
>supposed to do, and the other is that it doesn't fix (or generate) the
>accompanying documentation, which, in my view anyway, should be a requirement
>for any functionality change.
>
>> 04a_ExtraPath.0.8.14.patch
>> 05_NoKill.0.8.14.patch
>> 06_SCODocFix.0.8.14.patch
>> 07_SocketMemLeak.0.8.14.patch
>> 08_license.0.8.14.patch
>> 09_HP_comment.0.8.14.patch
>> 10_mutual-failure.0.8.14.patch
>> 11_fd_removal.0.8.14.patch
>
>And this one looks a little rash. One must assume that there is a version
>of Linux which requires these defines.
>

These are duplicate defines... FD is defined in time.h that is now
being included.

<Aram>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

>
> On Wed, 27 Sep 1995, Ben Laurie wrote:
> > > 02_DBMGroupCoreFix.0.8.14.patch
> >
> > I have two problems with this one. One is I don't understand what it is
> > supposed to do, and the other is that it doesn't fix (or generate) the
> > accompanying documentation, which, in my view anyway, should be a requirement
> > for any functionality change.
>
> It fixes a core dump bug sent to apache-bugs. There is no
> documentation for the use of DBM group files anyway. This patch doesn't
> alter any existing functionality.

It adds new functionality, which is a functionality change. There is very
little documentation for anything in Apache. Does this mean that we shouldn't
bother to document it?

I still don't get the point of this fix. Why allow an "incorrect" format,
rather than emitting an error message?

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

>
> At 11:53 PM 9/27/95 +0100, you wrote:
> >> Since no one else has steped forward to take the votes, I'll do it again
> >> if no one has any objections.
> >>
> >> Right now we have the following patches:
> >>
> >> 01_http_config.0.8.14.patch
> >> 02_DBMGroupCoreFix.0.8.14.patch
> >
> >I have two problems with this one. One is I don't understand what it is
> >supposed to do, and the other is that it doesn't fix (or generate) the
> >accompanying documentation, which, in my view anyway, should be a requirement
> >for any functionality change.
> >
> >> 04a_ExtraPath.0.8.14.patch
> >> 05_NoKill.0.8.14.patch
> >> 06_SCODocFix.0.8.14.patch
> >> 07_SocketMemLeak.0.8.14.patch
> >> 08_license.0.8.14.patch
> >> 09_HP_comment.0.8.14.patch
> >> 10_mutual-failure.0.8.14.patch
> >> 11_fd_removal.0.8.14.patch
> >
> >And this one looks a little rash. One must assume that there is a version
> >of Linux which requires these defines.
> >
>
> These are duplicate defines... FD is defined in time.h that is now
> being included.

I see. Now, for 10 points, can anyone explain the logic of having FD defines
in time.h? ;-)

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

On Thu, 28 Sep 1995, Ben Laurie wrote:
> Does this mean that we shouldn't bother to document it?
> Why allow an "incorrect" format, rather than emitting an error message?

Having a group file containing ":group" isn't obvious. It isn't what is
done elsewhere and it was a slight fiddle to allow the group and password
DBM files to overlap. Having the group file containing "group" was how I
was about to document it; with ":group" being a mentioned alternative only
for people that are going to overlap the files.

But you are right, it is a feature enhancement patch. It just seemed a
bit silly adding an error message patch for the 0.8.14 and then
removing the error message and allowing the new format for 1.0; especially
since the patch for the latter is so trivial.

Mark
Mark J Cox, mark@telescope.org -- URL:http://www.telescope.org/mark.html
University of Bradford, England ---------- tel +44.1274.384070/fax 391333

>
> On Thu, 28 Sep 1995, Ben Laurie wrote:
> > Does this mean that we shouldn't bother to document it?
> > Why allow an "incorrect" format, rather than emitting an error message?
>
> Having a group file containing ":group" isn't obvious. It isn't what is
> done elsewhere and it was a slight fiddle to allow the group and password
> DBM files to overlap. Having the group file containing "group" was how I
> was about to document it; with ":group" being a mentioned alternative only
> for people that are going to overlap the files.
>
> But you are right, it is a feature enhancement patch. It just seemed a
> bit silly adding an error message patch for the 0.8.14 and then
> removing the error message and allowing the new format for 1.0; especially
> since the patch for the latter is so trivial.

I'm not religious about the feature enhancement thing. Your method probably
disturbs the code less. What was, and is, worrying me, was that the change
makes something already almost incomprehensible (because of lack of
documentation) completely arcane. So, provide some docs, and I'll be happy.

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

> So, provide some docs, and I'll be happy.

hyperreal: /httpd/incoming/auth_dbm.html (replaces and revises docs/P14.html)

I also found my other patch that got lost in the 0,8,14 patch list; it was
in /httpd/incoming/patch.0.8.14.config_decline by mistake.

Mark
Mark J Cox, mark@telescope.org -- URL:http://www.telescope.org/mark.html
University of Bradford, England ---------- tel +44.1274.384070/fax 391333

It fixes a core dump bug sent to apache-bugs. There is no
documentation for the use of DBM group files anyway. This patch doesn't
alter any existing functionality.

...but it does add a new and incompatible form of DBM group file.

rst