Thread: 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@dunslane.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@dunslane.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@momjian.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@momjian.us> wrote: > Joshua D. Drake wrote: > > On Wed, 16 Apr 2008 13:59:50 -0400 > > Andrew Dunstan <andrew@dunslane.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@momjian.us> wrote: > > > Joshua D. Drake wrote: > > > On Wed, 16 Apr 2008 13:59:50 -0400 > > > Andrew Dunstan <andrew@dunslane.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@momjian.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@momjian.us> wrote: >> >> >>> Joshua D. Drake wrote: >>> >>>> On Wed, 16 Apr 2008 13:59:50 -0400 >>>> Andrew Dunstan <andrew@dunslane.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@momjian.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@momjian.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@momjian.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@momjian.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@dunslane.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@momjian.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@momjian.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 Momjianwrote: > 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@gmail.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@momjian.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@momjian.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@gmail.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@gregsmith.com http://www.gregsmith.com Baltimore, MD
"Heikki Linnakangas" <heikki@enterprisedb.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@gregsmith.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@gregsmith.com http://www.gregsmith.com Baltimore, MD