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

Re: Speakup bug



pj@pjb.com.au writes:

> I wrote:
>> Are staging modules frozen under the same rules as the rest of stable ?
>
> Jason White wrote:
>> Probably yes. "Stable" for Debian's purposes applies to the
>> packages, not to their components.
>
> But I fail to see any advantage from Debian's point of view
> in holding "staging" modules in a buggy condition in a release
> that's supposed to be stable - not just frozen, but stable.
>
> It's not just the kernel-module that's "staging", it's also
> the package; for example at the moment of accept/not-accept:
>> anyone who uses a "staging" module accepts the risk of
>> crashes and other potentially undesirable consequences.
> and that decision is made at the  aptitude install  moment.
> I'll reiterate that I think the "staging" status should
> be made visible in  aptitude show  ...

Its a bit complicated, since, as you already identified, several
components are playing together in the case of speakup: a kernel
component, which happens to live in the staging/ source directory of the
linux kernel, and associated user-space tools.  But I agree with you
that the package description of the speakup kernel modules should
probably mention that speakup is in staging/ right now.
It would be a bit overstated to call speakup unstable or experimental,
since it is around for many many years now.  It being a staging/ module
right now is more or less due to historic reasons.

>> Testing and unstable are regularly updated with new kernels,
>> so when the bug is fixed and finds its way into a kernel
>> release, the new kernel will enter Debian naturally.
>
> If it's a matter of waiting for a fix and then moving
> from stable to testing, then, well, that's not too bad.
> That also picks up other fixes, more up-to-date edbrowse, etc.
>
> There can't be useful movement on this until a fix exists, anyway.

Mind you, I am not quite up-to-date with all details of this issue,
but it seems to me that once a fix is actually known, and it can be
backported to 2.6.32 kernel sources, depending on the size of the actual
patch, it might still be worthwhile to submit it to the debian kernel
team as a bugreport against the package in stable.  If the fix is local
and simple enough, it might actually get applied (my guesswork).

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang/key@db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>


Reply to: