Policy for Dependencies
Kevin Ottens
ervin at kde.org
Tue Oct 20 20:26:49 UTC 2015
Hello,
On Thursday 15 October 2015 02:04:45 Aleix Pol wrote:
> On Wed, Oct 14, 2015 at 10:28 PM, Kevin Ottens <ervin at kde.org> wrote:
> > Hello,
> >
> > On Wednesday 14 October 2015 21:20:33 Christoph Cullmann wrote:
> >> Therefore my goal for frameworks is to make them actually as easy usable
> >> for people in that situation. We advertise that a lot everywhere but at
> >> the
> >> moment that is just not true beside for really simple stuff like
> >> "karchive".>
> > Just to put some historical perspective into this particular point. It
> > *is*
> > true, but for tier 1 and tier 2 frameworks only. That's why the dependency
> > rules of the tier system were designed the way they are.
> >
> > So if you are "people in that situation" as described by Christoph in his
> > email: stay away from anything which is above tier 2 or make it an
> > optional dependency. You still have more than 30 frameworks to pick from
> > for the other ones YMMV, you should be warned headaches might or might not
> > be ahead with tier 3.
> >
> > If you are someone working on a given framework and you are just content
> > of having it in KF5's tier 3, but did no refactoring or API work to get it
> > to tier 2 or tier 1: you're missing the point of KF5's tier and type
> > organization. You are also prematurely shrinking its potential user base
> > and that should bother you, really.
> >
> > If you remember the talk I gave back in the days about KF5, I mentioned
> > that the tier and type matrix is also a *maturity* system. It is our
> > responsibility to push the frameworks down the stack as much as possible.
> > Since then, I see lots of frameworks appearing, I don't see many of them
> > lowering their tier...
>
> Would it make sense then to define as part of the tier only the
> mandatory dependencies?
Perhaps that's what should happen indeed. I guess there's some potential
problems hiding though and it should be carefully evaluated. I also consider
that as the lesser path to be honest.
I much prefer some of the things we did back then with runtime detection
instead for soft-dependencies. What we did to get KMessageBox down the stack
is IMO what should be done at more places. Of course that can't be done
everywhere (especially if API is involved).
So instead of bending the rules or "just" providing compile time options to go
fast, I'd rather see real thinking put into reducing the dependencies when
problems arise. But hey, it's not like I'm going to do the work anyway. :-)
> Then the variable could be, instead of what Christoph proposed,
> something like KDE_ENFORCE_ALL_FRAMEWORKS.
Orthogonal aspect IMO. See David's summary on the build system knobs.
Regards.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151020/a9fe4c98/attachment.sig>
More information about the Kde-frameworks-devel
mailing list