Re: No Issue Tracker - Say it Ain't So! - Mailing list pgsql-hackers
| From | Christopher Browne |
|---|---|
| Subject | Re: No Issue Tracker - Say it Ain't So! |
| Date | |
| Msg-id | CAFNqd5U1QRjaZZ+LNL8nJqooTD-bOaTZ86ZJszCXoHO+ZV4YpQ@mail.gmail.com Whole thread Raw |
| In response to | Re: No Issue Tracker - Say it Ain't So! ("Joshua D. Drake" <jd@commandprompt.com>) |
| Responses |
Re: No Issue Tracker - Say it Ain't So!
("Joshua D. Drake" <jd@commandprompt.com>)
Re: No Issue Tracker - Say it Ain't So! (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-hackers |
On 30 September 2015 at 12:26, Joshua D. Drake <jd@commandprompt.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@idealist.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>
> 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@idealist.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.
bug tracker fits into that perspective on 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.
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
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.
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
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?"
question, "How would the Lone Ranger handle this?"
pgsql-hackers by date: