kdereview exemption for PolicyKit-KDE

[Aaron J. Seigo]

On Monday 17 November 2008, Kevin Krammer wrote:
> 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.

yes, that would be the next step.

(and let's not forget about system services that use policykit that exist 
outside of kde that we'd still like to work well with)

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

i don't think that's exactly the cas here ...

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

this is certainly a risk we run.

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

we have kdebase/runtime and kdelibs for the platform.

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

fair enough =)

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

branches are magical.

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

at the final point, yes, obviously. it doesn't mean we can or should rely on 
them to do all the work for us in determining what a good desktop set actually 
is.

> They don't seem to have a problem of taking Amarok and K3B from 
extragear
> as part of the multimedia efforts.

fine, then let's disband all the modules and have one module per library or 
application and deliver it 100% ala-carte with no combined releases at all. 
yeah, i know, that's stupid, right?

see, there's a middle ground here, one where we have a base set of "really 
important things to have so you have a basic envirionment" tools and then a 
galaxy of really great add-ons.

integration with OS services is not a "really great add on". getting that 
classification clear in our heads is pretty important.

> Some distributors don't care about a consistent KDE workspace experience 
no
> matter how hard we try to. See [1]

just because some downstreams display a lack of brilliance doesn't give us a 
reason to stop striving ourselves.

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

when we treat new contributions with what appears to be a lot of hassle and 
headache (aka beaurocracy) we discourage contribution, yes. whether these 
particular devs would be discouraged and fall off because of this or not, i 
can't say. but odds are better that a dev will stick around if they are 
greeted with enthusiasm and support.

in this case, the usefulness of the topic and the rarety of people working on 
it behooves us to be more lenient.

> > 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 said we shouldn't use it as a dumping ground, not that it is a dumping 
ground.

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

the option would remain either way? though i haven't been impressed to date 
with the results of such efforts.

-- 
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/20081117/0ce62223/attachment.sig>