* Ian Reinhart Geiser [Thu, 31 Mar 2005 10:32:25 -0500]:
Hello Ian,
> > the point is you're wrong. kde 3.4 is *not* BC with kde 3.3. the recent
> this should be not the case, if there is BIC changes then it must be on
> debian's patch sets.
(For the record, there are very few Debian specific patches in our KDE
packages. We do include branch pulls from CVS, though.)
> We have a policy of no BIC changes until the 4.0
> release. If this policy was violated we should (have) notified the KDE
> development team. Applications compiled vs 3.1 and greater are suppose to
> run without penalty under 3.4.
While I positively see that this holds true for kdelibs and other
libraries, and changes are reverted whenever they are spotted,
experience tells us that is not like this for module specific
libraries.
E.g., some kdepim libraries have removed symbols in point releases, so
the maintainer was forced to rename them. From the changelog at [1]:
- in 3.3.1, libmimelib1 -> libmimelib1a, libkleopatra0 ->
libkleopatra0a.
- in 3.3.2, libkcal2 -> libkcal2a.
[1]
http://packages.debian.org/changelogs/pool/main/k/kdepim/kdepim_3.3.2-2/changelog
And, as recently discovered, kdesdk's libcvsservice in 3.4.0 too.
While this could be excusable if those libraries were only used
withing their modules, this is not the case: libcvsservice has caused
segfaults in quanta and kdevelop (btw, the maintainers of kdesdk,
quanta and kdevelop are three separate persons in Debian), and
libmimelib is used in at least one completely KDE-unrelated project
(the mailing list archive handling tool 'lurker').
> > problem of libcvsservice (see archives of debian-kde list) shows that,
> > and IMHO, it's out of question to put 3.4 in stable.
> again was KDE even made aware of this?
Uhm, I'm quite sure that kdepim's maintainer Daniel Schepler did back
in November, when 3.3.1 was packaged and the issue discovered. I would
have to ask him to be completely sure, though. Shame on us if we didn't.
> > but maybe others in the team may have things to add ?
> It might be useful if we get more KDE involvement to help the debian
> packagers
> be more informed of what is going on. its probably that involvement that has
> helped the kubuntu guys get so far along so quickly. I know many of them
> are directly involved with KDE development, and the KDE organization.
Uhm, well. Ubuntu and Debian are quite different. In Ubuntu things
happen _fast_, because of their spirit and also because of their
resources. In Debian, individual developers can move fast, but the
distro as a whole is slow.
Just as a side note, the Kubuntu crew fully acknowledge the fact that
without the initial 3.4 packaging efforts of the Debian maintainers,
the wouldn't been able to go so fast.
> if you guys need any help, resources or information please let me know and we
> can see about getting you guys more in the loop. the real tragedy would be
> that debian stable repeats the catastrophe on the desktop that KDE suffered
> under woody. while kubuntu is a neat idea, i personally would like the
> reference debian to be something we can brag about too.
Well, I don't think that shipping with 3.3.2 instead of 3.4.0
qualifies as "catastrophe". _If_, as it has happened in previous
months, Sarge continues to get delayed, one would consider 3.4.x, but
I think that'll not be the case (and I _pray_ it isn't, really).
Some weeks ago, we asked people on the debian-kde lists that they
raised issues that they considered were a must-fix for KDE 3.3.2.
Several came up (that I can remember off hand: a kopete crash with
ICQ5, and kate printing almost 100MB/hour of debug output), and those
have been fixed. Which wasn't always easy, given that no more
backports happen in _3_3_BRANCH once _3_4_BRANCH is created. If there
are some other left, we can have a look.
About the offer for help, well, if you have any insight what could be
the best approach to dialog about the GFDL, it'll be appreciated.
And last but not least, thanks for your interest, Ian! :)
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Algebraic symbols are used when you do not know what you are talking about.
-- Philippe Schnoebelen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
