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

Re: [HACKERS] commitfest management webapp

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, pgsql-www(at)postgresql(dot)org
Subject: Re: [HACKERS] commitfest management webapp
Date: 2009-05-27 02:15:58
Message-ID: alpine.GSO.2.01.0905262135350.7909@westnet.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-www
On Tue, 26 May 2009, Robert Haas wrote:

> I'm open to suggestions on how to improve this situation, though, 
> because it's definitely not ideal, and precludes things that reasonable 
> people might want to do, like "contact the guy who submitted this 
> patch", "contact the authors of all patches waiting for review", and 
> similar.

Since you're taking the message-id where the patch was submitted at as an 
input, couldn't you scrape this information out of the archives?  You 
probably want to do a bit of that regardless; having the program pull and 
display the author and subject line of the archived message is a good 
sanity check that you entered the message ID correctly.

> I know that there are some of you reading this who may think that we 
> should convert to reviewboard or patchwork or some other system.  I can 
> say that personally I'm unimpressed by those suggestions because they 
> will almost certainly require process changes that this does not

We used Reviewboard a fair amount here at Truviso for a while.  Lately a 
good chunk of that patch review has been happening more efficiently by 
passing pointers to private git branches around instead.  I think you're 
right to focus on just the review workflow and not the patch review 
itself, let people use whatever tools they're already comfortable with for 
that part.

I just spent a few minutes poking around your code and that quickly was 
able to see how things fit together, which is certainly not something I 
can say about Reviewboard etc.  The interface looks good and the code easy 
enough to improve.  The main concerns I'm left with after that review are 
with how to properly test the security of the code.  Some maturity there 
is one major thing that more packages in larger use have going for them 
vs. rolling your own in this sort of situation.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

pgsql-www by date

Next:From: Alvaro HerreraDate: 2009-05-27 02:53:00
Subject: Re: commitfest management webapp
Previous:From: Tatsuo IshiiDate: 2009-05-27 02:09:59
Subject: Re: [sysadmins] Two upgrades this weekend ...

pgsql-hackers by date

Next:From: Mark WongDate: 2009-05-27 02:51:05
Subject: survey of WAL blocksize changes
Previous:From: Greg SmithDate: 2009-05-27 02:08:21
Subject: Re: effects of posix_fadvise on WAL logs

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