On Tue, Mar 04, 2008 at 12:28:51AM -0800, Don Armstrong wrote: > On Tue, 04 Mar 2008, Anthony Towns wrote: > > Well, ultimately, the problem's that "done" doesn't really mean all that > > much anymore -- we've got: > -done basically means "I'm the maintainer of this package, and I've > done what I needed to do to this bug."
Except it doesn't mean that anymore as soon as debbugs receives a command like: found $BUG $UNSTABLE_VER or notfixed $BUG $UNSTABLE_VER It's good to have a *command* for "I'm the maintainer of this package (or the submitter of this bug), and this bug is DONE.", but using the done field for that just doesn't work right anymore. > A much simpler method would be to disallow unversioned -done > if there are found versions, How about disallowing (or ignoring) versions entirely in pseudopackages? > and mark bugs that have found versions > but no fixed versions as open even if they have been -done'd. The logic's still pretty complicated then. We've got a few states: - do we have a version from the query, or not? - is the done-field set? - is found-in set? - is fixed-in set? With the matrix of done values being: !found, fix | found, !fix | both | neither no query-ver, no done-field DONE | OPEN | ? | OPEN no query-ver, done-field DONE | OPEN ? | DONE | DONE query-ver, no done-field cmp_ver | cmp_ver | cmp_ver | OPEN query-ver, done-field cmp_ver | cmp_ver | cmp_ver | DONE AFAICS, it's the special cases that bite; whether on implementation or usage. For example, by the above, if you had: stable: 1.0-1 -> 1.0-1etch1 unstable: 1.0-1 -> 1.0-2 and had a bug with found-in: 1.0-1; then adding "fixed-in: 1.0-1etch1" would close the bug in the no-query-ver view, even though it's still open in unstable. That's probably confusing, and probably undesirable. Having everything be version-tracked including dist-less queries and pseudopackages changes that to just always using cmp_ver, and removes the done-field from the logic entirely. > This way notfixed would "do the right thing" in making the bug appear > to be open, but would remain commutative. Commutativity's pretty easy -- it just means that if you make "notfixed" or "found" make a previously-closed bug open again; then "fixed" or "notfound" have to make a previously-open bug closed. That doesn't have to involve changing the done field at all -- ie, the commands can still just manipulate the fixed/found fields in the .summary; but if so, the CGIs (and archiving) have to take a different tack working out what "closed" means, at least in some cases. > We could then additionally deprecate reopen in favor of > found+submitter and finish retiring close as well. That sounds good. The constraints seem to be: - submitter must get a mail when a bug is deemed "closed", even if that's only by manipulation of fixed-in etc; it mustn't be possible to go from the bug being open to being archived without mailing the submitter - it must be easy to close bugs on pseudopackages (ie, mail to -done; no futzing around with control@) - there should be an easy way to deal with "notabugs" so they can be closed without ending up treated as open against any version of the package - the simpler the better I would love to see the non-version-tracking view disappear at this point; but afaics that needs us to come up with a pseudoversioning scheme for pseudopackages. Cheers, aj
signature.asc
Description: Digital signature