On 10/01/2015 10:35 AM, Robert Haas wrote:
On Wed, Sep 30, 2015 at 10:44 AM, Merlin Moncure <mmonc...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
