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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
