kdereview exemption for PolicyKit-KDE

Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For the
most part, it is as feature-complete as we planned for the 4.2 release, but it
is still in playground. We'd like to request an exemption to the normal
kdereview period in order to get it in before the hard feature freeze. Would
this be possible?

On Sunday 16 November 2008 03:28:26 Trever Fischer wrote:
> Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For the
> most part, it is as feature-complete as we planned for the 4.2 release, but
> it is still in playground. We'd like to request an exemption to the normal
> kdereview period in order to get it in before the hard feature freeze.
> Would this be possible?

I'm honestly not hot on this in particular because it might become a very
central part of our frameworks. I'd be more relaxed for something less
critical.

Regards.
--
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

At Sunday 16 November 2008 03:28, you wrote:
> Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For the
> most part, it is as feature-complete as we planned for the 4.2 release, but it
> is still in playground. We'd like to request an exemption to the normal
> kdereview period in order to get it in before the hard feature freeze. Would
> this be possible?

On November 4th(!) Allen has made a Last Call for kdereview stuff, because the freeze is at the 17th.

You can not ask at the 16th to move stuff to kdereview for the 4.2 release. That means there is only one day to review it.....

Best,

Toma

On Saturday 15 November 2008 9:28:26 pm Trever Fischer wrote:
> Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For the
> most part, it is as feature-complete as we planned for the 4.2 release, but it
> is still in playground. We'd like to request an exemption to the normal
> kdereview period in order to get it in before the hard feature freeze. Would
> this be possible?
>

Trever,

Questions like this should go to the release-team@... mailing list.
So I am CC'ing for you.

But, really this is much too late.  This is essentially asking for us
to delay the KDE 4.2 release for PolicyKit-KDE.  And I don't think we
will agree to that.

-Allen

Am Sonntag, 16. November 2008 13:50:55 schrieb Tom Albers:
> At Sunday 16 November 2008 03:28, you wrote:
> > Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For
> > the most part, it is as feature-complete as we planned for the 4.2
> > release, but it is still in playground. We'd like to request an exemption
> > to the normal kdereview period in order to get it in before the hard
> > feature freeze. Would this be possible?
>
> On November 4th(!) Allen has made a Last Call for kdereview stuff, because
> the freeze is at the 17th.

I am by no means somebody to decide on this matter, but Toma has a point.

I'm not sure whether the following is a pro or a con, but since the app is
packaged and used by distros already, at least according to the package's
name, there was already a lot of testing (pro), yet it also means that for
distro users it does not matter that much whether it is part of KDE 4.2 or not
(con).

Sven

[Lubos Lunak]

On Sunday 16 of November 2008, Trever Fischer wrote:
> Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For the
> most part, it is as feature-complete as we planned for the 4.2 release, but
> it is still in playground. We'd like to request an exemption to the normal
> kdereview period in order to get it in before the hard feature freeze.
> Would this be possible?

 Is this about the code on which I worked few weeks back to get it from
doesn't-really-do-anything to hopefully-kind-of-works (and occassionally
guessed and so in the process, since PolicyKit happens to have nice extensive
and useless API docs)? I rather disagree with an exception for this. What
does currently depend on PolicyKit anyway?

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http://www.suse.cz

On Sunday 16 November 2008 08:06:44 am Sven Burmeister wrote:

> Am Sonntag, 16. November 2008 13:50:55 schrieb Tom Albers:
> > At Sunday 16 November 2008 03:28, you wrote:
> > > Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For
> > > the most part, it is as feature-complete as we planned for the 4.2
> > > release, but it is still in playground. We'd like to request an
> > > exemption to the normal kdereview period in order to get it in before
> > > the hard feature freeze. Would this be possible?
> >
> > On November 4th(!) Allen has made a Last Call for kdereview stuff,
> > because the freeze is at the 17th.
>
> I am by no means somebody to decide on this matter, but Toma has a point.
>
> I'm not sure whether the following is a pro or a con, but since the app is
> packaged and used by distros already, at least according to the package's
> name, there was already a lot of testing (pro), yet it also means that for
> distro users it does not matter that much whether it is part of KDE 4.2 or
> not (con).
>
> Sven

PolicyKit-KDE hasn't been packaged yet as far as I know. You might be thinking

of PolicyKit (the actual gui-independent daemon) or PolicyKit-gnome (the gnome
bits). There aren't any fedora packages for PolicyKit-KDE, so the only way to
get it currently is through the source.

On Sunday 16 November 2008 07:50:55 am Tom Albers wrote:

> At Sunday 16 November 2008 03:28, you wrote:
> > Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For
> > the most part, it is as feature-complete as we planned for the 4.2
> > release, but it is still in playground. We'd like to request an exemption
> > to the normal kdereview period in order to get it in before the hard
> > feature freeze. Would this be possible?
>
> On November 4th(!) Allen has made a Last Call for kdereview stuff, because
> the freeze is at the 17th.
>
> You can not ask at the 16th to move stuff to kdereview for the 4.2 release.
> That means there is only one day to review it.....
>
> Best,
>
> Toma

Technically I sent the mail on the 15th, but with it being the weekend and all

I understand. We're not asking for the formal kdereview process, but are
instead asking for some kind of exemption.

Kevin does make a good point though:
> I'm honestly not hot on this in particular because it might become a very
> central part of our frameworks. I'd be more relaxed for something less
> critical.
If KDE had a tighter integration with policykit, that'd be really slick.
However, these are just the KDE gui bits. Our code is just a KDE frontend to
the authenticator. Without this in 4.2, KDE can still use policykit, but it
requires the user to have PolicyKit-gnome installed to authenticate or change
the default permissions.

On Sunday 16 November 2008 08:33:38 am Lubos Lunak wrote:
> On Sunday 16 of November 2008, Trever Fischer wrote:
>
>  Is this about the code on which I worked few weeks back to get it from
> doesn't-really-do-anything to hopefully-kind-of-works (and occassionally
> guessed and so in the process, since PolicyKit happens to have nice
> extensive and useless API docs)? I rather disagree with an exception for
> this. What does currently depend on PolicyKit anyway?

Maybe, but now its in a state of it-just-works-with-minor-bugs.

Afaik, nothing directly depends on polkit-kde. However, hal depends on
PolicyKit. So to do certain hal functions with privilege elevation, the user
needs a gui for authentication. The only other known gui for this is
PolicyKit-gnome, so getting it into 4.2 will allow KDE developers to be a bit
more comfortable in knowing that if they end up use polkit for something
(indrectly or otherwise), KDE has support for it built in.

At Sunday 16 November 2008 19:28, you wrote:

> On Sunday 16 November 2008 07:50:55 am Tom Albers wrote:
> > At Sunday 16 November 2008 03:28, you wrote:
> > > Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For
> > > the most part, it is as feature-complete as we planned for the 4.2
> > > release, but it is still in playground. We'd like to request an exemption
> > > to the normal kdereview period in order to get it in before the hard
> > > feature freeze. Would this be possible?
> >
> > On November 4th(!) Allen has made a Last Call for kdereview stuff, because
> > the freeze is at the 17th.
> >
> > You can not ask at the 16th to move stuff to kdereview for the 4.2 release.
> > That means there is only one day to review it.....
> >
> > Best,
> >
> > Toma
> Technically I sent the mail on the 15th, but with it being the weekend and all
> I understand. We're not asking for the formal kdereview process, but are
> instead asking for some kind of exemption.

We have a two week review period, not two or three days. I don't see why an exemption should be made for you and not for others.

Toma

On Sunday 16 November 2008, Trever Fischer wrote:

> If KDE had a tighter integration with policykit, that'd be really slick.
> However, these are just the KDE gui bits. Our code is just a KDE frontend
> to the authenticator. Without this in 4.2, KDE can still use policykit, but
> it requires the user to have PolicyKit-gnome installed to authenticate or
> change the default permissions.

Then why not just move it to kdereview and after the usual review period to
extragear?

Distributions can then still package the latest stable version together with
4.2

Cheers,
Kevin

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

[Nicolas Lécureuil-2]

On Sun, Nov 16, 2008 at 7:20 PM, Trever Fischer <wm161@...> wrote:
> PolicyKit-KDE hasn't been packaged yet as far as I know. You might be thinking
> of PolicyKit (the actual gui-independent daemon) or PolicyKit-gnome (the gnome
> bits). There aren't any fedora packages for PolicyKit-KDE, so the only way to
> get it currently is through the source.
>

Btw, You have it on mandriva

On Sunday 16 November 2008, Tom Albers wrote:
> We have a two week review period, not two or three days. I don't see why an
> exemption should be made for you and not for others.

quite simply: to avoid having a gnome runtime dependency for use of policykit.

yes, we could move that off to distributions to fix, but that screws our from-
source users and continues this rediculous "let the distros fix things we
can't, even though we really ought to be able to" pattern of behaviour we tend
to exhibit at times.

while i completely understand the release team's desire to stick to the plan
for the health and benefit fo the project, i'd like to see us not become so
bound to a set of rules we make for ourselves that we end up shooting
ourselves in the foot just to "obey the rules".

in this case, allowing people to use policykit without having to install gnome
seems like a good thing.

i'm about to go take a look at this code in question and i'll report back in a
bit. something that it doesn't seem anyone else in this thread has actually
done yet?

--
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

On Sunday 16 November 2008, Kevin Ottens wrote:

> On Sunday 16 November 2008 03:28:26 Trever Fischer wrote:
> > Hi, I'm Trever, one of the 4 or so of us working on PolicyKit-KDE. For
> > the most part, it is as feature-complete as we planned for the 4.2
> > release, but it is still in playground. We'd like to request an exemption
> > to the normal kdereview period in order to get it in before the hard
> > feature freeze. Would this be possible?
>
> I'm honestly not hot on this in particular because it might become a very
> central part of our frameworks. I'd be more relaxed for something less
> critical.

is this default conservativism, or do you have actual issues with this code
that people should be aware of?

--
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

On Sunday 16 November 2008, Trever Fischer wrote:

> On Sunday 16 November 2008 08:33:38 am Lubos Lunak wrote:
> > On Sunday 16 of November 2008, Trever Fischer wrote:
> >
> >  Is this about the code on which I worked few weeks back to get it from
> > doesn't-really-do-anything to hopefully-kind-of-works (and occassionally
> > guessed and so in the process, since PolicyKit happens to have nice
> > extensive and useless API docs)? I rather disagree with an exception for
> > this. What does currently depend on PolicyKit anyway?
>
> Maybe, but now its in a state of it-just-works-with-minor-bugs.

what are these minor bugs?

--
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

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

[Lubos Lunak]

On Monday 17 of November 2008, Aaron J. Seigo wrote:
> On Sunday 16 November 2008, Tom Albers wrote:
> > We have a two week review period, not two or three days. I don't see why
> > an exemption should be made for you and not for others.
>
> quite simply: to avoid having a gnome runtime dependency for use of
> policykit.

 What use of PolicyKit?

> yes, we could move that off to distributions to fix, but that screws our
> from- source users and continues this rediculous "let the distros fix
> things we can't, even though we really ought to be able to" pattern of
> behaviour we tend to exhibit at times.
>
> while i completely understand the release team's desire to stick to the
> plan for the health and benefit fo the project, i'd like to see us not
> become so bound to a set of rules we make for ourselves that we end up
> shooting ourselves in the foot just to "obey the rules".
>
> in this case, allowing people to use policykit without having to install
> gnome seems like a good thing.

 They could still get it from extragear or wherever and install it, if they
manage to install also software that actually needs it. I fail to see what is
so special about PolicyKit and KDE4.2 that it should be worth an exception
for a tool that couldn't even ask properly for a password 3 weeks back. The
universe will still exist even if policykit-kde moves to kdebase only after
4.2.

> i'm about to go take a look at this code in question and i'll report back
> in a bit. something that it doesn't seem anyone else in this thread has
> actually done yet?

 I can save you some work there. Just grep for the 'TODO' notes I've left and
svn log on src/policykitkde.cpp is an interesting read too (although it
misses "now it seems to be good enough for kupdateapplet and I couldn't care
less about the rest right now" stated explicitly somewhere).

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http://www.suse.cz

On Sunday 16 November 2008 06:37:59 pm Aaron J. Seigo wrote:

> On Sunday 16 November 2008, Trever Fischer wrote:
> > On Sunday 16 November 2008 08:33:38 am Lubos Lunak wrote:
> > > On Sunday 16 of November 2008, Trever Fischer wrote:
> > >
> > >  Is this about the code on which I worked few weeks back to get it from
> > > doesn't-really-do-anything to hopefully-kind-of-works (and
> > > occassionally guessed and so in the process, since PolicyKit happens to
> > > have nice extensive and useless API docs)? I rather disagree with an
> > > exception for this. What does currently depend on PolicyKit anyway?
> >
> > Maybe, but now its in a state of it-just-works-with-minor-bugs.
>
> what are these minor bugs?

The ones off the top of my head I can recall are it not properly grouping items

in the display list, some incorrect assumptions about dbus calls that lead to
crashes, a random freeze on the 'modify' button, and some strings that, imho,
could be changed to make more sense. And those TODOs in the source.

> * 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.
>
I wasn't sure how to best go about this proposal, so I just asked if it was
possible, opting to give whatever more details people needed. Seemed mildly
harmless to me at the time.

What works:
* Listing possible actions and their details that are defined in policykit.
* Asking for the password when authorization is needed.
* Changing implicit authorizations
* Resetting implicits
* Displaying the list of explicit authorizations for the current user

What doesn't work:
* The list model emits reset() after every change to policy, so expanded items
collapse, etc
* Reverting the implicit auths to defaults doesn't update the display.

What really needs fixed:
* Crashes on exit
* The random freeze when 'modify' is clicked to save the implicits. It might
just be my system though, as I notice it only happens when 'policykit-kde' is
running, which isn't part of the latest polkit-kde...
* Managing explicit authorizations.
* Showing authorizations for users other than the current one.
* Display details about explicit authorizations

The last two items in the FIX NOW list can be written up in just a few hours.
They're just not in yet for lack of time on our part.

[Thiago Macieira]

Aaron J. Seigo wrote:
>* 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)

I don't see how you can write a proper event loop integration in 650 lines
of code. Much less the integration plus the application code.

So, where is the event loop integration code for the convenience lib? Or,
another related question: why use the lib instead of QtDBus generated
wrappers around the D-Bus calls?

--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358