* Steve Langasek [Sun, 21 Nov 2004 02:47:35 -0800]: > KDE 3.3 in sarge is contingent on the KDE maintainers being able to provide > the same sort of assurances that were asked of the GNOME maintainers > regarding the safety of allowing these packages to trickle in (i.e., the > correctness of the package relationships), which calls for comprehensive > partial upgrade testing.
I have mixed feelinks when wrt 'partial upgrade testing' in KDE. we know from experience that KDE upstream really ensures that their monolithic x.y.z works together nicely, but that mixing even minor point releases can break things very badly. so, testing can you give the impression that the mixture works, but then it can show breakage unexpectedly. while is true that this could happen with Gnome too, it seems to me that for KDE the probability is much higher. > I understand that kparts makes the package relationships more complex than > those expressed in shlibs alone. This is one concrete reason I know of why > testing of partial upgrades is called for -- though of course, there may be > other reasons I don't know about, as well. my personal view/wish of the transition would be to let it happen, in a carefully chosen date, the more packages at once the better. if I'm not wrong, the full transition can happen, *without* *hints*, in three britney runs (kdelibs, then the core of kde, then 5 or so extra packages). IMVHO, such transition would have much less probability of breaking anything, in fact I think is as good as it can get, given kde's characteristics. * * * (the release managers may wish to skip this section, but please read the next one.) I attach the current state of kde packages. as calc already stated, they're mostly ready. kdemultimedia just needs the alpha buildd admin to have a look, and kdenetwork's dependencies will be satisfied soon. barring those two, the only important issue remaining is kdepim, which I think should get re-uploaded to fix the build system and fix a couple of dependency issues (e.g., #274611). * * * KDE 3.3.1 seems in quite good shape, being #266760 the only serious issue which can be resolved with a new arts upload. also, all the t-p-u uploads (of which at least 2 are remaining: kdegraphics for #278173 and #280373, probably kdenetwork for #282232) could be dropped, since all issues are addressed in sid. there is, however, one big issue left. my above talking about partial upgrades and leting all the transition happen at once, referred only to official KDE packages. but there is, as you know, nearly a hundred packages currently stalled by kdelibs (some with t-p-u uploads) that would become elegible for sarge once kdelibs 3.3.1 was allowed in. I have two concerns wrt these packages: 1. since there is no tranisition-all-at-once for them, one has really to check that the existing version in sarge will work correctly in a KDE 3.3 environment, as newer versions may or may not make sarge. if/when the KDE transition is approved, and before it happens, I volunteer (help welcome) to check the above, either by installing kdelibs 3.3 in a sarge system, or by installing the sarge verions of the packages in a sid system. most likely, will send mail to maintainers, too. 2. most importantly (but perhaps I'm being too paranoid here), and as all these packages were well known to be blocked from sarge, their versions in sid may not be really good release candidates (imagine, e.g., that an experimental version was uploaded to sid "because it won't enter sarge anyway"). hopefully, not candidate packages will have serious+ bugs on them, but I prefer to bet on the safe side. I'm seeking advice as how to deal with this (but perhaps the advice is "the RMs don't see #2 as a real problem"). the best I could come up with is a mass bug filing of 'serious' bugs tagged sid to all this packages, asking the maintainers to: (a) check if the package in sarge works in a KDE 3.3 environment (so that work for people helping with #1 can be reduced) (b) close the bug if is their opinion that the package in its current form is available for release. * * * and that was all for now, I think. sorry, as always, for the lengthy mail, and keep up the good work. cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson
arts - In testing, should take care of #266760. kdelibs - Ready to enter kdebase - Waiting for kdelibs. kdegraphics - Waiting for kdelibs. kdeutils - Waiting for kdelibs. kdeadmin - Waiting for kdelibs. kde-i18n - Waiting for kdelibs. kdegames - Waiting for kdelibs. kdetoys - Waiting for kdelibs. kdeaccessibility- Waiting for kdelibs. kdeartwork - Waiting for kdelibs, kdebase. === kdenetwork - Waiting for kdelibs, wireless-tools. [wireless-tools is building on m68k.] === kdemultimedia - Waiting for kdelibs. Builds: alpha ["Building" for 2 weeks]. === kdeedu - Waiting for kdelibs. Builds: mipsel [build failure]. kdebindings - Waiting for kdelibs. Needs 4 more days. Builds: mips, mipsel [needs D-W state removed]. === THE KDEPIM ISSUE kdepim - Waiting for kdelibs. Builds: m68k, powerpc, s390 [takes ages, requires 3GB+]. Probably needs another upload (see also #274611). kdesdk - Waiting for kdelibs, kdepim. Builds: m68k, s390 [D-W on kdepim]. kdewebdev - Waiting for kdelibs, kdesdk. Builds: m68k, s390 [D-W on kdepim]. kdevelop3 - Waiting for kdelibs, kdesdk. Builds: m68k, s390 [D-W on kdepim]. Should have versioned build-depends on libcvsservice (need upload?). kdeaddons - Waiting for kdelibs, kdebase, kdegames, kdemultimedia, kdepim. Builds: alpha, m68k, s390 [D-W on kdemultimedia (alpha), kdepim].