Re: KDE 3.3.1 for Sarge
* 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].
Reply to: