Creation of wiki page for open items of v11
Hi all,
I begin seeing bugs related to new features of v11 popping up around,
like this one for procedures:
/messages/by-id/CAFj8pRDxOwPPzpA8i+AQeDQFj7bhVw-dR2==rfWZ3zMGkm568Q@mail.gmail.com
Are there any objections in creating a wiki page to track all those bugs
and issues? We don't want to lose track of all that.
Thanks,
--
Michael
On Fri, Feb 9, 2018 at 9:14 AM, Michael Paquier <michael@paquier.xyz> wrote:
Hi all,
I begin seeing bugs related to new features of v11 popping up around,
like this one for procedures:
/messages/by-id/CAFj8pRDxOwPPzpA8i+AQeDQFj7bhVw-dR2==rfWZ3zMGkm568Q@mail.gmail.comAre there any objections in creating a wiki page to track all those bugs
and issues? We don't want to lose track of all that.
+1.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Fri, Feb 09, 2018 at 11:37:52AM +0530, Ashutosh Bapat wrote:
On Fri, Feb 9, 2018 at 9:14 AM, Michael Paquier <michael@paquier.xyz> wrote:
Are there any objections in creating a wiki page to track all those bugs
and issues? We don't want to lose track of all that.+1.
Okay, I have created a skeleton of page here:
https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items
Feel free to add any bugs or issues related to v11 that need to be
tracked before the release.
--
Michael
On 2/18/18 22:42, Michael Paquier wrote:
Okay, I have created a skeleton of page here:
https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items
Feel free to add any bugs or issues related to v11 that need to be
tracked before the release.
Do people find it useful to move the resolved items to a separate
section on the page, instead of just removing them? I'm not sure that
the resolved sections are useful, compared to just using the git log.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Apr 11, 2018 at 6:53 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
On 2/18/18 22:42, Michael Paquier wrote:
Okay, I have created a skeleton of page here:
https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items
Feel free to add any bugs or issues related to v11 that need to be
tracked before the release.Do people find it useful to move the resolved items to a separate
section on the page, instead of just removing them? I'm not sure that
the resolved sections are useful, compared to just using the git log.
If we have a section for resolved items, we can keep track of all
items. If we just delete the resolved items, we wouldn't know if it
was a mistake or it was intentional removal.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
On Wed, Apr 11, 2018 at 6:53 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:Do people find it useful to move the resolved items to a separate
section on the page, instead of just removing them? I'm not sure that
the resolved sections are useful, compared to just using the git log.
If we have a section for resolved items, we can keep track of all
items. If we just delete the resolved items, we wouldn't know if it
was a mistake or it was intentional removal.
It's not that much work to move the items rather than remove them,
so I'd vote for keeping up the practice. It has some value in terms
of tracking activity.
What *does* take time is adding a link to the commit, so I'd happily
drop that step. As Peter says, you can usually look in the commit
log if you care.
regards, tom lane
On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
On Wed, Apr 11, 2018 at 6:53 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:Do people find it useful to move the resolved items to a separate
section on the page, instead of just removing them? I'm not sure that
the resolved sections are useful, compared to just using the git log.If we have a section for resolved items, we can keep track of all
items. If we just delete the resolved items, we wouldn't know if it
was a mistake or it was intentional removal.It's not that much work to move the items rather than remove them,
so I'd vote for keeping up the practice. It has some value in terms
of tracking activity.What *does* take time is adding a link to the commit, so I'd happily
drop that step. As Peter says, you can usually look in the commit
log if you care.
The trouble is that sometimes it's not very obvious which commit log
entry relates to which open item.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
What *does* take time is adding a link to the commit, so I'd happily
drop that step. As Peter says, you can usually look in the commit
log if you care.
The trouble is that sometimes it's not very obvious which commit log
entry relates to which open item.
Sure, but is annotating the wiki page that way worth the trouble?
If the alternative is that committers refuse to update the wiki page
at all, or decide to remove entries rather than move-and-add-a-link,
we're not coming out ahead.
I'm not particularly wedded to the above idea; I'm just proposing it
as a compromise solution.
regards, tom lane
On Apr 11, 2018, at 11:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
What *does* take time is adding a link to the commit, so I'd happily
drop that step. As Peter says, you can usually look in the commit
log if you care.The trouble is that sometimes it's not very obvious which commit log
entry relates to which open item.Sure, but is annotating the wiki page that way worth the trouble?
If the alternative is that committers refuse to update the wiki page
at all, or decide to remove entries rather than move-and-add-a-link,
we're not coming out ahead.I'm not particularly wedded to the above idea; I'm just proposing it
as a compromise solution.
During some RMT discussions I had proposed formatting the open items
into a table on the Wiki page with some useful info to help track the status
and surface the necessary info to track down the open item.
It has been on my TODO to have a draft of that. Perhaps it will help solve
this problem.
Jonathan
Jonathan S. Katz wrote:
During some RMT discussions I had proposed formatting the open items
into a table on the Wiki page with some useful info to help track the status
and surface the necessary info to track down the open item.
The other proposal was that we could have a simple web app to track open
items. After all, we now know what we need from it. A wiki page seems
more laborious. (The commitfest app also sprung from a wiki page.)
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
The other proposal was that we could have a simple web app to track open
items. After all, we now know what we need from it. A wiki page seems
more laborious. (The commitfest app also sprung from a wiki page.)
Growing a number of non-issue issue trackers...
On Wed, Apr 11, 2018 at 6:57 PM, Andres Freund <andres@anarazel.de> wrote:
On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
The other proposal was that we could have a simple web app to track open
items. After all, we now know what we need from it. A wiki page seems
more laborious. (The commitfest app also sprung from a wiki page.)Growing a number of non-issue issue trackers...
Indeed.
(And of course, if we want to go in *any* direction away from the wiki,
it's not going to happen in time for *this* release..)
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Andres Freund wrote:
On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
The other proposal was that we could have a simple web app to track open
items. After all, we now know what we need from it. A wiki page seems
more laborious. (The commitfest app also sprung from a wiki page.)Growing a number of non-issue issue trackers...
Yes, because the generic ones are confusing, hard to search, easy to
misuse, easy for things to get lost, easy for dupes to crop up --- easy
for things go wrong all over the place.
The dedicated apps have a very limited purpose and work the way we want,
avoiding all these problems: in essence, they are but a glorified
repository of categorized links to our mailing list archives.
We've had wiki pages for open items for 10 years now. It's gotten
boring and tiresome.
https://wiki.postgresql.org/wiki/Category:Open_Items
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Magnus Hagander wrote:
(And of course, if we want to go in *any* direction away from the wiki,
it's not going to happen in time for *this* release..)
Absolutely. But if we never start, it'll never get done.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 04/11/2018 10:06 AM, Alvaro Herrera wrote:
Andres Freund wrote:
On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
The other proposal was that we could have a simple web app to track open
items. After all, we now know what we need from it. A wiki page seems
more laborious. (The commitfest app also sprung from a wiki page.)Growing a number of non-issue issue trackers...
Yes, because the generic ones are confusing, hard to search, easy to
misuse, easy for things to get lost, easy for dupes to crop up --- easy
for things go wrong all over the place.
Just like now except at least with an issue tracker it is easy to move
items from one place to another, assign ownership and track what is
actually going on.
The dedicated apps have a very limited purpose and work the way we want,
avoiding all these problems: in essence, they are but a glorified
No, they work the way you want which in turn creates an ever higher
barrier of entry for new community members.
We've had wiki pages for open items for 10 years now. It's gotten
boring and tiresome.
https://wiki.postgresql.org/wiki/Category:Open_Items
At least with an issue tracker it would be easy to see and know what is
going on there.
jD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
*** A fault and talent of mine is to tell it exactly how it is. ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
***** Unless otherwise stated, opinions are my own. *****
On 4/11/18 10:53, Tom Lane wrote:
It's not that much work to move the items rather than remove them,
Well, toward the end of the cycle, when the list of closed items is
quite long, then it does become a bit of a burden to carefully cut and
paste the item in the little browser window without making hash of the
wiki page.
It's not a very large deal, but I doubt the result is very useful. The
current "resolved before 11beta1" section is pretty much useless.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 4/11/18 10:53, Tom Lane wrote:
It's not that much work to move the items rather than remove them,
Well, toward the end of the cycle, when the list of closed items is
quite long, then it does become a bit of a burden to carefully cut and
paste the item in the little browser window without making hash of the
wiki page.
It's not a very large deal, but I doubt the result is very useful. The
current "resolved before 11beta1" section is pretty much useless.
Hm. There's definitely an argument to be made that it's not worth
tracking resolved items till after beta1. Once betas exist, the list
becomes useful to beta testers who may not be tracking events as closely
as hackers do.
regards, tom lane
On Apr 11, 2018, at 4:58 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 4/11/18 10:53, Tom Lane wrote:
It's not that much work to move the items rather than remove them,
Well, toward the end of the cycle, when the list of closed items is
quite long, then it does become a bit of a burden to carefully cut and
paste the item in the little browser window without making hash of the
wiki page.It's not a very large deal, but I doubt the result is very useful. The
current "resolved before 11beta1" section is pretty much useless.
I’ve found it useful, as from there I know which issues have been
resolved without having to comb through emails / commit logs.
If the list appears to grow long, we can reorganize the page to bring
the most important elements (active items, most recently fixed, timelines)
up top.
Jonathan
On Thu, Apr 12, 2018 at 2:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 4/11/18 10:53, Tom Lane wrote:
It's not that much work to move the items rather than remove them,
Well, toward the end of the cycle, when the list of closed items is
quite long, then it does become a bit of a burden to carefully cut and
paste the item in the little browser window without making hash of the
wiki page.It's not a very large deal, but I doubt the result is very useful. The
current "resolved before 11beta1" section is pretty much useless.Hm. There's definitely an argument to be made that it's not worth
tracking resolved items till after beta1. Once betas exist, the list
becomes useful to beta testers who may not be tracking events as closely
as hackers do.
+1
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Apr 11, 2018 at 10:33 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Wed, Apr 11, 2018 at 6:57 PM, Andres Freund <andres@anarazel.de> wrote:
On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote:
The other proposal was that we could have a simple web app to track open
items. After all, we now know what we need from it. A wiki page seems
more laborious. (The commitfest app also sprung from a wiki page.)Growing a number of non-issue issue trackers...
Indeed.
(And of course, if we want to go in *any* direction away from the wiki, it's
not going to happen in time for *this* release..)
We use commitfest app for tracking the patches submitted. It has done
well. Can we re-purpose the same for tracking open items?
Usually there are threads associated with the open items, then there
are patches to solve those and owners responsible in resolving them.
We have all the infrastructure in the commitfest app to track those
things, may be we could just relabel things. I haven't seen the
commitfest app code (and don't plan to do that myself) so may be this
is just a wild idea..
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Thu, Apr 12, 2018 at 11:46:33AM +0530, Ashutosh Bapat wrote:
Usually there are threads associated with the open items, then there
are patches to solve those and owners responsible in resolving them.
We have all the infrastructure in the commitfest app to track those
things, may be we could just relabel things. I haven't seen the
commitfest app code (and don't plan to do that myself) so may be this
is just a wild idea..
Moving open items from the wiki to the CF app is definitely possible,
even for this release. It is not mandatory to have a patch to create an
entry. One just needs a ML thread.
Agreed as well that it is not necessary to list fixed items before the
first beta is released.
--
Michael
Ashutosh Bapat wrote:
We use commitfest app for tracking the patches submitted. It has done
well. Can we re-purpose the same for tracking open items?
I think the rules are too different to cram both in the same place.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Apr 12, 2018 at 6:27 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
Ashutosh Bapat wrote:
We use commitfest app for tracking the patches submitted. It has done
well. Can we re-purpose the same for tracking open items?I think the rules are too different to cram both in the same place.
What do you mean by same place? Can you please explain this a bit?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat wrote:
On Thu, Apr 12, 2018 at 6:27 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
Ashutosh Bapat wrote:
We use commitfest app for tracking the patches submitted. It has done
well. Can we re-purpose the same for tracking open items?I think the rules are too different to cram both in the same place.
What do you mean by same place? Can you please explain this a bit?
"Both in the same place" I meant both the CF items and the open items,
in a single place which is the commitfest app.
The commitfest app is designed with the commitfest workflow in mind.
There are rules about when items can be added, there are states that
correspond to patches being developed and discussed. Open items don't
follow the same rules. What I fear is that if we cram open items in the
commitfest app, we will loosen rules and break the workflow in some way
that will cause us pain when we're back to normal commitfest mode.
The other point is that we want additional annotations for open items.
What commit creates an open item (so we know which committer to blame),
when was it created, when did we last notify the committer, what commit
closed it. We don't have that in commitfest, and I bet there would be
an urge to add those eventually.
I was suggesting a different app because that app would implement
solutions for these somewhat different needs.
Now, maybe what you suggest for open items is to create a separate view
using much of the commitfest app code, say
https://commitfest.postgresql.org/openitems/NNN
I think that would probably work well.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Apr 12, 2018 at 6:52 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
Now, maybe what you suggest for open items is to create a separate view
using much of the commitfest app code, say
https://commitfest.postgresql.org/openitems/NNN
I think that would probably work well.
Yes, that's what I had in mind.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Apr 12, 2018, at 9:24 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote:
On Thu, Apr 12, 2018 at 6:52 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
Now, maybe what you suggest for open items is to create a separate view
using much of the commitfest app code, say
https://commitfest.postgresql.org/openitems/NNN
I think that would probably work well.Yes, that's what I had in mind.
+1. Once the .org refresh goes live I would be happy to hack on
something for that, with the understanding it may not be adopted for
the v11 cycle.
Jonathan