On Sun, Jul 13, 2003 at 01:51:07PM +1000, Ben Burton wrote: > It seems then that our options are as follows. > (i) Wait for the Qt maintainers to upload a fix. > (ii) Do an NMU for Qt, despite the fact that this bug is not release-critical. > (iii) Resort to the technical committee. > (iv) Keep the package split and release sarge with a broken Qt development > environment. > Several months of experience suggest that (i) does not promise success. > Option (iii) seems rather heavy-handed to me. And I am loathe to see us > reach (iv), cementing debian as the only distribution with a deliberately > broken Qt. > I'd thus like to propose (ii) as the best solution. I realise this is not an > RC bug; technically it's not debian's problem but the upstream Qt app's > problem. Nevertheless, as it stands users are expected to divine the fact > that debian has deliberately broken Qt, that they should look in > README.Debian for a fix and that they are morally expected to tell upstream > that their code is wrong (after all, that's why they were forced through this > hassle in the first place). Though I certainly agree that the current packages are gratuitously broken, an NMU without the consent of the maintainer seems almost certain to turn into a pissing contest. Since (i) hasn't gotten anywhere in four months, I would suggest that (iii) is the way to go here: this is precisely the sort of case I think the technical ctte. is for. > I therefore see this is as a "release-critical usability problem", which the > BTS and policy have no formal concept of. I think that would be counted as 'grave'. -- Steve Langasek postmodern programmer
Attachment:
pgp0TLFczVJxk.pgp
Description: PGP signature