Thread: 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: https://www.postgresql.org/message-id/CAFj8pRDxOwPPzpA8i%2BAQeDQFj7bhVw-dR2%3D%3DrfWZ3zMGkm568Q%40mail.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
Attachment
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: > https://www.postgresql.org/message-id/CAFj8pRDxOwPPzpA8i%2BAQeDQFj7bhVw-dR2%3D%3DrfWZ3zMGkm568Q%40mail.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. +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
Attachment
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...
(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..)
--
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
Attachment
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