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
