Re: Releasing in September

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