Re: "Bugs" CF?

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: "Bugs" CF?
Дата
Msg-id 20150508020809.GK30322@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: "Bugs" CF?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: "Bugs" CF?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: commitfest app bug/feature
Следующее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)