Обсуждение: CommitFest 2010-07 now in progress
/me bangs gavel I hereby declare the 2010-07 CommitFest closed to further patch submissions, as it is now officially "In Progress". We have one month to provide initial review of the patches which have accumulated since the start of the last CommitFest, six months ago, and hopefully get a reasonable number of them committed. All reviewers currently assigned to a patch in "Needs Review" status should post a review within the next four days. All authors with patches in "Waiting on Author" status should post a response within four days. If there's a reason that can't happen, please let me know off-list. Some numbers: 68 patches were submitted 3 patches were withdrawn (deleted) by their authors -- 65 total patches currently in the application -- 3 committed to 9.0 -- 62 9.1 patches -- 1 rejected 3 returned with feedback 1 committed for 9.1 -- 57 pending 10 ready for committer -- 47 will still need reviewer attention 6 waiting on author to respond to review -- 41 need review before further action 23 patches "Needs Review" patches don't have a reviewer assigned -- 18 patches have reviews due within four days We could still use additional reviewers. It's not too late to sign up! To get an idea of what's involved, please read these pages: http://wiki.postgresql.org/wiki/Reviewing_a_Patch http://wiki.postgresql.org/wiki/RRReviewers On the lighter side: http://wiki.postgresql.org/images/5/58/11_eggyknap-patch-review.pdf Please send me an email (without copying the list) if you are available to review; feel free to include any information that might be helpful in assigning you an appropriate patch. To see what patches still need a reviewer, you could scroll through the web application looking at the "Reviewers" column: http://commitfest.postgresql.org/action/commitfest_view/inprogress -Kevin
New numbers on where we are with this CommitFest: 71 patches were submitted 3 patches were withdrawn (deleted) by their authors -- 68 total patches currently in the application -- 3 committed to 9.0 -- 65 9.1 patches -- 1 rejected 5 returned with feedback 11 committed for 9.1 -- 17 9.1 patches disposed -- 48 pending 8 ready for committer -- 40 will still need reviewer attention 9 waiting on author to respond to review -- 31 need review before further action 13 "Needs Review" patches don't have a reviewer assigned -- 18 patches have reviews due within four days or less I had particular concerns about the synchronous replication patches, because I've seen competing patches like that lead to significant wheel-spinning and duplication of effort. To try to minimize that, I asked Yeb to do a preliminary review of both. He has not completed reporting on that, but expects to finish within a day or two. My hope is that all parties who want to move this forward will join efforts and bring their ideas to bear on a single patch. I see that nobody has signed up for the GSoC patch regarding materialized views. Do we have an official "mentor" for this effort? Would it be a good or bad idea for that person to do the review? Although we've had some discussion around Markus Wanner's WIP refactoring patches and the prerequisite miscellaneous patches, there's nobody down as a Reviewer for any of them. I understand that the six WIP patches are there for feedback, not with expectation of a commit in this CF, but I'm less clear about the two prerequisite patches. The "WIP patch for serializable transactions with predicate locking" is big, but there's no expectation of a commit this CF, and Joe assures me he's working on it every day; so nobody should be concerned about the lack of a review post on that so far. I am hopeful that in the next week we can clear a lot of the pending patches which have already had some review, and get someone on every unclaimed patch. -Kevin "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > 68 patches were submitted > 3 patches were withdrawn (deleted) by their authors > -- > 65 total patches currently in the application > -- > 3 committed to 9.0 > -- > 62 9.1 patches > -- > 1 rejected > 3 returned with feedback > 1 committed for 9.1 > -- > 57 pending > 10 ready for committer > -- > 47 will still need reviewer attention > 6 waiting on author to respond to review > -- > 41 need review before further action > 23 patches "Needs Review" patches don't have a reviewer assigned > -- > 18 patches have reviews due within four days
On Thu, Jul 22, 2010 at 2:09 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > 48 pending > 8 ready for committer Note that all of the patches except one which are marked as "Ready for Committer" were either submitted by a committer, or the reviewer is a committer. Of those, 3 are mine. Two of those are patches I'm postponing committing at the request of Tom Lane to avoid making the 9.1 and 9.0 trees drift too much before 9.0 is out. However, given the rapidly decreasing frequency of commits to the 9.0 branch, I'm not sure how much longer it makes sense to hold off: I'm currently thinking I'll commit those two after beta4 wraps. The last of those is the 5-key syscaches patch, which only makes sense if knngist needs it, so it may get bumped to the next CF, as knngist was not submitted in time for this CF. The other 4 patches were either submitted or reviewed by Simon Riggs or Itagaki Takahiro, and I am presuming they will commit them themselves unless I hear otherwise (in which case I'm happy to pick them up). That leaves just one patch that's actually been reviewed and is ready to be picked up by a committer, so we actually have a bit of a pipelines stall here. > 18 patches have reviews due within four days or less This is a very big number... I hope some of these reviews start to come in soon. I think this is where our bottleneck is at present. > Although we've had some discussion around Markus Wanner's WIP > refactoring patches and the prerequisite miscellaneous patches, > there's nobody down as a Reviewer for any of them. I understand > that the six WIP patches are there for feedback, not with > expectation of a commit in this CF, but I'm less clear about the two > prerequisite patches. It seems to me that the discussion is Alvaro and I are having with Markus is tilted toward having Markus rewrite the imessages interface to use an SLRU, in which case neither of them will go in this CF. I'm hopeful that Heikki or Tom will comment on this also when they get back from their vacations. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas <robertmhaas@gmail.com> wrote: >> 18 patches have reviews due within four days or less > > This is a very big number... I hope some of these reviews start to > come in soon. I think this is where our bottleneck is at present. Based on off-list emails, I expect most of these to clear by this weekend. Part of this was caused by people "reserving" several patches up front, and posting reviews on some but just now getting to others; part has been caused by people traveling, and not being at "home base" to work on things; part has been due to high priority non-PostgreSQL issues taking people away from reviewing for a few days; and the predicate locking/serializable patch is just too big to review in a few days and I didn't bother taking it out of the count. You'd probably feel better about things if you had read all the off-list emails. Not that we couldn't use another reviewer or two. I'm still welcoming volunteers! -Kevin
Hi, On 07/22/2010 08:51 PM, Robert Haas wrote: > It seems to me that the discussion is Alvaro and I are having with > Markus is tilted toward having Markus rewrite the imessages interface > to use an SLRU, in which case neither of them will go in this CF. I'm > hopeful that Heikki or Tom will comment on this also when they get > back from their vacations. Just for the record: I don't currently think a rewrite to use SLRU makes any sense for imessages. But to answer Kevin's question: I don't expect to have the prerequisite patches committed this CF, as I don't think it currently makes any sense for Postgres to apply them. Nor did I feel there's general consensus that having we want to have a dynamic memory allocator (for shared memory). It would be nice to be able to keep track of these kind of patches, which are available to Postgres and get maintained, but aren't currently needed or wanted. But do we want to use the CF application for that? How do you prefer to proceed with these patches? It's also worth noting that Simon requested more and better documentation. But I simply can't promise to write anything soon. Regards Markus Wanner
Markus Wanner <markus@bluegap.ch> wrote: > On 07/22/2010 08:51 PM, Robert Haas wrote: >> It seems to me that the discussion is Alvaro and I are having >> with Markus is tilted toward having Markus rewrite the imessages >> interface to use an SLRU, in which case neither of them will go >> in this CF. I'm hopeful that Heikki or Tom will comment on this >> also when they get back from their vacations. > > Just for the record: I don't currently think a rewrite to use SLRU > makes any sense for imessages. From the sidelines -- I don't know much about our SLRU implementation, but on from what I have heard, it's hard to see that as a good fit for what you're trying to do. At a minimum, those suggesting it should probably sketch out how that would work just a little bit farther. > But to answer Kevin's question: I don't expect to have the > prerequisite patches committed this CF, as I don't think it > currently makes any sense for Postgres to apply them. OK, so all eight of these patches should be considered WIP submissions. That's good to know from a process management PoV. > Nor did I feel there's general consensus that having we want to > have a dynamic memory allocator (for shared memory). On the other hand, I seem to remember hearing mentions of a desire for that in the past, particularly regarding the ability to have pluggable modules. I suspect that any such feature would need to allocate blocks from which space can be allocated and released in a more lightweight manner than dealing with the OS -- probably with an interface similar to current memory contexts. How does the current patch deal with that? > It would be nice to be able to keep track of these kind of > patches, which are available to Postgres and get maintained, but > aren't currently needed or wanted. pgfoundry? > But do we want to use the CF application for that? How > do you prefer to proceed with these patches? For WIP patches, I'm inclined to leave them open until the end of the CF or until discussion seems to have hit an end. I wonder if we should have a flag in the application for these, so they show up in the counts in a different way. > It's also worth noting that Simon requested more and better > documentation. But I simply can't promise to write anything soon. For a WIP patch, I suspect that putting on your personal TODO list, to cover before any submission for acceptance, is the main thing. Of course, lack of comments or documentation may limit the feedback you get for your WIP submission, as reverse-engineering intent from code can be time-consuming and tedious. -Kevin
New numbers on where we are with this CommitFest, as we approach the half-way point: 72 patches were submitted 3 patches were withdrawn (deleted) by their authors 8 patches were moved to CommitFest 2010-09 -- 61 patches in CommitFest 2010-07 -- 3 committed to 9.0 -- 58 patches for 9.1 -- 1 rejected 13 returned with feedback 12 committed for 9.1 -- 26 disposed -- 32 pending 10 ready for committer -- 22 will still need reviewer attention 7 waiting on author to respond to review -- 15 need review before further action 2 "Needs Review" patches don't have a reviewer assigned -- 13 patches need review and have a reviewer assigned Of the eight patches moved to the next CF, all were moved by or at the request of their authors. One was because the author didn't feel the patch was ready for review and didn't have time to take care of that in this CF. Six were WiP patches which need documentation (perhaps a Wiki page) before others can effectively review them. One is ready for committer, but isn't needed until we are ready to commit the KNN-GiST, which was submitted for the next CF. 13 of the 22 patches which will still need reviewer attention have had at least one review. Many of the others have had discussion and comment entries, but not yet a formal review. The "WIP patch for serializable transactions with predicate locking" by Dan Ports and myself has had some off-list questions from Joe Conway. The questions are noted as opportunities for further code comments. He pointed out one bug which has been fixed. And the questions have caused me to notice a couple areas which need work to reduce the false positive rate. The last two patches which are without an assigned reviewer appear to be in that state because there aren't many people who feel competent to review these areas. The "ECPG FETCH readahead" patch by Zoltán Böszörményi and the "WiP: Per-column collation" patch by Peter Eisentraut both need *someone* to step up. Volunteers or suggestions welcome. Perhaps the biggest CF news of the last week is that we are no longer faced with a fork in the efforts to implement synchronous replication for 9.1 -- Zoltán Böszörményi has heroically offered to withdraw his patch and work with Fujii Masao on enhancing the subsequent "Another synchronous replication" patch. With everyone working from the same base to push this effort forward, I'm hopeful that we can overcome the challenges this technology presents. I think it will be very good for the project if we can get a fairly polished and "close to final" version committed before the last CommitFest, so that it has a full alpha test cycle to settle in. Note that this means that such a patch must be submitted within *three and a half months*! Yes, we are that far in to the 9.1 development cycle. Some of the other patches may have funny dates, but I believe from off-list emails that things are generally moving OK. -Kevin "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > 71 patches were submitted > 3 patches were withdrawn (deleted) by their authors > -- > 68 total patches currently in the application > -- > 3 committed to 9.0 > -- > 65 9.1 patches > -- > 1 rejected > 5 returned with feedback > 11 committed for 9.1 > -- > 17 9.1 patches disposed > -- > 48 pending > 8 ready for committer > -- > 40 will still need reviewer attention > 9 waiting on author to respond to review > -- > 31 need review before further action > 13 "Needs Review" patches don't have a reviewer assigned > -- > 18 patches have reviews due within four days or less
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: New numbers on where we are with this CommitFest, at the end of the third week: 72 patches were submitted 3 patches were withdrawn (deleted) by their authors 12 patches were moved to CommitFest 2010-09 -- 57 patches in CommitFest 2010-07 -- 3 committed to 9.0 -- 54 patches for 9.1 -- 1 rejected 17 returned with feedback 21 committed for 9.1 -- 39 disposed -- 15 pending 9 ready for committer -- 6 will still need reviewer attention 1 waiting on author to respond to review -- 5 patches need review now and have a reviewer assigned Of the four patches moved to the next CF, one was because we couldn't find a reviewer for ECPG code at this time, one was because both Florian and I would like to work up some additional tests for the "serializable lock consistency" patch before sending it to a committer, and two were because Itagaki changed jobs and didn't have time during this CF to finish reviews already well underway. With only ten days to go, in order to leave time for committers to do their thing, we need to be wrapping up the remaining patches. I think we look pretty good. Of the remaining six patches, two are Work in Progress, so are not expected to go to a committer; three involve a committer, so I figure they can decide when and if it's time to return or move them, which just leaves one which is down to tweaking docs. The "WIP patch for serializable transactions with predicate locking" patch has yet to have a review posted, although there have been off-list discussions. The reviewer had to put it aside for about a week due to job pressures, but is reported back on it. (The suspense is killing me.) Last week: > 72 patches were submitted > 3 patches were withdrawn (deleted) by their authors > 8 patches were moved to CommitFest 2010-09 > -- > 61 patches in CommitFest 2010-07 > -- > 3 committed to 9.0 > -- > 58 patches for 9.1 > -- > 1 rejected > 13 returned with feedback > 12 committed for 9.1 > -- > 26 disposed > -- > 32 pending > 10 ready for committer > -- > 22 will still need reviewer attention > 7 waiting on author to respond to review > -- > 15 need review before further action > 2 "Needs Review" patches don't have a reviewer assigned > -- > 13 patches need review and have a reviewer assigned
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > With only ten days to go, in order to leave time for committers to > do their thing, we need to be wrapping up the remaining patches. > I think we look pretty good. Of the remaining six patches, two > are Work in Progress, so are not expected to go to a committer; > three involve a committer, so I figure they can decide when and if > it's time to return or move them, which just leaves one which is > down to tweaking docs. How embarrassing -- I miscounted. It appears I counted Peter's WiP patch in two categories and missed counting the "unlimited parameters for xslt_process" in the above paragraph. (An omission which jumped out at me when reading this morning's posts.) Mike Fowler's latest post says "neither the existing code or the patched code appear able to evaluate the parameters." Is it time to mark this "Returned with Feedback" and hope for a new patch in the next CF? -Kevin
New numbers on where we are with this CommitFest, at the end of the fourth week: 72 patches were submitted 3 patches were withdrawn (deleted) by their authors 12 patches were moved to CommitFest 2010-09 -- 57 patches in CommitFest 2010-07 -- 3 committed to 9.0 -- 54 patches for 9.1 -- 1 rejected 18 returned with feedback 28 committed for 9.1 -- 47 disposed -- 7 pending 2 ready for committer -- 5 will still need reviewer attention 1 waiting on author to respond to review -- 4 patches need review now and have a reviewer assigned With about 56 hours left until the close of the CommitFest, we're down to two "Ready for Committer" and three other potentially committable patches. Do we have a plan (with a time line) for producing an 9.1alpha1 release after the CF closes? (Have we even set a policy on whether we do that when we're still in beta testing for the release which hit feature freeze six months ago?) No patches were moved to the next CF this week, seven were committed, and one was returned with feedback. Two of the four patches in "Needs Review" status are WiP patches, and for both a review is long overdue by CF guidelines. The other two in "Needs Review" status had new patches posted yesterday which respond to committer feedback. The last action for the one patch in "Waiting on Author" status was feedback from Tom five days ago. Last week: > 72 patches were submitted > 3 patches were withdrawn (deleted) by their authors > 12 patches were moved to CommitFest 2010-09 > -- > 57 patches in CommitFest 2010-07 > -- > 3 committed to 9.0 > -- > 54 patches for 9.1 > -- > 1 rejected > 17 returned with feedback > 21 committed for 9.1 > -- > 39 disposed > -- > 15 pending > 9 ready for committer > -- > 6 will still need reviewer attention > 1 waiting on author to respond to review > -- > 5 patches need review now and have a reviewer assigned
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> With about 56 hours left until the close of the CommitFest, we're
> down to two "Ready for Committer" and three other potentially
> committable patches.
I'm working on the pgbench latency patch now, and expect to have it
committed today. I'll look at xml_is_well_formed next, unless somebody
beats me to it. pg_stat_get_backend_server_addr is Peter's to commit,
and I suppose Robert will commit the BackendId-in-relpath patch after
another round of tweaking. gincostestimate may as well be moved to
Returned With Feedback, since Teodor doesn't seem to be responding
(on vacation, perhaps).
> Do we have a plan (with a time line) for
> producing an 9.1alpha1 release after the CF closes?
I don't think anyone's thought about it much. I'm tempted to propose
that we delay it until after the git conversion, so that alpha1 is the
first tarball we try to produce from the git repository. I would just
as soon that that first time be with something noncritical ;-)
regards, tom lane
At the close of the 2010-07 CommitFest, the numbers were: 72 patches were submitted 3 patches were withdrawn (deleted) by their authors 14 patches were moved to CommitFest 2010-09 -- 55 patches in CommitFest 2010-07 -- 3 committed to 9.0 -- 52 patches for 9.1 -- 1 rejected 20 returned with feedback 31 committed for 9.1 When we hit the end of the allotted time, I moved the last two patches to the next CF, for want of a better idea for disposition. One is "Ready for Committer" with an author who is a committer. The other is my WiP patch for serializable transactions -- there's a lot to review and the reviewer had unexpected demands on his time during the CF; he said he'll continue work on that outside the CF. -Kevin At the end of week four: > 72 patches were submitted > 3 patches were withdrawn (deleted) by their authors > 12 patches were moved to CommitFest 2010-09 > -- > 57 patches in CommitFest 2010-07 > -- > 3 committed to 9.0 > -- > 54 patches for 9.1 > -- > 1 rejected > 18 returned with feedback > 28 committed for 9.1 > -- > 47 disposed > -- > 7 pending > 2 ready for committer > -- > 5 will still need reviewer attention > 1 waiting on author to respond to review > -- > 4 patches need review now and have a reviewer assigned
On 18 August 2010 22:45, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > At the close of the 2010-07 CommitFest, the numbers were: > > 72 patches were submitted > 3 patches were withdrawn (deleted) by their authors > 14 patches were moved to CommitFest 2010-09 > -- > 55 patches in CommitFest 2010-07 > -- > 3 committed to 9.0 > -- > 52 patches for 9.1 > -- > 1 rejected > 20 returned with feedback > 31 committed for 9.1 > > When we hit the end of the allotted time, I moved the last two > patches to the next CF, for want of a better idea for disposition. > One is "Ready for Committer" with an author who is a committer. The > other is my WiP patch for serializable transactions -- there's a lot > to review and the reviewer had unexpected demands on his time during > the CF; he said he'll continue work on that outside the CF. > > -Kevin > > > At the end of week four: > >> 72 patches were submitted >> 3 patches were withdrawn (deleted) by their authors >> 12 patches were moved to CommitFest 2010-09 >> -- >> 57 patches in CommitFest 2010-07 >> -- >> 3 committed to 9.0 >> -- >> 54 patches for 9.1 >> -- >> 1 rejected >> 18 returned with feedback >> 28 committed for 9.1 >> -- >> 47 disposed >> -- >> 7 pending >> 2 ready for committer >> -- >> 5 will still need reviewer attention >> 1 waiting on author to respond to review >> -- >> 4 patches need review now and have a reviewer assigned So did the materialized views patch not get submitted? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Mon, Sep 13, 2010 at 7:44 AM, Thom Brown <thom@linux.com> wrote: > So did the materialized views patch not get submitted? I think someone else will need to pick it up and do a bunch more work with it before it can be considered a serious candidate for commit. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company