Thread: 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@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On 16 November 2012 07:20, Greg Smith <greg@2ndquadrant.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@2ndquadrant.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@fuzzy.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@fuzzy.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@2ndquadrant.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@2ndquadrant.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