Rolf Leggewie wrote... > I understand the desire for a quick, convenient and seemingly painless > solution. There have been several uploads and attempts in the past to > fix this in a sane way within isdnutils but ultimately we learned of the > futility of this and the decision was made that this needs to be fixed > elsewhere.
So explain that futlity. I still cannot see - but would like to
learn - why the old approach became inacceptable. Became _that_
inacceptable you considered it a lesser evil to silently break
virtually(*) all installations using isdnlog and other packages out
there, and putting some weird work unto each user of that package.
Work that even isn't documented in NEWS.Debian.
An approach that at least served well for many years and still does.
(*) I'll leave out "virtually" from now on as the remaining group,
"comes from squeeze or older, does not use udev", should be
neglectably small.
> I believe if Debian has to choose between convenience and
> doing things properly, the latter is strongly preferred.
The question here is rather deciding between breaking things and
keeping things working, even if it's not in the nicest way. And the
latter is the only acceptable.
Avoiding regressions is another thing of high importance. And if it's
inevitable, warn loudly and provide a transitions as painless as
possible.
> The ticket isn't only open since yesterday, trying to base your case on
> the imminent Wheezy release seems unjustified.
So, there was plenty of time to fix it.
And talking about myself, it _is_ justified. The boxes I run isdnlog
on are usually stable. Just due to other circumstances I upgraded one
of them even before the release, also resulting in the other bug
reports you have seen. I simply wasn't aware of the breakage any
earlier.
> Almost exactly two years
> ago on the exact DAY this ticket was opened I asked Sven to report the
> issue in the proper place so there could be a fix, this hasn't
> happened.
I don't get it. You (the isdnutils maintainers) deliberately broke the
package, by the way, also violated policy 10.6. Users send bug
reports since breakage may happen, but rather due to some errors or
unforseen side-effects. And now you expect them to do the work for
you.
> I'd have done this myself but I hope you respect that I had
> a lot of issues on my "isdnutils plate" and device nodes in the kernel
> isn't necessarily my forté.
Strongly disagree. You've broken the package. Fix it.
> My co-maintainer who is more skilled in
> that area apparently didn't end up being successful with that kernel
> work either.
For me, the obvious reaction then was to revert the breakage, wait
until all pre-requisites are met, wait a bit longer during a time of
transition so there's a fallback in case of a regression, then finally
get rid of the old code. I still fail to see why you started the other
way around.
> I would be much more inclined towards reactivating a band-aid fix if I
> had seen some work and progress on a proper solution. None of the
> proponents asking for a band-aid fix is stepping up to even reporting a
> bug in the proper place, (...)
Because it's not their job.
It is an act of courtesy by bug reporters to ease a maintainer's life
by providing patches, forwarding reports, alerting third parties and
the like. They are well advised to do these things, according to their
skils since it's their own interest to have issues resolved soon, or
provide other affected users a workaround for the time being. But
there is no obligation.
> (...) I'd humbly suggest to do that instead of
> calling in tech-ctte.
This didn't happen though, and now the package ist borken.
Just to repeat: You have broken the package. You refused to fix. You
denied patches to fix it. You've lowered the severity that marked the
package unfit for release. Now, tech-ctte is the only remaining move
to avoid breaking isdnutils installations in stable wheezy, annoying
users out there for a reason I still do not see explained.
> When I took over isdnutils the package was probably the biggest mess
> within Debian, and it was exactly because of all kinds of hacks like
> this one, so it won't be coming back I guess unless I can see that the
> band-aid will be only temporary.
No doubt, packaging and code still need a lot of attention, while just
a few hours of work could improve things a lot. So I was tempted to
react on #661110 and offer my help. But given this dispute I think
this might look a bit odd, wouldn't you agree?
Christoph
signature.asc
Description: Digital signature
