Re: No Issue Tracker - Say it Ain't So! - Mailing list pgsql-hackers

On Wed, Sep 30, 2015 at 7:17 AM, Kam Lasater <ckl@seekayel.com> wrote:
> On Tue, Sep 29, 2015 at 6:39 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> On 09/29/2015 03:08 PM, Merlin Moncure wrote:
>>> I've read this email about three times now and it's not clear at all
>>> to me what a issue/bug tracker brings to the table.
>>
>> Here are the problems I'd like to solve:
>>
>> 1. "Was this issue fixed in a Postgres update?  Which one?"
>>
>> 2. Not losing track of minor bugs.
>>
>> 3. Having a better way to track bugs which require multi-part solutions
>> (e.g. multixact).
>>
>> 4. Having a place for downstream projects/packagers to report bugs.
>>
>> 5. Not answering this question ever again: "Why doesn't your project
>> have a bug tracker?"
>
> I'm not sure if you are trolling me/us. I'm going to assume not and
> interpret the comment from the prospective of: "the current process
> works for those currently using the process"
>
> That may be true (I'll leave it to someone more familiar with the
> process to address). What that comment doesn't address is the needs of
> those who are not currently involved or those who are not on this
> email list. Just as "read the code" is an insufficient answer to a
> user who is looking to use a feature, "read the mailing list" is an
> insufficient answer to a query from a user about the state of bugs
> past and present.
>
> Given that, in addition to Josh's five points from an insider's
> perspective I would add some from an outsider's perspective:
>
> 1/ Is the issue I'm having a known bug that can be fixed by an upgrade
> to a more recent version, if so, which one?
>
> 2/ This project must be disorganized and/or not truly mature w/o a
> central tracker
>
> 3/ No hints or help on what might be an easier place to start contributing

I'm not trolling in any way.  I'm just challenging you to back up your
blanket assertions with evidence.  For example, you're assertion that
mailing lists are insufficient is simply stated and expected to be
taken on faith: *How* is it insufficient and *what* do things like in
the new world?  Be specific: glossing over these details doesn't
really accomplish anything and avoids the careful examination that may
suggest small tweaks to the current processes that could get similar
results with a lot less effort.  In this entire massive thread, so far
only Josh has come up with what I'd consider to be actionable problem
cases.

Josh's point, "2. Not losing track of minor bugs." is an example of
what's bugging (pun intended) me.  Do you think issues don't get lost
in issue trackers?  They absolutely can, and do, even (where I work)
with a full time paid PM who spends her entire day in JIRA managing
this stuff.  Sure, you can do things like run aging reports and all
that but that immediately suggests the questions, 'who is running the
report?'  and 'what are the expected outputs of that report?'.  So I'm
putting it back on you: what "minor bugs" have been missed, and please
clearly explain how an issue tracker would improve the situation with
a little more detail than "Issue tracker, therefore, better".  This
would allow for objective examination of how things might look after
making major process changes.

As I noted upthread google is incredibly efficient at tying up a
observed issue with the relevant fix and commentary, all based on
search engine integration with the mailing list that you've summarily
dismissed (without any evidence whatsoever) as ineffective.  You're
just assuming it's better without any examination of the costs
involved.  For example, implementation and training aside, I expect
one of the immediate downsides of moving away from google + mailing
list is that you're going to be suffering from a deluge of duplicate
issues.

Note, I'm not picking on Josh here.   The points pertaining to
querying issues are certainly better than wading through the release
notes which I've always felt to be kind of a pain.  What I'm driving
at is that you should identify actual pain points in the process and
explain clearly how things would improve.  Also, consider low impact
solutions first (for example what low tech method makes bug
identification to release easier?) and move into a big tooling change
only after discarding them.

merlin