Skip site navigation (1) Skip section navigation (2)

Re: automating CF submissions (was xlog location arithmetic)

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: automating CF submissions (was xlog location arithmetic)
Date: 2012-01-15 04:44:08
Message-ID: 4F125998.5020204@2ndQuadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 01/14/2012 10:49 PM, Gurjeet Singh wrote:
> So lets make it easy for the patch submitter to start the process. I 
> propose that we have a page in the CF application where people can 
> upload/attach the patch, and the app posts the patch to -hackers and 
> uses the post URL to create the CF entry.
>

That would be nice, but there's at least two serious problems with it, 
which I would guess are both unsolvable without adding an unsupportable 
amount of work to the current PostgreSQL web team.  First, it is 
technically risky for a web application hosted on postgresql.org to be 
e-mailing this list.  There are some things in the infrastructure that 
do that already--I believe the pgsql-commiters list being driven from 
commits is the busiest such bot.  But all of the ones that currently 
exist are either moderated, have a limited number of approved 
submitters, or both.

If it were possible for a bot to create a postgresql.org community 
account, then trigger an e-mail to pgsql-hackers just by filling out a 
web form, I'd give it maybe six months before it has to be turned off 
for a bit--because there are thousands messages queued up once the first 
bored spammer figures that out.  Securing web to e-mail gateways is a 
giant headache, and everyone working on the PostgreSQL infrastructure 
who might work on that is already overloaded with community volunteer 
work.  There's an element of zero-sum game here:  while this would 
provide some assistance to new contributors, the time to build and 
maintain the thing would be coming mainly out of senior contributors.  I 
see the gain+risk vs. reward here skewed the wrong way.

Second, e-mail provides some level of validation that patches being 
submitted are coming from the person they claim.  We currently reject 
patches that are only shared with the community on the web, via places 
like github.  The process around this mailing list tries to make it 
clear sending patches to here is a code submission under the PostgreSQL 
license.  And e-mail nowadays keeps increasing the number of checks that 
confirm it's coming from the person it claims sent it.  I can go check 
into the DKIM credentials your Gmail message to the list contained if 
I'd like, to help confirm it really came from your account.  E-mail 
headers are certainly not perfectly traceable and audit-able, but they 
are far better than what you'd get from a web submission.  Little audit 
trail there beyond "came from this IP address".

One unicorn I would like to have here would give the CF app a database 
of recent e-mails to pgsql-hackers.  I login to the CF app, click on 
"Add recent submission", and anything matching my e-mail address appears 
with a checkbox next to it.  Click on the patch submissions, and then 
something like you described would happen.  That would save me the 
annoying work around looking up message IDs so much.

The role CF manager would benefit even more from infrastructure like 
that too.  Something that listed all the recent e-mail messages for an 
existing submission, such that you could just click on the ones that you 
wanted added to the patch's e-mail history, would save me personally 
enough time that I could probably even justify writing it.

-- 
Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2012-01-15 04:49:54
Subject: Re: foreign key locks, 2nd attempt
Previous:From: Gurjeet SinghDate: 2012-01-15 03:49:00
Subject: Re: xlog location arithmetic

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group