Thread: Github commit messages to pgsql-www
What do we want to do with them... Andrew has set it up for the bulidfarm client code, and it does work, except they get caught in the moderator queue - becuase they are sent from noreply@github.com. The way I see it we have a couple of options for making this work: 1) Whiltelist noreply@github.com. We have no way of controlling this though, so *anybody* with a github repo can have it sent there, and they all come from the same address. I don't think we can whitelist on the combination of email and some part of the email,thus filtering based on repo. 2) Just moderate the commit messages as they show up. 3) Ask Andrew to move the primary to git.postgresql.org and use the commit message hook there, that will send the emails as the person who committed the patch (like we do for pgadmin for example). This has the advantage of allowing individual moderation, and the disadvantage that it doesn't scale if we want to end up with lots of repositories management-wise... Thoughts? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, 2011-01-25 at 20:55 +0100, Magnus Hagander wrote: > What do we want to do with them... > > Andrew has set it up for the bulidfarm client code, and it does work, > except they get caught in the moderator queue - becuase they are sent > from noreply@github.com. The way I see it we have a couple of options > for making this work: > > 1) Whiltelist noreply@github.com. We have no way of controlling this > though, so *anybody* with a github repo can have it sent there, and > they all come from the same address. I don't think we can whitelist on > the combination of email and some part of the email,thus filtering > based on repo. > > 2) Just moderate the commit messages as they show up. > > 3) Ask Andrew to move the primary to git.postgresql.org and use the > commit message hook there, that will send the emails as the person who > committed the patch (like we do for pgadmin for example). This has the > advantage of allowing individual moderation, and the disadvantage that > it doesn't scale if we want to end up with lots of repositories > management-wise... > If we are bouncing to .Org it seems we should be using .Org. I certainly don't want to moderate commit messages. JD > Thoughts? > > -- > Magnus Hagander > Me: http://www.hagander.net/ > Work: http://www.redpill-linpro.com/ > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Tue, Jan 25, 2011 at 7:55 PM, Magnus Hagander <magnus@hagander.net> wrote: > What do we want to do with them... > > Andrew has set it up for the bulidfarm client code, and it does work, > except they get caught in the moderator queue - becuase they are sent > from noreply@github.com. The way I see it we have a couple of options > for making this work: > > 1) Whiltelist noreply@github.com. We have no way of controlling this > though, so *anybody* with a github repo can have it sent there, and > they all come from the same address. I don't think we can whitelist on > the combination of email and some part of the email,thus filtering > based on repo. > > 2) Just moderate the commit messages as they show up. > > 3) Ask Andrew to move the primary to git.postgresql.org and use the > commit message hook there, that will send the emails as the person who > committed the patch (like we do for pgadmin for example). This has the > advantage of allowing individual moderation, and the disadvantage that > it doesn't scale if we want to end up with lots of repositories > management-wise... > > Thoughts? > Why do we want buildfarm commit messages to come to pgsql-www? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 01/25/2011 03:24 PM, Dave Page wrote: > > Why do we want buildfarm commit messages to come to pgsql-www? It was sent to -committers, not -www. cheers andrew
On Tue, Jan 25, 2011 at 21:24, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Jan 25, 2011 at 7:55 PM, Magnus Hagander <magnus@hagander.net> wrote: >> What do we want to do with them... >> >> Andrew has set it up for the bulidfarm client code, and it does work, >> except they get caught in the moderator queue - becuase they are sent >> from noreply@github.com. The way I see it we have a couple of options >> for making this work: >> >> 1) Whiltelist noreply@github.com. We have no way of controlling this >> though, so *anybody* with a github repo can have it sent there, and >> they all come from the same address. I don't think we can whitelist on >> the combination of email and some part of the email,thus filtering >> based on repo. >> >> 2) Just moderate the commit messages as they show up. >> >> 3) Ask Andrew to move the primary to git.postgresql.org and use the >> commit message hook there, that will send the emails as the person who >> committed the patch (like we do for pgadmin for example). This has the >> advantage of allowing individual moderation, and the disadvantage that >> it doesn't scale if we want to end up with lots of repositories >> management-wise... >> >> Thoughts? >> > > Why do we want buildfarm commit messages to come to pgsql-www? D'uh, stupid typo on my part. Of course, I mean pgsql-committers. Sorry. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Excerpts from Magnus Hagander's message of mar ene 25 16:55:20 -0300 2011: > What do we want to do with them... > > Andrew has set it up for the bulidfarm client code, and it does work, > except they get caught in the moderator queue - becuase they are sent > from noreply@github.com. The way I see it we have a couple of options > for making this work: > > 1) Whiltelist noreply@github.com. We have no way of controlling this > though, so *anybody* with a github repo can have it sent there, and > they all come from the same address. I don't think we can whitelist on > the combination of email and some part of the email,thus filtering > based on repo. > > 2) Just moderate the commit messages as they show up. As a pgsql-committers moderator I am not happy with #2. It would be a lot better if we could somehow do #1 coupled with some filtering that only allows selected projects to go through unmoderated. However, I spent some time looking at Mj2 settings yesterday without success. Could we do #3 but instead of moving the primary to git.pg.org just have a hook or cron'ed task that pushes from github (or pulls from it)? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, Jan 26, 2011 at 15:14, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Magnus Hagander's message of mar ene 25 16:55:20 -0300 2011: >> What do we want to do with them... >> >> Andrew has set it up for the bulidfarm client code, and it does work, >> except they get caught in the moderator queue - becuase they are sent >> from noreply@github.com. The way I see it we have a couple of options >> for making this work: >> >> 1) Whiltelist noreply@github.com. We have no way of controlling this >> though, so *anybody* with a github repo can have it sent there, and >> they all come from the same address. I don't think we can whitelist on >> the combination of email and some part of the email,thus filtering >> based on repo. >> >> 2) Just moderate the commit messages as they show up. > > As a pgsql-committers moderator I am not happy with #2. It would be a > lot better if we could somehow do #1 coupled with some filtering that > only allows selected projects to go through unmoderated. However, I > spent some time looking at Mj2 settings yesterday without success. Yeah, I doubt that's actually workable :( > Could we do #3 but instead of moving the primary to git.pg.org just have > a hook or cron'ed task that pushes from github (or pulls from it)? Sure, you can do something like that, but it has the same basic "scalability problem" - all the repos need to be created and maintained on git.postgresql.org. Plus it requires a push hook at github (because the mail scripts fire on receive, so it needs to be a push), which I don't think they support. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Jan 26, 2011 at 15:14, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>> Could we do #3 but instead of moving the primary to git.pg.org just have
>> a hook or cron'ed task that pushes from github (or pulls from it)?
> Sure, you can do something like that, but it has the same basic
> "scalability problem" - all the repos need to be created and
> maintained on git.postgresql.org.
> Plus it requires a push hook at github (because the mail scripts fire
> on receive, so it needs to be a push), which I don't think they
> support.
Personally I think there is way too much third-party crap showing up on
pgsql-committers already. I am very close to changing my filters to
bit-bucket *everything* out of pgfoundry, and you can bet that if stuff
from github starts being allowed through, it will go straight to
/dev/null here.
What I'd like to see is a reversion to the original design wherein
commit traffic for pgfoundry projects goes to lists for those individual
projects. As for github, people who want to watch that can watch it,
but please don't clutter pgsql-committers with it.
regards, tom lane
Excerpts from Tom Lane's message of mié ene 26 12:56:57 -0300 2011: > Personally I think there is way too much third-party crap showing up on > pgsql-committers already. I am very close to changing my filters to > bit-bucket *everything* out of pgfoundry, and you can bet that if stuff > from github starts being allowed through, it will go straight to > /dev/null here. +1 > What I'd like to see is a reversion to the original design wherein > commit traffic for pgfoundry projects goes to lists for those individual > projects. As for github, people who want to watch that can watch it, > but please don't clutter pgsql-committers with it. +1 I would even clean up the old Majordomo archives so that the pgfoundry stuff is elsewhere ... except that it would change the URLs for the remaining messages. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 01/26/2011 10:56 AM, Tom Lane wrote: > Personally I think there is way too much third-party crap showing up on > pgsql-committers already. I am very close to changing my filters to > bit-bucket *everything* out of pgfoundry, and you can bet that if stuff > from github starts being allowed through, it will go straight to > /dev/null here. That's your privilege. Personally, I filter committers into two buckets: pgsql and everything else. The everything else folder often only gets looked at once a week or so. But I do find it useful to see what's going on elsewhere. The reason I moved the buildfarm client code to github is that pgfoundry doesn't support git, and I like github's web interface much more than the generic one we're using on git.postgresql.org. The buildfarm server code has never been on pgfoundry, but when I published it recently I again chose github, for the same reasons. > What I'd like to see is a reversion to the original design wherein > commit traffic for pgfoundry projects goes to lists for those individual > projects. As for github, people who want to watch that can watch it, > but please don't clutter pgsql-committers with it. I'm not sure where the original design bit comes in. I was involved heavily in setting up pgfoundry (not sure if that's a claim to fame or infamy, but my excuse is that Josh shanghaied me) and this has been part of its behaviour from the start, IIRC. Certainly I can set up a mailing list on pgfoundry and send commit messages there. I was simply trying to fit in with existing practice. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On 01/26/2011 10:56 AM, Tom Lane wrote:
>> What I'd like to see is a reversion to the original design wherein
>> commit traffic for pgfoundry projects goes to lists for those individual
>> projects. As for github, people who want to watch that can watch it,
>> but please don't clutter pgsql-committers with it.
> I'm not sure where the original design bit comes in. I was involved
> heavily in setting up pgfoundry (not sure if that's a claim to fame or
> infamy, but my excuse is that Josh shanghaied me) and this has been part
> of its behaviour from the start, IIRC.
Well, how come creation of a foo project results in automatic creation
of a foo-committers list there, if there was no expectation of ever
actually using that list? I know this is still happening because it
happened last week when I set up pg_filedump at pgfoundry. I was rather
annoyed when I found out that the commit traffic actually went to
pgsql-committers.
regards, tom lane
On 01/26/2011 11:34 AM, Tom Lane wrote: > > Well, how come creation of a foo project results in automatic creation > of a foo-committers list there, if there was no expectation of ever > actually using that list? I know this is still happening because it > happened last week when I set up pg_filedump at pgfoundry. I was rather > annoyed when I found out that the commit traffic actually went to > pgsql-committers. > > Probably inattention on the part of the admins (including me), but I honestly don't recall. I know that the mail setup was discussed at the time. cheers andrew
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > > On Wed, Jan 26, 2011 at 15:14, Alvaro Herrera > > <alvherre@commandprompt.com> wrote: > >> Could we do #3 but instead of moving the primary to git.pg.org just have > >> a hook or cron'ed task that pushes from github (or pulls from it)? > > > Sure, you can do something like that, but it has the same basic > > "scalability problem" - all the repos need to be created and > > maintained on git.postgresql.org. > > > Plus it requires a push hook at github (because the mail scripts fire > > on receive, so it needs to be a push), which I don't think they > > support. > > Personally I think there is way too much third-party crap showing up on > pgsql-committers already. I am very close to changing my filters to > bit-bucket *everything* out of pgfoundry, and you can bet that if stuff > from github starts being allowed through, it will go straight to > /dev/null here. I did that years ago. I allow only pgfoundry projects I am interested in to flow through. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 26 January 2011 16:03, Alvaro Herrera <alvherre@commandprompt.com> wrote: > I would even clean up the old Majordomo archives so that the pgfoundry > stuff is elsewhere ... except that it would change the URLs for the > remaining messages. +1 I'd much prefer that. There's already *-commits, so a pgfoundry-commits supergroup could be introduced for those wishing to subscribe to everything that goes through pgfoundry, if such a list is really wanted. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935