Re: Commitfest status

The first commitfest has been on for about a week now, but I haven't
seem much festivities going on.

Do we plan to drain Bruce's patch queue completely during this
commitfest? Or the items on the developer wiki TODO:PatchStatus list?
When do we declare the commitfest to be over?

Bruce's queue has many patches in there that haven't had any activity,
and not all of the items are patches. The wiki is not quite up-to-date
either. Looking at the items in the wiki, here's my quick triage of the
items that have no reviewer assigned:

Dead space map - We want something that doesn't require a shared mem
block. It should also be crash-safe. I gave this, and the FSM a lot of
thought last Autumn, and I plan to work on this for 8.4, but the patch
as submitted is not acceptable.

On disk Bitmap Index - Needs work, abandoned by Gavin. No amount of
review will change that.

POSIX shared memory support - Doesn't seem like it's worth it, frankly.
I won't object if someone wants to put this in, but I'm not interested
to spend time on it myself.

stream bitmaps (API change for Group Index Tuples) - By me. I'm not
planning to work on this currently, as there's not much need for this
without bitmap indexes and grouped index tuples.

bitmap scan changes - same here

Grouped Index Tuples/Cluster Indexes - I'm not currently planning to
work on this further.

Group commit - just discussion, no patch

Maintaining cluster order on insert - AFAICT, rejected by Tom, because
the gain demonstrated by his test case was not worth adding so much
code. I don't think that was a good test case, as clustering in general
won't help much when the table fits in memory. There should be a bigger
gain on other workloads, but I'm not planning to work on this for now.

support for dumping only functions in pg_dump - An interesting patch,
needs some cleanup though. Would be nice to have support for other
objects than functions as well.

current_query - I don't understand why this is needed. What's the use case?

make --enable-integer-datetime the default - This needs more agreement
than review. Not that anyone is objecting, AFAIK.

TOAST thresholds - Not sure what this is. There is a patch by Tom here:
http://archives.postgresql.org/pgsql-patches/2008-02/msg00053.php that
looks ok to me.

Avahi support - I don't know enough about this to comment

DTrace enhancements - I don't know enough about this either to comment

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas wrote:
> The first commitfest has been on for about a week now, but I haven't
> seem much festivities going on.
>
> Do we plan to drain Bruce's patch queue completely during this
> commitfest? Or the items on the developer wiki TODO:PatchStatus list?
> When do we declare the commitfest to be over?
>
> Bruce's queue has many patches in there that haven't had any activity,
> and not all of the items are patches. The wiki is not quite up-to-date
> either. Looking at the items in the wiki, here's my quick triage of the
> items that have no reviewer assigned:

I am basically 1-2 days away from having the patch queue full/complete,
at which point I think we are going to need to make some decisions, as
you mentioned. Lots of items are unclear and just need a decision if it
is a TODO, patch work, or just discarded.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> The first commitfest has been on for about a week now, but I haven't
> seem much festivities going on.

Yeah, we are a bit behind on starting it :-(. Bruce was traveling
until the end of February and is still not caught up on updating
his list of open patches. And I had some Red Hat responsibilities
to take care of, as well as personal matters, and was happy to let
it slip a few days. But we need to get on with it.

> Do we plan to drain Bruce's patch queue completely during this
> commitfest? Or the items on the developer wiki TODO:PatchStatus list?

Right at the moment the raw data is still in Bruce's patch queue.
It's becoming increasingly obvious that that isn't going to work;
we can't have one man being a complete bottleneck for the entire
process. I concur with your other suggestion to try to move to
a wiki-based patch list, though it's unclear to me just how we
should manage that. I think I'd prefer a small number of people
(but more than just Bruce) responsible for updating the queue.

regards, tom lane

Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> > The first commitfest has been on for about a week now, but I haven't
> > seem much festivities going on.
>
> Yeah, we are a bit behind on starting it :-(. Bruce was traveling
> until the end of February and is still not caught up on updating
> his list of open patches. And I had some Red Hat responsibilities
> to take care of, as well as personal matters, and was happy to let
> it slip a few days. But we need to get on with it.
>
> > Do we plan to drain Bruce's patch queue completely during this
> > commitfest? Or the items on the developer wiki TODO:PatchStatus list?
>
> Right at the moment the raw data is still in Bruce's patch queue.
> It's becoming increasingly obvious that that isn't going to work;
> we can't have one man being a complete bottleneck for the entire
> process. I concur with your other suggestion to try to move to
> a wiki-based patch list, though it's unclear to me just how we
> should manage that. I think I'd prefer a small number of people
> (but more than just Bruce) responsible for updating the queue.

Consider I am collecting all our open items from the past 10 months.
Even when I am done the patch queue is going to be a load of work ---
take a look at what is there now.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

Bruce Momjian wrote:
> Tom Lane wrote:

> > Right at the moment the raw data is still in Bruce's patch queue.
> > It's becoming increasingly obvious that that isn't going to work;
> > we can't have one man being a complete bottleneck for the entire
> > process. I concur with your other suggestion to try to move to
> > a wiki-based patch list, though it's unclear to me just how we
> > should manage that. I think I'd prefer a small number of people
> > (but more than just Bruce) responsible for updating the queue.
>
> Consider I am collecting all our open items from the past 10 months.
> Even when I am done the patch queue is going to be a load of work ---
> take a look at what is there now.

We need storage of patches _outside_ our current patch queue.

As a first problem with the statu quo, it's not possible for other
people to add patches to the queue. Bruce suggests having a special
email address that will allow people to bounce patches to. I see this
as a kludge (a workable one perhaps, but still a kludge). Also it's not
clear how it deals with authorization, though this is probably not a
problem these days.

The second problem is that there's no way to actually extract the patch
from the queue. Cut'n pasting doesn't work, because whitespace is
mangled. So one has to resort (retort?) to extracting the patch from
one own's mbox, which sort of works -- unless it doesn't. And then you
have to work out what's the email containing the latest patch is; if
Bruce added a copy to the queue but the author updated it, how do you
find that out?

As a stopgap measure, a Wiki page could work. Patches should be
attached to the page, or a link to external storage should be posted
(but not to archives, obviously).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
>
> > > Right at the moment the raw data is still in Bruce's patch queue.
> > > It's becoming increasingly obvious that that isn't going to work;
> > > we can't have one man being a complete bottleneck for the entire
> > > process. I concur with your other suggestion to try to move to
> > > a wiki-based patch list, though it's unclear to me just how we
> > > should manage that. I think I'd prefer a small number of people
> > > (but more than just Bruce) responsible for updating the queue.
> >
> > Consider I am collecting all our open items from the past 10 months.
> > Even when I am done the patch queue is going to be a load of work ---
> > take a look at what is there now.
>
> We need storage of patches _outside_ our current patch queue.
>
> As a first problem with the statu quo, it's not possible for other
> people to add patches to the queue. Bruce suggests having a special
> email address that will allow people to bounce patches to. I see this
> as a kludge (a workable one perhaps, but still a kludge). Also it's not
> clear how it deals with authorization, though this is probably not a
> problem these days.

Right.

> The second problem is that there's no way to actually extract the patch
> from the queue. Cut'n pasting doesn't work, because whitespace is
> mangled. So one has to resort (retort?) to extracting the patch from
> one own's mbox, which sort of works -- unless it doesn't. And then you
> have to work out what's the email containing the latest patch is; if
> Bruce added a copy to the queue but the author updated it, how do you
> find that out?

Does the web site mhonarc archive have the same problem? Do you have
URLs? (You can download an mbox of my patches list from the top link.)

> As a stopgap measure, a Wiki page could work. Patches should be
> attached to the page, or a link to external storage should be posted
> (but not to archives, obviously).

The bottom line is that this going to be painful no matter how we go at
it:

http://momjian.us/cgi-bin/pgpatches

There are nine pages now. The patch queue will be twice that size once
I am done. I am trying to trim but it is difficult.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> The bottom line is that this going to be painful no matter how we go at
> it:
> http://momjian.us/cgi-bin/pgpatches

Yup.

> There are nine pages now. The patch queue will be twice that size once
> I am done. I am trying to trim but it is difficult.

Bruce, you are putting too much of the work on your own shoulders and
bottlenecking the whole process. Just dump stuff into the queue, don't
trim and for heavens sake stop fixing "simple" things as you go. Once
the queue is there we can spread around the work of processing the
items.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > The bottom line is that this going to be painful no matter how we go at
> > it:
> > http://momjian.us/cgi-bin/pgpatches
>
> Yup.
>
> > There are nine pages now. The patch queue will be twice that size once
> > I am done. I am trying to trim but it is difficult.
>
> Bruce, you are putting too much of the work on your own shoulders and
> bottlenecking the whole process. Just dump stuff into the queue, don't
> trim and for heavens sake stop fixing "simple" things as you go. Once
> the queue is there we can spread around the work of processing the
> items.

OK, you asked for it. All emails have been moved from pgpatches_hold to
pgpatches. There are 19 pages. Let the pain begin!

http://momjian.us/cgi-bin/pgpatches

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 7 Mar 2008 12:29:13 -0300
Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:

> Bruce Momjian wrote:
> > Tom Lane wrote:
>
> > > Right at the moment the raw data is still in Bruce's patch queue.
> > > It's becoming increasingly obvious that that isn't going to work;
> > > we can't have one man being a complete bottleneck for the entire
> > > process. I concur with your other suggestion to try to move to
> > > a wiki-based patch list, though it's unclear to me just how we
> > > should manage that. I think I'd prefer a small number of people
> > > (but more than just Bruce) responsible for updating the queue.
> >
> > Consider I am collecting all our open items from the past 10
> > months. Even when I am done the patch queue is going to be a load
> > of work --- take a look at what is there now.
>
> We need storage of patches _outside_ our current patch queue.

O.k. this is ugly, probably shouldn't be done, and I may be flamed into
oblivion for this but since we aren't using some kind of bug tracker
that will detach the patches etc...

Have we considered a read only imap server with a patches account that
anyone can attach to with their email client to pull patches?

Or, just a web-email interface that would allow someone to download the
attachment?

Sincerely,

Joshua D. Drake
- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH0W/pATb/zqfZUUQRAsBmAJ9afIUgsuN+26zjbdk8MHcfX9755QCeISM6
zxcu/CxQYN2ujjovJXrm2H8=
=E+FF
-----END PGP SIGNATURE-----

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Bruce, you are putting too much of the work on your own shoulders and
>> bottlenecking the whole process. Just dump stuff into the queue, don't
>> trim and for heavens sake stop fixing "simple" things as you go. Once
>> the queue is there we can spread around the work of processing the
>> items.

> OK, you asked for it. All emails have been moved from pgpatches_hold to
> pgpatches. There are 19 pages. Let the pain begin!
> http://momjian.us/cgi-bin/pgpatches

OK, so now we need to actually divvy up the work somehow. Anyone want
to take any particular pieces of this? I think the first step is triage
--- which items actually need review now, which are dead or should
become TODO entries, and which are trivial enough to just deal with
without review. (Bruce, I guess you already did that on a portion
of this list, but which portion?)

Since there are 19 pages and probably less than 19 interested hackers,
maybe we could just each take a page of the list as it stands and go
through it at that level? Although many of the threads cross pages, so
that's not ideal. Any other ideas?

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> Bruce, you are putting too much of the work on your own shoulders and
> >> bottlenecking the whole process. Just dump stuff into the queue, don't
> >> trim and for heavens sake stop fixing "simple" things as you go. Once
> >> the queue is there we can spread around the work of processing the
> >> items.
>
> > OK, you asked for it. All emails have been moved from pgpatches_hold to
> > pgpatches. There are 19 pages. Let the pain begin!
> > http://momjian.us/cgi-bin/pgpatches
>
> OK, so now we need to actually divvy up the work somehow. Anyone want
> to take any particular pieces of this? I think the first step is triage
> --- which items actually need review now, which are dead or should
> become TODO entries, and which are trivial enough to just deal with
> without review. (Bruce, I guess you already did that on a portion
> of this list, but which portion?)

Page 1-9 but lots I couldn't decide if they were TODO. I am now adding
comments to lots of entries so people know what I need to know about it.

> Since there are 19 pages and probably less than 19 interested hackers,
> maybe we could just each take a page of the list as it stands and go
> through it at that level? Although many of the threads cross pages, so
> that's not ideal. Any other ideas?

The problem is that as they are deleted, they will move. Perhaps I can
just comment on them to close them and not delete anything.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Since there are 19 pages and probably less than 19 interested hackers,
>> maybe we could just each take a page of the list as it stands and go
>> through it at that level? Although many of the threads cross pages, so
>> that's not ideal. Any other ideas?

> The problem is that as they are deleted, they will move. Perhaps I can
> just comment on them to close them and not delete anything.

Ah, right. And the other problem is additions of new messages to
threads. So the page boundaries can't be expected to stay stable for
long.

The comment thing is kinda cool, but I don't feel very comfortable about
using the comments for anything substantive. Actual reviews of patches,
for example, need to still be sent on the mailing lists so that they'll
go into the archives. I suggest we just use the comments for status
annotations, like "done" or "no patch here, make a TODO" or "needs
review, I will review".

regards, tom lane

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [080307 11:46]:

> Since there are 19 pages and probably less than 19 interested hackers,
> maybe we could just each take a page of the list as it stands and go
> through it at that level? Although many of the threads cross pages, so
> that's not ideal. Any other ideas?

Only 150 "patches" in that queue, if you eliminate all the discussions
and threads:
http://people.ifax.com/~aidan/pg/patches.mbox

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> Since there are 19 pages and probably less than 19 interested hackers,
> >> maybe we could just each take a page of the list as it stands and go
> >> through it at that level? Although many of the threads cross pages, so
> >> that's not ideal. Any other ideas?
>
> > The problem is that as they are deleted, they will move. Perhaps I can
> > just comment on them to close them and not delete anything.
>
> Ah, right. And the other problem is additions of new messages to
> threads. So the page boundaries can't be expected to stay stable for
> long.

Oh, yea, if I add things to the list they would bump things around.
Perhaps we can just skip the idea that the URLs are constant and rely on
the comments as staying with the emails.

> The comment thing is kinda cool, but I don't feel very comfortable about
> using the comments for anything substantive. Actual reviews of patches,
> for example, need to still be sent on the mailing lists so that they'll
> go into the archives. I suggest we just use the comments for status
> annotations, like "done" or "no patch here, make a TODO" or "needs
> review, I will review".

Yea, the comments are to prompt people about what we need to do.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

Aidan Van Dyk wrote:
-- Start of PGP signed section.
> * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [080307 11:46]:
>
> > Since there are 19 pages and probably less than 19 interested hackers,
> > maybe we could just each take a page of the list as it stands and go
> > through it at that level? Although many of the threads cross pages, so
> > that's not ideal. Any other ideas?
>
>
> Only 150 "patches" in that queue, if you eliminate all the discussions
> and threads:
> http://people.ifax.com/~aidan/pg/patches.mbox

True, but we can't just discard all the ideas we had --- we need to
decide if they are worth persuing or adding to TODO.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

On Fri, Mar 7, 2008 at 11:48 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Since there are 19 pages and probably less than 19 interested hackers,
> > maybe we could just each take a page of the list as it stands and go
> > through it at that level? Although many of the threads cross pages, so
> > that's not ideal. Any other ideas?
>
> The problem is that as they are deleted, they will move. Perhaps I can
> just comment on them to close them and not delete anything.

I checked the patches listing for our own stuff, and confirmed missing
some of the later exchanges. It wouldn't be helpful to a reviewer
without some of the other context on the mailing list.

ISTM if we move to a 'wiki style' patch management, or something more
formal like a bug tracker the work becomes more decentralized and the
patch developer becomes more involved in keeping the patch list up to
date with the latest stuff. I think the wiki, being a more organic
type of approach. is maybe a better fit for postgresql community
style, and there is still a lot of 'plumbing' work to do.

If you want to move some stuff to the wiki I will volunteer to help
out with the initial transfer of patches from the hold list. I can do
some review also, but am only up to snuff to review maybe 20% of the
patches on there, so maybe page/person is not a good way to divide it
up. I think better to just grab a patch and put yourself as a
reviewer on the wiki.

merlin

Bruce Momjian wrote:
> Aidan Van Dyk wrote:
> -- Start of PGP signed section.

> > Only 150 "patches" in that queue, if you eliminate all the discussions
> > and threads:
> > http://people.ifax.com/~aidan/pg/patches.mbox
>
> True, but we can't just discard all the ideas we had --- we need to
> decide if they are worth persuing or adding to TODO.

Move the ideas to a different mbox.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

* Bruce Momjian <bruce(at)momjian(dot)us> [080307 12:29]:
> Aidan Van Dyk wrote:
> -- Start of PGP signed section.
> > * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [080307 11:46]:
> >
> > > Since there are 19 pages and probably less than 19 interested hackers,
> > > maybe we could just each take a page of the list as it stands and go
> > > through it at that level? Although many of the threads cross pages, so
> > > that's not ideal. Any other ideas?
> >
> >
> > Only 150 "patches" in that queue, if you eliminate all the discussions
> > and threads:
> > http://people.ifax.com/~aidan/pg/patches.mbox
>
> True, but we can't just discard all the ideas we had --- we need to
> decide if they are worth persuing or adding to TODO.

Sure, but ideas *are* discussed on the list as they come up. But it's
not ideas that get committed during the commitfest.

It's up to the "itchy" person to use the discussion on the lists around
the ideas to come up with something concrete that *needs* to be more
than hand-waving to be reviewed during a commit fest.

That concrete something could be:
*) A complete "patch"
*) A partial patch (implementing step X of the discussed goals
*) A defined implementation proposal (a patch minus C-language code)

Ideas and discussion are important (actually vital). But the
commit-fest is a period that reviewers and committers set apart time to
process the *products* of ideas and proposals that have come about so
far.

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Merlin Moncure escribió:

> ISTM if we move to a 'wiki style' patch management, or something more
> formal like a bug tracker the work becomes more decentralized and the
> patch developer becomes more involved in keeping the patch list up to
> date with the latest stuff. I think the wiki, being a more organic
> type of approach. is maybe a better fit for postgresql community
> style, and there is still a lot of 'plumbing' work to do.

Right. If the submitter thinks that the reviewer is going to need to
have a look at the relevant email archives, he can post a link to the
archives in the discussion web page for the patch.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Aidan Van Dyk wrote:
> > > Only 150 "patches" in that queue, if you eliminate all the discussions
> > > and threads:
> > > http://people.ifax.com/~aidan/pg/patches.mbox
> >
> > True, but we can't just discard all the ideas we had --- we need to
> > decide if they are worth persuing or adding to TODO.
>
> Sure, but ideas *are* discussed on the list as they come up. But it's
> not ideas that get committed during the commitfest.
>
> It's up to the "itchy" person to use the discussion on the lists around
> the ideas to come up with something concrete that *needs* to be more
> than hand-waving to be reviewed during a commit fest.
>
> That concrete something could be:
> *) A complete "patch"
> *) A partial patch (implementing step X of the discussed goals
> *) A defined implementation proposal (a patch minus C-language code)
>
> Ideas and discussion are important (actually vital). But the
> commit-fest is a period that reviewers and committers set apart time to
> process the *products* of ideas and proposals that have come about so
> far.

Well, when do we make decisions on these non-patch issue? Seems the
commit fest is the right time to that too.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

Alvaro Herrera wrote:
> Merlin Moncure escribi?:
>
> > ISTM if we move to a 'wiki style' patch management, or something more
> > formal like a bug tracker the work becomes more decentralized and the
> > patch developer becomes more involved in keeping the patch list up to
> > date with the latest stuff. I think the wiki, being a more organic
> > type of approach. is maybe a better fit for postgresql community
> > style, and there is still a lot of 'plumbing' work to do.
>
> Right. If the submitter thinks that the reviewer is going to need to
> have a look at the relevant email archives, he can post a link to the
> archives in the discussion web page for the patch.

True, but what are the odds that is going to happen. We have trouble
getting context diffs.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Merlin Moncure escribi?:
>>
>>> ISTM if we move to a 'wiki style' patch management, or something more
>>> formal like a bug tracker the work becomes more decentralized and the
>>> patch developer becomes more involved in keeping the patch list up to
>>> date with the latest stuff. I think the wiki, being a more organic
>>> type of approach. is maybe a better fit for postgresql community
>>> style, and there is still a lot of 'plumbing' work to do.
>> Right. If the submitter thinks that the reviewer is going to need to
>> have a look at the relevant email archives, he can post a link to the
>> archives in the discussion web page for the patch.
>
> True, but what are the odds that is going to happen. We have trouble
> getting context diffs.
>

I know merlin and I allocated a lot of resources towards our patch. If
getting reviewed required us to jump through some hoops (like being
repsonsible for updating a wiki), then so be it. If someone doesn't
follow the patch submission rules, then the patch can't be reviewed as
it is not within the proper state ... not a punishment just a patch not
meeting review requirements.

What are the requirements of a patch submission, don't know. One thing
is for sure, the patch submitter is probably the most familiar with it
so should be involved at some level of review preparation. This
distributes the work and "attempts" to make patches more consistent when
reviewed.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

* Bruce Momjian <bruce(at)momjian(dot)us> [080307 13:11]:

> > Ideas and discussion are important (actually vital). But the
> > commit-fest is a period that reviewers and committers set apart time to
> > process the *products* of ideas and proposals that have come about so
> > far.
>
> Well, when do we make decisions on these non-patch issue? Seems the
> commit fest is the right time to that too.

There are 2 big decisions in the process:

1) Is this "feature/topic" worth *me* working on?
2) Is the result of that work worth going into "official" PostgreSQL CVS?

#1 is made by the developer, hopefully based on some initial discussion
on the lists. IF the discussion is overwhelmingly dismissive, or
negative, or points in the some other direction, hopefully that decision
will be an easy "no", so the developer doesn't waste his time. But the
reviewers/committers *don't* decide if or what is worth a developer's
effort. Even if it's *not* something that the community sees working
out for PostgreSQL, it very well *may* be something "worth it" for the
developer to pursue himself. It's simply his decision. And even if it
*is* something that may be very good and desirable for PostgreSQL, the
community can't make a developer work on it. It's an open source
project.

#2 is made by the reviewers/committers when the person presents the
work he thought "worth it". And they can only make that decision when
there is "something" to decide on.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Am Freitag, 7. März 2008 schrieb Bruce Momjian:
> OK, you asked for it.  All emails have been moved from pgpatches_hold to
> pgpatches.  There are 19 pages.  Let the pain begin!
>
>         http://momjian.us/cgi-bin/pgpatches

OK, now how about moving this directory to developer.postgresql.org, do
chgrp -R dev; chmod g+rw, and we can start working.

Peter Eisentraut wrote:
> Am Freitag, 7. M?rz 2008 schrieb Bruce Momjian:
> > OK, you asked for it. ?All emails have been moved from pgpatches_hold to
> > pgpatches. ?There are 19 pages. ?Let the pain begin!
> >
> > ????????http://momjian.us/cgi-bin/pgpatches
>
> OK, now how about moving this directory to developer.postgresql.org, do
> chgrp -R dev; chmod g+rw, and we can start working.

Huh, it is a single mbox file, and is tied to my mhonarc and comments
HTML code. What do you want to do?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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