Thread: "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
On Fri, May 8, 2015 at 5:24 AM, Stephen Frost <sfrost@snowman.net> wrote:
* 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.
The technical side can certainly be handled. It would require some special-casing that might make it a bit uglier, but it's certainly doable.
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.
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?
Apart from being cleaner from the code perspective, I think that might make it more clean from a user perspective as well. It would also mean that a patch can easily be re-categorised in and out of being a bugfix quite simply, and just get a history entry when that happens (and not a bumped-between-cf entry).
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...
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
On Tue, May 12, 2015 at 3:21 PM, Stephen Frost <sfrost@snowman.net> 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.
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"?
> 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.
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.
> > 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?
On Tue, May 12, 2015 at 4:08 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
-- 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.
I think the way things are now, a whole lof ot things could break if a patch is not on *any* commitfest...
* 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