Обсуждение: "Bugs" CF?

All,

Starting a new thread, as suggested by Magnus.

* Magnus Hagander (magnus@hagander.net) wrote:
> On Tue, May 5, 2015 at 3:47 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> > On Fri, May 1, 2015 at 1:16 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > > We really need to segregate the two..  By that what I mean is this: I
> > > want an "always-open" "bugfix" CF, which allows us to keep track of
> > > bugfix patches.  Having something about "applies to versions X, Y, Z"
> > > would be nice too...
> > >
> > > /me prods Magnus
> >
> > I don't really see that as a step forward.  Right now there's one
> > place to look at for patches that somebody wants me (or someone) to
> > pay attention to, and, when time permits, I look at it.  Dividing that
> > up into two places is not going to make me look at them more
> > frequently.

I agree that there's value in having fewer places to check for patches
to review, but bug-fixing patches are materially different from feature
patches and having them all lumped together into a CF that might not
start for another month or longer isn't good.

We have a 'Bug Fixes' category already..  Perhaps we could have a
'virtual' CF which goes across all the currently active CFs and pulls
together just the patches marked as 'Bug Fixes'.  What I don't like
about that approach is that we'll continue to get the question of
"which CF should I submit this bug fix for?"  If we go the other
direction of having a 'Bug Fixes' CF that always exists then we could
pull anything active from that CF into the view for all open CFs, or
perhaps just the current/next CF, and then it's clear where to submit
bug fix patches and we still have a single view of everything which is
'currently active'.

This is clearly just brainstorming, so let me outline the goal of the
discussion, at least as I see it:

a) make sure we don't lose track of bug-fix patches
b) make it clear where bug-fix patches should be submitted
c) provide a view of bug-fix patches for people to look at outside of  CF time
d) continue to have a single view which includes all active patches  with bug fixes listed first

Perhaps not all of those goals are worthwhile, in which case we should
work towards agreement on them prior to talking about implementation
(clearly, I've managed to craft this email entirely backwards; ah well).

> Thanks for highlighting that somebody was actually trying to get my
> attention in that thread. I missed it :)

Sorry. :)

> Which brings the point - this should be discussed in a separate thread,
> really. It's not part of feature freeze or beta schedule... It's more about
> process...

Done.
Thanks!
    Stephen

On 5/7/15 9:44 AM, Stephen Frost wrote:
> a) make sure we don't lose track of bug-fix patches
> b) make it clear where bug-fix patches should be submitted
> c) provide a view of bug-fix patches for people to look at outside of
>    CF time
> d) continue to have a single view which includes all active patches
>    with bug fixes listed first

I think these goals are valid, but are adequately served by the current
setup.

I think having a separate bucket for bugs would just lead to lots of
discussions over what qualifies as a bug.

Peter Eisentraut <peter_e@gmx.net> writes:
> On 5/7/15 9:44 AM, Stephen Frost wrote:
>> a) make sure we don't lose track of bug-fix patches
>> b) make it clear where bug-fix patches should be submitted
>> c) provide a view of bug-fix patches for people to look at outside of
>> CF time
>> d) continue to have a single view which includes all active patches
>> with bug fixes listed first

> I think these goals are valid, but are adequately served by the current
> setup.

Not sure I agree with that ...

> I think having a separate bucket for bugs would just lead to lots of
> discussions over what qualifies as a bug.

... but I do agree with this.  With our current methodology there's
not a lot of need to decide a-priori whether something is a feature
or a bug (in particular, the way it's categorized in the CF app is
not a high-stakes decision).  I think that's just as well.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > On 5/7/15 9:44 AM, Stephen Frost wrote:
> >> a) make sure we don't lose track of bug-fix patches
> >> b) make it clear where bug-fix patches should be submitted
> >> c) provide a view of bug-fix patches for people to look at outside of
> >> CF time
> >> d) continue to have a single view which includes all active patches
> >> with bug fixes listed first
>
> > I think these goals are valid, but are adequately served by the current
> > setup.
>
> Not sure I agree with that ...
>
> > I think having a separate bucket for bugs would just lead to lots of
> > discussions over what qualifies as a bug.

I don't believe it would- it's not like we have regular arguments over
on -bugs about what's a bug and what isn't.  In my recollection, at
least, there's been very little disagreement over what's a bug and what
isn't and what disagreement there has been has been quickly resolved.

I understand the *concern* as it does exist in a lot of software
development environments, but it's not an issue we suffer from,
thankfully.  I don't think we'd suddenly start argueing over that
distinction if the CF app did something a bit different than it does now
when it comes to bugs.  Sure, we'd still have the occational new user
who might submit their feature as a 'bug fix', but that's no different
than it being sent to -bugs, or even just to -hackers as a 'bug fix'.
We see it, someone points out that it's not a bug (and perhaps
reclassifies it in the CF) and we move on.

> ... but I do agree with this.  With our current methodology there's
> not a lot of need to decide a-priori whether something is a feature
> or a bug (in particular, the way it's categorized in the CF app is
> not a high-stakes decision).  I think that's just as well.

If we intentionally avoid making a distinction between features and bug
requests then it seems to follow that we feel bugs are no more important
than new features, and I have a seriously hard time with that position.
Further, I don't believe we actually feel that way (or why would we have
a dedicated -bugs list?).

What we do have, from what I've seen anyway, is an issue where people
don't put things into the CF because they don't want to add "new" things
to the currently open CF, since it has already "started", and putting a
bug fix into the "next" CF would mean no one is going to be looking at
it for a month or two, which is pretty obviously confusing for people
who are used to the responsiveness provided on -bugs.  Heck, it'd be
confusing for me to have to tell myself "oh, I need to look at June's CF
to see if there's any active bugs that we should be looking at before
the next set of minor releases" when it's the beginning of May.

I suspect there are also individuals who would be more interested in
helping with bug fixes (and perhaps looking to see if they cause
regressions) than new features that they're not going to see for a year
or more, and it'd be nice to leverage those volunteers to help us.
Companies who work with PG might also be willing to have their staff
spend time looking at bugs where they might be less inclined to point
someone at a much larger and open-ended commitfest that could suck up
days or even weeks worth of time spent reviewing proposed features.

I could go on, but perhaps it's a discussion to be had in person rather
than on the lists.  Even I realize it's getting bad when the response is
three or four times the size of the message being responded to. :)
Thanks!
    Stephen

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> ... but I do agree with this.  With our current methodology there's
>> not a lot of need to decide a-priori whether something is a feature
>> or a bug (in particular, the way it's categorized in the CF app is
>> not a high-stakes decision).  I think that's just as well.

> If we intentionally avoid making a distinction between features and bug
> requests then it seems to follow that we feel bugs are no more important
> than new features, and I have a seriously hard time with that position.

I am not arguing for that at all.  Rather, I'm pointing out that the real
decision is currently made pretty late in the process, eg by the committer
who decides whether to back-patch or not.  I'm afraid Peter's right that
a separate queue for bug fixes would encourage gaming the system by
putting debatable stuff into the bug-fix queue.

Now, if we can easily shove stuff back and forth between the main queue
and the bug-fix queue, maybe that's not such a big deal.  But it doesn't
seem like the current CF app is really amenable to that; doesn't it for
example want to leave an entry behind when you move something to another
CF?

> What we do have, from what I've seen anyway, is an issue where people
> don't put things into the CF because they don't want to add "new" things
> to the currently open CF, since it has already "started", and putting a
> bug fix into the "next" CF would mean no one is going to be looking at
> it for a month or two, which is pretty obviously confusing for people
> who are used to the responsiveness provided on -bugs.

I concur that this is a problem.  On the other hand, putting something
into the CF app already implies that you're not expecting it to get dealt
with right away...
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Now, if we can easily shove stuff back and forth between the main queue
> and the bug-fix queue, maybe that's not such a big deal.  But it doesn't
> seem like the current CF app is really amenable to that; doesn't it for
> example want to leave an entry behind when you move something to another
> CF?

I agree that we'd need to have that capability if we are to go down this
road, but I won't pretend to have any idea about the level of
difficulty.  If we're agreed that this is at least reasonable to explore
then we really need to ask Magnus to weigh in when it comes to the
implementation side of things.

Another thought which occured to me, just to throw it out there, was the
idea of a "Next point release" kind of CF, which is perhaps renamed when
to whatever the point release actually is and anything which didn't make
it is bumped to a new CF entry, or something along those lines.

Again, this is brainstorming to try and achieve the goals which I set
out earlier.  I'm not sure that I want to spend much more time on it
now, given the impending feature freeze date and the clearly
unattainable amount of work we still have sitting in front of us for it.

> > What we do have, from what I've seen anyway, is an issue where people
> > don't put things into the CF because they don't want to add "new" things
> > to the currently open CF, since it has already "started", and putting a
> > bug fix into the "next" CF would mean no one is going to be looking at
> > it for a month or two, which is pretty obviously confusing for people
> > who are used to the responsiveness provided on -bugs.
>
> I concur that this is a problem.  On the other hand, putting something
> into the CF app already implies that you're not expecting it to get dealt
> with right away...

I'm glad to hear that we agree there's an issue here worthwhile of
consideration.  I agree that, today, putting something into the CF
system (in any form) implies that it's not going to be handled right
away, and that's perfectly fine for new features, but it's why people
are confused about using the CF system for bug fixes.  I'd like to use
the CF system as a way to keep track of bug fix patches but I don't want
that to also mean that we ignore bug fix patches for months (not that I
think we would intentionally, especially if it also showed up on a
mailing list, but I do feel there's a serious risk that we'll drop the
ball on some bug fix patch that went to -hackers; that's what the CF
system was originally built to address in the first place, after all).
Thanks!    Stephen

Magnus,

* Magnus Hagander (magnus@hagander.net) wrote:
> We could also use the category that we have now, or even create the concept
> of a tag (where you can assign multiple ones). And then have a view that
> brings together a view of everything with a specific tag/category,
> *regardless* of which CF it's on.

I like the tag idea.

> So the patch itself would live in whatever CF it was put in (or punted to),
> but you can get a global view. Which with a filter would make it easy to
> see "everything flagged as a bugfix that has not been committed". Which I
> think is the main thing we're looking for here, is it not?

The biggest issue that I see with this is, again, trying to make sure
people know that they *should* put bug patches into the CF and make it
clear *which* CF to put them into.

I don't know that we've even got an answer for the second question
currently, do we?  My thought is "whatever one people are looking at
now" but I'm guessing others feel differently.

> > Another thought which occured to me, just to throw it out there, was the
> > idea of a "Next point release" kind of CF, which is perhaps renamed when
> > to whatever the point release actually is and anything which didn't make
> > it is bumped to a new CF entry, or something along those lines.
>
> That doesn't sound like a CF to me. Again, it might be a tag or a category
> or something, but the main thing with the CF term is that it's the
> fixed-period cycle of development. We shouldn't start abusing that too
> much...

A tag for this would be great..
Thanks!
    Stephen

Stephen Frost wrote:
> Magnus,
> 
> * Magnus Hagander (magnus@hagander.net) wrote:
> > We could also use the category that we have now, or even create the concept
> > of a tag (where you can assign multiple ones). And then have a view that
> > brings together a view of everything with a specific tag/category,
> > *regardless* of which CF it's on.
> 
> I like the tag idea.

+1

> > So the patch itself would live in whatever CF it was put in (or punted to),
> > but you can get a global view. Which with a filter would make it easy to
> > see "everything flagged as a bugfix that has not been committed". Which I
> > think is the main thing we're looking for here, is it not?
> 
> The biggest issue that I see with this is, again, trying to make sure
> people know that they *should* put bug patches into the CF and make it
> clear *which* CF to put them into.

Maybe the answer to this is not to put it in any CF at all, and just
expect it to be seen through a tag view.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

* Magnus Hagander (magnus@hagander.net) wrote:
> On Tue, May 12, 2015 at 3:21 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Magnus Hagander (magnus@hagander.net) wrote:
> > > We could also use the category that we have now, or even create the
> > concept
> > > of a tag (where you can assign multiple ones). And then have a view that
> > > brings together a view of everything with a specific tag/category,
> > > *regardless* of which CF it's on.
> >
> > I like the tag idea.
>
> Are there other things you would consider tags for as well? As in should we
> if we do this look at a generic tag system, or just a "tag this is a
> bugfix"?

I was thinking a generic system though I'm not sure that the tags should
be free-form..  My first thought is a "release" tag, ie: 9.4.2 or
something.  Having a 'committed' + '9.4.2' view would be kind of neat.

> > The biggest issue that I see with this is, again, trying to make sure
> > people know that they *should* put bug patches into the CF and make it
> > clear *which* CF to put them into.
> >
> > I don't know that we've even got an answer for the second question
> > currently, do we?  My thought is "whatever one people are looking at
> > now" but I'm guessing others feel differently.
>
> I would say it should go into whatever CF is currently "Open". Don't treat
> thems eparately from a submission POV, other than adding the tag. Only from
> a "consumption" POV, through the special view.

Yeah, but "Open" currently means June.  Perhaps that's not an issue but
it still feels awkward to me.

> > > > Another thought which occured to me, just to throw it out there, was
> > the
> > > > idea of a "Next point release" kind of CF, which is perhaps renamed
> > when
> > > > to whatever the point release actually is and anything which didn't
> > make
> > > > it is bumped to a new CF entry, or something along those lines.
> > >
> > > That doesn't sound like a CF to me. Again, it might be a tag or a
> > category
> > > or something, but the main thing with the CF term is that it's the
> > > fixed-period cycle of development. We shouldn't start abusing that too
> > > much...
> >
> > A tag for this would be great..
>
> How is that different from a  bugfix, though?

This would be the release tag that I'm suggesting above.
Thanks!
    Stephen

<p dir="ltr"><br /> On May 12, 2015 4:13 PM, "Stephen Frost" <<a
href="mailto:sfrost@snowman.net">sfrost@snowman.net</a>>wrote:<br /> ><br /> > * Magnus Hagander (<a
href="mailto:magnus@hagander.net">magnus@hagander.net</a>)wrote:<br /> > > On Tue, May 12, 2015 at 3:21 PM,
StephenFrost <<a href="mailto:sfrost@snowman.net">sfrost@snowman.net</a>> wrote:<br /> > > > * Magnus
Hagander(<a href="mailto:magnus@hagander.net">magnus@hagander.net</a>) wrote:<br /> > > > > We could also
usethe category that we have now, or even create the<br /> > > > concept<br /> > > > > of a tag
(whereyou can assign multiple ones). And then have a view that<br /> > > > > brings together a view of
everythingwith a specific tag/category,<br /> > > > > *regardless* of which CF it's on.<br /> > >
><br/> > > > I like the tag idea.<br /> > ><br /> > > Are there other things you would consider
tagsfor as well? As in should we<br /> > > if we do this look at a generic tag system, or just a "tag this is
a<br/> > > bugfix"?<br /> ><br /> > I was thinking a generic system though I'm not sure that the tags
should<br/> > be free-form..  My first thought is a "release" tag, ie: 9.4.2 or<br /> > something.  Having a
'committed'+ '9.4.2' view would be kind of neat.<p dir="ltr">I am definitely not sold on the idea of  per release tag.
Ithink that unnecessarily duplicates information that is already in git and belongs there. For that, I'd rather add a
fieldwith the commit id something ended up with (more than one per entry possible of course). But I'd like to hear from
othersas well. <br /><br /><br /><p dir="ltr">> > > The biggest issue that I see with this is, again, trying
tomake sure<br /> > > > people know that they *should* put bug patches into the CF and make it<br /> > >
>clear *which* CF to put them into.<br /> > > ><br /> > > > I don't know that we've even got an
answerfor the second question<br /> > > > currently, do we?  My thought is "whatever one people are looking
at<br/> > > > now" but I'm guessing others feel differently.<br /> > ><br /> > > I would say it
shouldgo into whatever CF is currently "Open". Don't treat<br /> > > thems eparately from a submission POV, other
thanadding the tag. Only from<br /> > > a "consumption" POV, through the special view.<br /> ><br /> >
Yeah,but "Open" currently means June.  Perhaps that's not an issue but<br /> > it still feels awkward to me.<p
dir="ltr">Toview bugs you would not care about that though  and just look at the consolidated report. <p
dir="ltr">/Magnus