Thread: commit messages from gforge -> pgsql-committers
One of the comments I saw over the past few days on how to make things on pgFoundry more visible was to have the commit messages for its projects sent out through pgsql-committers as well ... How many objections would there be to setting this up, and seeing how it works? The idea would be to change the subject header to reflect the project, instead of the list, so that one could create filters ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> One of the comments I saw over the past few days on how to make things on
> pgFoundry more visible was to have the commit messages for its projects
> sent out through pgsql-committers as well ...
> How many objections would there be to setting this up, and seeing how it
> works? The idea would be to change the subject header to reflect the
> project, instead of the list, so that one could create filters ...
Please add, not change, ie it should look something like
[COMMITTERS] project: list-of-files
However, if each project's fileset has a distinct module name, it may
be that we don't need the project label at all since the root of the
list-of-files will be enough. For instance all commits for the core
project already start with pgsql-server/, and it seems like that's
sufficient ID.
BTW, while you're messing with it, can you fix the random one-character
lossage that so frequently happens in the list of file names?
A recent example is
Subject: [COMMITTERS] pgsql-server/ oc/src/sgml/func.sgml oc/src/sgm ...
where of course "doc" is meant not "oc".
regards, tom lane
On Thu, 20 May 2004, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > One of the comments I saw over the past few days on how to make things on > > pgFoundry more visible was to have the commit messages for its projects > > sent out through pgsql-committers as well ... > > > How many objections would there be to setting this up, and seeing how it > > works? The idea would be to change the subject header to reflect the > > project, instead of the list, so that one could create filters ... > > Please add, not change, ie it should look something like > > [COMMITTERS] project: list-of-files > > However, if each project's fileset has a distinct module name, it may > be that we don't need the project label at all since the root of the > list-of-files will be enough. For instance all commits for the core > project already start with pgsql-server/, and it seems like that's > sufficient ID. k, will try that out and see ... can always change it afterwards ... > BTW, while you're messing with it, can you fix the random one-character > lossage that so frequently happens in the list of file names? A recent > example is > > Subject: [COMMITTERS] pgsql-server/ oc/src/sgml/func.sgml oc/src/sgm ... > > where of course "doc" is meant not "oc". I'm going to try once more to find a newer version ... both Bruce and I have gone through the current script and for the life of us can't find the reason for it ... :( Actually, I think *hangs head* I have some updates submit'd from Sean in my mailbox that I still haven't applied ... will look at this when I get back from Ontario, and have a real computer to work with again :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Tom Lane wrote: > BTW, while you're messing with it, can you fix the random one-character > lossage that so frequently happens in the list of file names? While we're asking for improvements to pgsql-committers, would it be possible for you to make it easier to view the "diff" for a particular CVS commit from the message describing the commit that is sent to -committers? For example, the -committers email could include the cvsweb URLs needed to view the diff, or the entire diff could be included in the email if it is small enough. -Neil
On Thu, 20 May 2004, Neil Conway wrote: > Tom Lane wrote: > > BTW, while you're messing with it, can you fix the random one-character > > lossage that so frequently happens in the list of file names? > > While we're asking for improvements to pgsql-committers, would it be > possible for you to make it easier to view the "diff" for a particular > CVS commit from the message describing the commit that is sent to > -committers? For example, the -committers email could include the cvsweb > URLs needed to view the diff, or the entire diff could be included in > the email if it is small enough. I can't see this really being possible ... have you seen this on another project? For the really simple commits, sure ... but for the more complex ones, we'd been talking a load of URLs, for each of the different files being updated ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > I can't see this really being possible ... have you seen this on another > project? Sure, it's quite common. There's a list of scripts that support this kind of functionality at the bottom of this page: http://www.badgers-in-foil.co.uk/projects/cvsspam/ So there are plenty of alternatives to choose from. For example, David Wheeler's "activitymail" can be instructed via a command-line argument to include inline diffs, or include diffs as attachments: http://search.cpan.org/~dwheeler/activitymail/ (that functionality described in "README") Whereas "cvslog" seems to support both including the entire diff with the message or including CVSWeb URLs: http://www.eyrie.org/~eagle/software/cvslog/ > For the really simple commits, sure ... but for the more complex > ones, we'd been talking a load of URLs, for each of the different files > being updated ... Personally I'd prefer the entire diff to be attached to each -committers mail, which would circumvent this problem. Would others find that objectionable? -Neil
On Thu, 20 May 2004, Neil Conway wrote: > Personally I'd prefer the entire diff to be attached to each -committers > mail, which would circumvent this problem. Would others find that > objectionable? I would really like that. It'd be a lot easier to see what's going on. Jon
On Thu, May 20, 2004 at 08:07:34PM +0000, Jon Jensen wrote: > On Thu, 20 May 2004, Neil Conway wrote: > > > Personally I'd prefer the entire diff to be attached to each -committers > > mail, which would circumvent this problem. Would others find that > > objectionable? > > I would really like that. It'd be a lot easier to see what's going on. I agree; I actually proposed this some time ago (with less details as to how to actually do it.) -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "El sentido de las cosas no viene de las cosas, sino de las inteligencias que las aplican a sus problemas diarios en busca del progreso." (Ernesto Hernández-Novich)
On Thu, 20 May 2004, Neil Conway wrote: > Marc G. Fournier wrote: > > I can't see this really being possible ... have you seen this on another > > project? > > Sure, it's quite common. There's a list of scripts that support this > kind of functionality at the bottom of this page: > > http://www.badgers-in-foil.co.uk/projects/cvsspam/ > > So there are plenty of alternatives to choose from. For example, David > Wheeler's "activitymail" can be instructed via a command-line argument > to include inline diffs, or include diffs as attachments: > > http://search.cpan.org/~dwheeler/activitymail/ > > (that functionality described in "README") > > Whereas "cvslog" seems to support both including the entire diff with > the message or including CVSWeb URLs: > > http://www.eyrie.org/~eagle/software/cvslog/ > > > For the really simple commits, sure ... but for the more complex > > ones, we'd been talking a load of URLs, for each of the different files > > being updated ... > > Personally I'd prefer the entire diff to be attached to each -committers > mail, which would circumvent this problem. Would others find that > objectionable? 'k, let me look into it when I get back ... but some of those diffs would be humongous, no? Ah well, let me look, I can try it out and if nobody likes it, can always disable the diffs again afterwards ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: >> >>Personally I'd prefer the entire diff to be attached to each -committers >>mail, which would circumvent this problem. Would others find that >>objectionable? >> >> > >'k, let me look into it when I get back ... but some of those diffs would >be humongous, no? Ah well, let me look, I can try it out and if nobody >likes it, can always disable the diffs again afterwards ... > > Perhaps two lists are needed, one for commital summaries and one for full diffs? You'd also want to be careful that someone importing a module didn't have the whole shebang go out ... cheers andrew
Neil Conway wrote: > Personally I'd prefer the entire diff to be attached to each -committers > mail, which would circumvent this problem. Would others find that > objectionable? Not me -- I have often wished for exactly that myself. Joe
Neil Conway <neilc@samurai.com> writes:
> Personally I'd prefer the entire diff to be attached to each -committers
> mail, which would circumvent this problem. Would others find that
> objectionable?
Yes --- way too bulky, not to mention it turns the list archive into a
duplicate of the CVS store. URLs pointing to the individual file diffs
on the cvsweb interface sound reasonable, though.
regards, tom lane
Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > Personally I'd prefer the entire diff to be attached to each -committers > > mail, which would circumvent this problem. Would others find that > > objectionable? > > Yes --- way too bulky, not to mention it turns the list archive into a > duplicate of the CVS store. URLs pointing to the individual file diffs > on the cvsweb interface sound reasonable, though. Agreed, even if the URL is only valid for a week or so. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > Agreed, even if the URL is only valid for a week or so. Why would the URL only be temporarily valid? -Neil
Neil Conway wrote: > Bruce Momjian wrote: > > Agreed, even if the URL is only valid for a week or so. > > Why would the URL only be temporarily valid? If Marc needed to save disk space or something. If we could auto-generate on the fly via a URL, even better. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Thu, 20 May 2004, Bruce Momjian wrote: > Neil Conway wrote: > > Bruce Momjian wrote: > > > Agreed, even if the URL is only valid for a week or so. > > > > Why would the URL only be temporarily valid? > > If Marc needed to save disk space or something. If we could > auto-generate on the fly via a URL, even better. Actaully, it just points the cvsweb interface ... I jus tconverted over t activitymail two secs ago ... let's see how it looks when it comes through ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
k, hasn't come through yet, but looked in the archives and the message looks good ... missed a / for cvsweb, so fixed that ... the Subject line uses the first line of the log message (up to the first . or 72 characters, so the subjects can actually tell a message in itself if you build your log message appropriately ... On Thu, 20 May 2004, Marc G. Fournier wrote: > On Thu, 20 May 2004, Bruce Momjian wrote: > > > Neil Conway wrote: > > > Bruce Momjian wrote: > > > > Agreed, even if the URL is only valid for a week or so. > > > > > > Why would the URL only be temporarily valid? > > > > If Marc needed to save disk space or something. If we could > > auto-generate on the fly via a URL, even better. > > Actaully, it just points the cvsweb interface ... I jus tconverted over t > activitymail two secs ago ... let's see how it looks when it comes through > ... > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, May 20, 2004 at 06:07:15PM -0400, Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > Personally I'd prefer the entire diff to be attached to each -committers > > mail, which would circumvent this problem. Would others find that > > objectionable? > > Yes --- way too bulky, not to mention it turns the list archive into a > duplicate of the CVS store. URLs pointing to the individual file diffs > on the cvsweb interface sound reasonable, though. It's easy to make a non-archived list which would contain the commit messages with diffs, and keep pgsql-committers with only the URLs to cvsweb ... -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "El sabio habla porque tiene algo que decir; el tonto, porque tiene que decir algo" (Platon).
Bruce Momjian wrote: >Neil Conway wrote: > > >>Bruce Momjian wrote: >> >> >>>Agreed, even if the URL is only valid for a week or so. >>> >>> >>Why would the URL only be temporarily valid? >> >> > >If Marc needed to save disk space or something. If we could >auto-generate on the fly via a URL, even better. > That's what cvsweb does ... it will generate a diff between any 2 arbitrary versions of a file on the fly. All you need to know are the revision numbers - e.g. http://developer.postgresql.org/cvsweb.cgi/pgsql-server/configure.diff?r1=1.365&r2=1.366 cheers andrew
Marc G. Fournier wrote: > k, hasn't come through yet, but looked in the archives and the message > looks good ... missed a / for cvsweb, so fixed that ... Looks good, but one minor quibble: the URL is to the cvsweb page for the file in question, not the diff for the change to the file described by the commit message. The latter would probably be more useful, and would mean the diff would be easily accessible when browsing the archives. Is this possible? -Neil
Neil Conway <neilc@samurai.com> writes:
> Marc G. Fournier wrote:
>> k, hasn't come through yet, but looked in the archives and the message
>> looks good ... missed a / for cvsweb, so fixed that ...
> Looks good, but one minor quibble: the URL is to the cvsweb page for the
> file in question, not the diff for the change to the file described by
> the commit message. The latter would probably be more useful, and would
> mean the diff would be easily accessible when browsing the archives. Is
> this possible?
Only if the script has access to the old and new revision numbers for
the file ... does it?
regards, tom lane
On Thu, 20 May 2004, Neil Conway wrote: > Marc G. Fournier wrote: > > k, hasn't come through yet, but looked in the archives and the message > > looks good ... missed a / for cvsweb, so fixed that ... > > Looks good, but one minor quibble: the URL is to the cvsweb page for the > file in question, not the diff for the change to the file described by > the commit message. The latter would probably be more useful, and would > mean the diff would be easily accessible when browsing the archives. Is > this possible? Not that I can tell from the man page ... but I just added the -V option so that old/new revision #s are added at the end of the file name itself ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 20 May 2004, Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > Marc G. Fournier wrote: > >> k, hasn't come through yet, but looked in the archives and the message > >> looks good ... missed a / for cvsweb, so fixed that ... > > > Looks good, but one minor quibble: the URL is to the cvsweb page for the > > file in question, not the diff for the change to the file described by > > the commit message. The latter would probably be more useful, and would > > mean the diff would be easily accessible when browsing the archives. Is > > this possible? > > Only if the script has access to the old and new revision numbers for > the file ... does it? It does, but it doesn't seem to append it for cvsweb itself ... I think the issue there might be that there are different web interfaces, so it wuold be difficult to support them all ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Nope, was wrong ... adding the -V does add teh revision to the end of the URL ... On Thu, 20 May 2004, Marc G. Fournier wrote: > On Thu, 20 May 2004, Tom Lane wrote: > > > Neil Conway <neilc@samurai.com> writes: > > > Marc G. Fournier wrote: > > >> k, hasn't come through yet, but looked in the archives and the message > > >> looks good ... missed a / for cvsweb, so fixed that ... > > > > > Looks good, but one minor quibble: the URL is to the cvsweb page for the > > > file in question, not the diff for the change to the file described by > > > the commit message. The latter would probably be more useful, and would > > > mean the diff would be easily accessible when browsing the archives. Is > > > this possible? > > > > Only if the script has access to the old and new revision numbers for > > the file ... does it? > > It does, but it doesn't seem to append it for cvsweb itself ... I think > the issue there might be that there are different web interfaces, so it > wuold be difficult to support them all ... > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
>> 'k, let me look into it when I get back ... but some of those diffs would >> be humongous, no? Ah well, let me look, I can try it out and if nobody >> likes it, can always disable the diffs again afterwards ... Showing diffs will also allow more eyes to find little bugs in the patches. Chris
Andrew Dunstan wrote: > >>Why would the URL only be temporarily valid? > >> > >> > > > >If Marc needed to save disk space or something. If we could > >auto-generate on the fly via a URL, even better. > > > > That's what cvsweb does ... it will generate a diff between any 2 > arbitrary versions of a file on the fly. All you need to know are the > revision numbers - e.g. > http://developer.postgresql.org/cvsweb.cgi/pgsql-server/configure.diff?r1=1.365&r2=1.366 My point is that for any non-trivial patch, you need to see all the files modified in a single view, rather than poke around to see different changes made to different files. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Thu, 20 May 2004, Bruce Momjian wrote: > Andrew Dunstan wrote: > > >>Why would the URL only be temporarily valid? > > >> > > >> > > > > > >If Marc needed to save disk space or something. If we could > > >auto-generate on the fly via a URL, even better. > > > > > > > That's what cvsweb does ... it will generate a diff between any 2 > > arbitrary versions of a file on the fly. All you need to know are the > > revision numbers - e.g. > > http://developer.postgresql.org/cvsweb.cgi/pgsql-server/configure.diff?r1=1.365&r2=1.366 > > My point is that for any non-trivial patch, you need to see all the > files modified in a single view, rather than poke around to see > different changes made to different files. I can enable the diff attachment for commit messages ... I just fear the size of the email going out for some of the large patches that are applied ... Tom appears to be against, everyone else seems to be for ... should we try it and see how it works out? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Thu, 20 May 2004, Bruce Momjian wrote: >>My point is that for any non-trivial patch, you need to see all the >>files modified in a single view, rather than poke around to see >>different changes made to different files. > > Tom appears to be against, everyone else seems to be for ... should we try > it and see how it works out? Could the entire diff be saved as a file and linked with a single URL? Joe
On Thu, 20 May 2004, Joe Conway wrote: > Marc G. Fournier wrote: > > On Thu, 20 May 2004, Bruce Momjian wrote: > >>My point is that for any non-trivial patch, you need to see all the > >>files modified in a single view, rather than poke around to see > >>different changes made to different files. > > > > Tom appears to be against, everyone else seems to be for ... should we try > > it and see how it works out? > > Could the entire diff be saved as a file and linked with a single URL? There do not appear to be any options for this in the software ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Fri, 21 May 2004, Neil Conway wrote: > Marc G. Fournier wrote: > > Tom appears to be against, everyone else seems to be for ... should we try > > it and see how it works out? > > Sure, although I personally think Andrew's suggestion of creating a > separate (non-archived) list that includes the full diff is the best > solution. That satisfies both of Tom's gripes: it is "bulky", yes, but > those who are against "bulkiness" can just subscribe to the old list, > and it won't bloat the size of the list archives. Can you have two DEFAULT lines in loginfo/commitinfo? Seems to defeat the concept of "default" :0 ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> I can enable the diff attachment for commit messages ... I just fear the
> size of the email going out for some of the large patches that are applied
That's my problem too. Someone suggested creating two mail lists, one
non-archived with the full diffs and one archived with the URLs only.
I like that idea since it doesn't bloat the archives and it lets people
choose what they want in their inbox --- can we do it that way?
Also, the new setup where the subject line is the first line of the
commit message seems cool to me, but if we're going to feed multiple
projects' commit messages into the same list then we'd better add the
project name to the subject.
regards, tom lane
Marc G. Fournier wrote: > Tom appears to be against, everyone else seems to be for ... should we try > it and see how it works out? Sure, although I personally think Andrew's suggestion of creating a separate (non-archived) list that includes the full diff is the best solution. That satisfies both of Tom's gripes: it is "bulky", yes, but those who are against "bulkiness" can just subscribe to the old list, and it won't bloat the size of the list archives. -Neil
On Fri, 21 May 2004, Tom Lane wrote: > Also, the new setup where the subject line is the first line of the > commit message seems cool to me, but if we're going to feed multiple > projects' commit messages into the same list then we'd better add the > project name to the subject. Done ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664