Thread: 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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
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
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
On 1/4/07, Simon Riggs <simon@2ndquadrant.com> 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
markwkm@gmail.com wrote: > On 1/4/07, Simon Riggs <simon@2ndquadrant.com> 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
On 1/4/07, Andrew Dunstan <andrew@dunslane.net> wrote: > markwkm@gmail.com wrote: > > On 1/4/07, Simon Riggs <simon@2ndquadrant.com> 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
markwkm@gmail.com wrote: > On 1/4/07, Andrew Dunstan <andrew@dunslane.net> wrote: >> markwkm@gmail.com wrote: >> > On 1/4/07, Simon Riggs <simon@2ndquadrant.com> 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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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/msg00000.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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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.
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
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
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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
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
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
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
Dave Page wrote: > 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. The hold queue is not used during normal development. I don't see value in a triage queue. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim C. Nasby wrote: > 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... This will not happen any time soon, AFAIK. Fixing the queue names now makes sense. In any case, the queues are now just mailboxes. We would need lots more infrastructure. So nothing should be predicated on what buildfarm might do. cheers andrew
> > 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
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
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: <P>A 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 thosethat 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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Zeugswetter Andreas ADI SD wrote: > > > > 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) ? 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. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > 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? They could be, but remember, my queues are only for patches that no one else has delt with, so auto-add doesn't make lots of sense, plus many patches aren't sent to patches, or are discussions in the patches list, or are ideas that have to be made into patches. > 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 :-) Yea. We could just throw things in the hold queue if we were sure we would get only good patches/ideas from all lists. Right now the hold queue is only used during this transition period between releases. I am afraid that to capture everything, you would basically just duplicate the archives. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Alvaro Herrera <alvherre@commandprompt.com> 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
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> 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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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/msg00000.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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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/msg00000.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 >
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/msg00000.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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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/msg00000.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 >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, May 15, 2007 16:33:32 -0700 "Joshua D. Drake" <jd@commandprompt.com> 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 . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGSnuT4QvfyHIvDvMRAmelAJ90HOW3iOYMABmA41XCjJnKV2urtwCfaFTt nquLm5G2tVKMCH3Ld7znGQM= =Vl54 -----END PGP SIGNATURE-----
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 decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Wednesday, May 16, 2007 10:36:42 -0500 "Jim C. Nasby" <decibel@decibel.org> 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 . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGSyp14QvfyHIvDvMRAjIHAJ9MKdROk7Mh0EvcpJoJJJ4uY6iKSQCgldFS ZAYrJ08nKewt1fZbXnXUeN8= =Huf8 -----END PGP SIGNATURE-----
Marc G. Fournier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > - --On Tuesday, May 15, 2007 16:33:32 -0700 "Joshua D. Drake" > <jd@commandprompt.com> 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----- >