Re: TODO <-> Commitfest - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: TODO <-> Commitfest
Date
Msg-id 37ed240d0808270754k45d99205i14698037cf78153d@mail.gmail.com
Whole thread Raw
In response to Re: TODO <-> Commitfest  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: TODO <-> Commitfest  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Aug 27, 2008 at 11:05 PM, Alvaro Herrera
<alvherre@commandprompt.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
nothing.

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

Cheers,
BJ


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Is it really such a good thing for newNode() to be a macro?
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: Is it really such a good thing for newNode() to be a macro?