You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Brad Nicholes <BN...@novell.com> on 2004/11/19 19:11:03 UTC
Re: svn commit: r76284 - apr/apr/trunk
Now that we have converted to SVN, why doesn't the subject line
include the file that is being changed in the commit message? This
makes it harder to prioritize patches that need to be reviewed.
Brad
>>> jorton@apache.org Thursday, November 18, 2004 2:31:22 PM >>>
Author: jorton
Date: Thu Nov 18 13:31:21 2004
New Revision: 76284
Modified:
apr/apr/trunk/CHANGES
Log:
Note apr_file_printf rewrite.
Modified: apr/apr/trunk/CHANGES
==============================================================================
--- apr/apr/trunk/CHANGES (original)
+++ apr/apr/trunk/CHANGES Thu Nov 18 13:31:21 2004
@@ -5,6 +5,10 @@
and upgrading it to do SHA-256. Not yet ready for prime time.
[Ben Laurie]
+ *) Rewrite apr_file_printf to handle arbitrary length strings.
+ PR 28029. [Chris Knight <Christopher.D.Knight nasa.gov>,
+ Garrett Rooney <rooneg electricjellyfish.net>]
+
Changes for APR 1.0.1
*) Fix HUP return codes in pollset when using KQueue.
Re: svn commit: r76284 - apr/apr/trunk
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Justin Erenkrantz wrote:
> --On Friday, November 19, 2004 11:11 AM -0700 Brad Nicholes
> <BN...@novell.com> wrote:
>
>> Now that we have converted to SVN, why doesn't the subject line
>> include the file that is being changed in the commit message? This
>> makes it harder to prioritize patches that need to be reviewed.
>
>
> Our CVS mailer only showed the last directory (with files) that was
> committed - so subject lines were *always* inaccurate when touching
> multiple directories. The SVN mailer always shows all directories that
> were modified. I think that's a far better compromise.
really? take a look at the current httpd commit page now on marc:
http://marc.theaimsgroup.com/?l=apache-cvs&r=1&b=200411&w=2
and compare it to the prior page
http://marc.theaimsgroup.com/?l=apache-cvs&r=2&b=200411&w=2
at least some of the commits in the past had the full filename in the
subject, making them much easier to scan. if everything starts looking like
it does now we'll have 50 million commits where the subject starts "svn
commit: r105782 - httpd/httpd/branches/2.0.x/..." and runs off the edge of
your email client.
anyway, not to complain - you guys have been doing great work, and I'm very,
very appreciative that things went so smoothly. but if there is a chance
that the commit email format can be made more useful, that would be great.
> Plus, we've
> received a number of complaints that the subject lines were too long to
> be useful: hence just the directory names.
httpd-test just had this subject
"svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test
Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules
c-modules/authany c-modules/client_add_filter c-modules/eat_post
c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter
c-modules/list_modules c-modules/nntp_like c-modules/random_chunk
c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite
c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess
t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules"
which I guess means that no matter what you do it can be long.
--Geoff
Re: svn commit: r76284 - apr/apr/trunk
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, November 19, 2004 11:11 AM -0700 Brad Nicholes
<BN...@novell.com> wrote:
> Now that we have converted to SVN, why doesn't the subject line
> include the file that is being changed in the commit message? This
> makes it harder to prioritize patches that need to be reviewed.
Our CVS mailer only showed the last directory (with files) that was
committed - so subject lines were *always* inaccurate when touching
multiple directories. The SVN mailer always shows all directories that
were modified. I think that's a far better compromise. Plus, we've
received a number of complaints that the subject lines were too long to be
useful: hence just the directory names. *shrug* -- justin