Re: No Issue Tracker - Say it Ain't So!

On Thu, Sep 24, 2015 at 6:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah; "let's write our own bug tracker" is a good way to make sure nothing
> comes of this. On the other hand, "let's get all the Postgres hackers to
> change their habits" is an equally good way to make sure nothing comes of
> this.

I think the way to achieve something is to set a limited scope and
agree what we're going to use the tool to accomplish. If some people
want to drive the entire development workflow off the tool and others
are using it to track issues and others to track bugs then the three
groups will all end up dissatisfied and give up.

My personal feeling is that we should use it basically like a
spreadsheet listing the current pending bugs that we don't want to
forget about. Generally with Postgres there are maybe a half-dozen
such bugs at any time that are being actively worked on and perhaps a
few dozen other bugs that we consider wishlist items that live on
people's todo lists.

What we should NOT do is

a) drive the entire workflow off a trouble ticketing system which is
what tools like Jira are intended for. That will be frustrating
because some people will spend a lot of effort entering information
and then get annoyed that others are ignoring it and working on what
they want. There's no need to mark bug "owners" or keep track of
"milestone targets" to track who is going to do what when about the
bug -- the goal is just that we don't forget about it.

b) try to keep a massive database to search through of every user
report that ever came in. This seems to be what Bugzilla is designed
for -- the default screen doesn't show all the bug reports instead it
has lots of tools for tagging and curating your bugs and searching
through them. Every bugzilla I'm familiar with is full of thousands of
bugs that get ignored until the release they were reported on gets
EOL'd and lots of effort goes into curating this list.

I think those two antipatterns are what most people are afraid of in
this community. I think Debbugs was the best culture fit in that it
isn't designed for either of these two usage models and is email
drive. I think github issues might be a good alternative though.

--
greg