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

Re: Bug mass filling



On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava <srivasta@debian.org> said:

[...]

>> and for policy:

>> These classifications are roughly equivalent to the bug severities
>> serious (for must or required directive violations), minor, normal or
>> important (for should or recommended directive violations) and
>> wishlist (for optional items). [2] However, this is not a direct
>> mapping, and the release managers determine which violations are
>> considered release-critical.

>         where does release criticality jump in here from? Policy has
> no mention of RC in this context, I see no reason to suddenly inject
> one.

Well, I did say that it was a very rough draft. ;)

Second try:
  "... However, this is not a direct mapping, and the release managers
  determine the severity of each violation."

>         The problem is there are two mappings, one from policy
> violations over to bug severities, and another from severities to
> RC. The former is , according to policy, pretty static; the latter is,
> by the release team directive, a fluid mapping based on the contents
> of a web page, which is updated by the RM's as needed.

>         I don't see any reason to fuzzy up the first mapping; and I
> see the etch-ignore tag as a perfectly legitimate and adequate
> representation of the fluidity of the second mapping.

>From my reading, the language for the first mapping is already a bit
fuzzy, since both places that define the mapping use the word "roughly".
So I think that we should either make it explicitly fuzzy by changing
the wording, or make it explicitly not fuzzy by removing the word
"roughly" (and possibly changing policy to reflect reality).

I also would prefer if the first mapping wasn't fuzzy.  But it sounds to
me like the release team is reading it as being a fuzzy mapping
(AFAICT), in which case I would suggest making it more clear that the
mapping is fuzzy.

-- 
Hubert Chan <uhoreg@debian.org> -- Jabber: hubert@uhoreg.ca
PGP/GnuPG key: 1024D/124B61FA         http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA



Reply to: