Where to point CommitFestOpen?

Tom,

Thoughts, better ideas?

Nope, that's why I ignored CommitFestOpen. I couldn't figure out where
to point it.

Note that I'm going to propose replacing the wiki with real software
come 8.5. The wiki method confuses new reviewers, and makes me spend
about 500% as much time managing the CF as it would take with actual
sofware. Spec to come.

--Josh

On Mon, Nov 3, 2008 at 2:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The problem I'm having with this is that the current scheme for naming
commitfest pages assumes you know the date for each one. It seems way
premature to bet on when the first 8.5 fest will start.

Wikimedia does seem to support renaming pages, so it seems like what
we should do is adopt a vague name for the page for the moment and
rename it whenever the 8.5 schedule becomes clearer. I'm tempted
to use CommitFest_2009-First as a temporary name.

That approach should be fine, although the naming scheme uses a space,
not an underscore:

CommitFest 2009-First

Note that if you rename a page you also need to update any redirects
which point to it.

Cheers,
BJ

Josh Berkus <josh@agliodbs.com> writes:

Note that I'm going to propose replacing the wiki with real software
come 8.5.

Where is this "real software" going to come from? I can't imagine that
software with more functionality than the wiki is going to spring into
existence without a huge investment of time.

I also note that the problem I'm griping about is hardly the fault of
the wiki software --- it's that we set up a naming convention without
sufficient foresight about future conditions. The only thing that
bespoke software might have done differently for us is impose some
perhaps-significantly-higher cost to change the convention.

So even if the software were going to appear for free, I think we have
evidence in hand right here that we don't know enough to write a spec
for it yet. Maybe by 8.6 when we've been through a *full* release cycle
with the commitfest idea, we could spec it right.

regards, tom lane

"Brendan Jurd" <direvus@gmail.com> writes:

Note that if you rename a page you also need to update any redirects
which point to it.

The directions on the "move" tab imply that this is taken care of
automatically? But anyway it'll just be a minor amount of extra
work when the time comes.

regards, tom lane

On Sun, 2 Nov 2008, Tom Lane wrote:

"Brendan Jurd" <direvus@gmail.com> writes:

Note that if you rename a page you also need to update any redirects
which point to it.

The directions on the "move" tab imply that this is taken care of
automatically?

What you get when you move something is redirect page that translates the
old name into the new one. But if you were already targeting that page
with a redirect, it would take a double redirect to find the new location,
and that doesn't work. See
http://en.wikipedia.org/wiki/Wikipedia:Double_redirects for more details.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

Greg Smith <gsmith@gregsmith.com> writes:

On Sun, 2 Nov 2008, Tom Lane wrote:

The directions on the "move" tab imply that this is taken care of
automatically?

What you get when you move something is redirect page that translates the
old name into the new one. But if you were already targeting that page
with a redirect, it would take a double redirect to find the new location,
and that doesn't work. See
http://en.wikipedia.org/wiki/Wikipedia:Double_redirects for more details.

Somehow, "prevent infinite loops" doesn't seem like justification for
"refuse to deal with a situation that the software creates automatically".
They ought to be willing to burrow more than one level ... see any Unix
kernel's treatment of symlinks for behavior that has actually stood the
test of usability over time.

regards, tom lane

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

Tom Lane wrote:

Somehow, "prevent infinite loops" doesn't seem like justification for
"refuse to deal with a situation that the software creates automatically".
They ought to be willing to burrow more than one level ... see any Unix
kernel's treatment of symlinks for behavior that has actually stood the
test of usability over time.

Having faced similar problems in another wiki some month ago, I wrote the
attached script to automate some tasks in a wiki. Maybe it will be of use.

Unfortunately I wrote it for a german wiki, some of the special pages
are named differently. Hence to use it in the Postgres-Wiki, something needs
to be done probably. (Not much though).

In particular it includes a function to "execute" a redirect in all pages
referencing a redirect page, i.e. change the links within all incoming pages.

Regards,
Jens-W. Schicke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkOxRYACgkQzhchXT4RR5CJQQCghUUCLO+e0QtZOTD7sALCPv0p
masAn1FfB786qM9QIbQXlOokK+4R7x7I
=HWF8
-----END PGP SIGNATURE-----