Report from Akademy Packager BoF

[Kevin Kofler]

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