On 10/01/2015 10:35 AM, Robert Haas wrote:
> On Wed, Sep 30, 2015 at 10:44 AM, Merlin Moncure <mmoncure@gmail.com> 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 think that the mailing list is pretty much just as good as a bug
> tracker would be for finding the discussion about some particular bug.
> I mean, our web site has all the mails from the email thread, and
> that's where the discussion is, and if that discussion were in a bug
> tracker it wouldn't have any more information than what is on the
> email thread. The email thread also usually contains a message
> indicating whether a fix was committed.
>
> Where the mailing list is less adequate is:
>
> - If you want to see a list of all the bugs by status, you have to
> review every thread individually. It would be useful to have a way to
> filter out the bug reports that turn out not to be really bugs vs. the
> ones that are real bugs which have been fixed vs. the ones that are
> real bugs that have not been fixed. Associating status with each bug
> number would make this easier.
>
> - Bug numbers are sometimes preserved in commit messages, but they
> never make it into release notes. This actually seems like something
> we could improve pretty easily and without a lot of extra work (and
> also without a bug tracker). If every committer makes a practice of
> putting the bug number into the commit message, and the people who
> write the release notes then transcribe the information there, I bet
> that would be pretty useful to a whole lotta people.
>
A lot of errors get fixed without a bug ever being raised. If we want a
tracker to represent some sort of historical record, all commits, or all
non-feature commits if we don't want to track features, should be
against tracker items. (In my former life I once had to send out a memo
to developers that said "If you're not working on items in the tracker
you're not doing your job.")
cheers
andrew
