Re: How can I check the treatment of bug fixes? - Mailing list pgsql-hackers

On Fri, May 27, 2011 at 5:54 PM, Andres Freund <andres@anarazel.de> wrote:
> If I see a bug in a region I know something about and its on a platform I care
> about (i.e. likely only linux) I try to do this. But its hard, in most
> situations one of you already did it. Tom and you are just to goddamn fast in
> many, many cases. Which is totally great, don't get me wrong, but makes it
> hard to beat you as a mere mortal ;)

It's funny to be lumped in with Tom, who leaves me in the dust!

But the problem is really with the bugs that never get a response, not
the ones that do.  There are no shortage of things that neither Tom
nor I nor anyone else is working on.

> Do you like separate patches for the back branches or is that basically
> useless work?

If it doesn't apply cleanly, yes.  It's also quite helpful to identify
how far the back-patch can reasonably go, and why.

> Related to doing stuff like that is that I really find it hard to write a patch
> that happens to be liked by Tom or you so it does not have to be mostly
> rewritten. For that to change for one I would like to have the Coding Style to
> be expanded because I think there are loads of rules that exist only in bits
> and bits on the mailing lists. For another I would like to get a patch back
> instead of rewritten because without knowing the individual reasons for the
> changes its sometimes rather hard to know what the reason for a specific change
> was. I do realize thats quite a bit of work for you which is why I hesitated
> writing that...

Well, frankly, I think you're doing pretty well.  I find it's quite
helpful to have a patch to start with, even if I don't agree with the
approach, because it gives me an idea of what portions of the code
need to be changed and often makes it easier to understand what is
broken.  But in your particular case, your recent patches have gone in
with minimal changes.  I tend to avoid spelling out all the details
on-list because I don't want to be seen as nit-picking.  If something
is a logic error or one or more places that needed to be changed were
altogether ignored, then I usually mention that, because those are,
well, important.  But if I reindented the code to make pg_indent
mangle it less or corrected a typo in a comment or simplified
something like:

if (something)
{  do stuff;
}
else  break;
more things;

to:

if (!something)  break;
do stuff;
more things;

...then I don't tend to mention that, first because it's sort of
self-evident that the second one is clearer, second because I don't
want to demoralize people who have done basically good work by
pointing out trivial flaws, and third because it's a bit
time-consuming.  But that really is third.  If you want to know why I
did something, feel free to ask.

I have been really pleased to see that there is a growing group of
people who I can rely on to submit good stuff most of the time, stuff
that I can apply without spending a lot of time on it.  If I were less
busy, I might spend more time hacking on patches that were marginal,
as I know Tom still does sometimes.  But I just don't have the cycles
for it.  It's far faster for me to read the patch and list the issues
than it is to fix them, unless the issues are trivial cosmetic stuff.
If there were fewer patches, I might spend more time hacking on
marginal patches, but as it is I mostly do that when I think that the
patch won't go in any other way.  Actually, I think it's kind of good
that the volume is such as to preclude my doing that very often.  It's
not so good for the patches that get bounced for lack of attention,
but I think overall the average quality of patches is improving
(perhaps partly for that reason?), and I expect that some of the
better and more prolific submitters will eventually get commit bits of
their own.  I can only hope that some of those people will be
interested in helping with the CF work.  It is easy to find people who
are willing to commit their own patches.  Finding people who are
willing to commit other people's patches is the tough part.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company