Re: Qt3 still broken (compat-headers), what to do?
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 pgpAKaCWgS8O5.pgp Description: PGP signature
Re: Qt3 still broken (compat-headers), what to do?
On Sat, Jul 12, 2003 at 11:51:18PM -0500, Steve Langasek wrote: 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. [...] 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. Bah, the Technical Committee takes months, sometimes over a year, to do something even as seemingly uncontroversial as voting in opposition to whichever solution Branden Robinson proposes. (Don't believe me? Read the debian-ctte archives.) To punt this to the Technical Committee is to stall a solution for potentially a very long time. If you're certain you're right, and you can get the NMU correct, the only people who will complain will be the package maintainers. -- G. Branden Robinson| It doesn't matter what you are Debian GNU/Linux | doing, emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://people.debian.org/~branden/ | pgpGAheUueheq.pgp Description: PGP signature
Re: Qt3 still broken (compat-headers), what to do?
On Sun, Jul 13, 2003 at 12:14:52AM -0500, Branden Robinson wrote: To punt this to the Technical Committee is to stall a solution for potentially a very long time. If you're certain you're right, and you can get the NMU correct, the only people who will complain will be the package maintainers. And given that they're the ones who'll be uploading the package again once the NMU is done and can easily revert the change, NMUing against the wishes of the maintainers and without the support of a higher authority doesn't seem overly productive either. I suppose there's always the option of NMUing, and hoping it sticks -- then taking it up with the tech ctte. if it doesn't... -- Steve Langasek postmodern programmer pgp181EPynCL2.pgp Description: PGP signature
Re: Qt3 still broken (compat-headers), what to do?
I suppose there's always the option of NMUing, and hoping it sticks -- then taking it up with the tech ctte. if it doesn't... This is more or less what I was thinking of. The impression I get is that the Qt maintainers have shifted their stances on this issue from defense to apathy. Though it's possible that this is just because apathy is an easier way to keep the package split until somebody does an NMU or calls in the technical committee. Ben.
Re: Qt3 still broken (compat-headers), what to do?
Ben Burton writes: Hi ho, it's time for another rant from me regarding the libqt3-compat-headers split. (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). So. Do people support this move or not? I wouldn't do it. Suppose you were the Qt maintainer, and you made a technical choice that some people disagree with, and they do an NMU on you. In the worst case, they could be doing another upload reverting your upload, and I can't say I would disagree with them. IMHO, what should happen, is try to convince the Qt maintainer, or agree with him to let the technical committee decide this one.. just my opinion of course... cheers domi
Re: Qt3 still broken (compat-headers), what to do?
I wouldn't do it. Suppose you were the Qt maintainer, and you made a technical choice that some people disagree with You mean a technical choice with a significant negative impact on users that breaks compatibility with upstream and every other linux distribution and that most (not some) people disagree with. and they do an NMU on you after four or five months of constant prodding and visible user confusion. IMHO, what should happen, is try to convince the Qt maintainer This option appears to lead nowhere, as explained in my earlier post. or agree with him to let the technical committee decide this one.. Taking it to the technical committee needn't require the Qt maintainers' consent. Furthermore, since the Qt maintainers seem so apathetic about this issue I'm certainly not going to wait for it. I honestly believe that in this case having a sarge Qt that's not broken should take precedence over maintainers' territoriality over their packages. And this is not a snap decision; the problem has been discussed for many months now without resolution, and the user errors continue to roll in. Ben.
Re: Qt3 still broken (compat-headers), what to do?
On Sun, Jul 13, 2003 at 12:14:52AM -0500, Branden Robinson wrote: Bah, the Technical Committee takes months, sometimes over a year, to do something even as seemingly uncontroversial as voting in opposition to whichever solution Branden Robinson proposes. So? This is more than enough time. This problem is to be fixed in sarge ... - Sebastian
Re: Qt3 still broken (compat-headers), what to do?
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. Option (iii) is certainly the way to go. Problems like this are exactly what the TC is for. My suggestion: Add a Recommends: libqt3-compat-headers to libqt3-dev. A dependency is too strong, since libqt3-dev is perfectly usable without the compatibility headers, but a recommendation ensures that the compat headers are installed along libqt3-dev in most cases. - Sebastian
Re: Qt3 still broken (compat-headers), what to do?
Bah, the Technical Committee takes months, sometimes over a year, to do something even as seemingly uncontroversial as voting in opposition to whichever solution Branden Robinson proposes. So? This is more than enough time. This problem is to be fixed in sarge ... Hmm? Are you saying that sarge is definitively well over a year away? b.
Re: Qt3 still broken (compat-headers), what to do?
My suggestion: Add a Recommends: libqt3-compat-headers to libqt3-dev. This is indeed what I would add were I to do an NMU, and I would include it in the list of solutions that I see as satisfactory were I to put it to the TC. b.
Re: Qt3 still broken (compat-headers), what to do?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 13 July 2003 06:32, Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Jul 13, 2003 at 12:14:52AM -0500, Branden Robinson wrote: To punt this to the Technical Committee is to stall a solution for potentially a very long time. If you're certain you're right, and you can get the NMU correct, the only people who will complain will be the package maintainers. And given that they're the ones who'll be uploading the package again once the NMU is done and can easily revert the change, NMUing against the wishes of the maintainers and without the support of a higher authority doesn't seem overly productive either. I suppose there's always the option of NMUing, and hoping it sticks -- then taking it up with the tech ctte. if it doesn't... I agree with this. Tell the maintainer you are NMU-ing, and do so to Delayed/. If he reverts/override the change, take it to the tech-ctte. Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/ET7NIzuKV+SHX/kRAq9YAJ4wO6NhuyuYo6Nd6Dpdj77JwiiFWwCfTJa9 yaGdRiU6mYYorG5r8QZHCUU= =WdL3 -END PGP SIGNATURE-
Re: Qt3 still broken (compat-headers), what to do?
On Sun, Jul 13, 2003 at 09:08:03PM +1000, Ben Burton wrote: Bah, the Technical Committee takes months, sometimes over a year, to do something even as seemingly uncontroversial as voting in opposition to whichever solution Branden Robinson proposes. So? This is more than enough time. This problem is to be fixed in sarge ... Hmm? Are you saying that sarge is definitively well over a year away? If he is, he's wrong. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?''
Re: Qt3 still broken (compat-headers), what to do?
Sebastian Rittau [EMAIL PROTECTED] writes: 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. Option (iii) is certainly the way to go. Problems like this are exactly what the TC is for. My suggestion: Add a Recommends: libqt3-compat-headers to libqt3-dev. A dependency is too strong, since libqt3-dev is perfectly usable without the compatibility headers, but a recommendation ensures that the compat headers are installed along libqt3-dev in most cases. Uhh, there's no reason the compat headers should have been split out in the first place. -- Poems... always a sign of pretentious inner turmoil. pgpOwozzSjaLu.pgp Description: PGP signature
Re: Qt3 still broken (compat-headers), what to do?
AT == Anthony Towns aj@azure.humbug.org.au writes: BB Hmm? Are you saying that sarge is definitively well over a BB year away? AT If he is, he's wrong. Hubris! Famous last words! The pride what cometh before a fall! ~ESP -- Evan Prodromou [EMAIL PROTECTED]
Re: Qt3 still broken (compat-headers), what to do?
On Sun, Jul 13, 2003 at 11:44:38AM -0400, Evan Prodromou wrote: AT == Anthony Towns aj@azure.humbug.org.au writes: BB Hmm? Are you saying that sarge is definitively well over a BB year away? AT If he is, he's wrong. Hubris! Famous last words! The pride what cometh before a fall! Not hubris, mere precision: sarge _might_ be well over a year away, but it's not _definitively_ over a year away. For those playing along at home (and if you're not, why not?) the debcamp bugsquash stuff is being tracked at: http://dc1.raw.no/~ajt/rcbugs.cgi There's no way for non debcamp types to list bugs there, maybe someone would like to remedy that; I'm sure it's a simple exercise to work out how. (Note that the bugs.debian.org urls linked from there will cease to work by the end of debcamp; hopefully we'll hook something up permanently to make up for it by then though) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpDDMYFohnUV.pgp Description: PGP signature
Qt3 still broken (compat-headers), what to do?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi ho, it's time for another rant from me regarding the libqt3-compat-headers split. This time my ex-housemate has been hit by the problem: she's just started working with Qt, and lo and behold she received a missing header compile error. She didn't look through README.Debian for the fix since it didn't occur to her that debian would deliberately break the Qt development environment like this. The motivation for this post is that I *really* want this issue fixed for sarge, lest we go through the whole debacle once more for users upgrading between stable releases. The contents of this email are as follows: 1. Problem description 2. Timeline 3. What can be done If you don't want to read this entire email, feel free to skip directly to section 3 where I discuss a possible Qt NMU amongst other things and ask for opinions. Otherwise, off we go. 1. Problem description Qt3 as produced by upstream includes a number of headers, including both modern headers and legacy headers to ease the Qt2 - Qt3 transition. In debian these headers are split into libqt3-headers and libqt3-compat-headers. There is *nothing* in the package management system to suggest to users that they might want libqt3-compat-headers. In particular, the main development packages (libqt3-mt-dev and libqt3-dev) depend on libqt3-headers but don't even mention libqt3-compat-headers (no depends, recommends or suggests). Several 3rd-party Qt apps still use these legacy headers. If a user tries to build one of these apps they get a compile error (missing header) and are given no further information. To find out how to fix this problem they have to (i) post to a mailing list or read an online FAQ, or (ii) think that perhaps this is a debian problem, not a Qt problem, and then think to read the README.Debian to see how and why debian introduced this breakage. The original motivation for this split was to encourage upstream developers to transition their apps from Qt2 to Qt3 headers, and to encourage users to hassle upstream developers because their debian build no longer works. The consequences of this split are that: (i) some upstream apps have migrated from Qt2 to Qt3 headers; (ii) many users have been confused by compile errors, as evidenced by posts to debian-kde over the past months; (iii) many people have simply installed libqt3-compat-headers to fix the problem, rendering the package split meaningless (since legacy headers in other Qt apps are no longer identified). There is a much less painful way to encourage upstream developers to migrate their headers; this is to run fixkdeincludes over the sources and email upstream the results. Of course this doesn't put the upstream developers under pressure from their users to fix what are debian-specific compile errors, which is presumably why the package split was used instead. The less harmful solution of putting #warnings in the legacy headers was proposed; this was rejected by the Qt maintainers because it differs from upstream's Qt release. Why silently moving all of the legacy headers into a separate not-installed-by-default package is more faithful to upstream's Qt release I do not understand. Most of the noise regarding this problem has died down, almost certainly because people who have already transitioned from woody to sid have experienced the problem, posted to mailing lists or read list archives and installed libqt3-compat-headers to get rid of the errors. Presumably the noise will start up again when we release sarge and get another round of errors and confusion from people upgrading from woody. I would like this issue resolved before this happens. 2. Timeline 3 Feb 2003: Headers are split; libqt3-compat-headers is born. 27 Feb 2003: The header split is discussed on -devel and -kde: http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg01724.html With the exception of a couple of vocal people (such as the Qt maintainers), IIRC most developers disagreed with the split. 17 Mar 2003: Ralf indicates in #184084 that the problem will be fixed, i.e., that libqt3-compat-headers will be introduced as a dependency for libqt3-dev and libqt3-mt-dev. This fix can be observed in KDE CVS (where the Qt packaging files are kept). 10 May 2003: A new Qt3 is uploaded to debian without the promised dependencies. 16 May 2003: These dependencies are removed from KDE CVS by the Qt maintainer: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/qt-copy/debian/control.diff?r1=1.56r2=1.57f=h The changes were never uploaded to debian. 3. What can be done I have been prodding on this issue for several months now with repeated posts to mailing lists and the Qt maintainers. A bug has been open (#184084) for this issue since 9 March. Despite what seems to be an strong majority of opinion against the split, nothing has been done, even though the fix is so utterly trivial (add
