Re: Anyone recognise this fixed bug (subtext: where is the bug DB?)

Alan> I also think a bugfix should have to be logged and given some sort of
Alan> patch id before a bug will be marked as closed.

In a more nearly ideal world, incoming mail will be classified by a
human who will open a bug ticket iff appropriate, and if so will
create and maintain a synopsis of the nature and scope of the bug
as well as any fixes or workarounds that are developed.

In the current situation, in which the information available for each
bug consists of a) the fact that someone sent it to perlbug in the
first place, and b) the dump of every mail message spawned as a result
(including the resulting flamewars and other topic drift), I don't
think the approach you suggest is realistic.

Certainly it would be a step forward if bug tickets had a text
associated with them that was not a mail message, into which the
administrator could put such information as the patchid that fixed
the bug. However as far as I can see at the moment, the biggest single
barrier to useful use of the bug database is the legacy of thousands
of unclassified open bugs lasting back to around June of last year.

I've started to try to bring some sanity to this situation, and in
that effort I have (in around 50 hours of work over the last few
days) marked 382 bugs as closed and 32 as abandoned. I've tried to
be relatively conservative in doing so, but I have to temper that
with the reality of the situation: there are still 1425 open tickets,
which is no help to man or pumpking.

Richard> We need to discuss this patchID a bit:  
Richard> Should it be a relation between ticketid and fixed_in_version
Richard> (5.6.0.2_p01_20000321.001)
Richard> Or should it be an unique (non-incrementing) ID?  (p_235354532)
Richard> Or version_unique_patchid (5.6.0.3_45151)
Richard> Or is there currently a standard patchID we can use that I don't know about?

I don't think we need another fixed field in the database; we need
something like a 'synopsis' field consisting of freeform text into
which the administrators can put such information.

Patches can be referred to in various ways: two primary mechanisms
are the email in which the patch was offered (reference either by
the bugtron messageid, or by the Message-ID field, or by some
reference into a p5p archive), or the repository branch and change
number with which it was applied to the official code.

Hugo