Re: How to submit a patch

Hello,

Could someone break out exactly what the process is "now" for
submitting a patch? Last month I sent a patch for pg_dump which never
got feedback (at least on thread). I just asked and alvaro asked me to
add it to the commitfest page. Which I have done but I think we need to
known all the steps and get it documented.

I have:

post to pgsql-hackers with idea, take feedback, code to consensus
post to pgsql-patches, await feedback
...
?

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> Hello,
>
> Could someone break out exactly what the process is "now" for
> submitting a patch? Last month I sent a patch for pg_dump which never
> got feedback (at least on thread). I just asked and alvaro asked me to
> add it to the commitfest page. Which I have done but I think we need to
> known all the steps and get it documented.
>
> I have:
>
> post to pgsql-hackers with idea, take feedback, code to consensus
> post to pgsql-patches, await feedback
> ...
> ?
>

If you posted it last month then it was too late for the commit-fest
that started on March 1, IIRC, so the fact that you didn't get feedback
is hardly surprising - a commit-fest is like a mini-feature-freeze.

As for the rest, we are still feeling our way a bit, as should have been
apparent from the list emails, so formal documentation is probably
premature.

cheers

andrew

On Wed, 16 Apr 2008 13:59:50 -0400
Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> If you posted it last month then it was too late for the commit-fest
> that started on March 1, IIRC, so the fact that you didn't get
> feedback is hardly surprising - a commit-fest is like a
> mini-feature-freeze.

O.k. then what happens at that point? It wasn't in the queue for May (I
had to add it)

>
> As for the rest, we are still feeling our way a bit, as should have
> been apparent from the list emails, so formal documentation is
> probably premature.

I assumed the docs would be subject to change but "something" that
gives one off and not often patch submitters a clue is probably useful.
It also allows us to actually discuss a pattern of behavior we are
starting versus bouncing through 50 threads trying to figure out what's
next.

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> On Wed, 16 Apr 2008 13:59:50 -0400
> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> >
> > If you posted it last month then it was too late for the commit-fest
> > that started on March 1, IIRC, so the fact that you didn't get
> > feedback is hardly surprising - a commit-fest is like a
> > mini-feature-freeze.
>
> O.k. then what happens at that point? It wasn't in the queue for May (I
> had to add it)

I review it and apply or reply to the author. The wiki had started
being updated after your submission so this is a transitionary phase.

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

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

On Wed, 16 Apr 2008 14:10:30 -0400 (EDT)
Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> Joshua D. Drake wrote:
> > On Wed, 16 Apr 2008 13:59:50 -0400
> > Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> >
> > >
> > > If you posted it last month then it was too late for the
> > > commit-fest that started on March 1, IIRC, so the fact that you
> > > didn't get feedback is hardly surprising - a commit-fest is like a
> > > mini-feature-freeze.
> >
> > O.k. then what happens at that point? It wasn't in the queue for
> > May (I had to add it)
>
> I review it and apply or reply to the author. The wiki had started
> being updated after your submission so this is a transitionary phase.

Wait... apply where? The wiki? or to the tree?

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> On Wed, 16 Apr 2008 14:10:30 -0400 (EDT)
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> > Joshua D. Drake wrote:
> > > On Wed, 16 Apr 2008 13:59:50 -0400
> > > Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> > >
> > > >
> > > > If you posted it last month then it was too late for the
> > > > commit-fest that started on March 1, IIRC, so the fact that you
> > > > didn't get feedback is hardly surprising - a commit-fest is like a
> > > > mini-feature-freeze.
> > >
> > > O.k. then what happens at that point? It wasn't in the queue for
> > > May (I had to add it)
> >
> > I review it and apply or reply to the author. The wiki had started
> > being updated after your submission so this is a transitionary phase.
>
> Wait... apply where? The wiki? or to the tree?

Apply to CVS.

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

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

Bruce Momjian wrote:
> Joshua D. Drake wrote:
>
>> On Wed, 16 Apr 2008 14:10:30 -0400 (EDT)
>> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>
>>
>>> Joshua D. Drake wrote:
>>>
>>>> On Wed, 16 Apr 2008 13:59:50 -0400
>>>> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>>>
>>>>
>>>>> If you posted it last month then it was too late for the
>>>>> commit-fest that started on March 1, IIRC, so the fact that you
>>>>> didn't get feedback is hardly surprising - a commit-fest is like a
>>>>> mini-feature-freeze.
>>>>>
>>>> O.k. then what happens at that point? It wasn't in the queue for
>>>> May (I had to add it)
>>>>
>>> I review it and apply or reply to the author. The wiki had started
>>> being updated after your submission so this is a transitionary phase.
>>>
>> Wait... apply where? The wiki? or to the tree?
>>
>
> Apply to CVS.
>
>

Bruce, I know you don't mean this, but it reads like you are undertaking
to review and apply all patches.

BTW, I don't see why the wiki can't pick up patches that were submitted
before it started.

cheers

andrew

On Wed, 16 Apr 2008 14:13:53 -0400 (EDT)
Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> > > I review it and apply or reply to the author. The wiki had
> > > started being updated after your submission so this is a
> > > transitionary phase.
> >
> > Wait... apply where? The wiki? or to the tree?
>
> Apply to CVS.
>

O.k. so patches may be applied through the development cycle but no
patches will be accepted after -X- date for a current commit fest. So
my question is:

If you are going to review the patch and apply or reply to the author,
at one point is it supposed to be on the wiki?

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Andrew Dunstan wrote:
> >>>>> If you posted it last month then it was too late for the
> >>>>> commit-fest that started on March 1, IIRC, so the fact that you
> >>>>> didn't get feedback is hardly surprising - a commit-fest is like a
> >>>>> mini-feature-freeze.
> >>>>>
> >>>> O.k. then what happens at that point? It wasn't in the queue for
> >>>> May (I had to add it)
> >>>>
> >>> I review it and apply or reply to the author. The wiki had started
> >>> being updated after your submission so this is a transitionary phase.
> >>>
> >> Wait... apply where? The wiki? or to the tree?
> >>
> >
> > Apply to CVS.
> >
> >
>
> Bruce, I know you don't mean this, but it reads like you are undertaking
> to review and apply all patches.

Didn't you read "review it and apply or reply to the author".

> BTW, I don't see why the wiki can't pick up patches that were submitted
> before it started.

True.

Frankly, I am getting pretty tired of people complaining about what I am
doing. Perhaps I should just stop and let everyone else deal with
things. I have lots of things I would rather be doing.

This is one of the reasons I didn't want to add wiki maintenance to my
already full workload. Instead I am having to field complaints.

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

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

Joshua D. Drake wrote:
> On Wed, 16 Apr 2008 14:13:53 -0400 (EDT)
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> > > > I review it and apply or reply to the author. The wiki had
> > > > started being updated after your submission so this is a
> > > > transitionary phase.
> > >
> > > Wait... apply where? The wiki? or to the tree?
> >
> > Apply to CVS.
> >
>
> O.k. so patches may be applied through the development cycle but no
> patches will be accepted after -X- date for a current commit fest. So
> my question is:
>
> If you are going to review the patch and apply or reply to the author,
> at one point is it supposed to be on the wiki?

I have no idea. If not dealt with, it will be on my web page once the
next commit fest starts.

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

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

Bruce Momjian wrote:
> Frankly, I am getting pretty tired of people complaining about what I am
> doing. Perhaps I should just stop and let everyone else deal with
> things. I have lots of things I would rather be doing.
>
> This is one of the reasons I didn't want to add wiki maintenance to my
> already full workload. Instead I am having to field complaints.
>
>

I didn't mean to complain about anything. Personally, I'm in favor of
reducing your workload.

cheers

andrew

Joshua D. Drake wrote:
> On Wed, 16 Apr 2008 13:59:50 -0400
> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> If you posted it last month then it was too late for the commit-fest
>> that started on March 1, IIRC, so the fact that you didn't get
>> feedback is hardly surprising - a commit-fest is like a
>> mini-feature-freeze.
>
> O.k. then what happens at that point? It wasn't in the queue for May (I
> had to add it)

There is different viewpoints on how it should happen. Hopefully the
picture will be clearer after one or two more commit fests.

Based on my observations, there's basically three different workflows a
patch can follow (assuming the patch gets committed in the end):

Workflow A:

1. You post patch to pgsql-patches
2. a committer picks it up immediately, and commits it.

Workflow B:

1. You post a patch to pgsql-patches
2. You add a link to the wiki page of the next commit fest
3. A committer picks up the patch from the wiki page, and commits it

Workflow C:

1. You post a patch to pgsql-patches
2. Bruce adds the patch to the unapplied patches queue after a while
3. At the beginning of the next commit fest, Alvaro (with the help from
others, I hope) goes through the patches queue, and puts a link to the
wiki page of the next commit fest
4. A committer picks up the patch from the wiki page, and commits it

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

On Wed, 16 Apr 2008 14:24:34 -0400 (EDT)
Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> > If you are going to review the patch and apply or reply to the
> > author, at one point is it supposed to be on the wiki?
>
> I have no idea. If not dealt with, it will be on my web page once the
> next commit fest starts.
>

This is the exact reason I posted the question :).

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Andrew Dunstan wrote:

> BTW, I don't see why the wiki can't pick up patches that were submitted
> before it started.

Of course it can. This one wasn't added initially because I didn't see it.

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

Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Frankly, I am getting pretty tired of people complaining about what I am
> > doing. Perhaps I should just stop and let everyone else deal with
> > things. I have lots of things I would rather be doing.
> >
> > This is one of the reasons I didn't want to add wiki maintenance to my
> > already full workload. Instead I am having to field complaints.
> >
> >
>
> I didn't mean to complain about anything. Personally, I'm in favor of
> reducing your workload.

OK. FYI, what would be really nice would be for someone to review and
apply the patch or give the author feedback so we could avoid adding it
to the wiki at all.

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

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

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

On Thu, Apr 17, 2008 at 5:17 AM, Bruce Momjian
wrote:
> Andrew Dunstan wrote:
> > Bruce Momjian wrote:
> > >
> > > This is one of the reasons I didn't want to add wiki maintenance to my
> > > already full workload. Instead I am having to field complaints.
> >
> > I didn't mean to complain about anything. Personally, I'm in favor of
> > reducing your workload.
>
> OK. FYI, what would be really nice would be for someone to review and
> apply the patch or give the author feedback so we could avoid adding it
> to the wiki at all.

Bruce,

Yes, that would be nice! But not likely in practice, unless your
patch happens to immediately catch the interest of a suitably
qualified person with commit privileges.

However, I don't know of any way the maintenance of the wiki is an
addition to your workload. I feel that the onus of adding the patch
to the wiki should be on the submitter, and we've already had some
success getting submitters to add their own patches. And Alvaro has
already offered to pick up the slack in cases where the submitter
fails to add their patch to the queue.

Every patch that somebody else adds to the wiki is another patch you
don't have to add to your queue, so how can this be anything but a
plus for you?

Cheers,
BJ

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: http://getfiregpg.org

iD8DBQFIBlfb5YBsbHkuyV0RAs6tAKDNR3CbqFC4YwROaoiwNMXSWKXWTgCbBaz1
pO90zcotv+/UMJrotfDTg/M=
=IY5R
-----END PGP SIGNATURE-----

On Wed, Apr 16, 2008 at 3:47 PM, Brendan Jurd <direvus(at)gmail(dot)com> wrote:
> On Thu, Apr 17, 2008 at 5:17 AM, Bruce Momjian
> > Andrew Dunstan wrote:
> > > Bruce Momjian wrote:
> > > >
>
> > > > This is one of the reasons I didn't want to add wiki maintenance to my
> > > > already full workload. Instead I am having to field complaints.
> > >
> > > I didn't mean to complain about anything. Personally, I'm in favor of
> > > reducing your workload.
> >
> > OK. FYI, what would be really nice would be for someone to review and
> > apply the patch or give the author feedback so we could avoid adding it
> > to the wiki at all.
> Yes, that would be nice! But not likely in practice, unless your
> patch happens to immediately catch the interest of a suitably
> qualified person with commit privileges.
>
> However, I don't know of any way the maintenance of the wiki is an
> addition to your workload. I feel that the onus of adding the patch
> to the wiki should be on the submitter, and we've already had some
> success getting submitters to add their own patches. And Alvaro has
> already offered to pick up the slack in cases where the submitter
> fails to add their patch to the queue.

One small point here. I've been mostly following this discussion on
this particular topic but have absolutely no idea what, if anything,
to do on the wiki in terms of submitting patch. There was a spot
related to the commit fest where we kept an to date version of our
patch which I can't find any more (might be lousy search skills on my
end).

There seems to be information scattered all over the place with
various overlapping lists whose function and location are changing
constantly. This is not a gripe by any means....it just that you
might get a little more help from the grass roots on the wiki as the
process settles down and there are examples of what to do.

merlin

Brendan Jurd wrote:
> > OK. FYI, what would be really nice would be for someone to review and
> > apply the patch or give the author feedback so we could avoid adding it
> > to the wiki at all.
>
> Bruce,
>
> Yes, that would be nice! But not likely in practice, unless your
> patch happens to immediately catch the interest of a suitably
> qualified person with commit privileges.
>
> However, I don't know of any way the maintenance of the wiki is an
> addition to your workload. I feel that the onus of adding the patch
> to the wiki should be on the submitter, and we've already had some
> success getting submitters to add their own patches. And Alvaro has
> already offered to pick up the slack in cases where the submitter
> fails to add their patch to the queue.
>
> Every patch that somebody else adds to the wiki is another patch you
> don't have to add to your queue, so how can this be anything but a
> plus for you?

Yes, but unless people actually applies patches from the wiki, it
doesn't help me --- adding patches to my queue is zero cost for me.

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

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

Heikki Linnakangas wrote:
> Based on my observations, there's basically three different workflows a
> patch can follow (assuming the patch gets committed in the end):
>
> Workflow A:
>
> 1. You post patch to pgsql-patches
> 2. a committer picks it up immediately, and commits it.
>
> Workflow B:
>
> 1. You post a patch to pgsql-patches
> 2. You add a link to the wiki page of the next commit fest
> 3. A committer picks up the patch from the wiki page, and commits it
>
> Workflow C:
>
> 1. You post a patch to pgsql-patches
> 2. Bruce adds the patch to the unapplied patches queue after a while
> 3. At the beginning of the next commit fest, Alvaro (with the help from
> others, I hope) goes through the patches queue, and puts a link to the
> wiki page of the next commit fest
> 4. A committer picks up the patch from the wiki page, and commits it

Yep, that's pretty accurate.

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

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

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

On Thu, Apr 17, 2008 at 6:03 AM, Merlin Moncure wrote:
> One small point here. I've been mostly following this discussion on
> this particular topic but have absolutely no idea what, if anything,
> to do on the wiki in terms of submitting patch. There was a spot
> related to the commit fest where we kept an to date version of our
> patch which I can't find any more (might be lousy search skills on my
> end).
>

Fair enough. The current commitfest page is at
http://wiki.postgresql.org/wiki/CommitFest:May

I agree that it's not well linked from the front page of the wiki (you
have to follow "Development information" -> "Project management
documentation" -> "Patches for May Commitfest").

I've added a redirect at http://wiki.postgresql.org/wiki/CommitFest
which currently points to May, but should be updated whenever we close
a commitfest against new submissions. That way submitters will always
have one URL to visit to add their stuff.

> There seems to be information scattered all over the place with
> various overlapping lists whose function and location are changing
> constantly. This is not a gripe by any means....it just that you
> might get a little more help from the grass roots on the wiki as the
> process settles down and there are examples of what to do.
>

I agree, and in fact I've just recently added some documentation about
how to add your patch to the wiki up the top of the CommitFest:May
page; I invite you to take a look and post back if you have any
comments.

Cheers,
BJ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: http://getfiregpg.org

iD8DBQFIBl9f5YBsbHkuyV0RAoP8AKDAOaXzhsC7ap0/AVf0F6SqxHOZwACfQ4LR
JJQcrRKbxoIzQHRbja6gqBw=
=tLDr
-----END PGP SIGNATURE-----

On Thu, 17 Apr 2008 06:19:49 +1000
"Brendan Jurd" <direvus(at)gmail(dot)com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, Apr 17, 2008 at 6:03 AM, Merlin Moncure wrote:
> > One small point here. I've been mostly following this discussion
> > on this particular topic but have absolutely no idea what, if
> > anything, to do on the wiki in terms of submitting patch. There
> > was a spot related to the commit fest where we kept an to date
> > version of our patch which I can't find any more (might be lousy
> > search skills on my end).
> >
>
> Fair enough. The current commitfest page is at
> http://wiki.postgresql.org/wiki/CommitFest:May
>
> I agree that it's not well linked from the front page of the wiki (you
> have to follow "Development information" -> "Project management
> documentation" -> "Patches for May Commitfest").
>
> I've added a redirect at http://wiki.postgresql.org/wiki/CommitFest
> which currently points to May, but should be updated whenever we close
> a commitfest against new submissions. That way submitters will always
> have one URL to visit to add their stuff.

We should also update the FAQ.

Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Merlin Moncure wrote:
> I've been mostly following this discussion on
> this particular topic but have absolutely no idea what, if anything,
> to do on the wiki in terms of submitting patch.
>

I think the short answer right now to this and to Joshua's original
question is: to submit a patch do what has always been done, i.e. send
the patch to the mailing list. You can also add the patch to the list on
the wiki, but if you don't, it won't be forgotten.

All the rest is for reviewers/committers.

I've been wondering idly and probably pointlessly if we should try
adopting something like the methodology of the Usenet Oracle, which, if
you ask it a question will usually send you one to answer in return.
Obviously we can't always do that, but maybe we should be asking people
who are obviously competent enough (judging by the quality and
complexity of the patches they submit) to step up to the plate more on
reviewing patches. No amount of process will substitute for more reviewers.

cheers

andrew

On Wed, 16 Apr 2008, Joshua D. Drake wrote:

>> I've added a redirect at http://wiki.postgresql.org/wiki/CommitFest
>> which currently points to May, but should be updated whenever we close
>> a commitfest against new submissions.
>
> We should also update the FAQ.

I wouldn't bother with that yet. That whole area of the Wiki is still
moving around a bit, and I expect some more usefully targetted pages will
emerge ("How to submit a patch" comes to mind). Having a stable
CommitFest URL is handy, but I don't think it's where the FAQ should be
sending people.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:

> Workflow A:
>
> 1. You post patch to pgsql-patches
> 2. a committer picks it up immediately, and commits it.

I'm more interested in knowing what happens when a committer *doesn't* commit
it. Personally I would almost rather a committer not commit my patch but
instead return feedback on the first go-around than commit it.

I would rather hear about any objections and fix them myself and in the
process learn how to do it better next time. It just isn't as good a learning
experience when I read the commit diffs and have to try to figure out what the
rationale was for the changes.

That's why waiting until feature freeze was so awful from my point of view.
There was never any time left to return patches to the author so Tom ended up
reworking any patches we really wanted.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

Gregory Stark wrote:
> That's why waiting until feature freeze was so awful from my point of view.
> There was never any time left to return patches to the author so Tom ended up
> reworking any patches we really wanted.
>

Some patches went back and forth a few times even after feature freeze.

Many patches last feature freeze seemed to me at least to be of lower
quality and/or higher complexity than usual, and we had a huge number.
Part of the idea behind commit-fest is to avoid that, and so kicking
patches back to the author is more likely to occur, I think.

cheers

andrew

On Wed, 16 Apr 2008, Heikki Linnakangas wrote:

> Based on my observations, there's basically three different workflows a patch
> can follow (assuming the patch gets committed in the end)

This list was so good that I used it as the basis for a new page on the
wiki: http://wiki.postgresql.org/wiki/Submitting_a_Patch

I just did a big cleanup of the whole developer's area there. Rather than
the nested mess there before, there's now a fairly complete entry page:

http://wiki.postgresql.org/wiki/Development_information

That should have the majority of what most people are looking for. The
previous "project management" page was collapsed into the above. There's
still a "Development projects" subpage there, but that's fairly specific
to people who know what they're looking for I think. The "March
Commitfest" section might be slimmed down a bit after the May one is
better defined.

One small change I'd suggest on the main site:
http://www.postgresql.org/developer/coding links to
http://wiki.postgresql.org/wiki/Developer_and_Contributor_Resources which
is now a redirect to the above page. I separated out the advocacy
contributors to their own section which made the longer title unneeded.
It would be nice one day to change that to use the shorter
Development_information URL instead. It would also be worth considering a
direct link to that URL in the manual, I believe it will remain stable
now.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Greg Smith wrote:
> On Wed, 16 Apr 2008, Heikki Linnakangas wrote:

> One small change I'd suggest on the main site:
> http://www.postgresql.org/developer/coding links to
> http://wiki.postgresql.org/wiki/Developer_and_Contributor_Resources
> which is now a redirect to the above page.

This request should be on -www and as a note I don't know that I like
the idea.

Joshua D. Drake

On Sat, 19 Apr 2008, Joshua D. Drake wrote:

> Greg Smith wrote:
>
>> One small change I'd suggest on the main site:
>> http://www.postgresql.org/developer/coding links to
>> http://wiki.postgresql.org/wiki/Developer_and_Contributor_Resources which
>> is now a redirect to the above page.
>
> This request should be on -www and as a note I don't know that I like the
> idea.

There were two suggestions there, and technically one of them goes to
-docs instead if we're gonna get picky.

1) Switch the URL that's already on the coding page to more directly point
to a URL that actually exists, rather than a redirect. That seems
undebatable.

2) Put a link to an area that contains information like current CommitFest
progress in the development section of the manual.

(2) was already suggested here recently; I said I didn't think that was a
good idea until the content there stabilized because I planned a
reorganization. I was just announcing that I believe that to be stable
now, and I nominate the revised "Developer information" page as the one to
link to.

If you don't like the idea of embedding a few choice URLs from the wiki
into the main documentation in general, I don't know why. The manual is
great for some things, the wiki is great for others, and the best way to
use both for what they're good at is to start coupling them together at
appropriate points.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD