[ Dropping -release, which gets this conversation through the bug already. ]
Thomas Goirand <z...@debian.org> (2013-09-30): > I'm very surprised that dates of bug reports come into consideration > here. I don't see why they should. In fact, that's one more reason why > we should speed up things: it has taken really too long to fix already. The idea is to figure out on which side of the balance between fixing things and risking breaking things we are. The fact that nobody bothered reporting this issue for so long seems to point out it isn't a showstopper. (Also, assuming both of us meant "worth" below.) > A missing init script is very annoying for our users. So I do think > it's worse it. I personally would not use the Stable package if it > doesn't include a correct init script, and it seems I'm not alone > thinking this way. I had to point some TGT users to my corrected > package in a private Debian repository. I would like to avoid doing > this in the future: explaining that Debian can't fix such an issue > within 9 months after the release doesn't feel great. How can you explain nobody reported the missing script for so long? > Also, I don't see how adding an init script makes it a disruptive or > dangerous patch. It has been successfully tested by many already, > including Julien Cristau who is the original author of it (IIRC, I > just added a few things in the script, but that's too long ago, so I > wouldn't be able to tell what I added). There's no authoring info whatsoever, and no bug report to track what happened, so that's not too nice… Besides, we already saw dependency loop issues when init scripts got added or modified, so yes, it can be dangerous. > I would find it very disappointing if Debian couldn't address this > kind of issue in an existing package in the stable distribution, only > because the release team think "it's not worse a stable upload". I > already find it frustrating that it has taken 3 months to get an > answer to this pu bug (even though I understand everyone is busy...). Yes, we could probably do better on the pu reply latency front. But that's orthogonal to the actual decision (which I already said I was waiting feedback from other team members for, so I'll be quiet now). Mraw, KiBi.
signature.asc
Description: Digital signature
