kdereview exemption for PolicyKit-KDE

[Kevin Krammer]

On Monday 17 November 2008, Aaron J. Seigo wrote:
> On Monday 17 November 2008, Kevin Krammer wrote:
> > On Monday 17 November 2008, Aaron J. Seigo wrote:
> >
> > So PolicyKit-KDE is not a framework but developers working with the
> > lastest release would need it?
>
> it's a simple matter of connect-the-dots:
>
> * if there is no KDE GUI for PolicyKit, will people be more or less
> encouraged to use it where appropriate from their apps?

Well, I agree that having a KDE GUI is a bonus, however I think not having 
a "standard" Qt-style API is probably more a blocking issue than not having a 
GUI for application users on the KDE workspace.

As Thiago observed earlier on, there seems to be some kind of reluctance to 
use a service's official API through Qt's capabilities so developers resort 
to hacking around wrappers.

> * will we go out and encourage people to use PolicyKit in their apps in our
> blogs and what not until there is a KDE GUI so we don't appear to be second
> class citizens there?

I have to admit that I am kind of worried to officially support a new service 
without knowing the developers' position related to the service upstream 
project, i.e. if they believe they can follow changes in timely manner even 
if the upstream pulls "a NetworkManager" [1]

> it's not a matter of "need" as much as "in all likliehood, far fewer KDE
> devs will work with it until there is a KDE GUI for it."

I agree, a problem until we have the concepts of platform not so tightly tied 
to workspace anymore.

> > > Why PolicyKit-kde should not be in 4.2:
> > >
> > > * It missed the deadline for review
> >
> > There is still plenty of time to get it reviewed properly and release
> > according to its own schedule, just not KDE's main one.
>
> that's a great way to avoid the issue. i'm not sure avoidance is what we
> should be aiming in for in this case. in fact, i'm rather convinced it
> isn't.

Well, seems we disagree on this one.

> > > * 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
> >
> > Especially considering this point I'd say that having it on its own
> > schedule has additional benefits.
> > Like allowing new releases in the time between 4.2 and 4.3, not requiring
> > backporting by distributions which want those improvements, etc.
>
> where to begin..
>
> * there is a reason we do collective releases of certain feature sets.
>
> * they can do independent releases if they want, just as any other app can,
> regardless of where they are.

Hmm, how does this work. Isn't a branch feature frozen once it is released? 
How are the new strings translated reliably outside string freeze?

> * which brings us to the real issue of relying on downstream to integrate
> the pieces that obviously belong together. it's a responsibility we should
> take more seriously that we do or have.

I think we should be able to provide the accessor capabilities for as many 
infrastructure components as possible, though it will still be the system 
integrator's choice and responsibility to decide which components they want 
to take.

They don't seem to have a problem of taking Amarok and K3B from extragear as 
part of the multimedia efforts.
Some distributors don't care about a consistent KDE workspace experience no 
matter how hard we try to. See [1]

> i'd also note that our downstreams haven't seen fit to write this code.

I am not sure why downstream should have written this code, but who writes the 
code for the GNOME GUI?
GNOME or upstream PolicyKit?

> along come a couple of people who decide to take it on. we ought to realize
> that this particular area is an important one and worth incubating with
> care. build excitement and commitment in these people, don't stonewall them
> until we end up with yet another bit of unmaintained cruft in extragear.

So you are afraid that these new developers will not stay around for 
maintenance? Not even long enough for development of 4.3 being opened?

> and don't get me wrong, extragear is great, but only when used to its
> strengths rather than as a dumping ground. (a mistake i've made in the past
> myself.)

If you see it as a dumping ground that it is obviously not a good idea to put 
anything important there.
I thought about it as a possibility to allow the project to tap into KDE 
resources while keeping the option to release as part of upstream 
(PolicyKit).

Cheers,
Kevin

[1] Just in case anyone doesn't know about it: NetworkManager upstream decided 
to redesign their official (D-Bus) interface without any compatibility 
measures and certain bleeding edge distributions decided to ship this version 
(some of them even before it got released!). 
Without either knowing that upstream understands the implications of 
developing infrastructure or our frontend developers having the resource to 
follow an incapable upstream we are not even talking about second class here.

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081117/db639749/attachment.sig>