[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: Aleix Pol <aleixpol () kde ! org>
Date: 2014-08-20 10:14:31
Message-ID: CACcA1RoV_J2_TjssnBfPS5qzQtN1JTdaBncwWAmu_iAOpSEsHA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Aug 19, 2014 at 11:25 PM, Albert Astals Cid <aacid@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, =C3=80lex 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 a=
n
> > > > > > 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 res=
t,
> > > > > > 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 actual=
ly
> > > > > 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 bei=
ng
> > > > > 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 =C3=80lex 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 caref=
ul
> > > > 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 t=
o
> > > 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 somewher=
e.
>
> 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 package=
s.
>
> 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
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 19, 2014 \
at 11:25 PM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" \
target="_blank">aacid@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">El Dimarts, 19 d'agost de 2014, a les 08:44:10, David \
Faure va escriure:<br> <div><div class="h5">> On Friday 15 August 2014 12:51:58 \
Kevin Ottens wrote:<br> > > On Friday 15 August 2014 09:34:04 Alex Merry \
wrote:<br> > > > On Friday 15 August 2014 10:21:57 Mark Gaiser wrote:<br>
> > > > On Fri, Aug 15, 2014 at 12:12 AM, Àlex Fiestas <<a \
href="mailto:afiestas@kde.org">afiestas@kde.org</a>><br> wrote:<br>
> > > > > Hi there<br>
> > > > ><br>
> > > > > At the Randa sprint we have discussed a little bit what to \
do with<br> > > > > > those<br>
> > > > > frameworks that are still not mature (for example they \
can't commit<br> > > > > > on<br>
> > > > > ABI/API stability) but they are ready for feedback from \
third party<br> > > > > > developers.<br>
> > > > ><br>
> > > > > Even though there was not consensus in the discussion this \
is an<br> > > > > > idea<br>
> > > > > that<br>
> > > > > came out during the discussion:<br>
> > > > ><br>
> > > > > -We introduce a Maturity level that we can use to manage<br>
> > > > > expectations<br>
> > > > > about<br>
> > > > > the Framework (for example whether API/ABI will be kept)<br>
> > > > > -We release Frameworks that are not ready together with the \
rest,<br> > > > > > but<br>
> > > > > we<br>
> > > > > have to make damn sure we manage expectations.<br>
> > > > ><br>
> > > > > With this we can get early feedback for new frameworks, and \
since we<br> > > > > > have<br>
> > > > > a<br>
> > > > > rapid release cycle we can improve them fast.<br>
> > > > ><br>
> > > > > What do you think?<br>
> > > ><br>
> > > > It depends on how you define maturity.<br>
> > > ><br>
> > > > For instance, if a maturity is simply a value set in each \
project'<br> > > > > metainfo.yaml and set by those that maintain it \
then the maturity<br> > > > > level quite frankly doesn't tell you \
anything.<br> > > > ><br>
> > > > But if you decide maturity dynamically based on git activity, \
api/abi<br> > > > > stability, number of people contributing and where \
the project itself<br> > > > > is used in other projects (just some \
conditions that i can think of<br> > > > > now, there is probably more). \
With this a project maturity actually<br> > > > > has a meaning. When \
going for this approach it would also be nice to<br> > > > > show a list \
of projects using "Framework X". Also, i do not consider a<br> > > \
> > project being healthy when it has only one developer [1] even if the<br> \
> > > > project is used by dozens of other projects and has much \
activity. For<br> > > > > us - kde devs - we probably don't care much \
if a framework is being<br> > > > > developed/maintained by one person, \
but for external potential<br> > > > > framework users that will be a \
concern. Specially companies.<br> > > ><br>
> > > I think you're talking less about "maturity" and more \
about "vitality",<br> > > > or<br>
> > > something. Anyway, naming aside, I think Àlex was talking \
specifically<br> > > > about API/ABI guarantees - we offer pretty strong \
guarantees, and fresh<br> > > > projects may not want to commit to that \
until they've had some<br> > > > real-world<br>
> > > usage and feedback. This would allow the equivalent to kdelibs' \
old<br> > > > "experimental" tagging, which was used for a couple \
of libraries while<br> > > > they settled on an API.<br>
> > ><br>
> > > I think it could be useful, but would definitely require very \
careful<br> > > > communication.<br>
> ><br>
> > And that's the problem if we release them. If it's released \
"with the<br> > > rest"<br>
> > expect people to have wrong expectations about them.<br>
> ><br>
> > A possibility would be perhaps to produce nightly tarballs for those<br>
> > frameworks which don't have the "release: true" flag. This \
way they keep<br> > > not being part of a release, and early adopters have \
something easy to<br> > > grab.<br>
> Wouldn't early adopters just checkout and build from git ?<br>
><br>
> I don't know about you, but I almost never download a source tarball,<br>
> because a git checkout is just so much easier to update later.<br>
> We mostly make tarballs for packagers, and the non-mature frameworks \
we're<br> > talking about should definitely NOT be packaged.<br>
><br>
> IMHO the solution is just to publicize the upcoming frameworks somewhere.<br>
<br>
</div></div>I see a small problem with git-only repos, and it's called<br>
release+distributions.<br>
<br>
I have heard that the plam is to frameworks-ize kdepimlibs, ideally one would<br>
like to do a release of kdepimlibs so that the kf5-based kdepim can use them<br>
but without guaranteeing ABI/API compatibility.<br>
<br>
But if we want distros to package that kdepim we're going to need packages.<br>
<br>
Cheers,<br>
Albert</blockquote><div><br></div><div>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).</div>
<div><br></div><div>Is ABI/API compatibility really a \
concern?</div><div><br></div><div>Aleix</div></div></div></div>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic