[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Etiquette about test regression, bug severities, etc.



Now that we have autopkgtests blocking testing migration, there is a
much stronger incentive for people to keep their tests passing in
testing.

If one's tests are broken by an update to another package, and the
increased britney migration delay doesn't do the job (perhaps the
delay is too short, or there is a problem with the ci arrangements)
then ideally there would be a bug open against the other package.
That bug would stop the migration.

There are some problems with this, though:

 * The only available bug severity is `serious' which also triggers
   testing autoremovals.  Testing autoremovals have very wide
   visibility - random maintainers of nth-level dependencies are at
   the very least alerted, and perhaps alarmed or inconvenienced.
   They can suddenly pop up and need things explaining.  That is not
   helpful.  And certainly autoremoving things for such a situation is
   not appropriate.

 * By Debian convention the bug severity is a matter for the
   maintainer of the package the bug is reported against.  filing a
   high-seveerity bug is sometimes seen as hostile.  Worse, if the
   maintainer disagrees about the severity (perhaps they take a
   different view about some technical details of the bad interaction)
   the maintainer of broken package has no recourse.

IMO we need a bug severity or tag that has the following properties:

 * The maintainer of a (direct or indirect) rdependency of A is
   entitled to maintain an open bug, with that tag, against A, even if
   the maintainer of A disagrees.

 * Such bugs, when appropriately tagged with fixed and found versions,
   prevent or *substantially* delay testing migration.

In the absence of such a self-help system, would it normally be
appropriate to ask the release team to manually defer the migration ?
If so then maybe that could be written down somewhere.  Also it should
probably make clear that such a request should not occur routinely,
only if either (i) the maintainers of the packages involved disagree
or (ii) the matter is urgent (eg because the dependency package will
migrate in the next day or two).

Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.


Reply to: