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

On 30 September 2015 at 12:26, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>
> 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?
>
>
> I am short on time today but I will take this specific one:
>
> Mailing lists are great for discourse however they do not:
>
> 1. Provide easy access to archived information
> Searching google isn't an answer it is a band-aid
> 2. Provide proper access to valid information
> Ever get an answer, check the link, find out the solution
references a 5 year old version of PostgreSQL and then find out the problem
is fixed in the 9.4 but not 9.3. You are running 9.3.
> (an issue tracker could track this, easily)
> 3. Provide properly linked information across threads
> My favourite is this:
> SUBJECT: Help (was no longer wanting help)
> Now nothing makes sense on the thread. It should be a new issue.
> 4. Using a recent submission as an example:
> josh(at)idealist(dot)org just submitted 6 patches. They are all based
around making basebackups more useful (specifically pg_basebackup). This is
awesome, but he has created 6 different threads with different discussions
which will likely cause intercommunication between threads.
>
> Using an issue tracker the first patch would be a parent issue
and the subsequent patches would be child issues (that whole dependency
thing). A single click would provide all the information required to
correctly determine what is going on with the series of interrelated
patches. A mailing list does not provide that.
>
> I could go on for a long time with specific examples that our current
model does not serve.

It's well and nice to think that an issue tracker resolves all of this,
and, if we
had tiny numbers of issues, we could doubtless construct a repository
indicating so. (Seems to me that the bit of "fan service" for GitHub's
bug tracker fits into that perspective on things...)

However, after having seen an RT system with tens of thousands of
tickets, it seems wishful thinking to me to imagine that simply adopting
an issue tracking system does much of anything to resolve these things.

It does not go without rather a lot more more than "mere assertion" that an
issue tracker directly improves those cases.

To the contrary, from what I have seen, if there's not rather a lot of
curation
work continually done on an issue tracking system, you *don't* get any of
those things.

I found with RT that if people were at all sloppy in how problems were
reported/reported on, that you get none of #1, #2, or #3.

It may very well be *worse* than that; it seems quite likely to me that if
an issue tracker is not being continually curated by substantially ALL of
its users, then you don't get any of those things. That *is* a lot more
pessimistic, and considerably likely, as it's pretty certain that members
of our email-loving community will decline to get involved in curating
data in some web app.

It seems likely to me that there's some value in trying out debbugs,
as it may provide some useful improvements, however imperfect.

Going to something "way better", particularly if it requires widely
distributed curation efforts, won't be better; it'll probably be a waste
of efforts.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"