Re: cutting down the TODO list thread - Mailing list pgsql-hackers
| From | John Naylor |
|---|---|
| Subject | Re: cutting down the TODO list thread |
| Date | |
| Msg-id | CAFBsxsHxjJpzsUgXPCFTfGSoDXFQXoETG8LGK=_tg1etvvgFeA@mail.gmail.com Whole thread Raw |
| In response to | Re: cutting down the TODO list thread (Bruce Momjian <bruce@momjian.us>) |
| Responses |
Re: cutting down the TODO list thread
|
| List | pgsql-hackers |
On Tue, Jan 24, 2023 at 11:57 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Tue, Jan 24, 2023 at 10:46:34AM +0700, John Naylor wrote:
> >
> > https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F#TODOs
> > 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.
>
> I think we just point them at the TODO list and they will read the top
> of the list first, no? I think you are right that we updated the top of
> the TODO but didn't update the places that link to it. I am thinking we
> should just trim down the text linking to it and let the top of the TODO
> list do its job.
Okay. How about:
"It's worth checking if the feature of interest is found in the TODO list on our wiki: http://wiki.postgresql.org/wiki/TODO. The entries there often have additional information about the feature and may point to reasons why it hasn't been implemented yet."
> > --
> > 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.
>
> Wow, I would not send a new person to the SQL standard docs. ;-) I am
> thinking we just don't have a good answer to this so let's say less.
Do I understand right that we could just remove this entire section "What areas need work?"?
> > 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
>
> Can new people identify trivial?
I'd say they have some idea about that, since we do regularly get typo fixes and doc clarifications. Sure there is some grey area, but I don't think the dividing point is important. The important thing is, we also sometimes get large and invasive patches without design discussion, which we want to discourage.
> I can now see that just removing the [E] label totally is the right
> answer. Yes, there might be an easy item on there, but the fact we have
> three labeled and they are not easy makes me thing [E] is causing more
> problems than it solves.
Okay, having heard no objections I'll remove it.
--
John Naylor
EDB: http://www.enterprisedb.com
>
> On Tue, Jan 24, 2023 at 10:46:34AM +0700, John Naylor wrote:
> >
> > https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F#TODOs
> > 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.
>
> I think we just point them at the TODO list and they will read the top
> of the list first, no? I think you are right that we updated the top of
> the TODO but didn't update the places that link to it. I am thinking we
> should just trim down the text linking to it and let the top of the TODO
> list do its job.
Okay. How about:
"It's worth checking if the feature of interest is found in the TODO list on our wiki: http://wiki.postgresql.org/wiki/TODO. The entries there often have additional information about the feature and may point to reasons why it hasn't been implemented yet."
> > --
> > 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.
>
> Wow, I would not send a new person to the SQL standard docs. ;-) I am
> thinking we just don't have a good answer to this so let's say less.
Do I understand right that we could just remove this entire section "What areas need work?"?
> > 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
>
> Can new people identify trivial?
I'd say they have some idea about that, since we do regularly get typo fixes and doc clarifications. Sure there is some grey area, but I don't think the dividing point is important. The important thing is, we also sometimes get large and invasive patches without design discussion, which we want to discourage.
> I can now see that just removing the [E] label totally is the right
> answer. Yes, there might be an easy item on there, but the fact we have
> three labeled and they are not easy makes me thing [E] is causing more
> problems than it solves.
Okay, having heard no objections I'll remove it.
--
John Naylor
EDB: http://www.enterprisedb.com
pgsql-hackers by date: