Re: CommitFest #3 and upcoming schedule

The third CommitFest for PostgreSQL 9.3 development is now officially
active. If you have the time and interest to review one of the many
patches submitted, claim it by adding yourself as a reviewer in the
CommitFest application at
https://commitfest.postgresql.org/action/commitfest_view?id=16

Project guidelines now ask each patch submitter to review patches of the
same number and approximate complexity as they submit. If you've
submitted some items to the CommitFest, please look at the open list and
try to find something you can review.

If you want to contribute to the development of PostgreSQL and you
haven't yet reviewed any patches yet, please read
http://wiki.postgresql.org/wiki/CommitFest and follow the appropriate
links for information about getting started. You necessarily don't need
to be a C coder to help. We need people to test, benchmark, and check
documentation, too. If you'd like to try reviewing but are not sure
which patch you want to look at, please send me an email off-list with
your areas of interest and a summary of your skill-set; I can help you
pick one.

This CF is scheduled to run from the 15th of November to the 15th of
December. Starting now any new patches should now be submitted to the
next CF, the last one for 9.3:
https://commitfest.postgresql.org/action/commitfest_view?id=17

I just moved a more readable copy of the schedule made during the 2012
Developer's Meeting to
http://wiki.postgresql.org/wiki/PostgreSQL_9.3_Development_Plan to help
make some changes made in the community development process easier to
see. There are two new ideas there worth explaining as we approach the
two periods they'll occur during.

The last week of this CommitFest (December 8 to 15) will include a new
planning week. This aims to help plan what work will be done up to and
during the final CF for 9.3, starting on January 15. The idea is to
make sure large features have identified reviewers and committers, and
determine whether it seems feasible to complete them during this
release. Last year the final CommitFest for the 9.2 release included a
large number of submissions that significantly delayed moving toward
feature freeze. The planning week hopes to identify things that risk
schedule slip again and set better expectations for them. Large code
submissions that arrive later, such that they haven't already been
addressed during that planning week, are unlikely to be considered for
commit in 9.3.

The other change is for the final 9.3 CommitFest, which is adding a
"triage" focus from Feb 1–7. The idea here is to focus on the sometimes
hard decisions about whether the new features still being worked on just
needs a final push of work, or if they are simply not ready to commit yet.

There are 67 code submissions and 7 documentation patches open right now
for today's 9.3 CF#3 2012-11. That makes this large but not
unprecedented. Last year at this time there were 47 code entries open,
and the record 2012-01 CF opened with 96 submissions.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

On 16 November 2012 07:20, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:

> Project guidelines now ask each patch submitter to review patches of the
> same number and approximate complexity as they submit. If you've submitted
> some items to the CommitFest, please look at the open list and try to find
> something you can review.

The deadline for 9.3 is looming and many patches have not yet been reviewed.

I'm sending a public reminder to all patch authors that they should
review other people's patches if they expect their own to be reviewed.

Simply put, if you don't help each other by reviewing other patches
then the inevitable result will be your patch will not be neither
reviewed nor committed.

PostgreSQL has always maintained high standards and the QA process for
all code is for it to be reviewed/discussed prior to commit, which is
known as "peer review". The PostgreSQL project is fortunate to have so
many keen developers, though for some time now there has been an
imbalance between the amount of code to review and the amount of time
available to do those reviews. I suggested that we encourage peer
review by developers, on the basis of "one patch, one review" as a way
of solving the problem. Since many/most people are submitting patches
as part of their professional job, this message needs to be passed on
to your bosses so they are able to allocate sufficient time for you to
do both development *and* peer review. Future planning needs to take
into account the time/cost of both of those tasks.

Let's bring balance to the situation through our own actions. Please
review one patch now for every one you submitted.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On 9.12.2012 16:56, Simon Riggs wrote:
> On 16 November 2012 07:20, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>
>> Project guidelines now ask each patch submitter to review patches of the
>> same number and approximate complexity as they submit. If you've submitted
>> some items to the CommitFest, please look at the open list and try to find
>> something you can review.
>
> The deadline for 9.3 is looming and many patches have not yet been reviewed.
>
> I'm sending a public reminder to all patch authors that they should
> review other people's patches if they expect their own to be reviewed.
>
> Simply put, if you don't help each other by reviewing other patches
> then the inevitable result will be your patch will not be neither
> reviewed nor committed.

IMHO many of the patches that are currently marked as "needs review" and
have no reviewers, were actually reviewed or are being discussed
thoroughly on the list, but this information was not propagated to the
CF page.

Not sure how to fix this except for updating patches that I've reviewed
and urging the others to do the same.

Tomas

On Sun, Dec 9, 2012 at 10:47 AM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>
> IMHO many of the patches that are currently marked as "needs review" and
> have no reviewers, were actually reviewed or are being discussed
> thoroughly on the list, but this information was not propagated to the
> CF page.

Should active discussion on the hackers list prevent someone from
doing a review? I know I am reluctant to review a patch when it seems
it is still being actively redesigned/debated by others.

Maybe a new status of "needs design consensus" would be useful.

Cheers,

Jeff

On 9.12.2012 22:41, Jeff Janes wrote:
> On Sun, Dec 9, 2012 at 10:47 AM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>>
>> IMHO many of the patches that are currently marked as "needs review" and
>> have no reviewers, were actually reviewed or are being discussed
>> thoroughly on the list, but this information was not propagated to the
>> CF page.
>
> Should active discussion on the hackers list prevent someone from
> doing a review? I know I am reluctant to review a patch when it seems
> it is still being actively redesigned/debated by others.
>
> Maybe a new status of "needs design consensus" would be useful.

IMHO introducing new statuses won't improve the state. Moreover reaching
a design consensus is a natural part of the review process.

I see those discussions as a part of the review process, so it's not
that an active discussion means 'no review' (although the CF page states
"needs review" or "no reviewer" for such patches).

There's nothing wrong with doing yet another review for a patch, but in
most cases I tend to agree with the points already raised in the
discussion so it's not really productive. Thus I share the same
reluctance to do more reviews for those actively discussed patches.

My point is that some of the "idle patches" are actually quite active in
the background, no one just updated the CF page. And I see many such
patches moved forward over the last few days.

Tomas

On Sunday, December 09, 2012 9:27 PM Simon Riggs
> On 16 November 2012 07:20, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>
>
> Let's bring balance to the situation through our own actions. Please
> review one patch now for every one you submitted.

In CF-3, I am Author of 5 and Reviewer of 5

3 of my patches as Author have been moved from CF-2
4 of the patches where I am reviewer have been moved from CF-2

One of my Patch : Patch for option in pg_resetxlog for restore from WAL
files
is dependent on another patch XLogReader, so I am expecting to get it done
only after XLogReader.

I wanted to know if I should attach myself as reviewer to more patches as
per initial policy of CF?

In anycase as soon as I get time I shall review more patches.

With Regards,
Amit Kapila.

On 2012-12-10 09:22:25 +0530, Amit Kapila wrote:
> On Sunday, December 09, 2012 9:27 PM Simon Riggs
> > On 16 November 2012 07:20, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> >
> >
> > Let's bring balance to the situation through our own actions. Please
> > review one patch now for every one you submitted.
>
> In CF-3, I am Author of 5 and Reviewer of 5
>
> 3 of my patches as Author have been moved from CF-2

You're not alone in that ;)

> 4 of the patches where I am reviewer have been moved from CF-2
>
> One of my Patch : Patch for option in pg_resetxlog for restore from WAL
> files
> is dependent on another patch XLogReader, so I am expecting to get it done
> only after XLogReader.

Btw, I posted the current version of this at:
http://archives.postgresql.org/message-id/20121204175212.GB12055%40awork2.anarazel.de

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services