Hi,
yesterday, we had a packager BoF at Akademy. The Fedora representatives were
me and dvratil (who was sitting around not attending any session, so I asked
him to come with me ;-) ), mostly it was me talking for us. Jgrulich planned
to attend, but did not make it because he had to take Thomas Pfeiffer to the
hospital with a leg injury.
There were not only GNU/Linux distributions represented, but also BSD and
the kdewin project (KDE for that horrible proprietary operating system you'd
want to throw out of the, well, window :-) ), and the Debian folks also
spoke for their bastard GNU/kFreeBSD port and their GNU/Hurd port.
It turns out the main pain points for us all lie in system integration, but
the issues we're having are different. The kdewin folks of course have
problems getting ANYTHING that integrates into the system to work, it always
has to be ported explicitly because their system is totally different. For
*BSD, Hurd and the like, the problems are dependencies that only support the
Linux kernel (ALSA, systemd etc.). And for us in Fedora, it is of course the
shared dependencies getting upgraded under us that KDE does not support yet.
There, the tenor was that KDE really needs to know on an earlier notice
about such changes, and I'd tend to agree with that, so I guess the REAL
problem has to be solved somewhere other than KDE. One big source of pain
was NM 0.9 and how it was dumped into F15 post-freeze on a basically
nonexistent notice. The "compromise" the NM developers came up with (the
hacked NM speaking both APIs) just didn't work out and ended up having to be
replaced in an update. Lamarque (who did the NM 0.9 port of the Plasma NM
stuff upstream) happened to be at the BoF and rightfully pointed out that
they got no notice at all from us that 0.9 support was needed until the
damage was already done, and we Fedora KDE people couldn't give him the
notice because nobody had told *us*, either. Sigh… Others I remember were
PolicyKit 1 (alias "polkit"), where we ended up having to ship the GNOME
auth agent even for KDE for a release, and BlueZ 5, where at least we got a
prerelease of BlueDevil in time.
There was also some discussion about release cycles. (I brought up that
Plasma and Apps releasing a few days after Frameworks as is now being
planned is suboptimal for us because it means we either delay the Frameworks
updates until the other stuff is out, or push Frameworks first and delay the
other stuff until Frameworks reaches stable, which means ~2 weeks.) There
were also some complaints about the monthly Frameworks releases, which are
"Firefox-style" releases, i.e. mixed features and bug fixes with no stable
branch. The kdewin folks were complaining that a release per month was just
too many for them (and also some small GNU/Linux distros) to handle to begin
with, others have the problem (already brought up on the mailing lists) that
they cannot push such releases that are not bugfix-only out to their stable
distro releases. This one is actually not really a problem for Fedora. We're
planning to just push those Frameworks updates in monthly pushes (i.e. one
per upstream release) as long as they don't start doing silly things like
changing the sonames of their libraries. At least that's what the consensus
was in the KDE SIG meetings so far (and what IMHO is the most sensible
plan).
There has also been some discussion about KDE requirements on things like
kernel settings. Somebody from upstream, I think it was Vishesh from Baloo,
asked us whether it'd be helpful for us to have KDE come with a list of
required kernel settings. We packagers pretty much agreed that such
requirements were not acceptable at all to begin with, but Vishesh and (with
his Phonon upstreamer hat on) apachelogger said that the software just can't
always work with the broken settings. There wasn't really a conclusion
reached on that issue, except that it probably has to be decided on a case
by case basis. The case in point was that, in order to be fast at indexing
(10+ times faster than e.g. Tracker) without hogging the HDD and the CPU,
Baloo needs some special scheduler options that only work in the default
Linux scheduler (CFQ) and not in the deadline scheduler Ubuntu is using. We
told them that distro kernels also need to work for GNOME and for non-
desktop use cases (server etc.) and thus we cannot necessarily satisfy every
settings request from KDE. I also compared it with the infamous Oracle
database.
Those were the main topics that have been brought up, the system integration
one having been the biggest one. We would probably have come up with more,
but at that point we ran out of time (we only had a 1-hour slot) and
deferred to mailing lists (most likely kde-packager).
Kevin Kofler
_______________________________________________
kde mailing list
kde@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kde
New to KDE4? - get help from http://userbase.kde.org
