Re: cutting down the TODO list thread

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: cutting down the TODO list thread
Date: 2023-01-11 07:09:56
Message-ID: CAFBsxsH01QYcKnik+7U8CFJ4Mpmn7c__n+=b2Vrn_S9y1v0Qog@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

So, I had intended to spend some time on this at least three times a year.
I've clearly failed at that, but now is as good a time as any to pick it
back up again.

Over in [1], Tom opined:

> John Naylor <john(dot)naylor(at)enterprisedb(dot)com> writes:
>
> > "WARNING for Developers: Unfortunately this list does not contain all
the
> > information necessary for someone to start coding a feature. Some of
these
> > items might have become unnecessary since they were added --- others
might
> > be desirable but the implementation might be unclear. When selecting
items
> > listed below, be prepared to first discuss the value of the feature. Do
not
> > assume that you can select one, code it and then expect it to be
committed.
> > "
>
> I think we could make that even stronger: there's basically nothing on
> the TODO list that isn't problematic in some way. Otherwise it would
> have been done already. The entries involve large amounts of work,
> or things that are subtler than they might appear, or cases where the
> desirable semantics aren't clear, or tradeoffs that there's not
> consensus about, or combinations of those.
>
> IME it's typically a lot more productive to approach things via
> "scratch your own itch". If a problem is biting you directly, then
> at least you have some clear idea of what it is that needs to be fixed.
> You might have to work up to an understanding of how to fix it, but
> you have a clear goal.

I've come up with some revised language, including s/15/16/ and removing
the category of "[E]" (easier to implement), since it wouldn't be here if
it were actually easy:

--
WARNING for Developers: This list contains some known PostgreSQL bugs, some
feature requests, and some things we are not even sure we want. This is not
meant to be a resource for beginning developers to get ideas for things to
work on. <WIP: maybe direct them to commitfest?>

All of these items are hard, and some are perhaps impossible. Some of these
items might have become unnecessary since they were added. Others might be
desirable but:

- a large amount work is required
- the problems are subtler than they might appear
- the desirable semantics aren't clear
- there are tradeoffs that there's not consensus about
- some combinations of the above

If you really need a feature that is listed below, it will be worth reading
the linked email thread if there is one, since it will often show the
difficulties, or perhaps contain previous failed attempts to get a patch
committed. If after that you still want to work on it, be prepared to first
discuss the value of the feature. Do not assume that you can start coding
and expect it to be committed. Always discuss design on the Hackers list
before starting to code.

Over time, it may become clear that a TODO item has become outdated or
otherwise determined to be either too controversial or not worth the
development effort. Such items should be retired to the Not Worth Doing
page.

[D] marks changes that are done, and will appear in the PostgreSQL 16
release.
--

We could also revise the developer FAQ:
- remove phrase "Outstanding features are detailed in Todo."
- add suggestion to to check the Todo or Not_worth_doing pages to see if
the desired feature is undesirable or problematic
- rephrase "Working in isolation is not advisable because others might be
working on the same TODO item, or you might have misunderstood the TODO
item." so it doesn't mention 'TODO' at all.

[1] https://www.postgresql.org/message-id/415636.1673411259%40sss.pgh.pa.us

--
John Naylor
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2023-01-11 07:18:21 Re: SQL/JSON revisited
Previous Message Elena Indrupskaya 2023-01-11 07:02:02 Re: SQL/JSON revisited