PR1634: Request for gcc-cvs-patches list

PR1634: Request for gcc-cvs-patches list

[Steven Bosscher]

Hello,

Back when God hadn't invented the dinosaurs yet (7 years ago) Joseph
opened a bug report requesting the creation of a gcc-cvs-patches
mailing list.  The bug report can be found here:
http://gcc.gnu.org/PR1634.

Then, nothing happened for many years, a few comments aside.

Joseph wants to keep this bug report open to help "actively
remembering" people about this open issue, and to track this issue
over time.  To me it seems there is nothing to track if no-one follows
up on te bug report.  And with >4500 open bug report, I also don't see
how people are going to find this one simple requests.  It is like a
needle in the hay stack, and nobody is even looking for the needle.

So I'm taking the issue here.

Do people think it is a good idea to have a gcc-cvs-patches list (or
gcc-svn-patches, also fine), where all patches automatically get sent
to, exactly as they are committed to SVN (maybe in  gzip'ed form)?
This would have been especially useful before GCC started using SVN,
but even today there are some reasons to have this, as discussed in
the bug report.

Personally, I like the idea.  But someone (probably Joseph, as the
requester) should persue the idea.  If sufficient people thing this is
a good idea, we can think about how to implement it.  Or the idea can
be rejected.  In either case, the enhancement can finally be closed.

Gr.
Steven

Re: PR1634: Request for gcc-cvs-patches list

[Paolo Bonzini]

> Do people think it is a good idea to have a gcc-cvs-patches list (or
> gcc-svn-patches, also fine), where all patches automatically get sent
> to, exactly as they are committed to SVN (maybe in  gzip'ed form)?
> This would have been especially useful before GCC started using SVN,
> but even today there are some reasons to have this, as discussed in
> the bug report.

If this is meant for usage by a program, I think that this can be done 
as easily with svn in the program, based on gcc-cvs messages.  Even for 
semi-automated usage, I think that this is too hard to do with the 
filters in mail program, and one would resort to procmail (Joseph, what 
did you have in mind?).  Put the recipe in contrib, and you get the same 
result as a public gcc-cvs-patches mailing list.

On the other hand, if it is meant for human usage the file list is 
already a clue to spot "wrong" commits.  Then, an equivalent but more 
versatile feature request would be to have patches visible online, with 
URLs like http://gcc.gnu.org/viewcvs/?r1=119999r2=120000&view=patch 
(which would do a "svn diff -x -u -r119999 -r120000").  Such URLs 
currently work with files but not with directories.  I don't know how 
fundamental a problem with ViewVC and svn-python bindings this is.

Note that the latter solution would be nice because gzipped patches sent 
to a mailing list wouldn't be visible from a browser.

Paolo

Re: PR1634: Request for gcc-cvs-patches list

[Joseph S. Myers]

On Mon, 26 Nov 2007, Paolo Bonzini wrote:

> On the other hand, if it is meant for human usage the file list is already a
> clue to spot "wrong" commits.  Then, an equivalent but more versatile feature
> request would be to have patches visible online, with URLs like
> http://gcc.gnu.org/viewcvs/?r1=119999r2=120000&view=patch (which would do a
> "svn diff -x -u -r119999 -r120000").  Such URLs currently work with files but
> not with directories.  I don't know how fundamental a problem with ViewVC and
> svn-python bindings this is.

The primary function is for a human reading the list (where patches 
directly inline in the message are by far preferable to URLs).

I believe the SVN log mailer supports mailing patches anyway.  So you 
could get 90% of the benefit by having the SVN mailer run twice for each 
commit, once with the present configuration for gcc-cvs and once with a 
different configuration (including patches, 10MB message size limit (and a 
similarly large limit for the list itself), truncating rather than 
splitting anything larger) for gcc-cvs-patches.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: PR1634: Request for gcc-cvs-patches list

[Daniel Berlin]

On 11/26/07, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Mon, 26 Nov 2007, Paolo Bonzini wrote:
>
> > On the other hand, if it is meant for human usage the file list is already a
> > clue to spot "wrong" commits.  Then, an equivalent but more versatile feature
> > request would be to have patches visible online, with URLs like
> > http://gcc.gnu.org/viewcvs/?r1=119999r2=120000&view=patch (which would do a
> > "svn diff -x -u -r119999 -r120000").  Such URLs currently work with files but
> > not with directories.  I don't know how fundamental a problem with ViewVC and
> > svn-python bindings this is.
>
> The primary function is for a human reading the list (where patches
> directly inline in the message are by far preferable to URLs).
>
> I believe the SVN log mailer supports mailing patches anyway.

It does.
>  So you
> could get 90% of the benefit by having the SVN mailer run twice for each
> commit, once with the present configuration for gcc-cvs and once with a
> different configuration (including patches, 10MB message size limit (and a
> similarly large limit for the list itself), truncating rather than
> splitting anything larger) for gcc-cvs-patches.
>

You don't even need to do this, you can tell it to send patches to one
address and just what it does now to the other, and it will happily do
so in one run :)

> --
> Joseph S. Myers
> joseph@codesourcery.com
>