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:
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: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: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:
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. +
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:
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. +
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. +
