This is my proposal: 1. Move interfaces into a 2.0 branch. 2. Leave major developers working on interfaces in 2.0. 3. Minor devs to work on legacy code fixes, minor features and backports (1.2x) 4. Major devs, one per week, to spend a day helping on legacy EFL.
This shouldn't' slow down interfaces development too much, also legacy isn't waiting for interfaces to catch up for important changes and fixes. Perhaps new but competent EFL developers could work on the legacy code, whereas long-time engineers work solely on interfaces in 2.0 branch. Legacy requesting that with each week can borrow one developer for one whole day from the 2.0 branch. e.g. jpeg or raster... Thus we can work towards an improved EFL 1.x release and continue strongly with interfaces development as the main focus for our stronger engineers. On Thu, Dec 7, 2017 at 1:45 PM, Andrew Williams <a...@andywilliams.me> wrote: > Why does it have to be black and white? releasing does not "guarantee no > changes", it probably does need to guarantee backward compatibility. The > challenge I see with our current situation is that we have published "beta" > which is not even close to stable and now don't have a clear next step to > get people involved. A "release candidate" might be an obvious step which > comes as part of a release plan, which is what I wanted to discuss. > > I think that EFL and our community is in a different place to where it was > years before ecore. We should learn from (everyone's) experience and figure > how to apply that to our current situation. Our current reality is that > companies with real products want to build on what we have. That's pretty > exciting I reckon. > > Until we have a release of the new API that people can actually start > relying on being somewhat stable we are expecting them to use only the old > API. In the meantime we have most active development on it's replacement. > We are basically saying "you can use the old stuff, but you'll need to port > later - or you can try and use the new stuff, which requires regular > updating to keep up". To me this looks like there is no practical way that > we can encourage new people to rely on EFL. This makes me sad. > > Should we instead figure when we might start releasing and set an > expectation to the public? Something like "come back in 2019"? > > Andrew > > On Thu, 7 Dec 2017 at 10:37 Carsten Haitzler <ras...@rasterman.com> wrote: > > > On Thu, 07 Dec 2017 08:54:05 +0000 Andrew Williams <a...@andywilliams.me > > > > said: > > > > so what applications can you build only with efl core and efl net and > > nothing > > else? > > > > zero applications will be built with these. it will not be tested. > history > > tells > > me so. BUT it will tie our hands in making changes. so what value does > this > > provide? none to any developers who know that the api is STILL unstable > and > > changes might be made, unless we guarantee NONE will be... and then if > > NONE are > > broken, our hands are tied. > > > > i'm speaking from experience here. i made eet 1.0 long (years) before > > ecore, > > evas, etc. etc. ... and people didn't go using it. been there. done that. > > and > > by the time the others were ready i was already going "crap - i shouldn't > > have > > done that" because eet had to hold legacy file format support (and still > > does) > > that was deprecated already in efl before edje 1.0 was done. > > > > what we have now i think is the best we can do. > > > > > Hi, > > > > > > To say that it is publicly available behind a BETA flag is one thing, > but > > > to call it a Beta Release is quite a stretch. To reference The Next > > > Generation Lexicon: "Beta phase generally begins when the software is > > > feature complete but likely to contain a number of known or unknown > > bugs.". > > > Given the current state of the interfaces I would say that to treat it > > like > > > that is exceptionally generous. I have never been anywhere where the > > > developers or users have been told "It's in beta - the APIs will > change - > > > we don't care" which is common parlance around here. > > > > > > I think it's unfair to say that releasing a subset has "no value". The > > APIs > > > described allow you to build a complete application - albeit without a > > > graphical front end - which is a great start, even a solid foundation. > > With > > > a little more work we could have Efl.Canvas and Efl.Gfx in there to get > > > early access to the new graphical APIs. It seems that Efl.Ui is sinking > > the > > > most time and we are having to rewrite areas of it as the underlying > > > libraries change. Surely nailing the underpinnings and releasing them > > gives > > > us a stable platform to deliver on. > > > > > > Calling for release discussions seems required to focus us. As everyone > > > acknowledges we are a team spread very thin and if we continue to have > > > little or no direction for release we will continue to work on what is > > > interesting and not to wrap up an API that is actually usable and > > reliable > > > to anyone. > > > > > > Right now I don't think it's clear what we are trying to achieve. It > > would > > > be a death knell to our chances of being taken seriously if we once > again > > > take 10 years to do a major upgrade. > > > > > > Regards, > > > Andrew > > > > > > On Thu, 7 Dec 2017 at 01:22 Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > > > > > 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. > > > > > > > > > This mean the remaining question is what is left to do for this. On > > my > > > > side : > > > > > - Remove reference to graphic interface when including > > Efl_Core/Efl_Net. > > > > > - Finish migration to Eina_Future > > > > > > > > > > If you have still some stuff on your plate, you should let us know. > > I do > > > > feel > > > > > that for helping Stefan we should open a ticket to track this last > > task > > > > until > > > > > a release. > > > > > > > > > > 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 > > > > > > > -- > > > http://andywilliams.me > > > http://ajwillia.ms > > > > > ------------------------------------------------------------ > ------------------ > > > 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 > > > > -- > http://andywilliams.me > http://ajwillia.ms > ------------------------------------------------------------ > ------------------ > 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 > ------------------------------------------------------------------------------ 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
