Re: Bug mass filling

[Manoj Srivastava]

On Thu, 26 Oct 2006 12:02:31 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 

> Manoj Srivastava writes ("Re: Bug mass filling"):
>> On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson
>> <[EMAIL PROTECTED]> said:
>> > There are two different and orthogonal properties of a policy
>> > requirement:
>> >   1. [...]
>> > [and]
>> >   2. Is a violation of the requirement release-critical ?  That
>> >  is, would it be better to remove the package (or to stick
>> >  with the old version of the package) than to live with this
>> >  bug ?
>> 
>> I posit the second one is not a characteristic of the policy
>> requirement; it is a characteristic of the bug.

> Well, yes.

>> My stance is that bug severity tags are tied to policy violations,
>> since that can be determined mechanically; violate a must
>> directive, bug is serious.  Whether or not all serious bugs are RC
>> is anothermatter that the release team determines; hence the
>> *-ignore tags.

> Why on earth is it useful to encode some scripturally-determined
> property of a bug in the severity ?

Because developers and bug reporters are human, and may need
some guidance about bug severities, and 

> The use for the severity is to 1. allow us to record whether the bug
> is release critical (which is definitely something we need to track)
> and 2. allow the project to prioritise its work (which is also
> something we need to track).  Helpfully we can use the same linear
> scale for both because all release-critical bugs should always have
> a higher priority than all non-release-critical bugs.

A very developer centric view. But there are other pepople in
 the community; and as a general statement this falls far short of the
 mark for which bug severities are actually useful for. Bug severities
 have one other purpose, and perhaps the most importan of all: It lets
 people know whether or not it is OK to upgrade or install a package,
 and but severities are one way of gauging a release' quality. While
 only partially relevant to this case, you are making what seems like
 a general statement, and missing important bits.



>> The problem is, since this involves human judgement, one can no
>> longer state in policy what category a must violation of policy
>> falls into; policy must waffle with well, if you find a policy
>> violation, fgiure out what severity the ciolation would be, consult
>> your feelings, other peoples feelings, release managers, and
>> perhaps the phase of the moon.

> This is a completely bizarre assertion.  If you're submitting a bug
> you can look at the BTS web page which gives clear definitions of
> all of the bug severities.

I see you are trolling. However, I suppose I can say I have
 been trolled, since I am going to reply anyway.

People do not work like that. Simply ignoring the way people
 report bugs, and pretending that every one looks at all kinds of
 unrelated bug reports and cogently arrives at a working, consistent,
 and borderline correct severity may work in an, ahem, bizarre world
 you live in, but does not work on planet earth.

So, policy guidelines as to bug severities are a cheap way to
 arrive at a consistent default for bug severities, and there is no
 reason not to add such guidance, as long as the guidelines are
 flexible, and, more importantly, correct.

> There is only one significant problem with the list at
>  http://www.debian.org/Bugs/Developer#severitieswhich is the
>  definition of `serious'.  It should be replaced with:

May I suggest that his opinion is perhaps as, umm, ridiculous,
 as the rest of your rant?

> Obviously there is room for judgement here by the submitter and the
> maintainer - but we rely on our colleagues to make the right
> decisions in all sorts of areas.

Jindani.

manoj

-- 
All things that are, are with more spirit chased than
enjoyed. Shakespeare, "Merchant of Venice"
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Ian Jackson]

Manoj Srivastava writes ("Re: Bug mass filling"):
> On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 
> > There are two different and orthogonal properties of a policy
> > requirement:
> >   1. [...]
> > [and]
> >   2. Is a violation of the requirement release-critical ?  That is,
> >  would it be better to remove the package (or to stick with the
> >  old version of the package) than to live with this bug ?
> 
> I posit the second one is not a characteristic of the policy
>  requirement; it is a characteristic of the bug.

Well, yes.

> My stance is that bug severity tags are tied to policy
>  violations, since that can be determined mechanically; violate a must
>  directive, bug is serious.  Whether or not all serious bugs are RC is
>  anothermatter that the release team determines; hence the *-ignore
>  tags.

Why on earth is it useful to encode some scripturally-determined
property of a bug in the severity ?

The use for the severity is to 1. allow us to record whether the bug
is release critical (which is definitely something we need to track)
and 2. allow the project to prioritise its work (which is also
something we need to track).  Helpfully we can use the same linear
scale for both because all release-critical bugs should always have a
higher priority than all non-release-critical bugs.

> The problem is, since this involves human judgement, one can no
>  longer state in policy what category a must violation of policy falls
>  into; policy must waffle with well, if you find a policy violation,
>  fgiure out what severity the ciolation would be, consult your
>  feelings, other peoples feelings, release managers,  and perhaps the
>  phase of the moon.

This is a completely bizarre assertion.  If you're submitting a bug
you can look at the BTS web page which gives clear definitions of all
of the bug severities.

There is only one significant problem with the list at
 http://www.debian.org/Bugs/Developer#severities
which is the definition of `serious'.  It should be replaced with:

 serious
 Release critical bugs (other than `grave' and `critical' bugs);
 see also the Release Managers' policy at .  Do not set
 this severity unless it would be better to remove the package
 from the distribution than to ship it with this bug.  The
 final decision about whether a bug is release critical rests
 with the Release Managers.

Obviously there is room for judgement here by the submitter and the
maintainer - but we rely on our colleagues to make the right decisions
in all sorts of areas.

> Since we already feel that our RM's are overworked (hence
>  dunc-tank and payment schemes), I strongly suggest we not add to the
>  RM's burdens any more than we have to.

If the RMs want to write a document saying what counts as a release
critical bug, can do so.  And lo, look, they have.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Wed, 25 Oct 2006 09:31:42 +0200, Andreas Barth <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]:
>> If you are aware of issues that are violations of muSt directives
>> that are never going to be RC, there should be a bug opened on
>> policy with severity important for every one of them.

> I hope to have time post-etch-release to do that (that is what I
> meant with "syncing between policy and release-policy").

Thanks. Your input shall be appreciated -- in the mean while,
 those of us with time and the inclination  can work on fixing the low
 hanging errors, so you may find your work later reduced a bit.

manoj
-- 
The more complex the mind, the greater the need for the simplicity of
play. Kirk, "Shore Leave", stardate 3025.8
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Steve Langasek]

On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote:
> Are you suggesting that each package can have a related list of
> non-transient bugs that should be marked (with a new tags called )
> ignore-this-policy-violation where this can be attached to any package
> related bug for any length of time until the issues is deemed
> worthy/necessary to be addressed?

No.  Why would anyone want this when downgrading these bugs to "important"
has the same effect in all respects and doesn't require changing code in 20
different places to account for a change in semantics?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: should, ought, must (was: Bug mass filling)

[Andreas Barth]

* Frank Küster ([EMAIL PROTECTED]) [061025 09:49]:
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek <[EMAIL PROTECTED]> 
> > said: 
> >> Is the word "generally" here an error?  I read this as implying the
> >> normal meaning of "should" -- that not everything which violates a
> >> "should" mandate is a bug.
> >
> > I am of the opinion that it is. We can replace non-buggy
> >  instances of should by 'ought to be', if needed.
> 
> But please don't forget a "legal definition" of those terms.  For me, as
> a non-native speaker, I have no idea whether "ought to" is weaker or
> stronger than "should", or just something different (and what).

I think we should (hehe) use the same definitions as the RFCs - or is
this text non-DFSG-free?

Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 
>
>> Because your choice of mapping blurs the distinction between
>> one-time exceptions for RCness (e.g., due to GRs for DFSG issues),
>> vs. policy violations that the release team does not believe should
>> be promoted to RC status at any time in the foreseeable future.
>> "etch-ignore" is most useful as a tag if its use is restricted to
>> those bugs whose *non*-release-criticality is transient in nature --
>> the alternative is that the release team is stuck going through the
>> BTS after each release and re-adding new tags to those bugs about
>> policy violations whose severity does not justify exclusion from the
>> release.
>
> That does not make sense. After etch is released, etch-ignore
>  tags are no-ops -- so there is no need to go back and untag anything.

The work would be to change the tag to "whatever-ignore".

> And if there are anyissues that are policy must directives
>  that the release team has take upon itself to say are policy
>  directives it is not worth following, then they should file important
>  bugs against polocuy to either have the requirements removed, or the
>  issue resovled by the tech ctte.

I don't like your wording of "not worth following".  A policy dictum
might well be important to follow, but non-conformance may still (always
or in particular cases) not be a reason to exclude it from the release.

But you're of course right that Policy and the release-policy should be
synchronized... 

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

should, ought, must (was: Bug mass filling)

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 
>> Is the word "generally" here an error?  I read this as implying the
>> normal meaning of "should" -- that not everything which violates a
>> "should" mandate is a bug.
>
> I am of the opinion that it is. We can replace non-buggy
>  instances of should by 'ought to be', if needed.

But please don't forget a "legal definition" of those terms.  For me, as
a non-native speaker, I have no idea whether "ought to" is weaker or
stronger than "should", or just something different (and what).

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Bug mass filling

[Andreas Barth]

* Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]:
> If you are aware of issues that are violations of muSt
>  directives that are never going to be RC, there should be a bug
>  opened on policy with severity important for every one of them.

I hope to have time post-etch-release to do that (that is what I meant
with "syncing between policy and release-policy").



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Jean-Christophe Dubacq]

On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote:
> So certain bugs can be marked $STABLE-ignore to allow transient rc
> issues to be ignored for a release and will become no-ops after release.
> Are you suggesting that each package can have a related list of
> non-transient bugs that should be marked (with a new tags called )
> ignore-this-policy-violation where this can be attached to any package
> related bug for any length of time until the issues is deemed
> worthy/necessary to be addressed?

If a rule defining a bug ended in the policy document, it certainly is
worthy of being addressed. As Manoj expressed several times, if a bug
can be ignored for an arbitrary length of time, it certainly should be
a note in the developer reference and not a sentence in the policy
document.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Kevin Mark]

On Tue, Oct 24, 2006 at 04:04:54PM -0700, Steve Langasek wrote:
> On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
> > > 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."
> 
> > Direct mapping of *WHAT*? are you falling into the assumption
> >  that serious == RC? Why?
> 
> Because your choice of mapping blurs the distinction between one-time
> exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy
> violations that the release team does not believe should be promoted to RC
> status at any time in the foreseeable future.  "etch-ignore" is most useful
> as a tag if its use is restricted to those bugs whose
> *non*-release-criticality is transient in nature -- the alternative is that
> the release team is stuck going through the BTS after each release and
> re-adding new tags to those bugs about policy violations whose severity does
> not justify exclusion from the release.
> 
Hi,
So certain bugs can be marked $STABLE-ignore to allow transient rc
issues to be ignored for a release and will become no-ops after release.
Are you suggesting that each package can have a related list of
non-transient bugs that should be marked (with a new tags called )
ignore-this-policy-violation where this can be attached to any package
related bug for any length of time until the issues is deemed
worthy/necessary to be addressed?

pandora-inspired,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Tue, Oct 24, 2006 at 06:48:10PM -0500, Manoj Srivastava wrote:
>> >> If you are aware of issues that are violations of muSt
>> >> directives that are never going to be RC, there should be a bug
>> >> opened on policy with severity important for every one of them.

>> > Why?  If these issues are downgraded to "should"s in policy,
>> > doesn't that again introduce ambiguity about whether a violation
>> > of that particular "should" is a bug, unnecessarily weakening the
>> > overall quality of the distro?

>> Why on earth would there be such an ambiguity? Should violations
>> are bugs, or severity normal.

>   Non-conformance with guidelines denoted by _should_ (or
>   _recommended_) will generally be considered a bug, but will not
>   necessarily render a package unsuitable for distribution.

> Is the word "generally" here an error?  I read this as implying the
> normal meaning of "should" -- that not everything which violates a
> "should" mandate is a bug.

I am of the opinion that it is. We can replace non-buggy
 instances of should by 'ought to be', if needed.

>> And why is the distro quality su=ffering? Aren't the RM's of the
>> opinion that these requirements are not worth following in the
>> first place?

> Hell no.  We're of the opinion that these requirements are not
> grounds for *excluding a package from release* -- but I certainly
> don't think that the release team's stick should be the only reason
> for maintainers to comply with the rules set out in policy!  And I

Well, maintainers ought to be following the should rules as
 well, so there is no reason for the directive to be a must if the bug
 is not deemed serious or a reason to keep the package out of the
 release until it is fixed.

> don't think maintainers should be left to believe that violations of
> certain directives in policy which are unambiguously the correct
> thing to do should be treated as non-bugs, which is what that
> "generally" implies.

Well, we seem to be in agreement here.  However, this change
 (removing generally) needs to  be ratified by a few more people
 before I would be comfortable changing it.

> I also don't think that all "should"s that might not be bugs should
> be automatically shunted to the devref as you suggest, because that
> leaves us with no standardization *process* for policy that we can
> use to get eyeballs on possible bugs in new requirements, AFAICS.

If something is not a requirement, that is, not doing it would
 not be considered a bug -- then it does not belong in the normative
 part of policy.  I think policy should be a minimal document, and
 omething which can be unequivocally taken at face value. It is not
 supposed to be waffling about, nor a thick tome of best practices. It
 is "do this, ot get a bug" book.


It should be easy enough to create a new document that is "it
 is kinda nice if you would do this, but, no worries, no bug on your
 package if you don't" and submit it to a similar process.

I just don't think that document should be conflated with our
 Technical policy.

manoj
-- 
Some people manage by the book, even though they don't know who wrote
the book or even what book.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 18:36:43 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Tue, Oct 24, 2006 at 04:36:52PM -0500, Manoj Srivastava wrote:
>> Since we already feel that our RM's are overworked (hence dunc-tank
>> and payment schemes), I strongly suggest we not add to the RM's
>> burdens any more than we have to.

> This is a laughable suggestion, given that the RMs' time is now
> being taken up defending the longstanding handling of BTS severities
> in this thread, when that is handling is precisely the one that,
> IME, minimizes the amount of work the release team should have to do
> to manually review bug states.

So, you want to be called in for every policy violation bug to
 weigh in on the severity? Sounds like that would increase the
 load. Just answering this question in the affiirmative would stop
 this thread of discussion dead in its tracks.

manoj
-- 
Honi soit la vache qui rit.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Steve Langasek]

On Tue, Oct 24, 2006 at 04:36:52PM -0500, Manoj Srivastava wrote:
> Since we already feel that our RM's are overworked (hence
>  dunc-tank and payment schemes), I strongly suggest we not add to the
>  RM's burdens any more than we have to.

This is a laughable suggestion, given that the RMs' time is now being taken
up defending the longstanding handling of BTS severities in this thread,
when that is handling is precisely the one that, IME, minimizes the amount
of work the release team should have to do to manually review bug states.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Steve Langasek]

On Tue, Oct 24, 2006 at 06:48:10PM -0500, Manoj Srivastava wrote:
> >> If you are aware of issues that are violations of muSt directives
> >> that are never going to be RC, there should be a bug opened on
> >> policy with severity important for every one of them.

> > Why?  If these issues are downgraded to "should"s in policy, doesn't
> > that again introduce ambiguity about whether a violation of that
> > particular "should" is a bug, unnecessarily weakening the overall
> > quality of the distro?

> Why on earth would there be such an ambiguity? Should
>  violations are bugs, or severity normal. 

  Non-conformance with guidelines denoted by _should_ (or _recommended_)
  will generally be considered a bug, but will not necessarily render a
  package unsuitable for distribution.

Is the word "generally" here an error?  I read this as implying the normal
meaning of "should" -- that not everything which violates a "should" mandate
is a bug.

> And why is the distro quality su=ffering? Aren't the RM's of
>  the opinion that these requirements are not worth following in the
>  first place?

Hell no.  We're of the opinion that these requirements are not grounds for
*excluding a package from release* -- but I certainly don't think that the
release team's stick should be the only reason for maintainers to comply
with the rules set out in policy!  And I don't think maintainers should be
left to believe that violations of certain directives in policy which are
unambiguously the correct thing to do should be treated as non-bugs, which
is what that "generally" implies.

I also don't think that all "should"s that might not be bugs should be
automatically shunted to the devref as you suggest, because that leaves us
with no standardization *process* for policy that we can use to get eyeballs
on possible bugs in new requirements, AFAICS.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Hubert Chan]

On Tue, 24 Oct 2006 17:00:45 -0500, Manoj Srivastava <[EMAIL PROTECTED]> said:

> On Tue, 24 Oct 2006 13:49:01 -0400, Hubert Chan <[EMAIL PROTECTED]>
> said:
>> On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava
>> <[EMAIL PROTECTED]> 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."

> Direct mapping of *WHAT*? are you falling into the assumption
> that serious == RC? Why?

No, the previous sentence (which is what we currently have in policy)
defines a mapping of serious bug <=> "must"/"required" directive
violation, and minor/normal/important bug <=> "should"/"recommended"
directive violation, and wishlist bug <=> "optional".  That's the
mapping that it is referring to.

My understanding is that the release team treats that as an approximate
mapping, and the current wording of policy allows this due to the use of
the word "roughly".

("Mapping" may not be the best word to use in policy.  But like I said,
it's a rough draft.)

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 16:18:11 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Tue, Oct 24, 2006 at 04:51:08PM -0500, Manoj Srivastava wrote:
>> > * Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
>> >> Strawman. No one is proosing that; we already have a mechanism
>> >> for making serious bugs non-RC (etch-ignore tags).

>> > Etch-ignore tags are usually used for issues where we expect them
>> > to be RC after etch releases. If we think an issue won't be RC
>> > for etch+1 etc, then adjusting the severity is correct.

>> I would assume violations of policy MUST directives are either bugs
>> in policy, which should be fixed, or an issue in the package that
>> needs to be fixed after etch releases.

>> If you are aware of issues that are violations of muSt directives
>> that are never going to be RC, there should be a bug opened on
>> policy with severity important for every one of them.

> Why?  If these issues are downgraded to "should"s in policy, doesn't
> that again introduce ambiguity about whether a violation of that
> particular "should" is a bug, unnecessarily weakening the overall
> quality of the distro?

Why on earth would there be such an ambiguity? Should
 violations are bugs, or severity normal. 

And why is the distro quality su=ffering? Aren't the RM's of
 the opinion that these requirements are not worth following in the
 first place?

Either the policy dictum has to be followed, and a bug results
 (must - serious; should - normal), or the dictum should be removed
 from policy and moved to, say, dev ref.

manoj

-- 
I can give you my word, but I know what it's worth and you don't. Nero
Wolfe, "Over My Dead Body"
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
>> > 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."

>> Direct mapping of *WHAT*? are you falling into the assumption that
>> serious == RC? Why?

> Because your choice of mapping blurs the distinction between
> one-time exceptions for RCness (e.g., due to GRs for DFSG issues),
> vs. policy violations that the release team does not believe should
> be promoted to RC status at any time in the foreseeable future.
> "etch-ignore" is most useful as a tag if its use is restricted to
> those bugs whose *non*-release-criticality is transient in nature --
> the alternative is that the release team is stuck going through the
> BTS after each release and re-adding new tags to those bugs about
> policy violations whose severity does not justify exclusion from the
> release.

That does not make sense. After etch is released, etch-ignore
 tags are no-ops -- so there is no need to go back and untag anything.

And if there are anyissues that are policy must directives
 that the release team has take upon itself to say are policy
 directives it is not worth following, then they should file important
 bugs against polocuy to either have the requirements removed, or the
 issue resovled by the tech ctte.

This bit about "Oh, lets just ignore policy, for we know
 better" is absolutely the wrong way to go about this.   Fixing policy
 is the right way.

manoj
-- 
Concept, n.: Any "idea" for which an outside consultant billed you
more than $25,000.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Steve Langasek]

On Tue, Oct 24, 2006 at 04:51:08PM -0500, Manoj Srivastava wrote:
> > * Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
> >> Strawman. No one is proosing that; we already have a mechanism for
> >> making serious bugs non-RC (etch-ignore tags).

> > Etch-ignore tags are usually used for issues where we expect them to
> > be RC after etch releases. If we think an issue won't be RC for
> > etch+1 etc, then adjusting the severity is correct.

> I would assume violations of policy MUST directives are either
>  bugs in policy, which should be fixed, or  an issue in the package
>  that needs to be fixed after etch releases.

> If you are aware of issues that are violations of muSt
>  directives that are never going to be RC, there should be a bug
>  opened on policy with severity important for every one of them.

Why?  If these issues are downgraded to "should"s in policy, doesn't that
again introduce ambiguity about whether a violation of that particular
"should" is a bug, unnecessarily weakening the overall quality of the
distro?

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Steve Langasek]

On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
> > 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."

> Direct mapping of *WHAT*? are you falling into the assumption
>  that serious == RC? Why?

Because your choice of mapping blurs the distinction between one-time
exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy
violations that the release team does not believe should be promoted to RC
status at any time in the foreseeable future.  "etch-ignore" is most useful
as a tag if its use is restricted to those bugs whose
*non*-release-criticality is transient in nature -- the alternative is that
the release team is stuck going through the BTS after each release and
re-adding new tags to those bugs about policy violations whose severity does
not justify exclusion from the release.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 13:49:01 -0400, Hubert Chan <[EMAIL PROTECTED]> said: 

> On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava
> <[EMAIL PROTECTED]> 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."

Direct mapping of *WHAT*? are you falling into the assumption
 that serious == RC? Why?

manoj
-- 
Hard work never killed anybody, but why take a chance? Charlie
McCarthy
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 07:21:35 +0200, Andreas Barth <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
>> Strawman. No one is proosing that; we already have a mechanism for
>> making serious bugs non-RC (etch-ignore tags).

> Etch-ignore tags are usually used for issues where we expect them to
> be RC after etch releases. If we think an issue won't be RC for
> etch+1 etc, then adjusting the severity is correct.

I would assume violations of policy MUST directives are either
 bugs in policy, which should be fixed, or  an issue in the package
 that needs to be fixed after etch releases.

If you are aware of issues that are violations of muSt
 directives that are never going to be RC, there should be a bug
 opened on policy with severity important for every one of them.

manoj
-- 
Any discovery is more likely to be exploited by the wicked than
applied by the virtuous.  -- Marion J. Levy, Jr.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 

> Manoj Srivastava writes ("Re: Bug mass filling"):
>> On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek
>> <[EMAIL PROTECTED]> said:
>> > When there are issues addressed in policy that are
>> > black-and-white where all violations of the policy requirement
>> > are definitely bugs, but not all such violations should be
>> > grounds for keeping a package out of a release, how do you
>> > suggest such rules should be handled in the normative language of
>> > policy, and how do you suggest that the related bugs be handled
>> > in the BTS?
>> 
>> Gee. Don't we already have something very like this?
>> 
>> 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]

> There are two different and orthogonal properties of a policy
> requirement:

I posit the second one is not a characteristic of the policy
 requirement; it is a characteristic of the bug.

>   1. Is the requirement applicable in all cases, or are there
>  sometimes overriding reasons to it another way, or exceptional
>  cases where the requirement ought not to apply ?

>   2. Is a violation of the requirement release-critical ?  That is,
>  would it be better to remove the package (or to stick with the
>  old version of the package) than to live with this bug ?

> I'm happy that the policy manual should itself determine the answer
> to the first question; and this is the conventional distinction
> between `must' vs `should'.

> But the second question is much more subtle, and also isn't properly
> decided by the process that maintains the policy manual.  It should
> be probably be decided by the package maintainer in the first
> instance; with the release managers giving both general guidance and
> specific advice, and having the final decision.

Nothing you have said contradicts either what I or aba have
 said; the devil lies in the details you have elided.

My stance is that bug severity tags are tied to policy
 violations, since that can be determined mechanically; violate a must
 directive, bug is serious.  Whether or not all serious bugs are RC is
 anothermatter that the release team determines; hence the *-ignore
 tags.

Andreas is of the opinion we should instead have all serious
 bugs be RC, violations of policy must directives that are not RC
 should be downgraded.

The problem is, since this involves human judgement, one can no
 longer state in policy what category a must violation of policy falls
 into; policy must waffle with well, if you find a policy violation,
 fgiure out what severity the ciolation would be, consult your
 feelings, other peoples feelings, release managers,  and perhaps the
 phase of the moon.

Unlike the decision of whether a seirous bug is RC under my
 proposal, where the word of the RM is law; there is no final
 authority about the severity of a policy violation bug under the
 alternate proposal.  Any maintainer is then free to insist that his
 violation of a bug would not be RC, anyway, and downgrade the bug; it
 would mean that the RM's would have to be brought in every time there
 is a violation of policy.

Since we already feel that our RM's are overworked (hence
 dunc-tank and payment schemes), I strongly suggest we not add to the
 RM's burdens any more than we have to.

manoj
-- 
He gave her a look that you could have poured on a waffle.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Ian Jackson]

Manoj Srivastava writes ("Re: Bug mass filling"):
> On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 
> > When there are issues addressed in policy that are black-and-white
> > where all violations of the policy requirement are definitely bugs,
> > but not all such violations should be grounds for keeping a package
> > out of a release, how do you suggest such rules should be handled in
> > the normative language of policy, and how do you suggest that the
> > related bugs be handled in the BTS?
> 
> Gee. Don't we already have something very like this? 
> 
>  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]

There are two different and orthogonal properties of a policy
requirement:

  1. Is the requirement applicable in all cases, or are there
 sometimes overriding reasons to it another way, or exceptional
 cases where the requirement ought not to apply ?

  2. Is a violation of the requirement release-critical ?  That is,
 would it be better to remove the package (or to stick with
 the old version of the package) than to live with this bug ?

I'm happy that the policy manual should itself determine the answer to
the first question; and this is the conventional distinction between
`must' vs `should'.

But the second question is much more subtle, and also isn't properly
decided by the process that maintains the policy manual.  It should be
probably be decided by the package maintainer in the first instance;
with the release managers giving both general guidance and specific
advice, and having the final decision.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Hubert Chan]

On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED]
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
> Strawman. No one is proosing that; we already have a mechanism
>  for making serious bugs non-RC (etch-ignore tags).

Etch-ignore tags are usually used for issues where we expect them to be
RC after etch releases. If we think an issue won't be RC for etch+1 etc,
then adjusting the severity is correct.



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Mon, 23 Oct 2006 12:30:20 -0400, Hubert Chan <[EMAIL PROTECTED]> said: 

> On Sat, 21 Oct 2006 15:40:28 -0500, Manoj Srivastava
> <[EMAIL PROTECTED]> said:
>> Gee. Don't we already have something very like this?

>> 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]

> Well, it says "... _roughly_ equivalent".  So it seems to me that
> both places (http://www.debian.org/Bugs/Developer and policy section
> 1.1) that attempt to correlate policy violations and bug severity do
> so with some hedging, and do not try to define a direct mapping.

Err, you seem to be assuming that there is a direct mapping
 between bug severity and RC-ness, which is not the case.

> 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.

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.

manoj
-- 
"I only touch base with reality on an as-needed basis!" Royal Floyd
Mengot (Klaus)
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Mon, 23 Oct 2006 12:05:09 +0200, Gabor Gombas <[EMAIL PROTECTED]> said: 

> On Sun, Oct 22, 2006 at 10:48:26PM -0700, Russ Allbery wrote:
>> I don't think using any non-POSIX feature should be a policy
>> violation, probably.  There are some that are in such widespread
>> use and are supported by all shells that weren't written
>> specifically as test suites that I think it's worthwhile making an
>> exception for them.  But using general bash features in /bin/sh
>> scripts really do break real systems.

> How about instead of speaking about POSIX, policy should just list
> the shells that are officially supported as /bin/sh? There is no
> need listing every shell, just a representative subset: bash
> (obviously), dash (it's popular) and an other "minimalistic" shell
> (posh?) to prevent allowing everything & the kitchen sink if dash
> starts to rapidly acquire new features.

> If a maintainer script does not work with a shell on the list ->
> serious bug, if it does not work with some other shell -> wishlist
> bug.

Policy is a slowly changing document, so it was deemed too
 much of a burden  for the list of shells to be maintained in policy;
 but I have no fundamental objections to this approach.

manoj
-- 
Refreshed by a brief blackout, I got to my feet and went next
door. Martin Amis, _Money_
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Sun, 22 Oct 2006 22:48:26 -0700, Russ Allbery <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> I personally think that maintainer scripts should allow for /bin/sh
>> to be not bash; or there should be documentation to the effect that
>> non bash /bin/sh is not supported.

> People actually use non-bash shells as /bin/sh and I get real bugs
> filed against my packages when this doesn't work.  (Usually they're
> using ash instead.)  The recent effort to speed up the boot process
> also achieved noticable gains by switching from bash to ash, so I
> expect that will prompt more people to try this.

> I don't think using any non-POSIX feature should be a policy
> violation, probably.  There are some that are in such widespread use
> and are supported by all shells that weren't written specifically as
> test suites that I think it's worthwhile making an exception for
> them.  But using general bash features in /bin/sh scripts really do
> break real systems.

refinement of the policy language is always welcome.

>> This is tension between quality of implementation (making sure that
>> maintianer scripts do not fall on their faces wehen the user takes
>> the supported action of chaning /bin/sh, and the new fangled rush
>> to push things out on time, ready or not, that makes such bugs non
>> RC.

>> I still think we should go for quality of implementation.

>> I also seem to be a minority in this regard.

> I think it's reasonable to make some tradeoffs between release
> quality and making a formal release that is a substantial
> improvement over stable.  If we try to get *everything*, we're
> basically leaving people with stable and all of the RC bugs that
> were already in stable and have since been discovered.

Strawman. No one is proosing that; we already have a mechanism
 for making serious bugs non-RC (etch-ignore tags).

manoj
-- 
We have phasers, I vote we blast 'em! Bailey, "The Corbomite
Maneuver", stardate 1514.2
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Hubert Chan]

On Sat, 21 Oct 2006 15:40:28 -0500, Manoj Srivastava <[EMAIL PROTECTED]> said:

> Gee. Don't we already have something very like this?

>  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]

Well, it says "... _roughly_ equivalent".  So it seems to me that both
places (http://www.debian.org/Bugs/Developer and policy section 1.1)
that attempt to correlate policy violations and bug severity do so with
some hedging, and do not try to define a direct mapping.

Given the amount of confusion on the issue (the single word "roughly" is
easily missed), I think that it would be a good idea to either update
policy so that "must"/"required" violations correspond exactly to the
release team's definition of release-critical, or to change the wording
to make it more explicit that a "must"/"required" violation is not
necessarily release-critical.

For the second option, (a very rough draft of) possible changed wording
for www.debian.org/Bugs/Developer is:

  serious
is a severe violation of Debian policy (roughly, it violates a
"must" or "required" directive, although the severity of a policy
violation is determined by the release managers), or, in the ...

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.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Matthias Julius]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> How about instead of speaking about POSIX, policy should just list the
> shells that are officially supported as /bin/sh? There is no need
> listing every shell, just a representative subset: bash (obviously),
> dash (it's popular) and an other "minimalistic" shell (posh?) to prevent
> allowing everything & the kitchen sink if dash starts to rapidly acquire
> new features.

You could say the script _should_ be POSIX compliant and _must_ work
with bash, dash, ash...

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Bruce Sass]

On Sun October 22 2006 23:22, Manoj Srivastava wrote:
> I still think we should go for quality of implementation.
>
> I also seem to be a minority in this regard.

I sincerely hope not.

> If the project feels that we should downgrade policy not to
>  set our maintainer scripts to allow for the admin to set /bin/sh to
>  be not bash, they can file a bug on policy, and so indicate their
>  belief on the bug reprot; I'll reluctantly degrade policy.

As long as Debian allows alternatives to /bin/sh -> /bin/bash, the only 
bugs which should be filed, afaict, are those against packages whose 
scripts specify /bin/sh and fail to work with any "sh" but bash... 
clearly they are buggy and should be specifying /bin/bash as their 
command interpreter.


- Bruce


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Gabor Gombas]

On Sun, Oct 22, 2006 at 10:48:26PM -0700, Russ Allbery wrote:

> I don't think using any non-POSIX feature should be a policy violation,
> probably.  There are some that are in such widespread use and are
> supported by all shells that weren't written specifically as test suites
> that I think it's worthwhile making an exception for them.  But using
> general bash features in /bin/sh scripts really do break real systems.

How about instead of speaking about POSIX, policy should just list the
shells that are officially supported as /bin/sh? There is no need
listing every shell, just a representative subset: bash (obviously),
dash (it's popular) and an other "minimalistic" shell (posh?) to prevent
allowing everything & the kitchen sink if dash starts to rapidly acquire
new features.

If a maintainer script does not work with a shell on the list -> serious
bug, if it does not work with some other shell -> wishlist bug.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Russ Allbery]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> I personally think that maintainer scripts should allow for
>  /bin/sh to be not bash; or there should be documentation to the
>  effect that non bash /bin/sh is not supported.

People actually use non-bash shells as /bin/sh and I get real bugs filed
against my packages when this doesn't work.  (Usually they're using ash
instead.)  The recent effort to speed up the boot process also achieved
noticable gains by switching from bash to ash, so I expect that will
prompt more people to try this.

I don't think using any non-POSIX feature should be a policy violation,
probably.  There are some that are in such widespread use and are
supported by all shells that weren't written specifically as test suites
that I think it's worthwhile making an exception for them.  But using
general bash features in /bin/sh scripts really do break real systems.

> This is tension between quality of implementation (making sure
>  that maintianer scripts do not fall on their faces wehen the user
>  takes the supported action of chaning /bin/sh, and the new fangled
>  rush to push things out on time, ready or not, that makes such bugs
>  non RC.

> I still think we should go for quality of implementation.

> I also seem to be a minority in this regard.

I think it's reasonable to make some tradeoffs between release quality and
making a formal release that is a substantial improvement over stable.  If
we try to get *everything*, we're basically leaving people with stable and
all of the RC bugs that were already in stable and have since been
discovered.  There are some policy violations (such as ensuring every
package has binary-arch and binary-indep targets) that require a *lot* of
package maintainer bugging and NMUs.  I think it's reasonable to tackle a
few of those for each release, and probably biting off more than we can
chew to try to tackle every one of them for a given release.

But, this does require that we try to prevent backsliding, and if we've
done a big push to get rid of a policy violation, we should keep that
violation RC for subsequent releases.

If it's not important enough to go fix every package that has the problem,
I think we should question whether it's correct to have it be a
requirement in policy.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Mon, 23 Oct 2006 12:24:29 +1000, Anthony Towns  
said: 

> On Sat, Oct 21, 2006 at 07:39:47PM -0500, Manoj Srivastava wrote:
>> > Is a bashism in a /bin/sh script a normal bug ("should only use
>> > POSIX features"), or a RC bug ("the appropriate shell bust be
>> > specified")? It's much easier to work out by just looking at the
>> > rc_policy text file maintained by the RM team [1].
>> Neither. It is a non RC serious bug.

> No, it's not. It's a minor/normal bug in the package, and a bug in
> policy that it's implied to be a serious bug.

Can you point me to the bug number of the policy bug?

I personally think that maintainer scripts should allow for
 /bin/sh to be not bash; or there should be documentation to the
 effect that non bash /bin/sh is not supported.

This is tension between quality of implementation (making sure
 that maintianer scripts do not fall on their faces wehen the user
 takes the supported action of chaning /bin/sh, and the new fangled
 rush to push things out on time, ready or not, that makes such bugs
 non RC.

I still think we should go for quality of implementation.

I also seem to be a minority in this regard.

If the project feels that we should downgrade policy not to
 set our maintainer scripts to allow for the admin to set /bin/sh to
 be not bash, they can file a bug on policy, and so indicate their
 belief on the bug reprot; I'll reluctantly degrade policy.

manoj
-- 
"How many teamsters does it take to screw in a light bulb?" "FIFTEEN!!
YOU GOT A PROBLEM WITH THAT?"
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Anthony Towns]

On Sat, Oct 21, 2006 at 07:39:47PM -0500, Manoj Srivastava wrote:
> > Is a bashism in a /bin/sh script a normal bug ("should only use
> > POSIX features"), or a RC bug ("the appropriate shell bust be
> > specified")? It's much easier to work out by just looking at the
> > rc_policy text file maintained by the RM team [1].
> Neither. It is a non RC serious bug.

No, it's not. It's a minor/normal bug in the package, and a bug in policy
that it's implied to be a serious bug.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug mass filling

[Russ Allbery]

(Yes, I'm on vacation, and really am still on vacation, but I had a brief
check-in moment and happened to see this thread.  Note that I probably
won't see responses, unless I get to them tomorrow night, until the
beginning of November.)

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> I have just run lintian on all the archive (amd64) for both binaries and
> sources, and the results are a bit scary. It looks like a lot of
> maintainers are uploading their packages, and don't really care with the
> policy.

> Maybe some errors (E:) of lintian could be changed to critical (C:) and
> uploads containing such critical errors be refused by dak? What do you
> think?

Please note that lintian considers *any* violation of policy, even things
that in practice won't cause problems, to be worthy of E:.  In this
particular case:

> Among all of the bugs reported by lintian, one concerns a lot of
> packages, the presence of the clean, binary, binary-arch, binary-indep
> and build targets. This is required by both the section 4.9 of the
> policy and the Etch release standards [1]. Here is the list of affected
> packages. What to do with them?

what's generally going on is that the package builds only arch-dependent
or arch-independent packages and therefore the missing target is a no-op.
Due to the way that the autobuilders work and the normal package building
tools work, in practice this will almost never be noticed.  However,
policy *does* require that the targets exist, so lintian dutifully
diagnoses the problem.

Another common lintian error that doesn't cause problems in practice (now)
is that lintian intentionally does not take transitive dependencies into
account when checking package dependencies and build dependencies.  This
means that if, for instance, your debian/rules calls a program from
po-debconf, lintian will complain if you don't build-depend on po-debconf,
even if you're already build-depending on debhelper which in turn
build-depends on po-debconf.  This is because reliance on transitive
dependencies in general creates dormant RC bugs.  If for some reason (and
I realize that this is unlikely, but one can construct reasons why it
might happen) debhelper drops or downgrades its dependency on po-debconf,
all those packages that just relied on debhelper to pull in po-debconf
immediately are RC-buggy.  Adding an explicit dependency is easy and
avoids this problem.

(If, however, a package is *defined* as being equivalent to depending on
another package, I'm willing to teach lintian about those special cases,
the same as how it handles virtual packages like c-shell now.)

I've put a lot of work into lintian over the past six months focused
specifically on eliminating false positives, so I'd love it if people
would run the unstable lintian regularly on packages and report as bugs
any false positives that don't look unavoidable.  (lintian -i will often
give you clues as to whether the false positive is unavoidable; if lintian
-i specifically recommends an override, that generally means that the
lintian maintainers believe it infeasible to entirely avoid false
positives there.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Sun, 22 Oct 2006 09:28:54 +1000, Anthony Towns  
said: 

> On Sat, Oct 21, 2006 at 03:40:28PM -0500, Manoj Srivastava wrote:
>> Gee. Don't we already have something very like this?

>> 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]

> Those classifications haven't been monitored or updated, so no, we
> don't.

Yes, we do. You seem to be conflating the severity and RC-ness
 of a bug --  bugs have severities, and the release team decides which
 bugs are RC or not.

> IIRC that changed pretty soon after woody's release, with the
> creation of a specific list of RC criteria maintained by the release
> team. The woody policy addenda [0], for instance, said:

>   Bashisms generally aren't release-critical, even when they're
>   in scripts marked #!/bin/sh. They may be release-critical if
>   their breakage causes other problems that are release-critical
>   if they ever happen.

> In contrast, policy still states:

>  Thus, shell scripts specifying `/bin/sh' as interpreter should
>  only use POSIX features.  If a script requires non-POSIX
>  features from the shell interpreter, the appropriate shell must
>  be specified in the first line of the script (e.g.,
>  `#!/bin/bash')

> Is a bashism in a /bin/sh script a normal bug ("should only use
> POSIX features"), or a RC bug ("the appropriate shell bust be
> specified")? It's much easier to work out by just looking at the
> rc_policy text file maintained by the RM team [1].

Neither. It is a non RC serious bug.

manoj
-- 
Quod erat demonstrandum. [Thus it is proven.  For those who wondered
WTF QED means.]
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Anthony Towns]

On Sat, Oct 21, 2006 at 03:40:28PM -0500, Manoj Srivastava wrote:
> Gee. Don't we already have something very like this? 

>  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]

Those classifications haven't been monitored or updated, so no, we don't.

IIRC that changed pretty soon after woody's release, with the creation of
a specific list of RC criteria maintained by the release team. The woody
policy addenda [0], for instance, said:

Bashisms generally aren't release-critical, even when they're in
scripts marked #!/bin/sh. They may be release-critical if their
breakage causes other problems that are release-critical if they
ever happen.

In contrast, policy still states:

 Thus, shell scripts specifying `/bin/sh' as interpreter should only
 use POSIX features.  If a script requires non-POSIX features from the
 shell interpreter, the appropriate shell must be specified in the
 first line of the script (e.g., `#!/bin/bash')

Is a bashism in a /bin/sh script a normal bug ("should only use POSIX
features"), or a RC bug ("the appropriate shell bust be specified")? It's
much easier to work out by just looking at the rc_policy text file
maintained by the RM team [1].

Cheers,
aj

[0] http://people.debian.org/~ajt/woody_policy_addenda.txt
[1] http://release.debian.org/etch_rc_policy.txt



signature.asc
Description: Digital signature

Re: Bug mass filling

[Don Armstrong]

On Sat, 21 Oct 2006, Petter Reinholdtsen wrote:
> [Don Armstrong]
> > Well, once I wake up a bit, you'll be able to go:
> >
> > Package: foopkg
> > User: username
> > Usertags: fooblehtag,bartag
> >
> > [But it won't work for setting multiple users... to do that, you'll
> > have to use control.]
> 
> This is even better.  Is there a web page documenting this new
> feature?  I would like to point the debian-edu developers to it.

Documentation? What's that?

It'll show up on http://www.debian.org/Bugs/Reporting once wml gets
rebuilt.


Don Armstrong
 
-- 
The sheer ponderousness of the panel's opinion ... refutes its thesis
far more convincingly than anything I might say. The panel's labored
effort to smother the Second Amendment by sheer body weight has all
the grace of a sumo wrestler trying to kill a rattlesnake by sitting
on it--and is just as likely to succeed.
 -- Alex Kozinski in Silveira V Lockyer

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
>> > That's not correct. [serious, grave, and critical] are the
>> > "release critical" severities, though some release critical
>> > issues won't be fixed for any given release, due to either being
>> > not known about or understood (ie, not filed at all, or not given
>> > the appropriate severity or attention), or given a specific
>> > exemption by the release team ("etch-ignore").

>> So riddle me this: currently, policy states that violating a "must"
>> or "required" directive in policy is a serious bug; which seems to
>> fly in the face of the release process having appropriated the
>> "serious" severity.

>> Are we removing the policy that violations of policy requirements
>> are serious bugs?  Is there new guidance on what policy violation
>> bug severities ought to be?  Are such bugs to be filed under
>> "normal"? Or "important"?

>> My understanding, which seems to be flawed, was policy violations
>> were taken seriously (heh), and policy violation meant to be
>> ignored for a release were granted special dispensation (remained
>> serious, but were exempt).

>> If this is not the case, we should change the policy, and drop any
>> reference to bug severities for packages violating policy.
>> Personally, think that is not a good idea, since adherence to
>> technical policy seems to be the underpinning of the high quality
>> of implementation we always had, but perhaps my mileage has varied.

> When there are issues addressed in policy that are black-and-white
> where all violations of the policy requirement are definitely bugs,
> but not all such violations should be grounds for keeping a package
> out of a release, how do you suggest such rules should be handled in
> the normative language of policy, and how do you suggest that the
> related bugs be handled in the BTS?

Gee. Don't we already have something very like this? 

 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]

All critical and grave bugs are release critical, and most
 serious bugs too. Any serious but which is non RC is tagged
 -ignore; and the ignore tag should only be set after
 consultation with the release managers.

> How should we distinguish this case from rules that are *generally*
> but not always an indication of a bug (policy's description of
> "should"), and from one-time exception grants by the release team
> (the current use of the "-ignore" tag)?

No one ever indicated that violations of a policy should
 directive is release critical, or even serious. Are you suggesting we
 should make _any_ policy violation the same?

Curently, violating a should policy directive means you get a
 "normal" severuty bug.

> The current handling sanctioned by the BTS admins seems an
> appropriate middle ground for distinguishing the cases that are most
> relevant to bug handling across releases.

It muddies up the nice, clean distinction that has always been
 in out technical policy: 

 a) MUST/REQUIRED violation: serious bug
If ignored
  a1) not RC
else
 a2) RC
 b) SHOULD violation
normal bug
 c) MAY/SUGGESTED violation
wishlist bug

manoj
-- 
If only you knew she loved you, you could face the uncertainty of
whether you love her.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Petter Reinholdtsen]

[Don Armstrong]
> Well, once I wake up a bit, you'll be able to go:
>
> Package: foopkg
> User: username
> Usertags: fooblehtag,bartag
>
> [But it won't work for setting multiple users... to do that, you'll
> have to use control.]

This is even better.  Is there a web page documenting this new
feature?  I would like to point the debian-edu developers to it.

Friendly,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Amaya]

Anthony Towns wrote:
> Please hold off on filing them for a few days, so I can add
> usertag-on-submit support to debbugs, so that it should be possible to
> automatically track this stuff, and easily avoid filing duplicate bugs
> if they're not fixed the next time bugs get filed.

Thanks, AJ. That is just what I was about to ask for :)


-- 
  ·''`. If I can't dance to it, it's not my revolution
 : :' :-- Emma Goldman
 `. `'   Proudly running Debian GNU/Linux (unstable)
   `- www.amayita.com  www.malapecora.com  www.chicasduras.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Amaya]

Miriam Ruiz wrote:
> Why don't we all try to calm down and get less paranoid?

I hope there are big Finnish saunas in Edinburgh. 
I think we all need to gather for a hot sauna next DebConf.

We should change this "you can't flame people you have had sauna with"
to "you can't flame me until you've had sauna with me" :)

> Most of us are nice people with just strong feelings about their
> ideas, but I guess it might be nice for all of us to learn how to
> empathyse and respect other's ideas, and think for a moment that other
> people might also good reasons for them, as not everything is black or
> white.

What I do as an exercise in order to improve the skills you mention,
empathy, respect, the feel of pleasure from working with others, is to
work with the people I sponsor. 

They provide manpower and skills I lack, they fix bugs I have no time to
look at, while I learn from them as they learn from me. I make mistakes
they forgive me for, they make mistakes I can help them fix. It is
something I encourage you all to do. Take a sponsoree and be his/her
mentor. It's good for the karma.

-- 
  ·''`. If I can't dance to it, it's not my revolution
 : :' :-- Emma Goldman
 `. `'   Proudly running Debian GNU/Linux (unstable)
   `- www.amayita.com  www.malapecora.com  www.chicasduras.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Don Armstrong]

On Sat, 21 Oct 2006, Andreas Barth wrote:
> * Don Armstrong ([EMAIL PROTECTED]) [061021 09:54]:
> > On Sat, 21 Oct 2006, Christian Perrier wrote:
> > > > Please hold off on filing them for a few days, so I can add
> > > > usertag-on-submit support to debbugs, so that it should be possible to
> > >   ^^
> > > 
> > > *that* will be a great feature..:)
> > 
> > This should "in theory" be working now.
> > 
> > Usertag: fooblehtag
> > 
> > should set the fooblehtag of the user sending the mail.
> 
> How can I set usertags of another user (or rather roleaccount) during
> submission?

Well, once I wake up a bit, you'll be able to go:

Package: foopkg
User: username
Usertags: fooblehtag,bartag

[But it won't work for setting multiple users... to do that, you'll
have to use control.]


Don Armstrong

-- 
In all matters of government, the correct answer is usually: "Do
nothing"
 -- Robert Heinlein _Time Enough For Love_ p428

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Don Armstrong ([EMAIL PROTECTED]) [061021 09:54]:
> On Sat, 21 Oct 2006, Christian Perrier wrote:
> > > Please hold off on filing them for a few days, so I can add
> > > usertag-on-submit support to debbugs, so that it should be possible to
> >   ^^
> > 
> > *that* will be a great feature..:)
> 
> This should "in theory" be working now.
> 
> Usertag: fooblehtag
> 
> should set the fooblehtag of the user sending the mail.

How can I set usertags of another user (or rather roleaccount) during
submission?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Don Armstrong]

On Sat, 21 Oct 2006, Christian Perrier wrote:
> > Please hold off on filing them for a few days, so I can add
> > usertag-on-submit support to debbugs, so that it should be possible to
>   ^^
> 
> *that* will be a great feature..:)

This should "in theory" be working now.

Usertag: fooblehtag

should set the fooblehtag of the user sending the mail.


Don Armstrong

-- 
If a nation values anything more than freedom, it will lose its
freedom; and the irony of it is that if it is comfort or money it
values more, it will lose that, too.
 -- W. Somerset Maugham

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Christian Perrier]

> Please hold off on filing them for a few days, so I can add
> usertag-on-submit support to debbugs, so that it should be possible to
  ^^

*that* will be a great feature..:)




signature.asc
Description: Digital signature

Re: Bug mass filling

[Kevin Mark]

On Fri, Oct 20, 2006 at 05:18:41PM -0700, Steve Langasek wrote:
> On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
> > > That's not correct. [serious, grave, and critical] are the "release
> > > critical" severities, though some release critical issues won't be
> > > fixed for any given release, due to either being not known about or
> > > understood (ie, not filed at all, or not given the appropriate
> > > severity or attention), or given a specific exemption by the release
> > > team ("etch-ignore").
> 
> > So riddle me this: currently, policy states that violating a
> >  "must" or "required" directive in policy is a serious bug; which
> >  seems to fly in the face of the release process having appropriated
> >  the "serious" severity.
> 
> > Are we removing the policy that violations of policy
> >  requirements are serious bugs?  Is there new guidance on what policy
> >  violation bug severities ought to be?  Are such bugs to be filed
> >  under "normal"? Or "important"?
> 
> > My understanding, which seems to be flawed, was policy
> >  violations were taken seriously (heh),  and policy violation meant to
> >  be ignored for a release were granted special dispensation (remained
> >  serious, but were exempt).
> 
> > If this is not the case, we should change the policy, and drop
> >  any reference to bug severities for packages violating policy.
> >  Personally, think that is not a good idea, since adherence to
> >  technical policy seems to be the underpinning of the high quality of
> >  implementation we always had, but perhaps my mileage has varied.
> 
> When there are issues addressed in policy that are black-and-white where all
> violations of the policy requirement are definitely bugs, but not all such
> violations should be grounds for keeping a package out of a release, how do
> you suggest such rules should be handled in the normative language of
> policy, and how do you suggest that the related bugs be handled in the BTS?
> How should we distinguish this case from rules that are *generally* but not
> always an indication of a bug (policy's description of "should"), and from
> one-time exception grants by the release team (the current use of the
> "-ignore" tag)?
> 
> The current handling sanctioned by the BTS admins seems an appropriate
> middle ground for distinguishing the cases that are most relevant to bug
> handling across releases.
> 
Hi Steve,
One of Debian's principal attributes is openness, as with all FLOSS
projects. With each release, would it useful to have, in addition to the
Release notes, a _document_ like this:

$RELEASE_NAME-ignore list:
===
PACKAGE|BUG NUMBER|BUG DESCIPTION  |REASON FOR IGNORING 
ISSUE[|OPTIONAL_NAME|OPTIONAL_DATE]
foo| 1234 | deletes db on mips | no one uses it on mips   | joe RM  
| 01-01-1969
foo| 1234 | deletes db on mips | happens only on sundays  | jane RM 
| 01-02-1969
===

so that users, sysadmin and such could see what issue may affect them.

Similarly,
this document could _first_ be started as a _wiki page_ which could be
generated from the current BTS info and during the release the RM's
could have a location where they can state their reasons and then the
package maintainer can have a centralized place for this info and an
easy way to see and comment upon it.

Because it seems that release issues between package maintainers and
release managers happens in various place and have conflicting or subtly
different answers depending upon person asked, when asked, etc. So a
solid single point of update would seem to at least address some of this
so that if 2 people or RM's give what seems to be confusing or
contradictory info, it would have a single place to reference, where
this would be easily seen by all involved.
happy cat hurding,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Bug mass filling

[Steve Langasek]

On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
> > That's not correct. [serious, grave, and critical] are the "release
> > critical" severities, though some release critical issues won't be
> > fixed for any given release, due to either being not known about or
> > understood (ie, not filed at all, or not given the appropriate
> > severity or attention), or given a specific exemption by the release
> > team ("etch-ignore").

> So riddle me this: currently, policy states that violating a
>  "must" or "required" directive in policy is a serious bug; which
>  seems to fly in the face of the release process having appropriated
>  the "serious" severity.

> Are we removing the policy that violations of policy
>  requirements are serious bugs?  Is there new guidance on what policy
>  violation bug severities ought to be?  Are such bugs to be filed
>  under "normal"? Or "important"?

> My understanding, which seems to be flawed, was policy
>  violations were taken seriously (heh),  and policy violation meant to
>  be ignored for a release were granted special dispensation (remained
>  serious, but were exempt).

> If this is not the case, we should change the policy, and drop
>  any reference to bug severities for packages violating policy.
>  Personally, think that is not a good idea, since adherence to
>  technical policy seems to be the underpinning of the high quality of
>  implementation we always had, but perhaps my mileage has varied.

When there are issues addressed in policy that are black-and-white where all
violations of the policy requirement are definitely bugs, but not all such
violations should be grounds for keeping a package out of a release, how do
you suggest such rules should be handled in the normative language of
policy, and how do you suggest that the related bugs be handled in the BTS?
How should we distinguish this case from rules that are *generally* but not
always an indication of a bug (policy's description of "should"), and from
one-time exception grants by the release team (the current use of the
"-ignore" tag)?

The current handling sanctioned by the BTS admins seems an appropriate
middle ground for distinguishing the cases that are most relevant to bug
handling across releases.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Sat, 21 Oct 2006 06:27:24 +1000, Anthony Towns  
said: 

> On Fri, Oct 20, 2006 at 04:06:05AM -0500, Manoj Srivastava wrote:
>> > Even then, it's only "serious" if it violates the release policy
>> > [http://release.debian.org/etch_rc_policy.txt]. Hence the reason
>> > that
>> No. A bug may be serious and yet not RC, as I understand it.

> That's not correct. [serious, grave, and critical] are the "release
> critical" severities, though some release critical issues won't be
> fixed for any given release, due to either being not known about or
> understood (ie, not filed at all, or not given the appropriate
> severity or attention), or given a specific exemption by the release
> team ("etch-ignore").

So riddle me this: currently, policy states that violating a
 "must" or "required" directive in policy is a serious bug; which
 seems to fly in the face of the release process having appropriated
 the "serious" severity.

Are we removing the policy that violations of policy
 requirements are serious bugs?  Is there new guidance on what policy
 violation bug severities ought to be?  Are such bugs to be filed
 under "normal"? Or "important"?

My understanding, which seems to be flawed, was policy
 violations were taken seriously (heh),  and policy violation meant to
 be ignored for a release were granted special dispensation (remained
 serious, but were exempt).

If this is not the case, we should change the policy, and drop
 any reference to bug severities for packages violating policy.
 Personally, think that is not a good idea, since adherence to
 technical policy seems to be the underpinning of the high quality of
 implementation we always had, but perhaps my mileage has varied.

manoj
-- 
The happiest time of a person's life is after his first
divorce. J.K. Galbraith
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Aurelien Jarno ([EMAIL PROTECTED]) [061021 00:37]:
> Anthony Towns a écrit :
> >On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote:
> >>Maybe some errors (E:) of lintian could be changed to critical (C:) and
> >>uploads containing such critical errors be refused by dak? What do you
> >>think?
> >
> >AFAIK dak doesn't support this? Does "C:" exist?
> 
> No AFAIK dak doesn't support that. It was actually a suggestion, I don't 
> know if it is easy to add. C: also does not exists, but it's really easy 
> to implement in lintian. Anyway which bugs are errors (E:) or critical 
> (C:) has to be decided in accordance with the release team.
> 
> My idea with an automated test at upload is that we can use the time 
> used to find such policy violations to find more complex bugs, and 
> therefore improve the quality of the distribution.

That sounds like a worthwhile idea to me - one of the first things we
should do post-etch probably.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Aurelien Jarno]

Anthony Towns a écrit :

On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote:

Maybe some errors (E:) of lintian could be changed to critical (C:) and
uploads containing such critical errors be refused by dak? What do you
think?


AFAIK dak doesn't support this? Does "C:" exist?


No AFAIK dak doesn't support that. It was actually a suggestion, I don't 
know if it is easy to add. C: also does not exists, but it's really easy 
to implement in lintian. Anyway which bugs are errors (E:) or critical 
(C:) has to be decided in accordance with the release team.


My idea with an automated test at upload is that we can use the time 
used to find such policy violations to find more complex bugs, and 
therefore improve the quality of the distribution.



Among all of the bugs reported by lintian, one concerns a lot of
packages, the presence of the clean, binary, binary-arch, binary-indep 
and build targets. This is required by both the section 4.9 of the

policy and the Etch release standards [1]. Here is the list of affected
packages. What to do with them?


Please hold off on filing them for a few days, so I can add
usertag-on-submit support to debbugs, so that it should be possible to
automatically track this stuff, and easily avoid filing duplicate bugs
if they're not fixed the next time bugs get filed.


Ok, please let me know when it's ready.

Bye,
Aurelien

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Anthony Towns]

On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote:
> Maybe some errors (E:) of lintian could be changed to critical (C:) and
> uploads containing such critical errors be refused by dak? What do you
> think?

AFAIK dak doesn't support this? Does "C:" exist?

> Among all of the bugs reported by lintian, one concerns a lot of
> packages, the presence of the clean, binary, binary-arch, binary-indep 
> and build targets. This is required by both the section 4.9 of the
> policy and the Etch release standards [1]. Here is the list of affected
> packages. What to do with them?

Please hold off on filing them for a few days, so I can add
usertag-on-submit support to debbugs, so that it should be possible to
automatically track this stuff, and easily avoid filing duplicate bugs
if they're not fixed the next time bugs get filed.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Bug mass filling

[Anthony Towns]

On Fri, Oct 20, 2006 at 04:06:05AM -0500, Manoj Srivastava wrote:
> > Even then, it's only "serious" if it violates the release policy
> > [http://release.debian.org/etch_rc_policy.txt]. Hence the reason
> > that
> No. A bug may be serious and yet not RC, as I understand it.

That's not correct. [serious, grave, and critical] are the "release
critical" severities, though some release critical issues won't be
fixed for any given release, due to either being not known about or
understood (ie, not filed at all, or not given the appropriate severity
or attention), or given a specific exemption by the release team
("etch-ignore").

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug mass filling

[Miriam Ruiz]

Why don't we all try to calm down and get less paranoid?

I don't think anyone's trying to piss off anyone, so I think we should all try
to take it less personal. We probably all have different priorities, different
goals and different ideas on how to achieve them, and I don't think anyone's
making proposals, asking questions or giving anwers with the purpose of making
anyone feel bad, that would be too presumptuous to think.

I'm lately seeing too many people getting so upset as to orphan their
packages, leave the project, too many insults everywhere or getting paranoid
about every single suggestion it is made. I think most of that is just caused
by the nerves, and after the release everythink will calm down.

Most of us are nice people with just strong feelings about their ideas, but I
guess it might be nice for all of us to learn how to empathyse and respect
other's ideas, and think for a moment that other people might also good
reasons for them, as not everything is black or white.

Miry




__ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Manoj Srivastava]

On Thu, 19 Oct 2006 18:49:09 +0100, Adam D Barratt <[EMAIL PROTECTED]> said: 

> On Thu, 2006-10-19 at 10:00 -0700, Kevin B. McCarty wrote:
>> Tshepang Lekhonkhobe wrote:
>> 
>> > Doesn't policy violation warrant Critical severity?
>> 
>> No, it "only" warrants the lowest RC severity, serious [0], unless
>> the bug in addition makes the package or other software (mostly)
>> unusable, causes data loss, or introduces a security hole.

> Even then, it's only "serious" if it violates the release policy
> [http://release.debian.org/etch_rc_policy.txt]. Hence the reason
> that

No. A bug may be serious and yet not RC, as I understand it.

manoj

-- 
A hacker does for love what others would not do for money.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Tshepang Lekhonkhobe]

On 10/19/06, Mike Hommey <[EMAIL PROTECTED]> wrote:

Waw, actually, i was trying to be less aggressive...

Anyways, since I'm too pissed and since I see no reason to put myself in
that mood any further, I'm taking a few days off Debian, which means my
current work on seamonkey^Hiceape will be on hold. All the work in
progress on my currently maintained packages will be on hold too.

If you want iceape in shape for etch if we are anything near a freeze,
well, get your fingers out of your asses, as we say in french.


I would take it out if it was in there, but please don't be pissed off
so soon. Continue hacking away and let's have the best release ever
:-) I really want to see Seamonkey in Etch, and you even asked the
RM's to allow you to upload it (version 1.1) when released later this
month.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Don Armstrong]

On Thu, 19 Oct 2006, Kevin Mark wrote:
> DD's trying to use Debian policy as a guide to make all packages
> pass policy requirement. Is this not what they are tasked to do?

There's nothing wrong with these goals. Indeed, I'm sure no one would
object to patches and bugs being filed to fix these policy issues.

The only question is whether the bugs are RC or not. The RMs have the
ability to determine which policy issues are RC; the people who can
override their decision (by making other bugs RC) are the maintainers
for a particular package, by deciding that a particular package is not
fit for release.

Otherwise, when the RMs have clarified the release policy (as they
have just done), then we should go back to fixing bugs instead of
arguing about whether or not the bugs are really all that bad or not.


Don Armstrong

-- 
Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
 -- Antoine de Saint-Exupe'ry, Terres des Hommes

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Steve Langasek]

On Thu, Oct 19, 2006 at 10:52:25PM +0200, Mike Hommey wrote:
> On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
> > > [another agression]

> Waw, actually, i was trying to be less aggressive...

This is a very, very old argument, and it doesn't really come across to me
as less aggressive to continue to suggest that the RMs are "changing the
rules" to meet the release deadline, or even that it will *appear* that we
are doing so, when these are rules that have governed the use of RC
severities in the BTS for at least the past three years and are explicitly
sanctioned by the BTS admins.

So I'm sorry that this upsets you, but it's not exactly the release team's
fault if people are inferring things from the BTS documentation that aren't
written there.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Kevin Mark]

On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
> > [another agression]
> 
> Sorry, but enough is enough. I'm fed up about your sudden agressions
> towards me for no reason at all. Welcome to my killfile.
> 
> 
Hi Andi,
from my perspective, I see this:
DD's trying to use Debian policy as a guide to make all packages pass
policy requirement. Is this not what they are tasked to do ? They see
inconsistencies between RM's understanding of these and their goals. And
they seem to say that if someone would alter, fix, change or clarify
policy, they could have a clear goal for them to reach release targets.
This way they would not be confused about the unclear judgments that
they are reading from RM's and won't bother them for further questions
that waste everyones time and patience. I dont see this as an attack on
RM's, I see it as folks wanting help to reach release goals and want
someone to just clarify policy. Now if nobody clarifies policy, they
have to get guidance from the only people who can: RM's. If there is
some reason why the RM's are not able/willing to do this, then that
leads to only further frustration and no progress, as witnesses by this
and other threads. So, if someone can just update, clarify, fix, or in
someway address this, please lets focus on the real goal: liw's tattoo!
have a nice day!
cheers,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
> > [another agression]

Waw, actually, i was trying to be less aggressive...

Anyways, since I'm too pissed and since I see no reason to put myself in
that mood any further, I'm taking a few days off Debian, which means my
current work on seamonkey^Hiceape will be on hold. All the work in
progress on my currently maintained packages will be on hold too.

If you want iceape in shape for etch if we are anything near a freeze,
well, get your fingers out of your asses, as we say in french.

Mike


signature.asc
Description: Digital signature

Re: Bug mass filling

[Julien BLACHE]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> Be aware that, even if you don't like it, this looks like you bend the
> rules so that it doesn't alter the release plan.
> Be also aware that too much bending the rules makes them useless.

Don't try to bend the rules, it's impossible. Instead, only realize
the truth: there are no rules.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Thomas Bushnell BSG]

Mike Hommey <[EMAIL PROTECTED]> writes:

>> So, what does the Etch RC policy remove from the bugs.d.o description?
>
> 'is a severe violation of Debian policy (roughly, it violates a "must" or
>  "required" directive), or'

Perhaps you should concentrate on the word "roughly" there.  What
constitutes a severe violation is in the judgment of the Release Team,
and the release goals indicate their judgment in the context of a
particular release.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 19, 2006 at 10:20:46PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
>> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]:
>> > Where does it say the scope for 4. Autobuilding is "buildds must not
>> > fail" ?
>> 
>> There are always bugs in any document.
>
> Be aware that, even if you don't like it, this looks like you bend the
> rules so that it doesn't alter the release plan.
> Be also aware that too much bending the rules makes them useless.

What about your proposing a GR to recall the Release Managers?  

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
> [another agression]

Sorry, but enough is enough. I'm fed up about your sudden agressions
towards me for no reason at all. Welcome to my killfile.


Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 10:20:46PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]:
> > Where does it say the scope for 4. Autobuilding is "buildds must not
> > fail" ?
> 
> There are always bugs in any document.

Be aware that, even if you don't like it, this looks like you bend the
rules so that it doesn't alter the release plan.
Be also aware that too much bending the rules makes them useless.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 10:15:16PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:06]:
> > That was not a link before it was changed before sarge release, in July
> > 2004.
> 
> The link was added later because people were barking around. The meaning
> was always the same.

The meaning of "Debian Policy" was always something else than
http://www.us.debian.org/doc/debian-policy/ ? Come on...

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]:
> Where does it say the scope for 4. Autobuilding is "buildds must not
> fail" ?

There are always bugs in any document.

For sarge, we e.g. sarge-ignored some MTAs which didn't provide -bs,
though LSB requires that. Now, we adjusted the policy to make it legal
(as long as they conflict with lsb of course). Nothing wrong with that,
the text isn't written in stone.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 22:06]:
> That was not a link before it was changed before sarge release, in July
> 2004.

The link was added later because people were barking around. The meaning
was always the same.

Anyways, July 2004 is a *bit* history now, don't you think so?

> So, what is written on http://www.debian.org/Bugs/Developer#severities
> doesn't count (not to say it's crap), and it's not necessary to change
> it.

If you disagree with what is written on the page, you might want to ask
[EMAIL PROTECTED] for clarification, or you could appeal to the
Technical Committee, or you could ask the developers in a GR. Until you
succeed at at least one of the ways, the definition as written down by a
member of [EMAIL PROTECTED] stays valid. As it is always.


Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 09:56:37PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Aurelien Jarno ([EMAIL PROTECTED]) [061019 21:31]:
> > Andreas Barth a écrit :
> > >A violation of the parts of the debian policy as listed on
> > >http://release.debian.org/etch_rc_policy.txt is serious level (that
> > >should be the same as the must-directives in policy, but - well, I hope
> > >that I have finally time post-etch to sync that finally).
> > >
> > >Any other policy violation is at most important level (unless it
> > >conincides with one of the other criteria for RC bugs, of course).
> > >
> > 
> > Note that what we are discussing (must have in targets debian/rules) are 
> > listed on http://release.debian.org/etch_rc_policy.txt
> 
> As vorlon said, that is listed under the heading of "4. Autobuilding",
> so the scope is "buildds must not fail" of this rule. That is why I

Where does it say the scope for 4. Autobuilding is "buildds must not
fail" ?

It does say "Packages must autobuild without failure on all
architectures on which they are supported", but that's one of the
options that make a bug RC.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 03:53:56PM -0400, Eric Dorland <[EMAIL PROTECTED]> 
wrote:
> * Andreas Barth ([EMAIL PROTECTED]) wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> > > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL 
> > > PROTECTED]> wrote:
> > > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > > > Note how subtly the Etch RC policy removes the first alternative of 
> > > > > the
> > > > > serious bug description...
> > > > 
> > > > Which do you mean? Please read the Etch RC policy. It tells:
> > > > | In addition to the issues listed in this document, an issue is release
> > > > | critical if it:
> > > > | [...]
> > > > | * in the maintainer's opinion, makes the package unsuitable
> > > > | for release
> > > > 
> > > > So, what does the Etch RC policy remove from the bugs.d.o description?
> > > 
> > > 'is a severe violation of Debian policy (roughly, it violates a "must" or
> > >  "required" directive), or'
> > 
> > The html-code for this part is:
> > serious
> > is a http://release.debian.org/etch_rc_policy.txt";>severe
> > violation of Debian policy (roughly, it violates a "must" or "required"
> > directive), or, in the package maintainer's opinion, makes the package
> > unsuitable for release.
> > 
> > So, obviously http://www.debian.org/Bugs/Developer#severities defines
> > that "severe violation of Debian policy" means anything referenced in
> > the etch_rc_policy-document.
> 
> I would have thought that meant a violation of
> http://www.us.debian.org/doc/debian-policy/.

That was not a link before it was changed before sarge release, in July
2004.

Interesting log in the web page cvs:

  The RM defines what the 'serious' severity means.

   regarding -a and -o in -test, aj, Kamion and vorlon said on June 8
that it is not considered RC by you guys. Okay to tag bugs with
'... uses XSIisms (test ... -a/-o ...) with sarge-ignore?
   jvw: no, it's not okay for them to be marked RC in the first place
   http://people.debian.org/~ajt/sarge_rc_policy.txt is the canonical
   place to look for the definition of "severe policy violation"
   sarge-ignore is not possible as it is not an RC issue
  [...]
   aj: so you say http://www.debian.org/Bugs/Developer#severities is
wrong?
   whatever
   I'm not going to be able to convince people that
http://www.debian.org/Bugs/Developer#severities is wrong, but I
might be able to say it isn't a Sarge issue at least, but that
involves sarge-ignore, which requires your okay
   it doesn't matter what that page says
   http://people.debian.org/~ajt/sarge_rc_policy.txt is canonical
   if the bug doesn't match the criteria on that page it's not serious
   grave or critical

So, what is written on http://www.debian.org/Bugs/Developer#severities
doesn't count (not to say it's crap), and it's not necessary to change
it.

By the way, reportbug doesn't give anything close to a hint that it
could be anything else than than Debian Policy:

3 serious
  is a severe violation of Debian policy (that is, the problem is a
  violation of a 'must' or 'required' directive); may or may not affect
  the usability of the package. Note that non-severe policy violations
  may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers
  may also designate other bugs as 'serious' and thus release-critical;
  however, end users should not do so.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 09:35:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> But I need to admit that I get sick, seriously sick. If someone doesn't
> agree with something, he just says "you do it wrong just for release of
> etch on $date". I really hate that. Especially when it's about things
> that are done that way since ages, but someone just recently has become
> aware of that.

I need to admit that I get sick, seriously sick of all that has been happening
in Debian in the last couple of months, between RM funding, dunc-tank, people
resigning, release date chosen on odd grounds, do whatever to release on that
date, whatever, 42 stupid useless GRs to delay (again) what was delayed
in order to release sarge, Sven Luther vs. Sven Luther's enemies, ...
... ... ...
I'm not even talking about that stupid Mozilla® affair.

> That really takes the fun away from Debian for me.

Same here.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Aurelien Jarno ([EMAIL PROTECTED]) [061019 21:31]:
> Andreas Barth a écrit :
> >A violation of the parts of the debian policy as listed on
> >http://release.debian.org/etch_rc_policy.txt is serious level (that
> >should be the same as the must-directives in policy, but - well, I hope
> >that I have finally time post-etch to sync that finally).
> >
> >Any other policy violation is at most important level (unless it
> >conincides with one of the other criteria for RC bugs, of course).
> >
> 
> Note that what we are discussing (must have in targets debian/rules) are 
> listed on http://release.debian.org/etch_rc_policy.txt

As vorlon said, that is listed under the heading of "4. Autobuilding",
so the scope is "buildds must not fail" of this rule. That is why I
asked to file the cases where buildds failed as serious, and the others
as important (and cases where "Packages in the archive must not be so
buggy [...] we refuse to support them." as serious as well, that is
under section "5. General").



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Eric Dorland]

* Andreas Barth ([EMAIL PROTECTED]) wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> > wrote:
> > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > > Note how subtly the Etch RC policy removes the first alternative of the
> > > > serious bug description...
> > > 
> > > Which do you mean? Please read the Etch RC policy. It tells:
> > > | In addition to the issues listed in this document, an issue is release
> > > | critical if it:
> > > | [...]
> > > | * in the maintainer's opinion, makes the package unsuitable
> > > | for release
> > > 
> > > So, what does the Etch RC policy remove from the bugs.d.o description?
> > 
> > 'is a severe violation of Debian policy (roughly, it violates a "must" or
> >  "required" directive), or'
> 
> The html-code for this part is:
> serious
> is a http://release.debian.org/etch_rc_policy.txt";>severe
> violation of Debian policy (roughly, it violates a "must" or "required"
> directive), or, in the package maintainer's opinion, makes the package
> unsuitable for release.
> 
> So, obviously http://www.debian.org/Bugs/Developer#severities defines
> that "severe violation of Debian policy" means anything referenced in
> the etch_rc_policy-document.

I would have thought that meant a violation of
http://www.us.debian.org/doc/debian-policy/. I certainly think it's
the release manager's responsibility to mark bugs that are not release
blocking etch-ignore, but if it is a violation of policy it should
still be serious. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6



signature.asc
Description: Digital signature

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 21:25]:
> On Thu, Oct 19, 2006 at 09:17:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> > > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL 
> > > PROTECTED]> wrote:
> > > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > > > Note how subtly the Etch RC policy removes the first alternative of 
> > > > > the
> > > > > serious bug description...
> > > > 
> > > > Which do you mean? Please read the Etch RC policy. It tells:
> > > > | In addition to the issues listed in this document, an issue is release
> > > > | critical if it:
> > > > | [...]
> > > > | * in the maintainer's opinion, makes the package unsuitable
> > > > | for release
> > > > 
> > > > So, what does the Etch RC policy remove from the bugs.d.o description?
> > > 
> > > 'is a severe violation of Debian policy (roughly, it violates a "must" or
> > >  "required" directive), or'
> > 
> > The html-code for this part is:
> > serious
> > is a http://release.debian.org/etch_rc_policy.txt";>severe
> > violation of Debian policy (roughly, it violates a "must" or "required"
> > directive), or, in the package maintainer's opinion, makes the package
> > unsuitable for release.
> > 
> > So, obviously http://www.debian.org/Bugs/Developer#severities defines
> > that "severe violation of Debian policy" means anything referenced in
> > the etch_rc_policy-document.
> 
> Yeah, right, whatever, as soon as etch is release on December 4th...

What do you intend to say by that? The definition of serious was already
that way when I was looking at the release from the very outside, before
I was a DD even (ok, it was sarge_rc_policy.txt, and not etch at that
time). It has *nothing* whatsoever to do with the planned release date
...


But I need to admit that I get sick, seriously sick. If someone doesn't
agree with something, he just says "you do it wrong just for release of
etch on $date". I really hate that. Especially when it's about things
that are done that way since ages, but someone just recently has become
aware of that.

That really takes the fun away from Debian for me. I don't know if
that's what you intend, but that's what you achieve.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Aurelien Jarno]

Andreas Barth a écrit :

A violation of the parts of the debian policy as listed on
http://release.debian.org/etch_rc_policy.txt is serious level (that
should be the same as the must-directives in policy, but - well, I hope
that I have finally time post-etch to sync that finally).

Any other policy violation is at most important level (unless it
conincides with one of the other criteria for RC bugs, of course).



Note that what we are discussing (must have in targets debian/rules) are 
listed on http://release.debian.org/etch_rc_policy.txt



--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 09:17:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> > wrote:
> > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > > Note how subtly the Etch RC policy removes the first alternative of the
> > > > serious bug description...
> > > 
> > > Which do you mean? Please read the Etch RC policy. It tells:
> > > | In addition to the issues listed in this document, an issue is release
> > > | critical if it:
> > > | [...]
> > > | * in the maintainer's opinion, makes the package unsuitable
> > > | for release
> > > 
> > > So, what does the Etch RC policy remove from the bugs.d.o description?
> > 
> > 'is a severe violation of Debian policy (roughly, it violates a "must" or
> >  "required" directive), or'
> 
> The html-code for this part is:
> serious
> is a http://release.debian.org/etch_rc_policy.txt";>severe
> violation of Debian policy (roughly, it violates a "must" or "required"
> directive), or, in the package maintainer's opinion, makes the package
> unsuitable for release.
> 
> So, obviously http://www.debian.org/Bugs/Developer#severities defines
> that "severe violation of Debian policy" means anything referenced in
> the etch_rc_policy-document.

Yeah, right, whatever, as soon as etch is release on December 4th...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > Note how subtly the Etch RC policy removes the first alternative of the
> > > serious bug description...
> > 
> > Which do you mean? Please read the Etch RC policy. It tells:
> > | In addition to the issues listed in this document, an issue is release
> > | critical if it:
> > | [...]
> > | * in the maintainer's opinion, makes the package unsuitable
> > | for release
> > 
> > So, what does the Etch RC policy remove from the bugs.d.o description?
> 
> 'is a severe violation of Debian policy (roughly, it violates a "must" or
>  "required" directive), or'

The html-code for this part is:
serious
is a http://release.debian.org/etch_rc_policy.txt";>severe
violation of Debian policy (roughly, it violates a "must" or "required"
directive), or, in the package maintainer's opinion, makes the package
unsuitable for release.

So, obviously http://www.debian.org/Bugs/Developer#severities defines
that "severe violation of Debian policy" means anything referenced in
the etch_rc_policy-document.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > Note how subtly the Etch RC policy removes the first alternative of the
> > serious bug description...
> 
> Which do you mean? Please read the Etch RC policy. It tells:
> | In addition to the issues listed in this document, an issue is release
> | critical if it:
> | [...]
> | * in the maintainer's opinion, makes the package unsuitable
> | for release
> 
> So, what does the Etch RC policy remove from the bugs.d.o description?

'is a severe violation of Debian policy (roughly, it violates a "must" or
 "required" directive), or'

> > Anyways, I've always thought the bts severity levels and release
> > criticality were orthogonal things. i.e. it's more complicated than
> > just saying "critical, grave and serious levels are RC".
> 
> That is wrong.
> 
> > There are
> > important or even normal issues (as per definition of the severity
> > levels) that are more release critical than serious (again, as per
> > definition of the severity levels) bugs.
> 
> Wrong. A bug is release-critical :<=> the bug has severity serious,
> grave, critical and has not been given an excemption by the release team

You may have missed the "thought" part of the sentence.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> Note how subtly the Etch RC policy removes the first alternative of the
> serious bug description...

Which do you mean? Please read the Etch RC policy. It tells:
| In addition to the issues listed in this document, an issue is release
| critical if it:
| [...]
| * in the maintainer's opinion, makes the package unsuitable
| for release

So, what does the Etch RC policy remove from the bugs.d.o description?

> Anyways, I've always thought the bts severity levels and release
> criticality were orthogonal things. i.e. it's more complicated than
> just saying "critical, grave and serious levels are RC".

That is wrong.

> There are
> important or even normal issues (as per definition of the severity
> levels) that are more release critical than serious (again, as per
> definition of the severity levels) bugs.

Wrong. A bug is release-critical :<=> the bug has severity serious,
grave, critical and has not been given an excemption by the release team

> But yet, violation of the Debian policy should be granted serious level.
> etch-ignore is here to make the issue not release critical.

Wrong. Etch-ignore is for exemptions for issues that otherwise match the
definition of release critical on that page. It is not for "normal
sorting" of issues.


A violation of the parts of the debian policy as listed on
http://release.debian.org/etch_rc_policy.txt is serious level (that
should be the same as the must-directives in policy, but - well, I hope
that I have finally time post-etch to sync that finally).

Any other policy violation is at most important level (unless it
conincides with one of the other criteria for RC bugs, of course).


Cheers,
Andi
Debian Release Manager
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 11:29:38AM -0700, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Thu, Oct 19, 2006 at 07:51:19PM +0200, Mike Hommey wrote:
> > On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> > wrote:
> > > > Doesn't policy violation warrant Critical severity?
> 
> > > No. Please see the top of http://release.debian.org/etch_rc_policy.txt
> > > for which bugs are critical, grave and serious.
> 
> > That is irrelevant for the severity of bugs.
> 
> > This is the relevant definition:
> 
> > serious is a severe violation of Debian policy (that is, the
> > problem is a violation of a 'must' or 'required' directive)
> 
> That definition, as listed on
> , links straight to the
> release team's RC bug policy.

Note how subtly the Etch RC policy removes the first alternative of the
serious bug description...

Anyways, I've always thought the bts severity levels and release
criticality were orthogonal things. i.e. it's more complicated than
just saying "critical, grave and serious levels are RC". There are
important or even normal issues (as per definition of the severity
levels) that are more release critical than serious (again, as per
definition of the severity levels) bugs.

But yet, violation of the Debian policy should be granted serious level.
etch-ignore is here to make the issue not release critical.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Steve Langasek]

On Thu, Oct 19, 2006 at 07:51:19PM +0200, Mike Hommey wrote:
> On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > > Doesn't policy violation warrant Critical severity?

> > No. Please see the top of http://release.debian.org/etch_rc_policy.txt
> > for which bugs are critical, grave and serious.

> That is irrelevant for the severity of bugs.

> This is the relevant definition:

> serious is a severe violation of Debian policy (that is, the
> problem is a violation of a 'must' or 'required' directive)

That definition, as listed on
, links straight to the
release team's RC bug policy.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Adam D. Barratt]

On Thu, 2006-10-19 at 10:00 -0700, Kevin B. McCarty wrote:
> Tshepang Lekhonkhobe wrote:
> 
> > Doesn't policy violation warrant Critical severity?
> 
> No, it "only" warrants the lowest RC severity, serious [0], unless the
> bug in addition makes the package or other software (mostly) unusable,
> causes data loss, or introduces a security hole.

Even then, it's only "serious" if it violates the release policy
[http://release.debian.org/etch_rc_policy.txt]. Hence the reason that

> [0] http://www.debian.org/Bugs/Developer#severities

says "[...]roughly, it violates a "must" or "required" directive". The
final word for what justifies a release-critical severity belongs to the
release team (hence also the paragraph on rc-ness at the foot of the
documentation).

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Adam D. Barratt]

On Thu, 2006-10-19 at 19:51 +0200, Mike Hommey wrote:
> On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > > Doesn't policy violation warrant Critical severity?
> > 
> > No. Please see the top of http://release.debian.org/etch_rc_policy.txt
> > for which bugs are critical, grave and serious.
> 
> That is irrelevant for the severity of bugs.
[...]
> Don't change severities for releasing-in-time purposes. There is

Erm... the release team have been the arbiters of what merits an RC
severity since at least before Sarge was released.

>From http://www.debian.org/Bugs/Developer#severities:

"Certain severities are considered release-critical, meaning the bug
will have an impact on releasing the package with the stable release of
Debian. Currently, these are critical, grave and serious. For complete
and canonical rules on what issues merit these severities, see the list
of Release-Critical Issues for Etch." The top of the latter page reads

"The purpose of this document is to be a correct, complete and canonical
list of issues that merit a "serious" bug under the clause "a severe
violation of Debian policy". 

In addition to the issues listed in this document, an issue is release
critical if it:
[...]

* in the maintainer's opinion, makes the package unsuitable
  for release
(these issues are "serious" severity)
"

i.e. if it's not in the policy and doesn't meet the above definition,
it's *not* severity serious or higher.

I'd suggest reading
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277074;msg=72, in which
a current member of [EMAIL PROTECTED] (and at the time an RM) confirms that a
member of the ftp-master team was correct in stating the above.

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Steve Langasek]

On Thu, Oct 19, 2006 at 07:01:20PM +0200, Frans Pop wrote:
> On Thursday 19 October 2006 18:45, Petter Reinholdtsen wrote:
> > If no problem is caused by it, I believe 'normal' or even 'wishlist'
> > severity is the proper severity to use.

> s/wishlist/minor/

> It _is_ a bug after all.

s/minor/important/, which is the severity used for policy violations that
don't qualify as release-critical.

And in this case, yes, the bugs should be filed as important rather than
serious; the etch RC policy claims they should be serious, but it also does
this in the section on "autobuilding" -- if no one has found any problems
autobuilding these packages before now, despite multiple full-archive
rebuilds over the past year, then it's a bug in the etch RC policy to
suggest that these should be RC when they don't cause practical problems.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> > Doesn't policy violation warrant Critical severity?
> 
> No. Please see the top of http://release.debian.org/etch_rc_policy.txt
> for which bugs are critical, grave and serious.

That is irrelevant for the severity of bugs.

This is the relevant definition:

serious is a severe violation of Debian policy (that is, the
problem is a violation of a 'must' or 'required' directive)

And in our case, the policy says:

Both the binary-arch and binary-indep targets must exist.

Don't change severities for releasing-in-time purposes. There is
etch-ignore for that.

Mike, wondering how many RC bugs will be tagged etch-ignore to reach the
80 bugs before freeze.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Aurelien Jarno ([EMAIL PROTECTED]) [061019 15:06]:
> Among all of the bugs reported by lintian, one concerns a lot of
> packages, the presence of the clean, binary, binary-arch, binary-indep 
> and build targets. This is required by both the section 4.9 of the
> policy and the Etch release standards [1]. Here is the list of affected
> packages. What to do with them?

If the bug also affects our autobuilders (especially the package has
binary-any-packages), serious. Otherwise, important severity.

If a package is totally broken (which might be in this case), serious
might also be ok - but that needs to be decided on a case-by-case-basis.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Andreas Barth]

* Tshepang Lekhonkhobe ([EMAIL PROTECTED]) [061019 18:09]:
> On 10/19/06, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> >
> >[Aurelien Jarno]
> >> I have just run lintian on all the archive (amd64) for both binaries and
> >> sources, and the results are a bit scary. It looks like a lot of
> >> maintainers are uploading their packages, and don't really care with the
> >> policy.
> >
> >What is the technical problem triggered by the packages with this
> >lintian message?  Is the autobuilders able to build these packages?
> >If the autobuilders fail, I recommend you report that as a important
> >or serious problem, and it it isn't, I recommend you report it as a
> >normal bug.
> 
> Doesn't policy violation warrant Critical severity?

No. Please see the top of http://release.debian.org/etch_rc_policy.txt
for which bugs are critical, grave and serious.



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Julien Danjou]

On Thu, Oct 19, 2006 at 06:45:53PM +0200, Petter Reinholdtsen wrote:
> Well, policy isn't a stick to beat other maintainers with, it is a
> tool to make sure our packages are well integrated and work properly.
> Thus, policy issues are not problems by themselves, they are policy
> issues because they might cause problems.  And in this case, I am not
> sure what the exact problem caused by the lack of the binary-indep
> target is, so I ask.
> 
> If no problem is caused by it, I believe 'normal' or even 'wishlist'
> severity is the proper severity to use.

If there's no problem, change the policy.

-- 
Julien Danjou
.''`.  Debian Developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


signature.asc
Description: Digital signature

Re: Bug mass filling

[Frans Pop]

On Thursday 19 October 2006 18:45, Petter Reinholdtsen wrote:
> If no problem is caused by it, I believe 'normal' or even 'wishlist'
> severity is the proper severity to use.

s/wishlist/minor/

It _is_ a bug after all.


pgp8CuxfBlHbn.pgp
Description: PGP signature

Re: Bug mass filling

[Kevin B. McCarty]

Tshepang Lekhonkhobe wrote:

> Doesn't policy violation warrant Critical severity?

No, it "only" warrants the lowest RC severity, serious [0], unless the
bug in addition makes the package or other software (mostly) unusable,
causes data loss, or introduces a security hole.

[0] http://www.debian.org/Bugs/Developer#severities

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Petter Reinholdtsen]

[Tshepang Lekhonkhobe]
> Doesn't policy violation warrant Critical severity?

Well, policy isn't a stick to beat other maintainers with, it is a
tool to make sure our packages are well integrated and work properly.
Thus, policy issues are not problems by themselves, they are policy
issues because they might cause problems.  And in this case, I am not
sure what the exact problem caused by the lack of the binary-indep
target is, so I ask.

If no problem is caused by it, I believe 'normal' or even 'wishlist'
severity is the proper severity to use.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Tshepang Lekhonkhobe]

On 10/19/06, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:


[Aurelien Jarno]
> I have just run lintian on all the archive (amd64) for both binaries and
> sources, and the results are a bit scary. It looks like a lot of
> maintainers are uploading their packages, and don't really care with the
> policy.

What is the technical problem triggered by the packages with this
lintian message?  Is the autobuilders able to build these packages?
If the autobuilders fail, I recommend you report that as a important
or serious problem, and it it isn't, I recommend you report it as a
normal bug.


Doesn't policy violation warrant Critical severity?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug mass filling

[Petter Reinholdtsen]

[Aurelien Jarno]
> I have just run lintian on all the archive (amd64) for both binaries and
> sources, and the results are a bit scary. It looks like a lot of 
> maintainers are uploading their packages, and don't really care with the 
> policy.

What is the technical problem triggered by the packages with this
lintian message?  Is the autobuilders able to build these packages?
If the autobuilders fail, I recommend you report that as a important
or serious problem, and it it isn't, I recommend you report it as a
normal bug.

Friendly,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug mass filling

[Aurelien Jarno]

Hi all,

I have just run lintian on all the archive (amd64) for both binaries and
sources, and the results are a bit scary. It looks like a lot of 
maintainers are uploading their packages, and don't really care with the 
policy.

Maybe some errors (E:) of lintian could be changed to critical (C:) and
uploads containing such critical errors be refused by dak? What do you
think?


Among all of the bugs reported by lintian, one concerns a lot of
packages, the presence of the clean, binary, binary-arch, binary-indep 
and build targets. This is required by both the section 4.9 of the
policy and the Etch release standards [1]. Here is the list of affected
packages. What to do with them?

E: adeos source: debian-rules-missing-required-target binary-indep
E: ale source: debian-rules-missing-required-target binary-indep
E: arabtex source: debian-rules-missing-required-target binary-arch
E: autoconf source: debian-rules-missing-required-target binary-arch
E: babygimp source: debian-rules-missing-required-target binary-arch
E: backupninja source: debian-rules-missing-required-target binary-arch
E: bamboo source: debian-rules-missing-required-target binary-arch
E: bastille source: debian-rules-missing-required-target binary-indep
E: bazaar-doc source: debian-rules-missing-required-target binary-indep
E: bicyclerepair source: debian-rules-missing-required-target binary-arch
E: bitlbee source: debian-rules-missing-required-target binary-indep
E: blootbot source: debian-rules-missing-required-target binary-arch
E: blootbot source: debian-rules-missing-required-target binary-indep
E: boost-build source: debian-rules-missing-required-target binary-arch
E: boost-build source: debian-rules-missing-required-target build
E: bootcd source: debian-rules-missing-required-target binary-arch
E: br2684ctl source: debian-rules-missing-required-target binary-indep
E: c-cpp-reference source: debian-rules-missing-required-target build
E: c2n source: debian-rules-missing-required-target binary-indep
E: cacti source: debian-rules-missing-required-target binary-arch
E: camlidl-doc source: debian-rules-missing-required-target binary-arch
E: cassbeam source: debian-rules-missing-required-target binary-indep
E: check source: debian-rules-missing-required-target binary-indep
E: cli-common source: debian-rules-missing-required-target binary-arch
E: clips-doc source: debian-rules-missing-required-target build
E: coco-cs source: debian-rules-missing-required-target binary-arch
E: coco-doc source: debian-rules-missing-required-target binary-arch
E: coco-doc source: debian-rules-missing-required-target build
E: coco-doc source: debian-rules-missing-required-target clean
E: coco-java source: debian-rules-missing-required-target binary-arch
E: configure-debian source: debian-rules-missing-required-target binary-arch
E: cthumb source: debian-rules-missing-required-target build
E: dag2html source: debian-rules-missing-required-target binary-indep
E: db4.2 source: debian-rules-missing-required-target binary-indep
E: debget source: debian-rules-missing-required-target binary-arch
E: debroster source: debian-rules-missing-required-target binary-arch
E: dhcp source: debian-rules-missing-required-target binary-indep
E: dpkg-ftp source: debian-rules-missing-required-target build
E: drbdlinks source: debian-rules-missing-required-target binary-arch
E: drgeo-doc source: debian-rules-missing-required-target binary-arch
E: dupload source: debian-rules-missing-required-target binary-arch
E: dvipng source: debian-rules-missing-required-target binary-indep
E: e00compr source: debian-rules-missing-required-target binary-indep
E: efp source: debian-rules-missing-required-target binary-arch
E: emms source: debian-rules-missing-required-target binary-indep
E: enigmail source: debian-rules-missing-required-target build
E: fapg source: debian-rules-missing-required-target binary-indep
E: fbpanel source: debian-rules-missing-required-target binary-indep
E: filler source: debian-rules-missing-required-target binary-arch
E: flawfinder source: debian-rules-missing-required-target binary-arch
E: flowscan source: debian-rules-missing-required-target binary-arch
E: fortunes-ga source: debian-rules-missing-required-target binary-arch
E: fortunes-it source: debian-rules-missing-required-target binary-arch
E: freeswan source: debian-rules-missing-required-target binary-arch
E: freetype1 source: debian-rules-missing-required-target binary-indep
E: fv source: debian-rules-missing-required-target binary-indep
E: gap-ctbllib source: debian-rules-missing-required-target binary-arch
E: gap-matrix-schreiersims source: debian-rules-missing-required-target 
binary-arch
E: gkrellmitime source: debian-rules-missing-required-target binary-indep
E: gkrellweather source: debian-rules-missing-required-target binary-indep
E: gnoise source: debian-rules-missing-required-target binary-indep
E: gnome-lokkit source: debian-rules-missing-required-target binary-indep
E: gnucap source: debian-rules-mis