On Fri, 08 Dec 2017 18:55:06 -0500 Cedric Bail <ced...@ddlm.me> said:
> > -------- Original Message -------- > > Subject: Re: [E-devel] What are we going to release? > > Local Time: December 6, 2017 5:22 PM > > UTC Time: December 7, 2017 1:22 AM > > From: ras...@rasterman.com > > To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net> > > Cedric Bail <ced...@ddlm.me> > > > > On Wed, 06 Dec 2017 19:45:39 -0500 Cedric Bail ced...@ddlm.me said: > > > >> Hi, > >> > >>> -------- Original Message -------- > >>> Subject: Re: [E-devel] What are we going to release? > >>> Local Time: December 6, 2017 6:13 AM > >>> UTC Time: December 6, 2017 2:13 PM > >>> From: dan...@octaforge.org > >>> To: enlightenment-devel@lists.sourceforge.net > >>> On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote: > >>> > >>>> Hi all, > >>>> As our last release was over 4 months ago I think we really need to > >>>> figure > >>>> what the next release will be, and when, so we can start focusing on > >>>> making > >>>> that subsection of our work releasable. > >>>> Clearly we are not going to get the interfaces completed any time soon. > >>>> The > >>>> list of things to port keeps getting longer and we have too many > >>>> outstanding patches to count. I have heard suggestions that we could > >>>> release a subset, for example Efl_Core and Efl_Net now that they we have > >>>> the Efl namespace split into groups. > >>>> This would mean releasing the API ( > >>>> https://www.enlightenment.org/develop/api/start) that is prefixed efl_io, > >>>> efl_net, efl_event or efl_loop and that's about it (as well as eina and > >>>> eo > >>>> which need to get merged into the non-legacy docs somehow). > >>>> Is this a good approach? Right now it seems like we need to focus on > >>>> completing portions of this and cut a release of some sort so that we can > >>>> have people look at usage, bindings and porting existing code. I'd love > >>>> to > >>>> get our website updated to filter just the APIs we plan to release soon. > >>>> And then generate another section for the work-in-progress completion of > >>>> interfaces... > >>>> Hi, > >>>> I told you on IRC already but I'm going to say it here publicly - > >>>> personally I don't think it's a good idea to release APIs unless we're > >>>> sure that it's really the API we want (i.e. it can be defined in Eolian > >>>> once it's stable, it can be used for bindings and it's > >>>> real-world-tested, i.e. we're sure of its practicality). I don't see any > >>>> real benefit in releasing a subset of our APIs, only potential issues. > >> > >> We have been working on EFL interfaces for years now. Literrally. We have > >> to do a release in the next 6 months. The main question is how to get > >> there and have something good enough for everyone. > >> My current take is that we finish cleaning up Efl_Core and Efl_Net for a > >> beta release (which mean no further change except if something is really > >> bad) and do an EFL release with that. This would make it possible for > >> people who want to do binding to start working on it and report problem > >> they have during 1.22 release cycle. This would be the only time we could > >> still break our API in my point of view, but only if it is asked by > >> binding developers. Finally for EFL 1.22, we will release an Efl_Ui > >> component. and everything below will also be marked stable. > >> > >> ALL of eo/interfaces is already released as "beta". has been now for a very > >> long time. how does this change anything? we have NEEDED to make changes > >> that have broken what we have. i don;'t see this as any change to the > >> current status. > > They are delivered behind a BETA flag, not in beta. This is totally not to the audience you speak of. it says beta. it means what it says. i disagree with you here. put yourself in someone else's shoes for this. they don't know the internals or details. they just know they have to #define some value that says "beta" in it. > different. You can not rely on using eo, eolian or any of the new interface > today at all. Try to write a binding in your spair time ? Give up, it is > going to be broken for next release. Trying to use .eo to make your own > objects, forget about it, it is going to be broken too. Basically, at this > point only people that can spend their full time on it are the one keeping up > with it (and barely). eolian and eo are still a moving target to the point you cannot do this. the c+ + bindings break regularly. i've given up building them so i can even run make check. talk to q66. we're not even close on depending on eo. until the bindings we have stop breaking due to eolian or eo changes for a few months (1-3m) ... we're not even close. > If we want to get more people eyes on this and get things settle it is time > to stop moving dirt around like crazy. It is important to not forget that a > core feature of this new API is that it is compatible with the old one. This > is done to allow for a smooth transition path. It also means we don't need to > release all of our API right away, we can turn on the light on a progressive > path. > > I see value in stabilizing everything below Efl_Core.h and Efl_Net.h in the > sense that we can maybe start to get people to look at what we have done, > build bindings and give us feedback. Application can start to rely on some of > the feature already of Eo. This will give us chance to improve the API that > is yet to come. then put it behind another #ifdef flag and i want to see actual evidence people use this new flag other than "us". because i bet it'll be no one or as close to no one as practically worth talking about. you know how these things go. put things in a branch? it's untested until it hits master. if it's an opt-in with effort ... nothing will change. and if it's "might still change" and not actually locked down then you'd be an idiot to use/try the api in anything as you'd depend on something that may break abi. you take a big risk. > There will be mistake, their will be dead API, nothing is ever perfect and > even if we wait another 6 months, a year to release this bits there would > still be things that are not perfect. So let's start releasing small bits > that are nearing being good enought and see where we are completely wrong, > before we release everything and we end up with a massive amount of errors. > Focusing our energy on releasing the lower bits will help us to get to a > point where we can release the next layer. but you either break the api/abi if needed in which case anyone who did try the api is REALLY annoyed. distros like suse (ask simotek) will report abi breaks and if needed patch the api out so abu breaks are avoided. ask simotek about eflete/enventor and packaging. if anything will change at all. even small things, then it's a problem. the only way to do this is to guarantee NO changes and that paints us into a corner. see above about the breaks still happening. > Cedric > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
