commitfest.postgresql.org

[Robert Haas]

Per Dave Page's request of this morning, my CommitFest management
application now has a real hostname (see subject line).  I have also
sent Dave an email with details of the install process and location of
files, per his request (let me know if there's somewhere else those
details should be posted).

Brendan Jurd has graciously migrated all of the data from the
CommitFest wiki page to the app by writing a script to parse the wiki
markup and inserting the resulting data directly into the database.
There are a few loose ends.  The application stamps comments with the
community login of the person who left them, but the import stamped
them with names instead.  This is actually of some significance, since
the app will allow you to edit your own comments but not those of
other people.  We could probably fix this if someone can give us
access to (or a dump of) the realname to username mappings from the
community login DB.  Also, we're currently missing the reviewer names
due to limitations of the import script; Brendan is fixing this.

Filling the DB with live data revealed a few warts.  In particular,
the original ordering of patches was alpha by topic and then alpha by
name, which I thought would be OK, but upon seeing how it really
looked, I hated it.  So the topic manager now lets you set a sort
order for commitfest topics, and the order is now numeric by topic
sortorder, then alpha by topic, then by ascending patch ID (so the
oldest patch comes up first within each topic section).  Also, I
originally had the topics displayed as a table column, but that didn't
really work for me once I saw it either, so it's been reorganized to
do it the same way the wiki does.

We're still hacking on a few other details of the formatting and
interface, but you might want to cruise over and have a look.  Please
however continue to make ALL CHANGES on the wiki, and not in the app.
Brendan is going to manually move changes over to the new system
incrementally until we get the kinks worked out.  I think we're close,
but we're not quite there yet.  As a reminder, if you'd like to review
or submit patches against the source, you can find it here:

http://git.postgresql.org/gitweb?p=pgcommitfest.git;a=summary
git://git.postgresql.org/git/pgcommitfest.git

...Robert

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

[Brendan Jurd]

2009/7/3 Robert Haas <robertmhaas@...>:
> Also, we're currently missing the reviewer names
> due to limitations of the import script; Brendan is fixing this.

Update: The reviewer names have now been populated.

Cheers,
BJ

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

[Jaime Casanova-2]

On Fri, Jul 3, 2009 at 12:34 AM, Brendan Jurd<direvus@...> wrote:
> 2009/7/3 Robert Haas <robertmhaas@...>:
>> Also, we're currently missing the reviewer names
>> due to limitations of the import script; Brendan is fixing this.
>
> Update: The reviewer names have now been populated.
>

looks good... now, how can i mark a patch as being reviewed? or i have
to told you in order to you mark it?

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. [phone]

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

[Brendan Jurd]

2009/7/3 Jaime Casanova <jcasanov@...>:

> On Fri, Jul 3, 2009 at 12:34 AM, Brendan Jurd<direvus@...> wrote:
>> 2009/7/3 Robert Haas <robertmhaas@...>:
>>> Also, we're currently missing the reviewer names
>>> due to limitations of the import script; Brendan is fixing this.
>>
>> Update: The reviewer names have now been populated.
>>
>
> looks good... now, how can i mark a patch as being reviewed? or i have
> to told you in order to you mark it?

Until we have a solid consensus to switch to using the new app, please
continue to make your changes on the wiki.  I'll replicate the changes
by hand as we go until switchover.

If you'd like to make your changes on the app yourself and save me the
trouble, please do!  Just select the patch you're interested in, click
"edit patch" on the upper right and change the status and/or reviewer
fields as required.

Please let us know if you encounter any problems with withe app, or
have suggestions for improvement.

Cheers,
BJ

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

[Tom Lane-2]

Brendan Jurd <direvus@...> writes:
> Please let us know if you encounter any problems with withe app, or
> have suggestions for improvement.

It looks like every patch and comment is timestamped ... but with
yesterday (the time of data import, I suppose).  This is much worse
than useless.  If you can't get the actual date, leave it off.

                        regards, tom lane

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

[Tom Lane-2]

On "suggestions for improvement": I need to be able to bookmark the
commitfest summary list (whichever page is equivalent to the old wiki
page).  The current URL seems to be
http://commitfest.postgresql.org/action/commitfest_view?id=2
which is both opaque as can be and not looking like it's intended to
be stable over the long term.  I can also imagine people wanting to
refer to particular patch entries in email, but those URLs are no
better.  Could we pay some attention to using URLs that are stable
and self-explanatory?

                        regards, tom lane

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

[Tom Lane-2]

I tried the "New Patch Comment" feature.  It's absolutely horrid.
I get a page showing a "comment type" button, one line for Message-ID,
and one line for Content.  No explanation of what those are, and no
visibility any more of the patch I'm trying to comment on.  I have no
idea what I'm supposed to do here, and if I were trying to respond to
someone else's comment, it would be nice to be able to see that comment.

                        regards, tom lane

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

[Robert Haas]

On Fri, Jul 3, 2009 at 10:35 AM, Tom Lane<tgl@...> wrote:
> On "suggestions for improvement": I need to be able to bookmark the
> commitfest summary list (whichever page is equivalent to the old wiki
> page).  The current URL seems to be
> http://commitfest.postgresql.org/action/commitfest_view?id=2
> which is both opaque as can be and not looking like it's intended to
> be stable over the long term.  I can also imagine people wanting to
> refer to particular patch entries in email, but those URLs are no
> better.  Could we pay some attention to using URLs that are stable
> and self-explanatory?

I'm not sure why you would think that it's not stable.  It's not
stable in the sense that it won't always be the open CommitFest, but
it's certainly stable in the sense that it will always be the same
CommitFest that it is now.  It's actually MORE stable than the wiki,
since the wiki doesn't permit you to change the name of the CommitFest
without also changing the URL.

I'm also not sure what you would think that it's not self-explanatory,
since it looks pretty self explanatory to me.  You've asked to view a
commitfest.  The id of that commitfest is 2.  What more do you want to
know?

If you're advocating for the use of wiki-style names, where the URL
actually contains the name of the things that it points to, then you
have incompatible requirements, because things can, do, and will
continue to get renamed.  If the URL is built around the name, then
the URL will change when the name changes.  If you want it to be
stable, a non-natural key is your only option.  And I frankly don't
see what's wrong with that.  We regularly deal in message-IDs or other
links to the archives, which are certainly totally opaque.
Fortunately, they're links.  You can click on them, and then you see
what they are.

...Robert

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

[Robert Haas]

On Fri, Jul 3, 2009 at 10:40 AM, Tom Lane<tgl@...> wrote:
> I tried the "New Patch Comment" feature.  It's absolutely horrid.
> I get a page showing a "comment type" button, one line for Message-ID,
> and one line for Content.  No explanation of what those are, and no
> visibility any more of the patch I'm trying to comment on.  I have no
> idea what I'm supposed to do here, and if I were trying to respond to
> someone else's comment, it would be nice to be able to see that comment.

The message-ID is the (optional) ID of a message you'd like to link
to.  The comment is the text of your comment.  If there's a legitimate
reason for confusion here, I have no idea what it is.

I agree that the comment box probably needs to be converted into a
text area rather than a single line.  But I also think that comments
on the wiki should be kept short.  If you have more than a few lines
of text, there's a good chance you should be sending an email to
-hackers and then linking to it.  There are some projects that are
managed using a discussion forum or a bug tracker and as far as I know
you've always been opposed to that, as am I.  So complaining that this
system doesn't work that way seems disingenuous.  Also, if you think
this interface is inconvenient for leaving a comment, have you tried
doing it on the wiki lately?

Anyway, I'm sure there's room for improvement in this tool.  I intend
to make improvements.  I still think it's already better than the
wiki.  Moving things to a different commitfest or a different section
of the same commitfest (like, particularly relevant to you, the
"committed" section) is takes me minutes on the wiki and seconds with
this app.

...Robert

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

[Heikki Linnakangas-3]

Robert Haas wrote:

> On Fri, Jul 3, 2009 at 10:35 AM, Tom Lane<tgl@...> wrote:
>> On "suggestions for improvement": I need to be able to bookmark the
>> commitfest summary list (whichever page is equivalent to the old wiki
>> page).  The current URL seems to be
>> http://commitfest.postgresql.org/action/commitfest_view?id=2
>> which is both opaque as can be and not looking like it's intended to
>> be stable over the long term.  I can also imagine people wanting to
>> refer to particular patch entries in email, but those URLs are no
>> better.  Could we pay some attention to using URLs that are stable
>> and self-explanatory?
>
> I'm not sure why you would think that it's not stable.  It's not
> stable in the sense that it won't always be the open CommitFest, but
> it's certainly stable in the sense that it will always be the same
> CommitFest that it is now.  It's actually MORE stable than the wiki,
> since the wiki doesn't permit you to change the name of the CommitFest
> without also changing the URL.

We have redirects to the previous, open, and in-progress commitfests in
the wiki (see http://wiki.postgresql.org/wiki/CommitFest). Those
redirects are bookmarkable.

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

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

[Tom Lane-2]

Robert Haas <robertmhaas@...> writes:
> On Fri, Jul 3, 2009 at 10:35 AM, Tom Lane<tgl@...> wrote:
>> The current URL seems to be
>> http://commitfest.postgresql.org/action/commitfest_view?id=2
>> which is both opaque as can be and not looking like it's intended to
>> be stable over the long term.

> I'm not sure why you would think that it's not stable.

Because it's exposing three or four details of your implementation,
which you might wish to change later.

> I'm also not sure what you would think that it's not self-explanatory,
> since it looks pretty self explanatory to me.

It's impossible to know that this is commitfest 2009-07.

                        regards, tom lane

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

[Tom Lane-2]

Robert Haas <robertmhaas@...> writes:
> On Fri, Jul 3, 2009 at 10:40 AM, Tom Lane<tgl@...> wrote:
>> I tried the "New Patch Comment" feature.  It's absolutely horrid.
>> I get a page showing a "comment type" button, one line for Message-ID,
>> and one line for Content.  No explanation of what those are, and no
>> visibility any more of the patch I'm trying to comment on.  I have no
>> idea what I'm supposed to do here, and if I were trying to respond to
>> someone else's comment, it would be nice to be able to see that comment.

> The message-ID is the (optional) ID of a message you'd like to link
> to.  The comment is the text of your comment.  If there's a legitimate
> reason for confusion here, I have no idea what it is.

It's not apparent that the message-ID is optional, nor what it is for
really.  And the fact that the boxes are the same size leaves one
wondering what the comment is supposed to be too.  The basic complaint
is that the page assumes you already know what to do with it.
Given the vast amount of white space left behind by the omission of
any context information, it doesn't seem unreasonable to include a
couple sentences of explanation.

> I agree that the comment box probably needs to be converted into a
> text area rather than a single line.  But I also think that comments
> on the wiki should be kept short.  If you have more than a few lines
> of text, there's a good chance you should be sending an email to
> -hackers and then linking to it.  There are some projects that are
> managed using a discussion forum or a bug tracker and as far as I know
> you've always been opposed to that, as am I.  So complaining that this
> system doesn't work that way seems disingenuous.  Also, if you think
> this interface is inconvenient for leaving a comment, have you tried
> doing it on the wiki lately?

I spent a large part of the last year leaving comments on the wiki.
Yeah, it was a bit tedious to use wiki markup, but at least all the
information you needed was a click away.  (The wiki wasn't designed
on the assumption that users already know how to use it.)  And the
context didn't all disappear from view the moment you wanted to add
something.

> I still think it's already better than the wiki.

Maybe to you, but right now I think the wiki is far more usable
and far more flexible.  It hasn't got arbitrary assumptions about
what size comment people are allowed to leave, for example.

                        regards, tom lane

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

[Robert Haas]

On Fri, Jul 3, 2009 at 11:46 AM, Heikki
Linnakangas<heikki.linnakangas@...> wrote:

> Robert Haas wrote:
>> On Fri, Jul 3, 2009 at 10:35 AM, Tom Lane<tgl@...> wrote:
>>> On "suggestions for improvement": I need to be able to bookmark the
>>> commitfest summary list (whichever page is equivalent to the old wiki
>>> page).  The current URL seems to be
>>> http://commitfest.postgresql.org/action/commitfest_view?id=2
>>> which is both opaque as can be and not looking like it's intended to
>>> be stable over the long term.  I can also imagine people wanting to
>>> refer to particular patch entries in email, but those URLs are no
>>> better.  Could we pay some attention to using URLs that are stable
>>> and self-explanatory?
>>
>> I'm not sure why you would think that it's not stable.  It's not
>> stable in the sense that it won't always be the open CommitFest, but
>> it's certainly stable in the sense that it will always be the same
>> CommitFest that it is now.  It's actually MORE stable than the wiki,
>> since the wiki doesn't permit you to change the name of the CommitFest
>> without also changing the URL.
>
> We have redirects to the previous, open, and in-progress commitfests in
> the wiki (see http://wiki.postgresql.org/wiki/CommitFest). Those
> redirects are bookmarkable.

We can do the same thing here.  It's a SMOP.

...Robert

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

[Robert Treat]

On Friday 03 July 2009 11:50:29 Tom Lane wrote:

> Robert Haas <robertmhaas@...> writes:
> > On Fri, Jul 3, 2009 at 10:35 AM, Tom Lane<tgl@...> wrote:
> >> The current URL seems to be
> >> http://commitfest.postgresql.org/action/commitfest_view?id=2
> >> which is both opaque as can be and not looking like it's intended to
> >> be stable over the long term.
> >
> > I'm not sure why you would think that it's not stable.
>
> Because it's exposing three or four details of your implementation,
> which you might wish to change later.
>
> > I'm also not sure what you would think that it's not self-explanatory,
> > since it looks pretty self explanatory to me.
>
> It's impossible to know that this is commitfest 2009-07.
>

commitfest.postgresql.org/2009/07 ?

That, or any similar scheme, seems easily doable with a little apache rewrite
magic and some programming. See my blog urls for one such example.

--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com

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

[Joshua D. Drake]

On Fri, 2009-07-03 at 14:06 -0400, Robert Treat wrote:

> On Friday 03 July 2009 11:50:29 Tom Lane wrote:
> > Robert Haas <robertmhaas@...> writes:
> > > On Fri, Jul 3, 2009 at 10:35 AM, Tom Lane<tgl@...> wrote:
> > >> The current URL seems to be
> > >> http://commitfest.postgresql.org/action/commitfest_view?id=2
> > >> which is both opaque as can be and not looking like it's intended to
> > >> be stable over the long term.
> > >
> > > I'm not sure why you would think that it's not stable.
> >
> > Because it's exposing three or four details of your implementation,
> > which you might wish to change later.
> >
> > > I'm also not sure what you would think that it's not self-explanatory,
> > > since it looks pretty self explanatory to me.
> >
> > It's impossible to know that this is commitfest 2009-07.
> >
>
> commitfest.postgresql.org/2009/07 ?
>
> That, or any similar scheme, seems easily doable with a little apache rewrite
> magic and some programming. See my blog urls for one such example.

O.k. I am probably blowing something out of the water here but do we
need yet another domain?

wiki.postgresql.org/commitfest/2009/07 (or www)

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@...
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


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

[Robert Haas]

On Fri, Jul 3, 2009 at 11:50 AM, Tom Lane<tgl@...> wrote:

> Robert Haas <robertmhaas@...> writes:
>> On Fri, Jul 3, 2009 at 10:35 AM, Tom Lane<tgl@...> wrote:
>>> The current URL seems to be
>>> http://commitfest.postgresql.org/action/commitfest_view?id=2
>>> which is both opaque as can be and not looking like it's intended to
>>> be stable over the long term.
>
>> I'm not sure why you would think that it's not stable.
>
> Because it's exposing three or four details of your implementation,
> which you might wish to change later.
>
>> I'm also not sure what you would think that it's not self-explanatory,
>> since it looks pretty self explanatory to me.
>
> It's impossible to know that this is commitfest 2009-07.

Backing up for a moment to ten thousand feet here, I posted a link to
this web app on May 26th.  I received several comments on it, all of
them positive, including some constructive feedback from you which I
took to heart.  It is now July 1st, and I am trying very hard to get
ready for the next CommitFest, which I have agreed to manage.  So I
need to determine whether there is some finite number of changes of
manageable size that I can make to get this to a state where we can
use it, or whether I should give up hope now and go back to the wiki.
The latter outcome would be disappointing to me, but that's where
we're going to end up if we can't actually boil this down to a
specific list of changes to be made.

I accept the need for and am willing to make the following changes:

- Changing the patch comment field from type text to type textarea and
integrating it into the patch view page to provide context.
- Adding a note to the effect that the message ID is optional.
- Adding stable links with mnemonic names for the open, in progress,
and most recently closed commitfests.

With respect to the issue of the page URLs, I'm very unconvinced of
the value of making a change.  First of all, one of your arguments is
that I might want to change them later.  I can promise you that I
won't want to do any such thing, or at the VERY least that the old
URLs will always be supported.  There would be a sort of perverse
irony to me changing the application to use a different kind of key
for the reason that Tom Lane is afraid that some day I might want to
use a different kind of key.

Secondly, if we are going to make a change, it would be nice to know
what the use case is for the change and to have a set of requirements
that are not mutually contradictory.  It is not possible to both
assign the URLs to the pages based on the names of the objects to
which the refer (which are changeable) and to guarantee that the URLs
will never change.  So you can either have URL stability or you can
have wiki-style names, but you can't have both, unless perhaps you
include both the ID and the name in the link but make the name just
decoration.  I am frankly at a loss to why this is a big deal: if you
bookmark the page, your browser will record the page title; if you use
firefox, you can also find by page title in the address bar.  And
we've never had pages for individual patches before anyway, so why
should it now be critical how those links are formatted?  But if it is
critical then please describe exactly how you think it should work.

...Robert

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

[Robert Haas]

On Fri, Jul 3, 2009 at 2:10 PM, Joshua D. Drake<jd@...> wrote:
> O.k. I am probably blowing something out of the water here but do we
> need yet another domain?

Because it's installed on a different VM and I don't want to move it
just to make the URL look different?

...Robert

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

[slakr]

Robert Treat wrote:

> On Friday 03 July 2009 11:50:29 Tom Lane wrote:
>> Robert Haas <robertmhaas@...> writes:
>>> On Fri, Jul 3, 2009 at 10:35 AM, Tom Lane<tgl@...> wrote:
>>>> The current URL seems to be
>>>> http://commitfest.postgresql.org/action/commitfest_view?id=2
>>>> which is both opaque as can be and not looking like it's intended to
>>>> be stable over the long term.
>>> I'm not sure why you would think that it's not stable.
>> Because it's exposing three or four details of your implementation,
>> which you might wish to change later.
>>
>>> I'm also not sure what you would think that it's not self-explanatory,
>>> since it looks pretty self explanatory to me.
>> It's impossible to know that this is commitfest 2009-07.
>>
>
> commitfest.postgresql.org/2009/07 ?
>
> That, or any similar scheme, seems easily doable with a little apache rewrite
> magic and some programming. See my blog urls for one such example.
>

I believe Tom wants details removed from the URL, so future
implementation changes don't either a) break bookmarks because more
stuff is needed in the URL or b) don't break bookmarks but be limited to
existing sutff in the URL (ie. hacky work arounds).  If that's the case,
your best best is to use some kind of key, like 16 random bytes
displayed in hex, that looks up the data.

IMHO, I don't see much gain to encoding the date into the url either.
This is not a great way of telling the user when something occurred.  A
lookup is going to occur either way, so why not get all data at once
using a single method?

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

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

[Robert Haas]

On Fri, Jul 3, 2009 at 3:00 PM, Andrew Chernow<ac@...> wrote:

>>>>> The current URL seems to be
>>>>> http://commitfest.postgresql.org/action/commitfest_view?id=2
>>>>> which is both opaque as can be and not looking like it's intended to
>>>>> be stable over the long term.
>>>>
>>>> I'm not sure why you would think that it's not stable.
>>>
>>> Because it's exposing three or four details of your implementation,
>>> which you might wish to change later.
>>>
>>>> I'm also not sure what you would think that it's not self-explanatory,
>>>> since it looks pretty self explanatory to me.
>>>
>>> It's impossible to know that this is commitfest 2009-07.
>>>
>>
>> commitfest.postgresql.org/2009/07 ?
>>
>> That, or any similar scheme, seems easily doable with a little apache
>> rewrite magic and some programming. See my blog urls for one such example.
>
> I believe Tom wants details removed from the URL, so future implementation
> changes don't either a) break bookmarks because more stuff is needed in the
> URL or b) don't break bookmarks but be limited to existing sutff in the URL
> (ie. hacky work arounds).  If that's the case, your best best is to use some
> kind of key, like 16 random bytes displayed in hex, that looks up the data.

I *am* using some kind of key.  Specifically, in integer derived from
a serial column.  It's just as stable as 16 random bytes displayed in
hex, but a lot shorter and easier to remember, if you're the sort of
person who likes to remember URLs.  :-)

> IMHO, I don't see much gain to encoding the date into the url either. This
> is not a great way of telling the user when something occurred.  A lookup is
> going to occur either way, so why not get all data at once using a single
> method?

Sorry, I'm not following this part.

...Robet

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

[Dimitri Fontaine-3]

Hi,

Le 3 juil. 09 à 20:44, Robert Haas a écrit :
> - Adding stable links with mnemonic names for the open, in progress,
> and most recently closed commitfests.

May I suggest something looking about like:
   http://commitfest.postgresql.org/current
   http://commitfest.postgresql.org/open
   http://commitfest.postgresql.org/in-progress
   http://commitfest.postgresql.org/previous

> With respect to the issue of the page URLs, I'm very unconvinced of
> the value of making a change.

Your software seems to be better than a wiki, but its potential users  
are expressing needs and bikescheding. I think you'd better accept  
both kind of changes as long as it's not making your life much harder  
than you'd want. Frankly, what URL looks better:
   http://commitfest.postgresql.org/action/commitfest_view?id=2
   http://commitfest.postgresql.org/2009/07

Oh, and while at it, I don't foresee that we would want the commitfest  
of july 2009 to change its name but not the "semantic" URL pointing to  
its management. Or if it's ever wanted, as has been said, have a look  
at Apache Rewrite Rules system, it's made for supporting content being  
moved. Something in the spirit of:
   RedirectPermanent /2009/07 /2009/08

While at it, I imagine that within a given commit fest, a single patch  
will have a stable shortname, or if it comes to change, we could  
accept that the URL too change:
   http://commitfest.postgresql.org/action/patch_view?id=71
   http://commitfest.postgresql.org/2009/07/Synch_Rep
   http://commitfest.postgresql.org/current/Synch_Rep

Now, rather than following the names with apache setup, maybe you  
could add something like some history tables tracking short name  
changes (maybe some ON UPDATE trigger would do), so that referring to  
an older name would send a HTTP 302 redirect to the new name URL?

I'd like your work to be useful for all of us and appreciated to its  
real value, and those changes well seem like user interface  
improvements rather than basic structure or behavior questioning.

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