Fwd: Hayes

Lubos Lunak kde-policies@mail.kde.org
Tue, 28 Jan 2003 13:52:19 +0100


On Tuesday 28 of January 2003 01:52, Rob Kaper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday January 28 2003 12:52 am, Marc Mutz wrote:
> > I'd say yes and yes. Plugins can deeply change the internals of
> > applications and lead to unstable apps.
> >
> > As far as plugins distributed with KDE releases are concerned, plugins
> > are oftern not very visible, so a badly written plugin will reflect
> > back badly on the app (maintainer).
> >
> > Things are of course different if the plugin is not distributed with
> > KDE. In that case, the user normally needs to install the plugin off
> > appsy or whatever and thus is well aware of the plugin as an entity of
> > it's own, separate from the app.
>
> The majority of users will get KDE through installations by distributions,
> which might include those by default anyway.

 But then it's a problem of the distribution, and the app maintainer can say 
"it's not in official KDE, use <some other place> to complain". If there's a 
bugreport for KWin talking about Liquid, those are simply sent to Mosfet 
after a quick check that it's not a problem in KWin itself (not that I have 
something against Liquid, but this one is simply outside of CVS).

 If some of the kwin styles in CVS was KWin "non-compliant" in some important 
way, I would also (as the current KWin maintainer) try to make its author 
either to fix it or to remove it from official KDE. For many users, a fault 
in the style would be simply KWin's fault, and they wouldn't be able to see a 
difference.

 Also, code from official KDE apps is often used as a base for developing 3rd 
party apps, or people who try to learn KDE programming learn often from it. 
We already ship enough awful pieces of code, there's no need to intentionally 
allow shipping more of it. What if somebody writes a new plugin based on the 
non-conforming one? It will be non-conforming as well, and the developer of 
it maybe even won't know, because "but I've written it based on that plugin 
officially shipped with KDE!".

>
> How about a clearer visibility and distinction of plugins in KAboutData and
> the bug wizard? If the main argument is that this distinction is missing,
> we should tackle that, and not try to fix it elsewhere in release policies.

 I think this would be often difficult to achieve. IMHO if the app maintainer 
and the plugin maintainer can't reach a consensus, then the maintainer should 
be the one to decide. And if the maintainer wouldn't want to be reasonable and 
e.g. provide flawed API for the plugins, well, that's another issue.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/