Re: cutting down the TODO list thread

On Wed, Jan 18, 2023 at 3:13 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> I think we risk overloading people with too many words above, and they
> will not read it fully. Can it be simplified? I wonder if some of this
> belows in the developer's FAQ and linked to that from the TODO list.

I think you're right. That further drives home what I mentioned a few days
ago: Maybe we don't need to change much in the actual list itself, but
rephrase references to it from elsewhere. Here's a first draft to see what
that would look like:
--
https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F#TODOs

from:
"PostgreSQL maintains a TODO list on our wiki:
http://wiki.postgresql.org/wiki/TODO

We have attempted to organize issues and link in relevant discussions from
our mailing list archives. Please read background information if it is
available before attempting to resolve a TODO. If no background information
is available, it is appropriate to post a question to
pgsql-hackers(at)postgresql(dot)org and request additional information and inquire
about the status of any ongoing work on the problem."

to:
"It's worth checking if the feature of interest is found in the TODO list
on our wiki: http://wiki.postgresql.org/wiki/TODO. That list contains some
known PostgreSQL bugs, some feature requests, and some things we are not
even sure we want. Many entries have a link to an email thread containing
prior discussion, or perhaps attempts that for whatever reason didn't make
it as far as getting committed."

...which might make more sense if moved below the "brand new features"
section.

--
https://wiki.postgresql.org/wiki/Developer_FAQ

1)
from:
"What areas need work?
Outstanding features are detailed in Todo.

You can learn more about these features by consulting the archives, the SQL
standards and the recommended texts (see books for developers)."

to:
??? -> For "what areas need work?", we need to have a different answer, but
I'm not sure what it is.

2)
from:
"What do I do after choosing an item to work on?

Send an email to pgsql-hackers with a proposal for what you want to do
(assuming your contribution is not trivial). Working in isolation is not
advisable because others might be working on the same TODO item, or you
might have misunderstood the TODO item. In the email, discuss both the
internal implementation method you plan to use, and any user-visible
changes (new syntax, etc)."

to:
"What do I do after choosing an area to work on?

Send an email to pgsql-hackers with a proposal for what you want to do
(assuming your contribution is not trivial). Working in isolation is not
advisable because experience has shown that there are often requirements
that are not obvious, and if those are not agreed on beforehand it leads to
wasted effort. In the email, discuss both the internal implementation
method you plan to use, and any user-visible changes (new syntax, etc)."

> On Wed, Jan 11, 2023 at 02:09:56PM +0700, John Naylor wrote:
> > 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:
>
> I think it is still possible for a simple item to be identified as
> wanted and easy, but not completed and put on the TODO list.

Theoretically it's possible, but in practice no one puts any easy items
here. Currently, there are three marked as easy:

pg_dump:
- Dump security labels and comments on databases in a way that allows to
load a dump into a differently named database
- Add full object name to the tag field. eg. for operators we need
'=(integer, integer)', instead of just '='.

Dump and restore is critical to get right, and the code base is pretty
large and hairy, so I don't actually believe for a second that these items
are easy.

ECPG:
- sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified

In one sentence there are four uses of jargon that only someone with
experience would understand. I have hacked around ECPG multiple times and
have no idea what this means.

The last two also don't have any motivation spelled out, much less an email
thread.

So my inclination is, the [E] marker here is unjustified.

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