httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: segfault patch for util_ldap (was:Re: cvs commit: httpd-2.0 STATUS)
Date Wed, 29 Sep 2004 03:59:59 GMT
On Tue, 28 Sep 2004 18:00:12 -0600, Brad Nicholes <> wrote:
> >>>> Tuesday, September 28, 2004 5:31:47 PM >>>
> >At 06:12 PM 9/28/2004, Brad Nicholes wrote:
> >>   I wouldn't consider posting the patch if there was going to be
> >>another release in a week and a half, but that usually isn't the
> case
> >>and a patch for an experimental module usually isn't reason enough
> to
> >>roll another release.  Past history shows that it usually takes a
> >>serious vulnerability to warrant the turnaround we saw with 2.0.52.
> >
> >No, it just takes someone motivated.  I hated the thought of 2.0.51
> >sitting around so I did something about it :)
> It takes a little more than just motivation, it also takes a need and
> consensus.  To all those using auth_ldap and util_ldap, this patch is
> very import.  To the rest, they don't really care so another release
> within 3 weeks is just a pain.  All I really want to do is release a
> patch to make life easier for those that care and want to move forward
> with ldap, not cause a headache for the majority that don't.  I really
> doubt I am going to get 3 +1's in favor of rolling a release all for a
> patch to an experimental module.
> Quoting the download page:
> "Official Patches
> When we have patches to a minor bug or two, or features which we
> haven't yet included in a new release, we will put them in the patches
> subdirectory so people can get access to it before we roll another
> complete release."
> All this is, is a patch to fix a bug which hasn't been included in a
> new release yet so people can get access to it, it doesn't warrant a new
> release.  It's not that big of an issue.

Any committer should be able to put patches in the appropriate
directory for any fix s/he deems appropriate once it has been approved
for the stable branch, without asking for additional approval, and
without regards to whether or not there will be another release within
n days.

As a *completely* separate issue: I'm don't think Brad should assume
that there would not be enough people willing to test/approve another
release just because it primarily contained fixes to experimental
modules.  (Though he probably would get to do all the really heavy

View raw message