"Bugs" CF?

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

* 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

On May 12, 2015 4:13 PM, "Stephen Frost" <sfrost@snowman.net> wrote:

* 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.

I am definitely not sold on the idea of per release tag. I think that
unnecessarily duplicates information that is already in git and belongs
there. For that, I'd rather add a field with the commit id something ended
up with (more than one per entry possible of course). But I'd like to hear
from others as well.

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.

To view bugs you would not care about that though and just look at the
consolidated report.

/Magnus