Re: [HACKERS] commitfest.postgresql.org

On Fri, Jul 3, 2009 at 3:08 PM, Dimitri Fontaine<dfontaine(at)hi-media(dot)com> wrote:
> 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

We've definitely gotten to the "harder than I'd want" point at this point.

> 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

I humbly submit that it's insane to thing about editing httpd.conf
every time somebody renames an object. The point here is to *reduce*
the administrative burden of maintaining this thing.

> 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?

So, the good thing about the current system is that the URL *doesn't*
change and you *don't* need complicated bookkeeping to remember every
URL you've ever assigned to the thing to get it. I am well aware that
it's possible to design a system that does this, but what benefit do
we get out of it? Making it possible to tell what a URL points to
without clicking on it, for those occasions when you're stranded on a
desert island with a URL and no Internet access?

There's a subtle and pernicious danger of the system you're proposing,
too. If we regularly change the URLs that refer to certain objects,
but compensate for that by remembering the whole history of URLs that
have ever referred to that object, then there will multiple URLs that
refer to the same object, of which all but one will contain WRONG
information about what that link points to. The
http://commitfest.postgresql.org/2009/07/Sync_Rep link, for example,
might imply to someone that the patch is in the 2009-07 commitfest,
but in fact it may well have been moved to the 2009-11, 2010-01, or
2010-03 commitfest, or we might have finally come to our senses and
realized that it ought to be called "streaming rep" and rename it.

It's true that the current URLs, without some sort of accompanying
text, do not tell you what they point to. But no information can
often be better than disinformation.

> 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.

I'd like that, too.

...Robert