<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>