You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2010/06/15 16:21:08 UTC
Re: svn commit: r954862 - /httpd/httpd/trunk/CHANGES
On Tue, Jun 15, 2010 at 9:06 AM, <rj...@apache.org> wrote:
> Author: rjung
> Date: Tue Jun 15 13:06:14 2010
> New Revision: 954862
>
> URL: http://svn.apache.org/viewvc?rev=954862&view=rev
> Log:
> Fix obsolete reference to 2.1 in CHANGES.
>
> Likely we still have to clean CHANGES from things backported
> to 2.2.x.
trunk CHANGES needs to track fixes/enhancements since the last alpha,
so the candidates for pruning would be in the section "Changes with
Apache 2.3.0".
attached is a patch to prune 2.3.0 changes which were backported to
some 2.2.x release; look reasonable?
something that would make future-2.4 CHANGES more usable would be to
collapse stuff like {"introduce mod_foo", "fix bug1 in mod_foo", "fix
bug2 in mod_foo", "make enhancement1 to mod_foo"} within the same
release into one mod_foo entry, and to axe entries which are for
implementation details that users don't care about (or at least, if
there is an external implication then document that and not the
implementation detail)
Re: svn commit: r954862 - /httpd/httpd/trunk/CHANGES
Posted by Rainer Jung <ra...@kippdata.de>.
On 15.06.2010 23:20, Graham Leggett wrote:
> On 15 Jun 2010, at 4:21 PM, Jeff Trawick wrote:
>
>> trunk CHANGES needs to track fixes/enhancements since the last alpha,
>> so the candidates for pruning would be in the section "Changes with
>> Apache 2.3.0".
>>
>> attached is a patch to prune 2.3.0 changes which were backported to
>> some 2.2.x release; look reasonable?
>>
>> something that would make future-2.4 CHANGES more usable would be to
>> collapse stuff like {"introduce mod_foo", "fix bug1 in mod_foo", "fix
>> bug2 in mod_foo", "make enhancement1 to mod_foo"} within the same
>> release into one mod_foo entry, and to axe entries which are for
>> implementation details that users don't care about (or at least, if
>> there is an external implication then document that and not the
>> implementation detail)
>> <2.3.0-backports.txt>
>
> Are we not going overboard on pruning the CHANGES file?
>
> Wearing my end user hat, had I been brave and installed v2.3.5, and
> wanted to consider v2.3.6, I'm going to download the tarball, open it
> up, and look at the CHANGES file. Where I won't find a complete list of
> changes between v2.3.5 and v2.3.6. The kicker of course is that I won't
> know these changes are missing, after all, I am a brave webmaster, not a
> C coder or a developer, I don't subscribe to the dev list, and I haven't
> read this or any other thread on this issue, and the CHANGES file has
> been around for over a decade, and there is no reason to suspect it
> works differently.
>
> Of course, you might include a sentence at the top of CHANGES saying
> "some changes have been backported to v2.2". Trouble is, which changes?
> Which changes were backported before v2.3.5 was released? Which after?
> No idea.
>
> I entirely understand the idea behind pruning the CHANGES file of
> entries older than the point at which trunk was branched to form v2.2,
> to ensure CHANGES did not grow boundlessly. A simple "this file
> continues on this branch" did the trick, and CHANGES file resets to zero
> size, and we start again.
>
> By way of comparison, here is the CHANGES file in httpd v2.2, which
> contains lots of entries over the life of the branch, and can be assumed
> to be large:
>
> -rw-r--r-- 1 minfrin 501 108719 Jun 6 01:48 CHANGES
>
> And here is our configure script:
>
> -rwxr-xr-x 1 minfrin 501 654523 Sep 23 2009 configure
>
> I don't see any benefit in attempting to shorten this file any further,
> given that it is short enough already. A clear and unambiguous CHANGES
> file is something useful to end users, however the current CHANGES file
> has holes in it, and is as a result of no use to end users at all.
All that has been pruned now was changes pre 2.3.*0* which have been
backported. So this part of history is no longer relevant. Entries
younger than 2.3.0 have *not* been pruned, even if backported.
I agree with Jeff, that 2.4.0 should start with a different granularity
of historic change information. E.g. bugs only fixed durng the 2.3.x
life in new modules are not really relevant for the 2.4 user. If he
likes he can dig into the old 2.3 change file, but as a new 2.4 user he
would only like to know what the new modules are and what they provide.
but that's maybe a "What's new in 2.4" type docs page.
Rainer
Re: svn commit: r954862 - /httpd/httpd/trunk/CHANGES
Posted by Graham Leggett <mi...@sharp.fm>.
On 15 Jun 2010, at 4:21 PM, Jeff Trawick wrote:
> trunk CHANGES needs to track fixes/enhancements since the last alpha,
> so the candidates for pruning would be in the section "Changes with
> Apache 2.3.0".
>
> attached is a patch to prune 2.3.0 changes which were backported to
> some 2.2.x release; look reasonable?
>
> something that would make future-2.4 CHANGES more usable would be to
> collapse stuff like {"introduce mod_foo", "fix bug1 in mod_foo", "fix
> bug2 in mod_foo", "make enhancement1 to mod_foo"} within the same
> release into one mod_foo entry, and to axe entries which are for
> implementation details that users don't care about (or at least, if
> there is an external implication then document that and not the
> implementation detail)
> <2.3.0-backports.txt>
Are we not going overboard on pruning the CHANGES file?
Wearing my end user hat, had I been brave and installed v2.3.5, and
wanted to consider v2.3.6, I'm going to download the tarball, open it
up, and look at the CHANGES file. Where I won't find a complete list
of changes between v2.3.5 and v2.3.6. The kicker of course is that I
won't know these changes are missing, after all, I am a brave
webmaster, not a C coder or a developer, I don't subscribe to the dev
list, and I haven't read this or any other thread on this issue, and
the CHANGES file has been around for over a decade, and there is no
reason to suspect it works differently.
Of course, you might include a sentence at the top of CHANGES saying
"some changes have been backported to v2.2". Trouble is, which
changes? Which changes were backported before v2.3.5 was released?
Which after? No idea.
I entirely understand the idea behind pruning the CHANGES file of
entries older than the point at which trunk was branched to form v2.2,
to ensure CHANGES did not grow boundlessly. A simple "this file
continues on this branch" did the trick, and CHANGES file resets to
zero size, and we start again.
By way of comparison, here is the CHANGES file in httpd v2.2, which
contains lots of entries over the life of the branch, and can be
assumed to be large:
-rw-r--r-- 1 minfrin 501 108719 Jun 6 01:48 CHANGES
And here is our configure script:
-rwxr-xr-x 1 minfrin 501 654523 Sep 23 2009 configure
I don't see any benefit in attempting to shorten this file any
further, given that it is short enough already. A clear and
unambiguous CHANGES file is something useful to end users, however the
current CHANGES file has holes in it, and is as a result of no use to
end users at all.
Regards,
Graham
--
Re: svn commit: r954862 - /httpd/httpd/trunk/CHANGES
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Jun 15, 2010 at 12:52 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 15.06.2010 18:30, Rainer Jung wrote:
>
> Sorry for the noise, forget about the second addition, doesn't seem to be
> the same thing (prepared statements vs. connection pools).
>
>> @@ -1131,11 +1082,6 @@ Changes with Apache 2.3.0
>> into the environment with the name AUTHENTICATE_<COLUMN>. This brings
>> mod_authn_dbd behaviour in line with mod_authnz_ldap. [Graham Leggett]
>>
>> - *) mod_dbd: Key the storage of prepared statements on the hex string
>> - value of server_rec, rather than the server name, as the server name
>> - may change (eg when the server name is set) at any time, causing
>> - weird behaviour in modules dependent on mod_dbd. [Graham Leggett]
>> -
>> *) mod_proxy_fcgi: Added win32 build. [Mladen Turk]
>>
>> *) sendfile_nonblocking() takes the _brigade_ as an argument, gets
>>
>>
>> I guess for this the corresponding 2.2 entry is:
>>
>> *) mod_dbd: key connection pools to virtual hosts correctly even when·
>> ServerName is unset/unavailable [Graham Leggett]
some small overlap in the code changes, but I agree, not the same
thanks for the add'l research!
Re: svn commit: r954862 - /httpd/httpd/trunk/CHANGES
Posted by Rainer Jung <ra...@kippdata.de>.
On 15.06.2010 18:30, Rainer Jung wrote:
Sorry for the noise, forget about the second addition, doesn't seem to
be the same thing (prepared statements vs. connection pools).
> @@ -1131,11 +1082,6 @@ Changes with Apache 2.3.0
> into the environment with the name AUTHENTICATE_<COLUMN>. This brings
> mod_authn_dbd behaviour in line with mod_authnz_ldap. [Graham Leggett]
>
> - *) mod_dbd: Key the storage of prepared statements on the hex string
> - value of server_rec, rather than the server name, as the server name
> - may change (eg when the server name is set) at any time, causing
> - weird behaviour in modules dependent on mod_dbd. [Graham Leggett]
> -
> *) mod_proxy_fcgi: Added win32 build. [Mladen Turk]
>
> *) sendfile_nonblocking() takes the _brigade_ as an argument, gets
>
>
> I guess for this the corresponding 2.2 entry is:
>
> *) mod_dbd: key connection pools to virtual hosts correctly even when·
> ServerName is unset/unavailable [Graham Leggett]
Rainer
Re: svn commit: r954862 - /httpd/httpd/trunk/CHANGES
Posted by Rainer Jung <ra...@kippdata.de>.
On 15.06.2010 16:21, Jeff Trawick wrote:
> On Tue, Jun 15, 2010 at 9:06 AM,<rj...@apache.org> wrote:
>> Author: rjung
>> Date: Tue Jun 15 13:06:14 2010
>> New Revision: 954862
>>
>> URL: http://svn.apache.org/viewvc?rev=954862&view=rev
>> Log:
>> Fix obsolete reference to 2.1 in CHANGES.
>>
>> Likely we still have to clean CHANGES from things backported
>> to 2.2.x.
>
> trunk CHANGES needs to track fixes/enhancements since the last alpha,
> so the candidates for pruning would be in the section "Changes with
> Apache 2.3.0".
>
> attached is a patch to prune 2.3.0 changes which were backported to
> some 2.2.x release; look reasonable?
>
> something that would make future-2.4 CHANGES more usable would be to
> collapse stuff like {"introduce mod_foo", "fix bug1 in mod_foo", "fix
> bug2 in mod_foo", "make enhancement1 to mod_foo"} within the same
> release into one mod_foo entry, and to axe entries which are for
> implementation details that users don't care about (or at least, if
> there is an external implication then document that and not the
> implementation detail)
+1, I verified all of them.
I found another two backported fixes:
@@ -1096,10 +1055,6 @@ Changes with Apache 2.3.0
*) mod_ssl: Add support for caching SSL Sessions in memcached. [Paul
Querna]
- *) mod_ldap: Fix the search limit parameter to ldap_search_ext_s()
- for SDKs that define LDAP_NO_LIMIT to something other than -1.
- [David Jones <oscaremma gmail.com>]
-
*) apxs: Enhance -q flag to print all known variables and their values
when invoked without variable name(s).
[William Rowe, Sander Temme]
(look for "ldap_search_ext_s" in the 2.2 CHANGES) and
@@ -1131,11 +1082,6 @@ Changes with Apache 2.3.0
into the environment with the name AUTHENTICATE_<COLUMN>. This brings
mod_authn_dbd behaviour in line with mod_authnz_ldap. [Graham
Leggett]
- *) mod_dbd: Key the storage of prepared statements on the hex string
- value of server_rec, rather than the server name, as the server name
- may change (eg when the server name is set) at any time, causing
- weird behaviour in modules dependent on mod_dbd. [Graham Leggett]
-
*) mod_proxy_fcgi: Added win32 build. [Mladen Turk]
*) sendfile_nonblocking() takes the _brigade_ as an argument, gets
I guess for this the corresponding 2.2 entry is:
*) mod_dbd: key connection pools to virtual hosts correctly even when·
ServerName is unset/unavailable [Graham Leggett]
Regards,
Rainer
Re: svn commit: r954862 - /httpd/httpd/trunk/CHANGES
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/15/2010 9:21 AM, Jeff Trawick wrote:
>
> attached is a patch to prune 2.3.0 changes which were backported to
> some 2.2.x release; look reasonable?
Looks reasonable, thanks for this effort.