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

Re: ndiswrapper



On 9/12/06, Andreas Barth <aba@not.so.argh.org> wrote:
* Raul Miller (moth.debian@gmail.com) [060911 18:30]:
> We have a release critical bug filed against ndiswrapper.
>
> More specifically, bug 353277 is severity critical, stipulating that
> ndiswrapper be in contrib, not in main.
>
> Here's the definition of "Severity: Serious" from bugs.debian.org: "is
> a severe violation of Debian policy (roughly, it violates a "must" or
> "required" directive), ..."
>
> So, an obvious question is: what does Debian policy say about contrib?
>
> http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

Actually, the definition refers to
http://release.debian.org/etch_rc_policy.txt as what serious is

I was going by the definition at
http://www.debian.org/Bugs/Developer#severities

The release manager document you referred to says:

  Further to this, certain issues may be exempted from being
  considered release critical for etch by the release manager.
  This is expressed by tagging the report "etch-ignore"; this
  should not be done without explicit authorisation from the
  release manager.

And gives a list of such issues where the first item on
the list is "DFSG-freeness".

Given these statements, I fail in seeing this bug as serious on the
package. (Of course, the situation might change after TC ruling.)

Well, of course, it might very well be that the release manager
will grant an "etch-ignore" exception for this bug.  However,
the package maintainer has not yet gotten such an
exception.

(On the other hand, note that this exception, if granted, would not
make the bug go away -- it would mean that the bug is no longer
release critical for etch, but would not take it off the plate of the
technical committee.)

> So, I'd like to propose that we issue an opinion that ndiswrapper
> needs to be in contrib, to comply with debian policy.

What do you want? Issue an opinion or overrule the maintainer? My
understanding is that the first doesn't change anything.

It's my understanding that the maintainer has agreed that if
the TC decides that it belongs in contrib that the package will
go in contrib.

Of course, the TC has not yet agreed that this is the case.
(I'm hoping that, by discussing this, the TC can come to
some sort of agreement that allows us to resolve this
bug.)

It's also possible that this no longer reflects the maintainer's
point of view.

On the flip side, this issue has been hanging around for
many, many months.

Anyways, the way I see it, the package currently violates policy,
and packaging it in contrib instead of main would make it
comply with policy.  None of what you have presented here
really deals with this issue.

--
Raul



Reply to: