You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2012/01/22 16:20:26 UTC
2.2.22
Seems to me that there's enough to warrant a 2.2.22 release...
As long as we're doing a 2.4.1, why not also provide a 2.2.22
at the same time?
I offer to RM this as well, with the hopes of releasing both
by the end of the week.
Comments?
Re: 2.2.22
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jan 22, 2012, at 11:13 PM, William A. Rowe Jr. wrote:
>
> I had expressed my intent, as you well know, on the security and
> private lists, to RM 2.2.22 the moment the last security patch is
> in place (using the same autogunk tooling so that users have no
> surprises in upgrading). And I am still committed to helping out
> by doing so.
>
Bill, just a reminder that RMing a release involves actual
*effort* and not just the flapping of one's lips. Considering
your actions here over the last few months, I wanted to make
sure you recalled that...
Re: 2.2.22
Posted by Eric Covener <co...@gmail.com>.
> True. Stefan has gone above and beyond in contributing to making
> these 2.4 tags ready. In fact, he's earned the distinction of
> being a key contributor to making it happen. Hard to imagine how
> far we would be without his help.
+1
Re: 2.2.22
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/23/2012 5:35 AM, Graham Leggett wrote:
>
> The Include/IncludeOptional stuff is your code, instead of voting against your own code, fix it instead:
The code below is a simplification of your code. I merely reorganized
your logic, warts and all.
When my sense of obligation to 2.2/2.0 and those users is satisfied with
this release candidate, I can turn my attention to remaining defects,
which appears to be the failure to ignore all not-found failures given
one success case. I trust that we don't want to ignore other failures,
such as unreadable/permission denied/bad syntax?
> r931435 | wrowe | 2010-04-07 06:51:46 +0200 (Wed, 07 Apr 2010) | 6 lines
>
> First order simplification; Add IncludeOptional for introducing
> wildcard pattern matches or specific includes which may be omitted.
> Refactors ap_process_resource_config() to deal efficiently with
> a single file, and renames the new _ex() flavor per list discussion
> to ap_process_fnmatch_configs() for wildcard processing.
> It should not have fallen on sf to have to document this change.
True. Stefan has gone above and beyond in contributing to making
these 2.4 tags ready. In fact, he's earned the distinction of
being a key contributor to making it happen. Hard to imagine how
far we would be without his help.
Re: 2.2.22
Posted by Graham Leggett <mi...@sharp.fm>.
On 23 Jan 2012, at 6:13 AM, William A. Rowe Jr. wrote:
>> Seems to me that there's enough to warrant a 2.2.22 release...
>> As long as we're doing a 2.4.1, why not also provide a 2.2.22
>> at the same time?
>
> Because, 2.4.x is a distraction to shipping 2.2.22. You are
> welcome to do a 2.4.x, although I will vote against it without
> sensible include/includeoptional behavior, or without a sensible
> non-DoSing core filter, or without the correction of sometimes
> faulty acceptfilter none/mod_ssl behavior on win32.
The Include/IncludeOptional stuff is your code, instead of voting against your own code, fix it instead:
Little-Net:httpd-trunk minfrin$ svn log -c 931435
------------------------------------------------------------------------
r931435 | wrowe | 2010-04-07 06:51:46 +0200 (Wed, 07 Apr 2010) | 6 lines
First order simplification; Add IncludeOptional for introducing
wildcard pattern matches or specific includes which may be omitted.
Refactors ap_process_resource_config() to deal efficiently with
a single file, and renames the new _ex() flavor per list discussion
to ap_process_fnmatch_configs() for wildcard processing.
931435 wrowe AP_INIT_TAKE1("Include", include_config, NULL,
88449 rbb (RSRC_CONF | ACCESS_CONF | EXEC_ON_READ),
931435 wrowe "Name(s) of the config file(s) to be included; fails if the wildcard does "
931435 wrowe "not match at least one file"),
931435 wrowe AP_INIT_TAKE1("IncludeOptional", include_config, (void*)1,
931435 wrowe (RSRC_CONF | ACCESS_CONF | EXEC_ON_READ),
931435 wrowe "Name or pattern of the config file(s) to be included; ignored if the file "
931435 wrowe "does not exist or the pattern does not match any files"),
It should not have fallen on sf to have to document this change.
People who commit code are responsible for ensuring any documentation that concerns their code is both present and accurate.
Regards,
Graham
--
Re: 2.2.22
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/22/2012 9:20 AM, Jim Jagielski wrote:
> Seems to me that there's enough to warrant a 2.2.22 release...
> As long as we're doing a 2.4.1, why not also provide a 2.2.22
> at the same time?
Because, 2.4.x is a distraction to shipping 2.2.22. You are
welcome to do a 2.4.x, although I will vote against it without
sensible include/includeoptional behavior, or without a sensible
non-DoSing core filter, or without the correction of sometimes
faulty acceptfilter none/mod_ssl behavior on win32. Only one
of those is a serious security issue you are ignoring, and that
would only be one vote against, which certainly doesn't prevent
its release.
I had expressed my intent, as you well know, on the security and
private lists, to RM 2.2.22 the moment the last security patch is
in place (using the same autogunk tooling so that users have no
surprises in upgrading). And I am still committed to helping out
by doing so.
Or maybe you didn't know... I do suggest you review the open
defect threads on security and dev w.r.t. 2.2.22-dev and 2.4.1-dev
because the current list precludes any sane tag and roll of either.
Sorry if I assume you had read messages that you hadn't scanned.
You are welcome to do an earlier 2.2.x tag which I will vote against
for shipping known-vulnerable software. Of course, that is only
one vote against, and certainly doesn't prevent its release.
Of course with 2.4.x, I hope you are going with the most modern
autoconf/libtool tooling, since there is nothing forcing a user
to adopt it, and any config defects will shake out soon enough.
My attitude towards maintaining consistent tooling for 2.2.x src
tarballs is entirely related to ease-of-mandatory-transitions.
Re: 2.2.22
Posted by Graham Leggett <mi...@sharp.fm>.
On 22 Jan 2012, at 5:20 PM, Jim Jagielski wrote:
> Seems to me that there's enough to warrant a 2.2.22 release...
> As long as we're doing a 2.4.1, why not also provide a 2.2.22
> at the same time?
>
> I offer to RM this as well, with the hopes of releasing both
> by the end of the week.
>
> Comments?
+1
(And thanks for doing it)
Regards,
Graham
--