[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:       Albert Astals Cid <aacid () kde ! org>
Date:       2014-08-19 21:25:41
Message-ID: 2661366.6OoFUPqjUJ () xps
[Download RAW message or body]

El Dimarts, 19 d'agost de 2014, a les 08:44:10, David Faure va escriure:
> On Friday 15 August 2014 12:51:58 Kevin Ottens wrote:
> > On Friday 15 August 2014 09:34:04 Alex Merry wrote:
> > > 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 comm=
it
> > > > > on
> > > > > ABI/API stability) but they are ready for feedback from third par=
ty
> > > > > developers.
> > > > > =

> > > > > Even though there was not consensus in the discussion this is an
> > > > > idea
> > > > > that
> > > > > 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
> > > > > have
> > > > > 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/a=
bi
> > > > stability, number of people contributing and where the project itse=
lf
> > > > 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 conside=
r 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 specifica=
lly
> > > about API/ABI guarantees - we offer pretty strong guarantees, and fre=
sh
> > > 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.
> > =

> > And that's the problem if we release them. If it's released "with the
> > rest"
> > expect people to have wrong expectations about them.
> > =

> > A possibility would be perhaps to produce nightly tarballs for those
> > frameworks which don't have the "release: true" flag. This way they keep
> > not being part of a release, and early adopters have something easy to
> > grab.
> Wouldn't early adopters just checkout and build from git ?
> =

> I don't know about you, but I almost never download a source tarball,
> because a git checkout is just so much easier to update later.
> We mostly make tarballs for packagers, and the non-mature frameworks we're
> talking about should definitely NOT be packaged.
> =

> IMHO the solution is just to publicize the upcoming frameworks somewhere.

I see a small problem with git-only repos, and it's called =

release+distributions.

I have heard that the plam is to frameworks-ize kdepimlibs, ideally one wou=
ld =

like to do a release of kdepimlibs so that the kf5-based kdepim can use the=
m =

but without guaranteeing ABI/API compatibility.

But if we want distros to package that kdepim we're going to need packages.

Cheers,
  Albert
_______________________________________________
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]