Hi, I had not intended to seem like I was giving up - I am pushing hard to try and have this discussion as I think it is important. The paragraph you referenced was intending to point out that our mailing list discussions do not have an open nature to them so others feel it is not worth contributing. When words like “guarantee” and “zero value” are used can you not see how that could be received?
As I have pointed out before the interface parent ticket has new tickets added faster than we are closing existing ones. I see also that completely broken eo widgets are being pushed into master (see efl.ui.panes for example) and abandoned. With that in mind can we realistically expect to release the whole lot in one go this decade? I will work with the folk I have been chatting with to see if I can pull together the requirements that are driving the desire to start building on eo api rather than legacy. Andrew On Sun, 10 Dec 2017 at 11:33, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sun, 10 Dec 2017 09:35:05 +0000 Andrew Williams <a...@andywilliams.me> > said: > > > Hi, > > > > Apologies I was not aware of these plans that everyone agreed on. Can you > > please point me to this plan? It is very difficult to make a case for > > change without knowing the preceding plan that would need to change. > > that all of eo/efl interfaces is behind the same beta flag until done. > it's the > state you see now. there were and are no plans to pick and choose some > interfaces to release as stable, and some not. at one point we were talking > about making just eo stable but then we realized it needed lots of changes > and > this has never come up again. > > you want the plan? see the tickets for interfaces. that's the work to be > done > and the work done on the interfaces themselves feeds back to the lower > levels > all the time. > > > To require irc logs or ML emails asking for this change is to imply that > > we, the community, are serving just this community - I thought we were > > looking bigger picture than that. It would be a violation of trust to > paste > > private conversations or concerns into this email chain, perhaps those > who > > are in agreement will contribute to this conversation. > > if you're using them as a justification, then they should be quoted here. > > > I am confused about what you mean regarding consensus. I have seen no > > discussion bar this about release plans or indeed the plan / priority for > > interfaces. If we could publicly discuss or collaborate on that this > would > > be a lot easier. I agree that there has been little discussion on this > > that's because it is one blob of work and the "let's release different b > its at > different times" is not there because that was not agreed on, otherwise > it'd be > in tickets. > > what was agreed on is what is already there in code and tickets. the > things to > be eoified (well it is a rough list that gets more refined as time goes > on). > it's all behind the same ifdef. ... > > if you want to change this direction and state... you should convince many > people it's a good idea. i, so far, am not convinced it is. you'd need to > convince more than me too. > > > thread but from your first email it seemed like it would be a waste of > time > > discussing so I’m not surprised. This does not detract from the number of > > people who have spoken to me that are disappointed we cannot be thinking > > about releasing some of our work. > > every time i disagree you seem to take it as a "i give up". so what should > i > do" just shut up and pretend to agree? what is the point of a discussion > when > it has to become a "let me just lie and not express what i think to make > someone else happy"? you expressed an opinion. i expressed a counter one. i > believe the value does not justify the cost. i made that clear. convince me > otherwise. otherwise this is not a discussion. > > > However if the plan you described is publicly available then I apologise > > for the confusion. I can point these individuals to the document and we > can > > think harder about what the smallest change could be that provides a > > solution for everyone. > > > > Thanks, > > Andrew > > On Sun, 10 Dec 2017 at 01:09, Carsten Haitzler <ras...@rasterman.com> > wrote: > > > > > 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 > > > > > > -- > > http://andywilliams.me > > http://ajwillia.ms > > > -- > ------------- 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
