> >> If it isn't obsolete then fix the code to use the newer APIs
>
> Why should that be a precondition for removing the incorrect
> "obsolete" label?
Because if we remove the obsolete label the users are going to be
suprised when it goes away entirely with && BROKEN or && !HOTPLUG or
similar.
> >> to end up && BROKEN let alone Obsolete.
>
> That can't happen. Any change that breaks isdn4linux before its
> replacement is ready would constitute a regression.
> We've been there once, remember?
Want to be on that. There is nobody maintaining it. That isn't a
sustainable situation so it will break.
> I beg to differ. Existence of a working replacement is exactly
> the criterion we arrived at when discussing the meaning of the
> term "obsolete". So lack of a working replacement *is* an
> argument for concluding that something is not obsolete.
Ok then it should be marked "BROKEN" instead.
> - The authors of certain in-kernel API changes seem to have
> neglected the isdn4linux subsystem in their work.
For simile changes they have kept it going (eg the tty changes), but the
code is too big and too messy for that to happen for all things. Thus
it will eventually break
> - These are two independent problems. Blocking the correction of
> one of them because the other one still exists doesn't help,
> but only risks deadlock.
No risk of deadlock. It'll progress to && BROKEN which will either cause
sufficient pain for someone to get off their arse and fix it, for enough
of a vendors users to get the vendor to do the work or for someone who
cares to pay a third party to do the work.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
