Andres Freund <and...@anarazel.de> writes:
> Thus I'm trying to summarize my understanding in this email. It probably
> doesn't 100% match other people's understanding. After we've resolved
> those differences, we should update the wiki page, and delete outdated
> content.

> Commitfests primarily exists so:

> - we do not accidentally loose track of patch submissions that deserve
>   attention, that previously happened frequently
> - that reviewers and committers quickly can find patches deserving their
>   attention (i.e. ones in in needs-review and ready-for-committer
>   respectively)
> - that there's a single point documenting the state of the patch, to
>   avoid situations where different people interpret a thread differently
>   without noticing.

I think that third point is at best an idealized statement, and it's not
very reflective of actual practice.  We're not great about updating the CF
entry's state, and even if we were, I don't think there's a bright line
between Needs Review and Waiting On Author.  There may have been enough
feedback provided so that the author has something to do, yet not so much
that there's no point in further review.  So maybe there's something that
can be improved about the CF tool there.  But anyway you said you wanted
to summarize current actual practice, and this isn't quite what really
happens IME.

There are a couple of meta-goals as well, although I'm not sure whether
they belong in this document:

* Encourage people to review other people's patches.  This isn't just
to make the patches better, it's to make the reviewers better: they
gain familiarity with the PG code base.

* Ensure that committers don't have to *always* feel guilty about
not working on other people's patches instead of their own.  Otherwise
we'd just stay in CF mode all the time.

> Submitting a patch as a commitfest entry to a specific commitfest
> implies a statement by the author that the patch needs input from
> others. That input can be agreement on design decisions, high level code
> review, testing, etc.

... or even just that the author would like somebody to commit it.

Also, there's at least one rule you forgot to cover, concerning
asking people to review patches more or less proportionally to the
amount of patches they've submitted.  This is surely a lot squishier
than the other rules, but without it, nothing much happens.

                        regards, tom lane

Reply via email to