[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: How to promote less mature Frameworks?
From:       Alex Merry <alex.merry () kde ! org>
Date:       2014-08-15 8:34:04
Message-ID: 64013694.TlQARPTQjr () typo
[Download RAW message or body]

On Friday 15 August 2014 10:21:57 Mark Gaiser wrote:
> On Fri, Aug 15, 2014 at 12:12 AM, =C0lex Fiestas <afiestas@kde.org> wrote:
> > Hi there
> > =

> > At the Randa sprint we have discussed a little bit what to do with those
> > frameworks that are still not mature (for example they can't commit on
> > ABI/API stability) but they are ready for feedback from third party
> > developers.
> > =

> > Even though there was not consensus in the discussion this is an idea t=
hat
> > came out during the discussion:
> > =

> > -We introduce a Maturity level that we can use to manage expectations
> > about
> > the Framework (for example whether API/ABI will be kept)
> > -We release Frameworks that are not ready together with the rest, but we
> > have to make damn sure we manage expectations.
> > =

> > With this we can get early feedback for new frameworks, and since we ha=
ve
> > a
> > rapid release cycle we can improve them fast.
> > =

> > What do you think?
> =

> It depends on how you define maturity.
> =

> For instance, if a maturity is simply a value set in each project'
> metainfo.yaml and set by those that maintain it then the maturity
> level quite frankly doesn't tell you anything.
> =

> But if you decide maturity dynamically based on git activity, api/abi
> stability, number of people contributing and where the project itself
> is used in other projects (just some conditions that i can think of
> now, there is probably more). With this a project maturity actually
> has a meaning. When going for this approach it would also be nice to
> show a list of projects using "Framework X". Also, i do not consider a
> project being healthy when it has only one developer [1] even if the
> project is used by dozens of other projects and has much activity. For
> us - kde devs - we probably don't care much if a framework is being
> developed/maintained by one person, but for external potential
> framework users that will be a concern. Specially companies.

I think you're talking less about "maturity" and more about "vitality", or =

something. Anyway, naming aside, I think =C0lex was talking specifically ab=
out =

API/ABI guarantees - we offer pretty strong guarantees, and fresh projects =
may =

not want to commit to that until they've had some real-world usage and =

feedback. This would allow the equivalent to kdelibs' old "experimental" =

tagging, which was used for a couple of libraries while they settled on an =

API.

I think it could be useful, but would definitely require very careful =

communication.

Alex


_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]