Re: Releasing in September - Mailing list pgsql-hackers

From Torsten Zühlsdorff
Subject Re: Releasing in September
Date
Msg-id 56A5D35D.5010603@toco-domains.de
Whole thread Raw
In response to Re: Releasing in September  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Releasing in September  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On 20.01.2016 22:37, Peter Eisentraut wrote:
> On 1/20/16 1:44 PM, Robert Haas wrote:
>> And, you know, I did my time fighting major wars to try to compress
>> the release schedule, and honestly, it wasn't that much fun.  The
>> process we have now is imperfect in many ways, but I no longer have
>> abuse heaped on me for wanting to boot a patch out of a CommitFest.
>> That may be bad for the project, but it's spared me a lot of grief
>> personally.  I think that many other people are in the same situation.
>> Everybody would like somebody else to be the schedule enforcer ...
>> unless they have something that they still want to get in, in which
>> case they would like nobody to do it.
>
> Yeah, a lot of the ideas in this thread, while reasonable, are of the
> sort "We need to be better about ..." which sounds a lot like "I need to
> be better about exercising".  A system based purely on distributed
> willpower isn't going to last very long, as we are finding out.
>
> Sure, I'd like more than one party to review my patches, and I'd like to
> spend more time doing additional reviews on other people's patches.  But
> I can barely keep up as it is.  I know we need code reviews, but I think
> it's never going to work well to the point that we are satisfied with
> it.  Just look around the world, in software, open or commercial, or
> even academics, and tell me who has peer reviews figured out.

Nobody, but there are different solutions. And the same solutions works 
different in quality and quantity in the different projects.
In FreeBSD for example there is an online tool for review 
(http://review.freebsd.org) which was opened to public. There you can 
review any code, left comments in the parts you wanted, submit different 
users to it etc.
It is not perfect, but a huge step forward for the project. And 
something i misses here often.
But as stated earlier in another thread: for a not-so-deep-involved 
volunteer, it is often unclear *what* to review. The threads are long 
and often there is no final description about how the patch is supposed 
to work. That make testing quite hard and time consuming.

It is not just about the schedule, the reviewer and participants. Its 
also some more basic.

Greetings,
Torsten



pgsql-hackers by date:

Previous
From: Rushabh Lathia
Date:
Subject: Re: Optimization for updating foreign tables in Postgres FDW
Next
From: Torsten Zühlsdorff
Date:
Subject: Re: Batch update of indexes