On Sat, 09 Dec 2017 13:38:51 +0000 Andrew Williams <a...@andywilliams.me> said:
> This has become a circular argument, as many do around here, vis: > *) people are asking for us to try and agree on stable areas of the API so > we can start testing it externally > *) we won’t do that until there is proof that people are using our beta > APIs (which are currently unstable). > How can we break this loop? which people where are asking for a release of a small susbet of the api? show me. > I cannot believe that all of the new APIs are completely unstable until we > release - that is basically a house of cards that we hope one day will > become rigid. Some of what we have is more mature than other things - but > every single API we add immediately goes into the BETA flag for next > release.. you are asking for a change of plans that everyone working on eo/interfaces agreed on. you have to make your case for that CHANGE. don't tell me "people are asking". show me the emails here asking, and from who. show me the irc logs or the phab tickets. i'm not talking about the full release of what was planned but the subset you mentioned. see above. those changes come with a cost (locking yourself in). we'd be stupid to pay the cost with no evidence beyond your comment "people are asking". not to mention it'd also be ignoring the previous agreement on what to do. until the people working on eo/interfaces can ALL come to a consensus... nothing is going to change. and there is no input from most of them at this point, and no overwhelming evidence to ignore any input from them if it were to come. > If we cannot make any release in the way previously discussed then we > absolutely should have some other way of illustrating our confidence in an > API. Therefore an alternative I propose is to add an ALPHA flag (which is > mostly what BETA feels like at the moment) where new Eo goes and those > marked as BETA are the classes we feel could be eliciting feedback. > This way we are able to show where we know we have not tested as much and > can show a journey through creation, testing and integration into the BETA > area. > > Without this we are just hoping that some day all our classes will be > stable so we can roll a release... > > Andrew > On Sat, 9 Dec 2017 at 12:48, Carsten Haitzler <ras...@rasterman.com> wrote: > > > On Fri, 08 Dec 2017 19:06:47 -0500 Cedric Bail <ced...@ddlm.me> said: > > > > > > -------- Original Message -------- > > > > Subject: Re: [E-devel] What are we going to release? > > > > Local Time: December 7, 2017 5:06 PM > > > > UTC Time: December 8, 2017 1:06 AM > > > > From: ras...@rasterman.com > > > > To: Andrew Williams <a...@andywilliams.me> > > > > Enlightenment developer list < > > enlightenment-devel@lists.sourceforge.net> > > > > > > > > On Thu, 07 Dec 2017 13:45:51 +0000 Andrew Williams > > a...@andywilliams.me > > > > said: > > > > > > > > Without a guarantee of no changes then you don't provide anything > > stable to > > > > build on top of. It's no different to what we do now. We could just > > say "we > > > > think these interfaces are ok now - you can try using them but we might > > > > still break them" which is is not some special beta release. it's just > > > > providing a "we think its more stable now" assessment. > > > > > > I am thinking of a stronger commitment on our part here. Basically as I > > said > > > in my email above, if a binding doesn't report a real big problem with > > what > > > is under that RC umbrella, then we do not break it. > > > > unless it's "absolutely will not break at all" then it's really no better > > in > > the end. > > > > > I am afraid that for a lot of this lower level, we are now starting to do > > > what we were doing before we release EFL 1.0. Trying to make it perfect > > > without having ever spend the time to prepare a proper release. We need > > to > > > focus and get things out. > > > > > > > but still if it's just what you were saying then what apps can be > > written > > > > using those api's - and will they be? > > > > > > EFL apps already exist. They can get migrated to the new API. That is the > > > main target of this release. > > > > other than some mechanical "sed work" like s/evas_object_del/efl_del/g ... > > which buys nothing really useful... what is really going to be done? and > > what > > will this demonstrate to us or anyone else api-wise? not much. > > > > > >> 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. > > > >> > > > >> what we have is a release candidate so to speak that is clearly > > showing its > > > >> state - it's not stable. > > > >> > > > >> trying to release something as stable that is NOT (call it a release > > > >> candidate or whatever) is just being dishonest. > > > >> > > > >> 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. > > > >> > > > >> and they need the full stack done to build them. not just some small > > > >> sub-bits. thus i point out what i did already... what apps with such a > > > >> subset of api's (efl core/loop/net?). they can't even build things > > with > > > >> efl.gfx. they need efl.ui and even then the efl.ui we are proposing > > means > > > >> them losing several widgets they have used before etc. ... so that's > > > >> already a sacrifice. > > > > > > No, they don't ! Do not forget that EFL Eo API is compatible with the > > legacy > > > API and that this is especially done to allow people to migrate their > > > application as time goes. Bits by bits. > > > > they absolutely do. e.g. c#. without the full stack it's pointless. and > > they're > > not going to migrate... except rewrite in a new language. you know that as > > well > > as i do. > > > > > [snip] > > > > > > >> Should we instead figure when we might start releasing and set an > > > >> expectation to the public? Something like "come back in 2019"? > > > >> > > > >> well we hoped to finish in 2016, then by end of 2017 ... we have a > > better > > > >> chance now as people are really focusing on it, but i actually suspect > > > >> 2019 is a safe bet. mid 2018 might be "optimistic" and end of Q1 2018 > > is > > > >> "totally crazy optimistic if the world all aligns right". > > > > > > If we keep trying to release everything at once without commitment and > > not by > > > slice of useful bits, then sure we will still be at it in 2019 or maybe > > even > > > later. But we don't need to do so. Existing apps and existing bindings > > won't > > > stop working. The new API is designed to allow for a smooth transition. > > It is > > > designed to allow you to mix old and new together. This way, you can > > already > > > build a useful application by building with Efl_Core, Efl_Net and > > Elementary. > > > This is fine. > > > > it's not about "trying to release all at once". it's about not painting > > ourselves into a corner. not limiting ourselves before we really need to. > > > > every release we do means we stop doing eo work and instead stabilize a > > release. the more we do the more we push a final result into 2019. without > > a > > significant amount of the interfaces api available you won't really get > > much, if > > any, valuable feedback, and instead simply lose at least a few months of > > work > > time into release work. (1 month per release at least). > > > > i don't see how this gets us to our goal better or sooner than what we are > > doing now. what i do see is: > > > > 1. getting there later > > 2. not gaining anything really valuable in return for that delay > > > > but here's my take... the above is my advice, but delay-wise... i'm not > > responsible. but mark my words that the goal that MATTERS - interfaces > > that can > > be used in BINDINGS like C#, C++, JS, LUA etc. will only get delayed ... > > and > > you know well enough how much a release delays. we have a whole mountain of > > new coverity complaints. any eo api to be "stabilized for release" needs a > > lot > > of attention in review and actual use before that release goes out if you > > want > > any kind of stability guarantee to it. and you know full well that just > > these > > few api's are of nil use to the consumers of bindings like above until > > there > > is a LOT more there. > > > > but if you wish to take the risk and the blame when things get delayed... > > you > > go ahead. all i want is proof of actual use in the wild like you claim, > > because unless there is such proof, no lessons will ever be learned from > > this. > > think of it as a "KPI". proof that the "stable beta api" is used without > > the > > current unstable beta #define and so on... in more than a few trivial > > places. > > > > > 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 ------------------------------------------------------------------------------ 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
