How to promote less mature Frameworks?

Wed Aug 20 11:57:48 UTC 2014

On Wednesday 20 of August 2014 12:14:31 Aleix Pol wrote:
> 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).

kdepimlibs master is currently frameworks and Laurent is planning to split the 
repository some time around beginning of September, so yes - we want 
Frameworks. I think that some frameworks will be almost immediately ready for 
release once they are split out, because Laurent has already ported them away 
from kdelibs4support, and there are no plans for larger API/ABI breaks (maybe 
just removing deprecated stuff). 

But in the Akonadi framework for instance I'm planning some larger changes 
that will take some time to implement, so we might want to ship some 
"unstable" (in API/ABI terms) version of the framework, so that Plasma could 
finally get a working calendar for example.

Dan

> 
> Is ABI/API compatibility really a concern?
> 
> Aleix

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140820/c9bdfdfc/attachment.sig>