On Mon, 8 Dec 2008 21:49:09 +0100 Morten Kjeldgaard <mok@bioxray.au.dk> wrote: > One of the purposes of Debian and the FOSS community is to make it > possible to develop and distribute software that is authored and > supported by volunteers. True. > We have a responsibility of supporting > software components that are still being used by people. Hmmm, no - not completely, not even if you add the missing "free" in front of 'software components'. Still being used is not a safe or sane criterion, still being supported is more important. Bit rot is the constant enemy and there is no good reason to retain unsupported code in Debian. You say you have offered to maintain gtk1.2 but that is not the complete solution - it is dead upstream and that severely compromises the "value" of merely having a willing maintainer in Debian, unless that maintainer also takes over upstream maintenance of the codebase which, frankly, makes absolutely no sense. Again, I have done this and I continue to do this - I try never to speak from a position that I have not experienced personally. Taking over upstream is a significant burden and it is immensely stupid to take over maintenance of a codebase that has already been replaced and for which a clear, supported and proven upgrade path is both well established and thoroughly debugged. For one thing, such a choice glibly ignores all the bug fixes made in the new version - those simply cannot be backported to gtk1.2 because the bug fix needs to be implemented via a restructuring of the code that will force a SONAME bump. > There are > people other than Debian Developers using the distribution, they > might not be using the latest versions of the toolkits, but that is > their choice. Then their choice can be supported by oldstable. That is no justification for using gtk1.2 with newly written code in unstable. Choices have consequences - one consequence of choosing gtk1.2 for newly written code is that people who know a whole lot more than you about writing secure, portable, usable code get a chance to laugh at you hysterically because you made such an insane choice. The fact that someone chooses gtk1.2 does not mean that Debian has any responsibility to include that code - in fact it means the exact reverse. Debian has a responsibility to provide stable, secure, portable code. gtk1.2 is none of those things, not any more. I have written code using it, I have debugged code written against it, I have ported packages away from it and I can say with some degree of certainty that gtk1.2 is *not* stable, secure or portable against the versions of other libraries in unstable. Things have moved on and gtk1.2 has been left behind - DELIBERATELY. That situation can only ever get worse - nothing will ever be improved within gtk1.2 - that alone makes it insane to write new code that uses gtk1.2. How are you going to fix a new security bug in gtk1.2 should it come along? > As long as there is interest in the FOSS community for > a specific component, it should be maintained in Debian. WRONG WRONG WRONG. As long as there is SUPPORT in the FOSS community for a specific component then it CAN be maintained in Debian. There is no 'should' involved. Debian has absolutely NO responsibility to package any specific piece of software, especially unsupported libraries. Support means upstream support, not merely a Debian maintainer. Nobody can require that Debian contains a specific package. I've said this many times, Debian is categorically not a dumping ground for every piece of bit rot free software on the internet and beyond. I deliberately include gtk1.2 in the category of bit rot software. Equally, I will consider libqof1 (my own upstream library) bit rot software as soon as I release libqof2 after Lenny. Don't come crying to me looking for support for libqof1 after that date as the reply is guaranteed to offend. I have taken sufficient steps to ensure that all reverse dependencies can already work with libqof2 but this is easy for me because there aren't many of them. The problem with Gtk is the sheer weight of reverse dependencies and the sad reality is that some of those packages *MUST* die simply to ensure that gtk1.2 can be laid to rest in peace for evermore. gtk1.2 deserves to be removed - it is unsupportable and your offer to maintain it makes me seriously doubt whether you understand what is actually required to do so. > I am not saying that all rdepends of GTK+ 1.2 should be kept in the > distribution. My position is that it is too early to retire the > library GTK+ 1.2. I have offered to maintain it. Maintaining it is insufficient and taking on the upstream codebase is completely insane. The code is dead, long long dead. There are no sane reasons to use gtk1.2 code in any newly written code - that includes within gtk1.x itself. If you doubt my assessment, speak to any of the authors of gtk1.2. > If you want to change my opinion on this, you have to present valid > arguments and not ridicule and/or exaggerations. I think I have the knowledge and direct experience necessary to put forth such arguments and I believe that I have earned the respect of many people in Debian for the quality and quantity of my work both inside Debian and on a multitude of upstream projects that support Debian packages. Do not think that I speak from a position of ignorance of gtk1.2 or of the work involved in porting packages to gtk+2.0. Indeed, I get the impression that I have far more direct experience of precisely this task than you. I wrote gtk1.2 code, I've ported gtk1.2 packages to Gtk+2.0 (not all successfully) and I have started up new upstream projects from a clean codebase directly to Gtk+2.0 support, as well as using this knowledge to help port other Debian packages to Gtk+2.0, as with gdis. I therefore make a bold statement to you: If you want to change *my* opinion on gtk1.2 you are going to have to present valid arguments for retaining it because in my opinion, none of your arguments to date have withstood a perfectly rational and purely technical critique. In my not so humble opinion, gtk1.2 is wanton bit rot. It is unsafe to use as a development platform, nobody with any respect in Debian or outside would recommend using gtk1.2 for ANY newly written code - least of all the GTK upstream developers who wrote the code in the first place. Even patching gtk1.2 to improve the code is, IMNSHO, a lesson in abject futility because there can be no possible justification for not using the proven upgrade path to Gtk+2.0. I assert these statements as self-evident with regard to gtk1.2: 1. It is wholly and completely deprecated code. 2. No upstream support has existed for a prolonged period of time and nobody has seen fit to step in - I would propose that this is due, in no small part, to the proven upgrade path to Gtk+2.0 3. There is no justification for using gtk1.2 with newly written code. 4. Applications using gtk1.2 have already had a very prolonged period during which to achieve the necessary port to Gtk+2.0 - including GnuCash which is commonly accepted as the one mainstream Gtk application with active upstream support that had the longest and most difficult transition to Gtk+2.0 All of this is evident merely from the authors of gtk1.2, without getting into the details of distributions. Proposing any further extension of support for gtk1.2 is proposing to further undermine the development of free software by the retention of outmoded, insecure, abandoned code that gets worse and worse with every year. gtk1.2 is a horror story from the perspective of 20:20 hindsight; the codebase reeks of unworkable concepts and unwise abstractions. It was fantastic at the time but that time has come and gone far, far away. gtk+2.0 is getting old-in-the-tooth and v3 is much awaited for precisely the same reasons as gtk+2.0 is better than gtk1.2. There comes a time in the life of any library, that the codebase simply cannot stand any more improvements without large amounts of restructuring and for that restructuring to occur, a SONAME bump must happen. The code from before the SONAME bump is, by definition, hacked to the nth degree, it has been patched and poked so many times that the codebase gets to look like a threadbare carpet. The SONAME bump occurs for very, very good reasons and the code that arrives after the transition (although some settling down time might be necessary) is more coherent, easier to support and easier to continue development until such time as the next SONAME bump becomes inevitable. Gtk+2.0 has had more than enough time to settle down after the SONAME bump and has gained the respect of upstream developers as the most common GUI for upstream projects written in C (where Qt is probably the same for C++), as well as picking up bindings for other languages. This is the reality of library development, not just in free software but anywhere where the goal is stable, secure, portable code. I cannot actually believe that you think it is a rational choice to go backwards to such a horribly mangled codebase as gtk1.2. IMNSHO, the mere fact that you are even considering this as a viable choice makes me think that you simply do not understand what is at stake. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpZKD41z9rzd.pgp
Description: PGP signature