Skip site navigation (1) Skip section navigation (2)

Re: TODO <-> Commitfest

From: "Brendan Jurd" <direvus(at)gmail(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "David Fetter" <david(at)fetter(dot)org>, "PG Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TODO <-> Commitfest
Date: 2008-08-27 14:54:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Aug 27, 2008 at 11:05 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> David Fetter wrote:
>> For example, Common Table Expressions is both on the TODO list and on
>> September's Commitfest.  They should probably point to each other so
>> long as such a relationship exists.
> (Actually what this says is that we need a single link: from the
> Commitfest to Todo.  Linking the other way around is probably not as
> useful.)

Well, you can't "link" to an individual item on the Todo list anyway.
You can link to sections in the Todo list (for example, [[Todo#MONEY
data type]] would work) but individual items don't have any kind of
anchor that you can link to.

You could add a note to the item on the CommitFest that says "This
patch addresses Todo item 'add foo support to bar'", with a link to
the relevant Todo section.  This would serve as a reminder to update
the Todo when the patch is committed.  You'd still have to search for
the right item on the Todo page, but I suppose it's better than

So, to take a live example, the Windowing Functions item on the
September CommitFest might end up looking something like this:

Windowing Functions
    This patch addresses Todo item "Implement SQL:2008 window functions"
    David Fetter says: Git repository is here.

It does seem like a lot of effort for a minor benefit though.  And, as
Alvaro mentions, it increases the administrative burden on committers.

On the other hand we could just put the onus for this on the patch
submitters themselves.  That is, make a policy "If you submit a patch
which resolves a Todo item, please mark the Todo item as done if/when
that patch is committed."  Maybe they forget to do it, but it's
probably still a step up from our current strategy.


In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2008-08-27 15:05:38
Subject: Re: Is it really such a good thing for newNode() to be a macro?
Previous:From: Tom LaneDate: 2008-08-27 14:41:05
Subject: Re: Is it really such a good thing for newNode() to be a macro?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group