This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bugzilla: Version = unspecified vs. trunk?


On Thu, 15 Mar 2012, Roland McGrath wrote:

> I think we should have a protocol whereby 2.xx.90 bugs get some
> standard treatment en masse that requires that someone retest them
> against the new release and either update to the release version or
> close them.  If nobody retests a bug, it gets put into some clear
> state indicating that (perhaps closed but with a special keyword).

I don't think that makes any more sense than saying that's the policy for 
a bug that was reported against 2.5.  If someone tests against current 
trunk before submitting a bug, that's *better* than reporting having only 
tested with (what was probably a distributor version of) some older 
release; it doesn't make the bug in any greater need of retesting 
(although it's a good idea for all bugs to be triaged, whatever version 
the bug claims to have been tested with).

A better policy would be to use the "last reconfirmed" field in triage and 
say it means the bug was confirmed in trunk as of that date; part of 
triage would be verifying a bug in trunk.  Then, bugs with older "last 
reconfirmed" dates could be periodically reviewed - but that doesn't 
depend on what version they were originally reported against.

Presumably your idea is that trunk bugs reflect some transient defect in 
the source tree, but I don't think that's the normal case.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]