Re: [HACKERS] 8.3 pending patch queue
On Wed, May 16, 2007 at 12:33:38AM -0300, Marc G. Fournier wrote: Someone (you, I think) advocated a '3 weeks and then dump the rest of the patches' (not quote as strong of wording, but similar) ... why not split the patches list up: submitted patches, not reviewed reviewed patches, needs work, waiting on author reviewed patches, ready for commit. Once feature freeze started, the first list should only get small patches to it, easily reviewed and committed ... then, focus on reviewing list A and move the patch to list B or commit it ... once list A is cleared off, we go into Beta ... if a patch on list B gets re-submitted before Beta, it gets reviewed and either committed, or punt'd to the next release ... I don't think we want to be adding anything new in beta. But if we went into 'alpha' when list A is cleared that might work. (BTW, it's not really clear which list A is...) That leaves Freeze - Beta being as long as it takes to get thorugh List A ... and the only thing punt'd to the next release being that which really isn't ready ... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.3 pending patch queue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, May 16, 2007 10:36:42 -0500 Jim C. Nasby [EMAIL PROTECTED] wrote: On Wed, May 16, 2007 at 12:33:38AM -0300, Marc G. Fournier wrote: Someone (you, I think) advocated a '3 weeks and then dump the rest of the patches' (not quote as strong of wording, but similar) ... why not split the patches list up: submitted patches, not reviewed reviewed patches, needs work, waiting on author reviewed patches, ready for commit. Once feature freeze started, the first list should only get small patches to it, easily reviewed and committed ... then, focus on reviewing list A and move the patch to list B or commit it ... once list A is cleared off, we go into Beta ... if a patch on list B gets re-submitted before Beta, it gets reviewed and either committed, or punt'd to the next release ... I don't think we want to be adding anything new in beta. But if we went into 'alpha' when list A is cleared that might work. (BTW, it's not really clear which list A is...) List A is the 'unreviewed patches list', which, on Feature Freeze, would be 'closed' ... Feature Freeze would last until all Patches in List A are processed, whether that means going back to the Author for fixes/work, or gets committed to the source tree ... Once List A is cleared off, then we dive into Beta, at which point in time only bug fixes would be applied ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGSyp14QvfyHIvDvMRAjIHAJ9MKdROk7Mh0EvcpJoJJJ4uY6iKSQCgldFS ZAYrJ08nKewt1fZbXnXUeN8= =Huf8 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.3 pending patch queue
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, May 15, 2007 16:33:32 -0700 Joshua D. Drake [EMAIL PROTECTED] wrote: If the developers were to actually take a step back and say, Hey... instead of working on these dozen different features, I should work on three and help someone review another three... We wouldn't have this problem. Isn't that the point of the feature freeze period? To put 'development' off to the side and spend the time reviewing what is pending? Except at least from the patch status page, few are actually reviewing. It seems we have dumped all our problems on a hand full of hackers. If ppl find it so inconviencing to not be able to submit patches becaus we're in a feature freeze, then won't that motivate them to do some review, get the patches cleared so that they *can* move on? In theory yes, but see my comment above. Someone (you, I think) advocated a '3 weeks and then dump the rest of the patches' (not quote as strong of wording, but similar) ... why not split the patches list up: submitted patches, not reviewed reviewed patches, needs work, waiting on author reviewed patches, ready for commit. I did that, read the whole thread. Bruce did it too ;) and Stefan (all in slightly different ways). Joshua D. Drake Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGSnuT4QvfyHIvDvMRAmelAJ90HOW3iOYMABmA41XCjJnKV2urtwCfaFTt nquLm5G2tVKMCH3Ld7znGQM= =Vl54 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
If people want proof that we have had some patches for months, this email is from Simon from January, 2007. --- Simon Riggs wrote: On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote: I will start processing the patches held for 8.3 this week or next, now that the holiday break is over: http://momjian.postgresql.org/cgi-bin/pgpatches_hold The following patches don't appear on this list: Concurrent psql Original submission http://archives.postgresql.org/pgsql-patches/2006-08/msg00249.php Latest http://archives.postgresql.org/pgsql-hackers/2006-12/msg00527.php Described here: http://community.enterprisedb.com/concurrent/index.html WAL Index Split Original submission http://archives.postgresql.org/pgsql-patches/2006-12/msg00045.php Latest http://archives.postgresql.org/pgsql-patches/2007-01/msg0.php Grouped Items Latest http://archives.postgresql.org/pgsql-patches/2006-11/msg00051.php Described here: http://community.enterprisedb.com/git/index.html Maintain Cluster Order http://archives.postgresql.org/pgsql-patches/2006-08/msg00124.php All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: If people want proof that we have had some patches for months, this email is from Simon from January, 2007. I don't think anyone (at least sanely) questions that there are patches hanging out there. Joshua D. Drake --- Simon Riggs wrote: On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote: I will start processing the patches held for 8.3 this week or next, now that the holiday break is over: http://momjian.postgresql.org/cgi-bin/pgpatches_hold The following patches don't appear on this list: Concurrent psql Original submission http://archives.postgresql.org/pgsql-patches/2006-08/msg00249.php Latest http://archives.postgresql.org/pgsql-hackers/2006-12/msg00527.php Described here: http://community.enterprisedb.com/concurrent/index.html WAL Index Split Original submission http://archives.postgresql.org/pgsql-patches/2006-12/msg00045.php Latest http://archives.postgresql.org/pgsql-patches/2007-01/msg0.php Grouped Items Latest http://archives.postgresql.org/pgsql-patches/2006-11/msg00051.php Described here: http://community.enterprisedb.com/git/index.html Maintain Cluster Order http://archives.postgresql.org/pgsql-patches/2006-08/msg00124.php All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.3 pending patch queue
Joshua D. Drake wrote: Bruce Momjian wrote: If people want proof that we have had some patches for months, this email is from Simon from January, 2007. I don't think anyone (at least sanely) questions that there are patches hanging out there. My point is that pushing them for 8.4 effectively doesn't move us forward because we have been pushing for a while. And you can't blame tracking because everyone knows what has to happen. --- Joshua D. Drake --- Simon Riggs wrote: On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote: I will start processing the patches held for 8.3 this week or next, now that the holiday break is over: http://momjian.postgresql.org/cgi-bin/pgpatches_hold The following patches don't appear on this list: Concurrent psql Original submission http://archives.postgresql.org/pgsql-patches/2006-08/msg00249.php Latest http://archives.postgresql.org/pgsql-hackers/2006-12/msg00527.php Described here: http://community.enterprisedb.com/concurrent/index.html WAL Index Split Original submission http://archives.postgresql.org/pgsql-patches/2006-12/msg00045.php Latest http://archives.postgresql.org/pgsql-patches/2007-01/msg0.php Grouped Items Latest http://archives.postgresql.org/pgsql-patches/2006-11/msg00051.php Described here: http://community.enterprisedb.com/git/index.html Maintain Cluster Order http://archives.postgresql.org/pgsql-patches/2006-08/msg00124.php All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: Joshua D. Drake wrote: Bruce Momjian wrote: If people want proof that we have had some patches for months, this email is from Simon from January, 2007. I don't think anyone (at least sanely) questions that there are patches hanging out there. My point is that pushing them for 8.4 effectively doesn't move us forward because we have been pushing for a while. Hmm, I don't agree.. Two steps forward, one step back. You are still going forward. And you can't blame tracking because everyone knows what has to happen. I am not blaming the tracker, the tracker is only part of the equation. IMO this particular problem is about a lot of people wanting to eat ice cream without doing their chores first. All due respect to all the great developers that submitted patches but they submitted all of these features and have reviewed few of the patches. If the developers were to actually take a step back and say, Hey... instead of working on these dozen different features, I should work on three and help someone review another three... We wouldn't have this problem. Tom said it best (incomplete quote) a lot of people tried to run before they could walk. Sincerely, Joshua D. Drake --- Joshua D. Drake --- Simon Riggs wrote: On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote: I will start processing the patches held for 8.3 this week or next, now that the holiday break is over: http://momjian.postgresql.org/cgi-bin/pgpatches_hold The following patches don't appear on this list: Concurrent psql Original submission http://archives.postgresql.org/pgsql-patches/2006-08/msg00249.php Latest http://archives.postgresql.org/pgsql-hackers/2006-12/msg00527.php Described here: http://community.enterprisedb.com/concurrent/index.html WAL Index Split Original submission http://archives.postgresql.org/pgsql-patches/2006-12/msg00045.php Latest http://archives.postgresql.org/pgsql-patches/2007-01/msg0.php Grouped Items Latest http://archives.postgresql.org/pgsql-patches/2006-11/msg00051.php Described here: http://community.enterprisedb.com/git/index.html Maintain Cluster Order http://archives.postgresql.org/pgsql-patches/2006-08/msg00124.php All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] 8.3 pending patch queue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, May 15, 2007 16:33:32 -0700 Joshua D. Drake [EMAIL PROTECTED] wrote: If the developers were to actually take a step back and say, Hey... instead of working on these dozen different features, I should work on three and help someone review another three... We wouldn't have this problem. Isn't that the point of the feature freeze period? To put 'development' off to the side and spend the time reviewing what is pending? If ppl find it so inconviencing to not be able to submit patches becaus we're in a feature freeze, then won't that motivate them to do some review, get the patches cleared so that they *can* move on? Someone (you, I think) advocated a '3 weeks and then dump the rest of the patches' (not quote as strong of wording, but similar) ... why not split the patches list up: submitted patches, not reviewed reviewed patches, needs work, waiting on author reviewed patches, ready for commit. Once feature freeze started, the first list should only get small patches to it, easily reviewed and committed ... then, focus on reviewing list A and move the patch to list B or commit it ... once list A is cleared off, we go into Beta ... if a patch on list B gets re-submitted before Beta, it gets reviewed and either committed, or punt'd to the next release ... That leaves Freeze - Beta being as long as it takes to get thorugh List A ... and the only thing punt'd to the next release being that which really isn't ready ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGSnuT4QvfyHIvDvMRAmelAJ90HOW3iOYMABmA41XCjJnKV2urtwCfaFTt nquLm5G2tVKMCH3Ld7znGQM= =Vl54 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
On Sat, Jan 06, 2007 at 04:56:12PM -0500, Bruce Momjian wrote: I am open to new names. patches-8_3 ? Anything coming in after FF then goes to patches-8_4. The problem there is that the web site references these, so changing the URL for every release is odd, plus right now both queues are for 8.3. If we're going to start having the buildfarm build patches we might want to hold off on changing any names since the buildfarm stuff might want some changes anyway... -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
I'm confused, I thought the difference between the pgpatches queue and the pgpatches_hold queue is the release the patch is targeted for. If there's a third queue for patches that need review before being added to another queue, could we have that visible somewhere, so that we know what's in it? Well, sort of. During 8.2 feature freeze the 8.2 hold queue was for 8.3, and the patches queue was for 8.2, but once we started 8.3, they were both for 8.3. So wouldn't it be easier to always move the hold queue into the patches queue asap when the new dev cycle begins (the patches queue is naturally empty when we release, because patches have been applied or moved to the hold queue) ? Andreas ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Lukas Kahwe Smith wrote: Andrew Dunstan wrote: The latter does not exist, AFAIK. Before feature freeze for cycle X, we don't usually hold patches for release X+1, as I understand it. In general, we should try to hold patches as little amount of time as possible. That way they don't go stale as easily. I did not follow this thread closely, but it would be nice if someone could compile all of these defacto standards into a wiki page. The developer's FAQ has that information: PA web site is maintained for patches awaiting review, a href=http://momjian.postgresql.org/cgi-bin/pgpatches; http://momjian.postgresql.org/cgi-bin/pgpatches/a, and those that are being kept for the next release, a href=http://momjian.postgresql.org/cgi-bin/pgpatches_hold; http://momjian.postgresql.org/cgi-bin/pgpatches_hold/a./P -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: The hold queue has patches that still need discussion, or ideas for patches, so it is more than just patches ready for application, and moving the whole thing at once would overwhelm patch reviewers. So why aren't all patches that are posted to the -patches list in the hold queue? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.3 pending patch queue
Alvaro Herrera wrote: Bruce Momjian wrote: The hold queue has patches that still need discussion, or ideas for patches, so it is more than just patches ready for application, and moving the whole thing at once would overwhelm patch reviewers. So why aren't all patches that are posted to the -patches list in the hold queue? Because I haven't looked them over yet, and wasn't putting things in the queue while we were waiting on 8.2.1. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: The hold queue has patches that still need discussion, or ideas for patches, so it is more than just patches ready for application, and moving the whole thing at once would overwhelm patch reviewers. So why aren't all patches that are posted to the -patches list in the hold queue? Because I haven't looked them over yet, and wasn't putting things in the queue while we were waiting on 8.2.1. No, I mean in principle, not in this particular case. If we have two queues, and there's a barrier to moving patches from the hold queue to the other queue, why aren't patches posted in pgsql-patches put right away in the hold queue? After all, there's already a barrier to applying a patch in the non-hold queue, which is that someone reviews and approves it. Does it make sense to have three barriers to the patch managing process? ISTM two is good enough (first when moving a patch from the hold queue to the main queue, and then when applying a patch from the main queue). I hope I'm making sense here :-) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.3 pending patch queue
Alvaro Herrera [EMAIL PROTECTED] writes: So why aren't all patches that are posted to the -patches list in the hold queue? I think the really short answer to this is that Bruce is behind on processing the patches list. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: So why aren't all patches that are posted to the -patches list in the hold queue? I think the really short answer to this is that Bruce is behind on processing the patches list. Probably. :-( -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: Simon Riggs wrote: All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. You might remember months ago that people were complaining I was pushing things into CVS too quickly, so while the patches are in my mailbox, they are not in the queue until I feel the community has the time to focus on it. So, there's a queue of patches in your mailbox waiting to get to the queue? A queue to the queue :). All the patches clearly need review, so let's not rush them into the CVS, but it'd be nice to have them all in one queue. Ps. I agree with the later comments that the naming of the two patch queues is a bit confusing. Having queues named after the release numbers the patches are targeted for seems like a good idea. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.3 pending patch queue
Heikki Linnakangas wrote: Bruce Momjian wrote: Simon Riggs wrote: All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. You might remember months ago that people were complaining I was pushing things into CVS too quickly, so while the patches are in my mailbox, they are not in the queue until I feel the community has the time to focus on it. So, there's a queue of patches in your mailbox waiting to get to the queue? A queue to the queue :). All the patches clearly need review, so let's not rush them into the CVS, but it'd be nice to have them all in one queue. Right, because even the decision of whether they should be in the queue is a decision for us. The hold queue additions are less stringent than the main patch queue. Ps. I agree with the later comments that the naming of the two patch queues is a bit confusing. Having queues named after the release numbers the patches are targeted for seems like a good idea. OK, naming suggestions? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: Right, because even the decision of whether they should be in the queue is a decision for us. The hold queue additions are less stringent than the main patch queue. Isn't that always the case though, not just after FF when the hold queue starts getting activity again? That would imply the need to a permanent triage(?) queue, and a version specific one imho. Regards, Dave ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: Heikki Linnakangas wrote: Bruce Momjian wrote: Simon Riggs wrote: All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. You might remember months ago that people were complaining I was pushing things into CVS too quickly, so while the patches are in my mailbox, they are not in the queue until I feel the community has the time to focus on it. So, there's a queue of patches in your mailbox waiting to get to the queue? A queue to the queue :). All the patches clearly need review, so let's not rush them into the CVS, but it'd be nice to have them all in one queue. Right, because even the decision of whether they should be in the queue is a decision for us. The hold queue additions are less stringent than the main patch queue. I'm confused, I thought the difference between the pgpatches queue and the pgpatches_hold queue is the release the patch is targeted for. If there's a third queue for patches that need review before being added to another queue, could we have that visible somewhere, so that we know what's in it? Ps. I agree with the later comments that the naming of the two patch queues is a bit confusing. Having queues named after the release numbers the patches are targeted for seems like a good idea. OK, naming suggestions? The 8.3 patch queue, and the 8.4 patch queue? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Heikki Linnakangas wrote: I'm confused, So I see. I thought the difference between the pgpatches queue and the pgpatches_hold queue is the release the patch is targeted for. If there's a third queue for patches that need review before being added to another queue, could we have that visible somewhere, so that we know what's in it? OK, naming suggestions? The 8.3 patch queue, and the 8.4 patch queue? The latter does not exist, AFAIK. Before feature freeze for cycle X, we don't usually hold patches for release X+1, as I understand it. In general, we should try to hold patches as little amount of time as possible. That way they don't go stale as easily. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.3 pending patch queue
Andrew Dunstan wrote: The latter does not exist, AFAIK. Before feature freeze for cycle X, we don't usually hold patches for release X+1, as I understand it. In general, we should try to hold patches as little amount of time as possible. That way they don't go stale as easily. I did not follow this thread closely, but it would be nice if someone could compile all of these defacto standards into a wiki page. regards, Lukas PS: Dont me make read this entire thread just to create this wiki page myself :P ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Heikki Linnakangas wrote: Bruce Momjian wrote: Heikki Linnakangas wrote: Bruce Momjian wrote: Simon Riggs wrote: All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. You might remember months ago that people were complaining I was pushing things into CVS too quickly, so while the patches are in my mailbox, they are not in the queue until I feel the community has the time to focus on it. So, there's a queue of patches in your mailbox waiting to get to the queue? A queue to the queue :). All the patches clearly need review, so let's not rush them into the CVS, but it'd be nice to have them all in one queue. Right, because even the decision of whether they should be in the queue is a decision for us. The hold queue additions are less stringent than the main patch queue. I'm confused, I thought the difference between the pgpatches queue and the pgpatches_hold queue is the release the patch is targeted for. If there's a third queue for patches that need review before being added to another queue, could we have that visible somewhere, so that we know what's in it? Well, sort of. During 8.2 feature freeze the 8.2 hold queue was for 8.3, and the patches queue was for 8.2, but once we started 8.3, they were both for 8.3. Ps. I agree with the later comments that the naming of the two patch queues is a bit confusing. Having queues named after the release numbers the patches are targeted for seems like a good idea. OK, naming suggestions? The 8.3 patch queue, and the 8.4 patch queue? Not really, no, as outlined above. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.3 pending patch queue
Devrim GUNDUZ wrote: -- Start of PGP signed section. Hi Bruce, On Mon, 2007-01-08 at 11:35 -0500, Bruce Momjian wrote: OK, naming suggestions? BTW, why do you keep those pages in your homepage, but not in postgresql.org? Just wondering. --and personally, I'd prefer to see them in our (PG) web page. Because the minute I add something to the queue, it has to be visible. Uploading it to postgresql.org adds an unnecessary delay, and deleting it unnecessary overhead. I actually am momjian.postgresql.org, so I don't see the issue of which machine it is on. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.3 pending patch queue
On Sat, 2007-01-06 at 16:29 -0500, Bruce Momjian wrote: The issue is that the _hold_ patches are for patches that arrived after feature freeze. The patches that arrived after 8.2 was released don't go in there because it might cause confusion. Right, which is why I'm pointing it out; they did all arrive before 8.2 I also have to control how quickly I push out patches from the queue so as not to overwhelm folks. Yes, I see the challenge. I'm not hassling you, just asking for stuff to be added appropriately to the queue. I just used too many/wrong words in the request; again, sorry. Just found another one, which was issued after 8.2. pg_standby, latest version: http://archives.postgresql.org/pgsql-patches/2006-12/msg00179.php -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: The problem there is that the web site references these, so changing the URL for every release is odd, Not a problem though - it's trivial for us to update whatever webpages link to it. plus right now both queues are for 8.3. Well, yeah - that's why it's confusing! Regards, Dave ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.3 pending patch queue
On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote: I will start processing the patches held for 8.3 this week or next, now that the holiday break is over: http://momjian.postgresql.org/cgi-bin/pgpatches_hold The following patches don't appear on this list: Concurrent psql Original submission http://archives.postgresql.org/pgsql-patches/2006-08/msg00249.php Latest http://archives.postgresql.org/pgsql-hackers/2006-12/msg00527.php Described here: http://community.enterprisedb.com/concurrent/index.html WAL Index Split Original submission http://archives.postgresql.org/pgsql-patches/2006-12/msg00045.php Latest http://archives.postgresql.org/pgsql-patches/2007-01/msg0.php Grouped Items Latest http://archives.postgresql.org/pgsql-patches/2006-11/msg00051.php Described here: http://community.enterprisedb.com/git/index.html Maintain Cluster Order http://archives.postgresql.org/pgsql-patches/2006-08/msg00124.php All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.3 pending patch queue
Simon Riggs wrote: All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. You might remember months ago that people were complaining I was pushing things into CVS too quickly, so while the patches are in my mailbox, they are not in the queue until I feel the community has the time to focus on it. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.3 pending patch queue
Simon Riggs wrote: I'm not clear about the difference between the unapplied patches list and the hold list. What is the significance of the two lists? There's a number of patches submitted to pgsql-patches that don't show up on either list. I haven't made a list of these, but they include major patches such as Grouped Item indexes and a number of others. Many of those are clearly marked as ready to apply/review/reject. Can I request that those be reviewed first? The unapplied patches list looks long and many things on it aren't even patches, AFAICS - presumably TODO items-in-waiting? Some minor points: [PATCHES] Incrementally Updated Backup, Simon Riggs has already been applied to 8.2 [PATCHES] WAL logging freezing, Heikki Linnakangas has already been agreed/applied to 8.2 Thanks. These two items have been removed from the patches hold queue. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
On Sat, 2007-01-06 at 10:56 -0500, Bruce Momjian wrote: Simon Riggs wrote: All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. You might remember months ago that people were complaining I was pushing things into CVS too quickly, so while the patches are in my mailbox, they are not in the queue until I feel the community has the time to focus on it. I'm sorry if I explained that badly. All I meant to say was that the patches aren't on the queue for review, so could they be placed at the appropriate chronological point in the queue. (I was/am imagining the queue to be ordered in time of arrival). Patch review is, for me, harder than writing patches in the first place, so with that in mind I don't expect it to happen quickly. You've explained your on it now, so I'm patient. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] 8.3 pending patch queue
Simon Riggs wrote: On Sat, 2007-01-06 at 10:56 -0500, Bruce Momjian wrote: Simon Riggs wrote: All have been awaiting review for at least a month (though in one case the latest version is quite recent). They probably ought to be on the hold queue; all are ready to be reviewed for final application/rejection. I'd hasten to add that none of those are mine. My patches have received good attention, so I'm not complaining just completing admin. You might remember months ago that people were complaining I was pushing things into CVS too quickly, so while the patches are in my mailbox, they are not in the queue until I feel the community has the time to focus on it. I'm sorry if I explained that badly. All I meant to say was that the patches aren't on the queue for review, so could they be placed at the appropriate chronological point in the queue. (I was/am imagining the queue to be ordered in time of arrival). It is. Patch review is, for me, harder than writing patches in the first place, so with that in mind I don't expect it to happen quickly. You've explained your on it now, so I'm patient. The issue is that the _hold_ patches are for patches that arrived after feature freeze. The patches that arrived after 8.2 was released don't go in there because it might cause confusion. I also have to control how quickly I push out patches from the queue so as not to overwhelm folks. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: The issue is that the _hold_ patches are for patches that arrived after feature freeze. The patches that arrived after 8.2 was released don't go in there because it might cause confusion. I also have to control how quickly I push out patches from the queue so as not to overwhelm folks. Perhaps it would cause less confusion to name the queues for the version they will be reviewed/applied for, rather than to toggle between queue 1 and 2, the logic of which isn't aways immediately obvious to the causal observer. Regards, Dave. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Dave Page wrote: Bruce Momjian wrote: The issue is that the _hold_ patches are for patches that arrived after feature freeze. The patches that arrived after 8.2 was released don't go in there because it might cause confusion. I also have to control how quickly I push out patches from the queue so as not to overwhelm folks. Perhaps it would cause less confusion to name the queues for the version they will be reviewed/applied for, rather than to toggle between queue 1 and 2, the logic of which isn't aways immediately obvious to the causal observer. I don't actually toggle. Hold is for stuff during feature freeze. I am open to new names. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: Dave Page wrote: Bruce Momjian wrote: The issue is that the _hold_ patches are for patches that arrived after feature freeze. The patches that arrived after 8.2 was released don't go in there because it might cause confusion. I also have to control how quickly I push out patches from the queue so as not to overwhelm folks. Perhaps it would cause less confusion to name the queues for the version they will be reviewed/applied for, rather than to toggle between queue 1 and 2, the logic of which isn't aways immediately obvious to the causal observer. I don't actually toggle. Hold is for stuff during feature freeze. But then you go back to the other one once we're through freeze is what I mean. I am open to new names. patches-8_3 ? Anything coming in after FF then goes to patches-8_4. /D ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Dave Page wrote: Bruce Momjian wrote: Dave Page wrote: Bruce Momjian wrote: The issue is that the _hold_ patches are for patches that arrived after feature freeze. The patches that arrived after 8.2 was released don't go in there because it might cause confusion. I also have to control how quickly I push out patches from the queue so as not to overwhelm folks. Perhaps it would cause less confusion to name the queues for the version they will be reviewed/applied for, rather than to toggle between queue 1 and 2, the logic of which isn't aways immediately obvious to the causal observer. I don't actually toggle. Hold is for stuff during feature freeze. But then you go back to the other one once we're through freeze is what I mean. I kind of do both at the same time until the hold queue is empty. I am open to new names. patches-8_3 ? Anything coming in after FF then goes to patches-8_4. The problem there is that the web site references these, so changing the URL for every release is odd, plus right now both queues are for 8.3. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.3 pending patch queue
On Mon, 2007-01-01 at 19:56 -0500, Bruce Momjian wrote: Andrew Dunstan wrote: Bruce Momjian wrote: I will start processing the patches held for 8.3 this week or next, now that the holiday break is over: http://momjian.postgresql.org/cgi-bin/pgpatches_hold Some of these look obsolete. Also, . the plperl out params patch needs substantial rework by its author, IMHO. . there is a new version of the enums patch that has been submitted. Yes, I will have to go through it, find the valuable ones, and get comments. Sounds good. I'm not clear about the difference between the unapplied patches list and the hold list. What is the significance of the two lists? There's a number of patches submitted to pgsql-patches that don't show up on either list. I haven't made a list of these, but they include major patches such as Grouped Item indexes and a number of others. Many of those are clearly marked as ready to apply/review/reject. Can I request that those be reviewed first? The unapplied patches list looks long and many things on it aren't even patches, AFAICS - presumably TODO items-in-waiting? Some minor points: [PATCHES] Incrementally Updated Backup, Simon Riggs has already been applied to 8.2 [PATCHES] WAL logging freezing, Heikki Linnakangas has already been agreed/applied to 8.2 -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.3 pending patch queue
Simon Riggs wrote: I'm not clear about the difference between the unapplied patches list and the hold list. What is the significance of the two lists? AIUI, the hold list is those patches providing new features that were held over between 8.2 feature freeze and 8.2 branch. Since they have been around for a while I think they have some claim to priority. The other list is just the normal running list of such patches that Bruce keeps. There's a number of patches submitted to pgsql-patches that don't show up on either list. That also happens. The only way I can see of ensuring it does not happen would be to auto-process all patch submissions. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote: Simon Riggs wrote: I'm not clear about the difference between the unapplied patches list and the hold list. What is the significance of the two lists? AIUI, the hold list is those patches providing new features that were held over between 8.2 feature freeze and 8.2 branch. Since they have been around for a while I think they have some claim to priority. The other list is just the normal running list of such patches that Bruce keeps. OK. Makes sense, thanks. There's a number of patches submitted to pgsql-patches that don't show up on either list. Hopefully the priority applies to all things that should be on the list. That also happens. The only way I can see of ensuring it does not happen would be to auto-process all patch submissions. Sounds a good idea. Patch farm anyone? Auto apply/make check? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] 8.3 pending patch queue
On 1/4/07, Simon Riggs [EMAIL PROTECTED] wrote: On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote: That also happens. The only way I can see of ensuring it does not happen would be to auto-process all patch submissions. Sounds a good idea. Patch farm anyone? Auto apply/make check? I'm actually trying to simplify something I was working on at OSDL to do this. PLM at OSDL was a little to Linux focused. Will let everyone know when I have a working prototype. Mark ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.3 pending patch queue
[EMAIL PROTECTED] wrote: On 1/4/07, Simon Riggs [EMAIL PROTECTED] wrote: On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote: That also happens. The only way I can see of ensuring it does not happen would be to auto-process all patch submissions. Sounds a good idea. Patch farm anyone? Auto apply/make check? I'm actually trying to simplify something I was working on at OSDL to do this. PLM at OSDL was a little to Linux focused. Will let everyone know when I have a working prototype. Feel free to discuss design/functionality any time. For example, a mechanism to feed patches to the buildfarm has previously been suggested. If this could be done in some automated, controlled and reasonably safe way it might be useful - it might afford reviewers a try before you buy option. Also, hooking this up with the stuff that Lukas Smith is doing might be good. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] 8.3 pending patch queue
On 1/4/07, Andrew Dunstan [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On 1/4/07, Simon Riggs [EMAIL PROTECTED] wrote: On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote: That also happens. The only way I can see of ensuring it does not happen would be to auto-process all patch submissions. Sounds a good idea. Patch farm anyone? Auto apply/make check? I'm actually trying to simplify something I was working on at OSDL to do this. PLM at OSDL was a little to Linux focused. Will let everyone know when I have a working prototype. Feel free to discuss design/functionality any time. For example, a mechanism to feed patches to the buildfarm has previously been suggested. If this could be done in some automated, controlled and reasonably safe way it might be useful - it might afford reviewers a try before you buy option. Also, hooking this up with the stuff that Lukas Smith is doing might be good. I'll start another thread about what PLM is doing and what my initial ideas are. Do you have a pointer to what Lukas Smith is doing? Mark ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.3 pending patch queue
[EMAIL PROTECTED] wrote: On 1/4/07, Andrew Dunstan [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On 1/4/07, Simon Riggs [EMAIL PROTECTED] wrote: On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote: That also happens. The only way I can see of ensuring it does not happen would be to auto-process all patch submissions. Sounds a good idea. Patch farm anyone? Auto apply/make check? I'm actually trying to simplify something I was working on at OSDL to do this. PLM at OSDL was a little to Linux focused. Will let everyone know when I have a working prototype. Feel free to discuss design/functionality any time. For example, a mechanism to feed patches to the buildfarm has previously been suggested. If this could be done in some automated, controlled and reasonably safe way it might be useful - it might afford reviewers a try before you buy option. Also, hooking this up with the stuff that Lukas Smith is doing might be good. I'll start another thread about what PLM is doing and what my initial ideas are. Do you have a pointer to what Lukas Smith is doing? some of the stuff in here: http://developer.postgresql.org/index.php/Main_Page cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.3 pending patch queue
Andrew Dunstan wrote: Simon Riggs wrote: I'm not clear about the difference between the unapplied patches list and the hold list. What is the significance of the two lists? AIUI, the hold list is those patches providing new features that were held over between 8.2 feature freeze and 8.2 branch. Since they have been around for a while I think they have some claim to priority. The other list is just the normal running list of such patches that Bruce keeps. FYI, I haven't been applying patches as aggressively because we were kind of focused on 8.2.0 and the holidays. Now that that is over, there will be more activity. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] 8.3 pending patch queue
I will start processing the patches held for 8.3 this week or next, now that the holiday break is over: http://momjian.postgresql.org/cgi-bin/pgpatches_hold -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.3 pending patch queue
Bruce Momjian wrote: I will start processing the patches held for 8.3 this week or next, now that the holiday break is over: http://momjian.postgresql.org/cgi-bin/pgpatches_hold Some of these look obsolete. Also, . the plperl out params patch needs substantial rework by its author, IMHO. . there is a new version of the enums patch that has been submitted. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 pending patch queue
Andrew Dunstan wrote: Bruce Momjian wrote: I will start processing the patches held for 8.3 this week or next, now that the holiday break is over: http://momjian.postgresql.org/cgi-bin/pgpatches_hold Some of these look obsolete. Also, . the plperl out params patch needs substantial rework by its author, IMHO. . there is a new version of the enums patch that has been submitted. Yes, I will have to go through it, find the valuable ones, and get comments. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
