Bug#714140: pu: package tgt/1.0.17-1
Hi,
Sorry, I didn't remember the exact details, now I do. There *was* a bug
report earlier than you (and I) thought.
On 09/30/2013 04:59 PM, Cyril Brulebois wrote:
> [ Dropping -release, which gets this conversation through the bug
> already. ]
>
> Thomas Goirand <zigo@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.)
I believe you missed this one:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577925
This bug report was sent to the BTS in 2010. Here, we just had a
careless maintainer, IMO, and *me* who didn't care about it until
recently: others cared before I did and NMU-ed the package in Sid, at
least these 5 other people in this bug report, including one who would
have like it to be fixed in ... squeeze!!!
>> 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?
See above.
>> 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…
See above.
> Besides, we already saw dependency
> loop issues when init scripts got added or modified, so yes, it can be
> dangerous.
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Should-Start: zfs
# Should-Stop: zfs
I don't see how this could do a dependency loop.
>> 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
Yes. Though that's not orthogonal to the frustration of not seeing
things fixed fast enough in Debian.
Cheers,
Thomas Goirand (zigo)
Reply to: