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

On 09/30/2015 07:44 AM, Merlin Moncure wrote:
> 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.

I don't see any way to make small tweaks to the existing process which
would fix any of these problems.  I think if that were possible, we'd
already have done it.  Suggestions welcome, of course.

For example, "just use the wiki for this" has been mentioned as an
alternative.  But we've tried "just using the wiki" for a number of
things, and it doesn't really work.  For example, using the wiki as a
way of breaking down the various multixact issues manifestly didn't
work.  A big part of the problem there is that there's no good way for
the wiki to notify people when there's been an update; a smaller part is
that the formatting gets messed up and impossible to follow.

> 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? 

More accurately: losing track of *fewer* minor bugs.

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

In my experience it has not been effective.  Generally when a client
asks me the question about which release a particular bug is fixed in,
it takes me 15-30 minutes to determine the answer using
google/list/commitlog.  The client would not be able to determine it for
themselves at all.  While I appreciate the billable hours, it doesn't
seem like a good use of the customer's money, you know?

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

As opposed to duplicate emails, which we already get?

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

Well, if you have suggestions that don't involve an email-driven bug
tracker, please make them.  I don't have any other ideas.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com