Re: Patch review - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Patch review
Date
Msg-id 87d4r6kkf3.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Patch review  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Responses Re: Patch review
List pgsql-hackers
"Stefan Kaltenbrunner" <stefan@kaltenbrunner.cc> writes:

> Tom Lane wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> Not sure if this is platform-specific, but I keep being annoyed by not being
>>> able to actually *view* the patches in the queue. I have to download them,
>>> and then open them separately. I can't just view them in the browser,
>>> because they're all named ".bin" and come out as mime type
>>> "application/octet-stream".
>>
>> Yeah, it happens that way for me too.  The other huge, huge problem with
>> it is the lack of stability of URLs for the items in the list, which
>> makes it difficult to identify which item you're talking about.
>
> yeah that is fairly annoying :-(

Strangely enough I have the opposite complaint. Sometimes the patch is
displayed inline (seems to be pretty unpredictable) and that makes it hard to
download and apply. If you download the page you have to un-html-escape it and
if you copy-paste the contents the whitespace is messed up.

It would be nice if the patches list were fed into reviewboard or viewcvs or
something like it. Even if we only used it for viewing patches it would at
least make that nice.

I couldn't see how to make it work with reviewboard at first glance. It seems
to assume you're starting form a working tree and wants to generate the diff
and send it in itself. If you generate it yourself then you have to tell it
precisely what it's a diff against. It doesn't seem to expect to be used as a
general purpose patch viewer.

>> Personally I'd be happier with an editable wiki page consisting of links
>> to the original messages in the mail list archives, plus free-format
>> annotations (such as status).  This should be trivial to set up and
>> reasonably flexible.  With experience we might find we need something
>> fancier, but let's not overdesign our solution at the start.
>
> I will see if I can come up with a proposal on the developer wiki for a list
> that looks like that tomorrow.

How powerful are these wiki things? Can you write a script which automatically
inserts a new line in a table in the wiki whenever an email to the patches
list containing a patch comes in?

Can you add buttons on the wiki itself to do common actions like removing the
item from the table or joining it up with another item? That way we would only
have to actually edit the wiki content if we have something substantive to add
such as review comments.

> _IF_ we are looking for an (over)designed solution

I'm against overdesigned solutions. If we want more than a wiki I think it
would be reviewboard. I think something which fills a specific hole like
reviewboard is much more likely to work in the long term than an overarching
solution whose problem description is as vague as a "tracker". As soon as our
process changes the "tracker" will be obsolete whereas a problem-specific
solution like reviewboard will always be useful as long as there are patches
to review.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: Patch review
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: Patch review