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(at)momjian(dot)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(at)momjian(dot)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(at)2ndquadrant(dot)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(at)gmail(dot)com wrote:
> On 1/4/07, Simon Riggs <simon(at)2ndquadrant(dot)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(at)dunslane(dot)net> wrote:
> markwkm(at)gmail(dot)com wrote:
> > On 1/4/07, Simon Riggs <simon(at)2ndquadrant(dot)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(at)gmail(dot)com wrote:
> On 1/4/07, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> markwkm(at)gmail(dot)com wrote:
>> > On 1/4/07, Simon Riggs <simon(at)2ndquadrant(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)nasby(dot)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

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
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 bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)commandprompt(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)commandprompt(dot)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(at)hub(dot)org MSN . scrappy(at)hub(dot)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(at)decibel(dot)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(at)decibel(dot)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(at)hub(dot)org MSN . scrappy(at)hub(dot)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(at)commandprompt(dot)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-----
>