How to promote less mature Frameworks?

[Aleix Pol]

On Tue, Aug 19, 2014 at 11:25 PM, Albert Astals Cid <aacid at kde.org> wrote:

> 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, Àlex Fiestas <afiestas at 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
> > > > > > 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/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 Àlex was talking
> specifically
> > > > about 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.
> > >
> > > 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
> would
> like to do a release of kdepimlibs so that the kf5-based kdepim can use
> them
> but without guaranteeing ABI/API compatibility.
>
> But if we want distros to package that kdepim we're going to need packages.
>
> Cheers,
>   Albert


It would be very interesting to have somebody working on kdepimlibs around.
I keep hearing that they will be available soon, but I still ignore whether
the people doing the work want the kdepimlibs to become KDE Frameworks
(they didn't want them to be part of kdelibs already, so there must be
reasons).

Is ABI/API compatibility really a concern?

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140820/429a4c8b/attachment.html>