SEO

This has been saved for the next commit-fest:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Gregory Stark wrote:
> "Andrew Dunstan" <andrew@dunslane.net> writes:
>
> > Gregory Stark wrote:
> >> Attached is an updated patch.
> >>
> >
> > This patch appears to add a nonexistent test to the regression schedules.
>
> I must have forgotten to cvs add it. Sorry.
>
> Also, I forgot to mention previously there is an unrelated trivial hunk in
> here. I noticed we free the password early, presumably for security reasons,
> but don't actually overwrite the memory at that point. I added a memset in
> there, otherwise the free seems kind of pointless. I normally don't bother
> with "security" features like that since they don't really add any security
> but as long as it's there it may as well do something vaguely useful.
>

[ Attachment, skipping... ]

>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Bruce Momjian <bruce@momjian.us> writes:
> This has been saved for the next commit-fest:
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold

Er, why "saved"? Until there's a new patch submission there's not going
to be more work to do on this in the next fest.

I think maybe you need to think a bit harder about the distinction
between your TODO-items-in-waiting list and the commit fest queue.
I was willing to wade through a pile of TODO-items-in-waiting this
time, because I pressed you to make the list available before having
sorted through it; but I'm not going to be pleased to see those same
threads in the fest queue next time, unless someone's done some actual
work in between.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > This has been saved for the next commit-fest:
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> Er, why "saved"? Until there's a new patch submission there's not going
> to be more work to do on this in the next fest.
>
> I think maybe you need to think a bit harder about the distinction
> between your TODO-items-in-waiting list and the commit fest queue.
> I was willing to wade through a pile of TODO-items-in-waiting this
> time, because I pressed you to make the list available before having
> sorted through it; but I'm not going to be pleased to see those same
> threads in the fest queue next time, unless someone's done some actual
> work in between.

It is in the next fest so I will remember to ask if people have done any
work on them --- if not they are either deleted or moved to the next
commit fest.

Are you suggesting we just delete the threads and let them die if they
don't submit a new version?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Bruce Momjian <bruce@momjian.us> writes:
> Are you suggesting we just delete the threads and let them die if they
> don't submit a new version?

I am suggesting that they are not material for another commit fest until
some new work has been done. (And the appearance of that new work would
trigger an entry being made in the pending-commit-fest list.)

I've surely got no objection to you hanging on to such threads in your
personal almost-TODO list, and prodding people when appropriate. But
the commit fest queue is not for that purpose.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Bruce Momjian wrote:
> Tom Lane wrote:
>
>> Bruce Momjian <bruce@momjian.us> writes:
>>
>>> This has been saved for the next commit-fest:
>>> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>>>
>> Er, why "saved"? Until there's a new patch submission there's not going
>> to be more work to do on this in the next fest.
>>
>> I think maybe you need to think a bit harder about the distinction
>> between your TODO-items-in-waiting list and the commit fest queue.
>> I was willing to wade through a pile of TODO-items-in-waiting this
>> time, because I pressed you to make the list available before having
>> sorted through it; but I'm not going to be pleased to see those same
>> threads in the fest queue next time, unless someone's done some actual
>> work in between.
>>
>
> It is in the next fest so I will remember to ask if people have done any
> work on them --- if not they are either deleted or moved to the next
> commit fest.
>
> Are you suggesting we just delete the threads and let them die if they
> don't submit a new version?
>
>

My understanding was that all items in a commit-fest have one of these
three dispositions:

.. committed
.. rejected
.. referred back to author for more work

We're really only interested in the third one here, and so, yes, the
ball should be in the author's court, not yours. I don't see any reason
for you to move items from one queue to another like that. It just looks
like it's making work.

cheers

andrew


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Andrew Dunstan <andrew@dunslane.net> writes:
> My understanding was that all items in a commit-fest have one of these
> three dispositions:

> . committed
> . rejected
> . referred back to author for more work

Right. But Bruce's personal queue has got a different lifecycle:
items get removed when they are resolved by a committed patch, or
by being rejected as not wanted, or by being summarized on the public
TODO list. For what he's doing that's a very good definition ---
things don't get forgotten just because nothing has happened lately.
But it's becoming clearer to me that the commit-fest queue has to be
a separate animal. We used Bruce's queue as the base this time around,
because we had no other timely-available source of the raw data.
Seems like it's time to split them, though.

If we do split them then there is going to be some added effort to
maintain the commit fest queue. Bruce has made it pretty clear
that he doesn't want to put in any extra cycles here. So someone
else has to step up to the plate if this is going to work.
Any volunteers out there?

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > My understanding was that all items in a commit-fest have one of these
> > three dispositions:
>
> > . committed
> > . rejected
> > . referred back to author for more work
>
> Right. But Bruce's personal queue has got a different lifecycle:
> items get removed when they are resolved by a committed patch, or
> by being rejected as not wanted, or by being summarized on the public
> TODO list. For what he's doing that's a very good definition ---
> things don't get forgotten just because nothing has happened lately.
> But it's becoming clearer to me that the commit-fest queue has to be
> a separate animal. We used Bruce's queue as the base this time around,
> because we had no other timely-available source of the raw data.
> Seems like it's time to split them, though.

Right, if the patch author stops working on it, but it is a feature we
want, the thread goes on the TODO list (or we complete the patch), so
yes, it is a different life-cycle.

> If we do split them then there is going to be some added effort to
> maintain the commit fest queue. Bruce has made it pretty clear
> that he doesn't want to put in any extra cycles here. So someone
> else has to step up to the plate if this is going to work.
> Any volunteers out there?

I assumed the wiki was going to be the official patch list from now on
and my web pages were just going to be a public display of things I was
tracking.

Frankly, I haven't been putting anything on the queue for the next
commit fest now except stuff that was already in-process for this commit
fest. The ideas is that we can commit stuff that has appeared since the
commit fest started before the next commit fest starts. I also moved
the emails to the next commit fest queue because that preserves the
comments made too.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Andrew Dunstan wrote:
> > Are you suggesting we just delete the threads and let them die if they
> > don't submit a new version?
> >
> >
>
> My understanding was that all items in a commit-fest have one of these
> three dispositions:
>
> . committed
> . rejected
> . referred back to author for more work
>
> We're really only interested in the third one here, and so, yes, the
> ball should be in the author's court, not yours. I don't see any reason
> for you to move items from one queue to another like that. It just looks
> like it's making work.

True. I could move the emails back to my private mailbox and just track
them there too. I moved them so it would be visible we were waiting for
some people.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches