kdereview exemption for PolicyKit-KDE

[Aaron J. Seigo]

On Saturday 15 November 2008, Trever Fischer wrote:
> Would this be possible?

Important points:

* This will break our freeze; or at least, it will given the length of the 
discussion we seem to be in for here.

* There won't be time to do a kdereview move of the code, it would have to go 
straight to kdebase. But a lot of code in KDE does this, so let's not kid 
ourselves on the one hand.

* We should obviously default to respect of the release schedule, but the 
moment we lack the flexibility to know when to bend a day here or there, the 
rules win and we (KDE) lose.


What is PolicyKit:

* PolicyKit, which is a framework for users to run priveleged code/commands in 
a way that can be controlled by system wide policies without the user 
requiring special priveleges (e.g. all those "enter your root password" diaogs 
we have; many of which could be much more sanely and safely replaced by 
using PolicyKit)

* It is used more and more in modern distributions for things like installing 
a package or setting the system time.

* Applications use it over D-Bus. There is no required library to link to 
(though there is a "convenience" C lib out there)


What PolicyKit-kde is:

* The required GUI bits for PolicyKit.

* It is two exectubles, one is 844 LOC and the other is 648 LOC. They 
communicate with PolicyKit via D-Bus, and link against libkdeui (and it's 
dependencies) and the PolicyKit libraries (e.g. the dbus convenience lib)


What PolicyKit-kde isn't:

* A framework. It's two apps that work with the PolicyKit framework. PolicyKit 
is the framework, PolicyKit-kde is sort of the equivalent of pinentry-qt for 
gnupg.


Why PolicyKit-kde is important:

* PolicyKit is an important feature for KDE to take advatage of (particularly 
in things like system settings) but right now using it for anything that 
requires user interaction means having GNOME installed as PolicyKit does not 
provide the GUI, but relies on a desktop environment for that. 

* It's also important because system tools these days often use PolicyKit, 
meaning that even if you use KDE you still need GNOME installed on those 
systems


Why PolicyKit-kde should be in 4.2:

* So we aren't waiting another 6 months in this, frankly, embarassing 
situation

* So KDE appication devs (who overwhelmingly work against the last released 
version) can start using PolicyKit in their apps sooner rather than later

* It is already being packaged and used by some distributions (though 
certainly not all)


Why PolicyKit-kde should not be in 4.2:

* It missed the deadline for review

* It probably hasn't had the testing it needs. We have the next two months to 
do that with it in kdebase, however, should it go there.

* It's not 100% feature complete. I see a couple TODOs in the code, but 
nothing that looks critical to use. So this is a very week point in the 
"should not" column


My personal recommendation:

* We include PolicyKit-kde so as to fill this hole. The only reason we wouldn't 
at this point would be to stick to our schedule principles, which seems to be 
very unpragmatic to me in this situation. Our job in KDE is to create good 
software; the schedule is there to help us do that. Our job is not to follow 
the schedule, however; it's there to help us create good software, but should 
not be allowed to get in the way of that.

* The PolicyKit-kde devs give us a *full report* as to what works, what 
doesn't, what needs to be improved ASAFP. Given their request for an 
exemption, they should have done this right from the start. A three sentence 
request email with no context, no explanation and no description of the 
product seems pretty weak.


Some closing remarks:

* As for the "but then what point is there in having a schedule?!" point: the 
point of having a schedule is to provide order and discipline, to rule out 
those cases that aren't in our best interest even if it's not convenient. It 
is not there to make KDE worse. This is where common sense and reason must 
come into play.

* Given that PolicyKit-kde is two small apps that nothing links against (They 
aren't libs!) this makes it trivial for us to fix them or even outright replace 
them should we want to. The API they use is set by a third party, PolicyKit, 
not the PolicyKit-kde apps. This limits the risk involved substantially.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081116/3640f5bd/attachment.sig>