On Thu, Mar 06, 2008 at 02:56:39PM -0800, Don Armstrong wrote: > > 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. > I think that it can, and should, actually. In the cases where there's > a found version that is greater than the fixed version, the bug is no > longer done, and should be shown as such.
Right, that's exactly what I'm saying: from the BTS's point-of-view done
status should be determined based on the versions, not whether an email
address is in some field.
> I already do ignore versions entirely in pseudopackages.
Well, in that case, maybe we should just make them disjoint:
pseudopackages don't do versions ever; versioned packages do versions
always. The "done" field is canonical for pseudopackages, and purely
advisory for normal packages.
For pseudopackages the only states are "is currently a bug" and "is not
currently a bug" (open and done, respectively); for versioned packages,
the states are "was found in version X or earlier", "was fixed in version
X or earlier" and "was not relevant for version X".
For pseudopackages we ignore dist=, and for versioned packages we default
dist=unstable if dist=/version= is unspecified.
> > The logic's still pretty complicated then.
> > With the matrix of done values being:
pseudopkg, no done-field OPEN
pseudopkg, done-field DONE
cmp_ver=found | cmp_ver=fixed | cmp_ver=other
versionedpkg, done-field OPEN | DONE | NOT-PRESENT
versionedpkg, no done-field OPEN | ? | NOT-PRESENT
with the only questionable behaviour being a bug with some fixed-versions
but no done-field set (which we should disallow afaics); and you mark
notabugs by removing all the found-versions so it's NOT-PRESENT anywhere,
and setting done.
In that case, the behaviour would be:
NNNN-done: set fixed version, done field
found: set found version
notfound: remove found version
fixed: set fixed version, if done not set, set based on From:
notfixed: remove fixed version (don't unset done)
expire: if done is set, and bug is not OPEN in relevant dists, expire
> > !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
> ^^^^^^^
> These are the ones I suggest we change; currently we mark these as
> done; I suggest that we mark them as done or absent/found.
For the latter one you have to do the version comparison, because you might
have a version earlier than found.
The differences between the two tables above are:
!found, fix | found, !fix | both | neither
no query-ver, no done-field OPEN | ---- | OPEN | ----
no query-ver, done-field ---- | DONE | ---- | ----
query-ver, no done-field ---- | ---- | ---- | cmp_ver
query-ver, done-field ---- | ---- | ---- | cmp_ver
(because query-ver becomes equivalent to whether it's a pseudopackage
or not)
This also gives you support for falling back to non-vt'ed BTSes that
behave the same way debbugs used to: it just means everything's a
pseudopackage.
> > 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.
> If setting fixed sets the -done field, yes.
You could alternatively set it up so the "fixed" control@ gives an error
if the done-field isn't already set (by a mail to -done, eg).
> > 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.
> We'd still have the done field in the logic because of the cases where
> there's no versions at all.
We only *need* that for pseudopackages though. For versioned packages, we
can require a version to be included.
> What I think we should get rid of are the
> dist-less queries, and perhaps default to dist=unstable;arch=source or
> some equivalent for dist-less queries.
Yup.
> > 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
> Right now, we require done to be set before we archive, so they'll get
> a mail on -done. [I think we should keep this constraint.]
Yes, definitely.
> > - 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
> For non pseudopackages, this requires using control+done at this
> moment. [One of my longer term goals is to finish ripping out all of
> the bug modification commands from service so they can be easily
> invoked using psuedoheaders from process, so you could just send a
> single mail to -done (and do other useful things at submit@ time when
> you don't even know the bug number yet.)]
Sending a mail to control@ for notabugs sounds reasonable to me anyway,
really. For comparison, we don't support adding tags while mailing
-done, right?
Cheers,
aj
signature.asc
Description: Digital signature
