Hello. On 29/07/15 08:44, Jean-Philippe André wrote: > Hi, > > On Wed, Jul 29, 2015 at 1:54 PM, Cedric BAIL <cedric.b...@free.fr> wrote: > >> On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz >> <michael.blumenkra...@gmail.com> wrote: >>> On Wed, 29 Jul 2015 12:21:07 +0900 >>> Jean-Philippe André <j...@videolan.org> wrote: >>>> On Wed, Jul 29, 2015 at 9:20 AM, Christopher Michael < >>>> cpmich...@osg.samsung.com> wrote: >>>>> On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote: >>>>>> On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL <cedric.b...@free.fr> >>>>> wrote: >>>>>>> I have learned that commit >> 5cb6cdbc5e1a13ea0262e155983b494e6519abde in >>>>>>> efl tree break all the past version of Enlightenment. Without >> patching >>>>>>> Enlightenment itself, there is no way to fix this apparently. We >> are >>>>>>> now very close to the release and this is breaking one of the few >>>>>>> application we have. I think this patch should be reverted asap. >>>>>> I am not advocating in either direction, but I will need to >> immediately >>>>> do >>>>>> another E19 release as well as make changes in E-git if this is >> reverted; >>>>>> internal windows will remain permanently unclickable in this case >> since >>>>>> hacks were added to work around these changes. >>>>> Also not advicating in either direction, but this DID cause US a lot >> of >>>>> HEADACHE because it changed expected behaviour. IMO, a bit late in the >>>>> process to introduce a major change like this. This SHOULD have been >>>>> done earlier in the cycle and had time to flush out. >>>> Sorry to sound so naive, but did you report those behaviour breaks? Why >>>> work around instead of fixing EFL? >>> These sorts of things happen regularly. Every time I update Elementary >> on my >>> desktop, I find new "bugs" in applications that I've written as a result >> of >>> behavior changes. We usually say that such changes are justified because >> "it's a >>> bug fix" or "the previous behavior was broken", but these are still >> behavior >>> changes which break applications. >> Ok, this is something that should not happen, but did in the past. >> That's why I have been advocating for proper behavior checking of the >> whole stack for a long time and that is finally moving forward with >> exactness starting to get some love, but much more is needed (still we >> also need espion to move forward on this). One of the thing we should >> not let slide, is to report any future breakage as soon as it happen, >> ideally we should be able to record a trace for an exactness tests >> suite and make sure that doesn't get broken. >> >>>> If I understand correctly, E 19.6+ are compatible with EFL < 1.15, but >> only >>>> E from git is compatible with EFL 1.15? >>> <E19.6 requires EFL < 1.15 due to behavioral changes >>> >>> E19.6 requires EFL >= 1.15 because I didn't get the backwards >> compatibility >>> right on the first try >>> >>> E19.7 requires EFL >= 1.11 (as in E19.0 release) >>> >>> E-git requires >= 1.15 for API usage >> Ok, now I am super confused ! So if we revert the change from current >> EFL tree, E19.7 should be fine as it is compatible with previous >> version of EFL. Will E-git still be fine ? If it wil, we can just >> revert and have the situation fixed. >> >>>> Then we have a problem IMHO since our release cycles are not in sync, we >>>> can't just go and break everyone's E by updating EFL. This includes >> forked >>>> versions of E, as well as other applications using ecore events >> directly. >>> I don't think the release cycle timelines are an issue here, especially >>> considering you're citing forked versions of E which we have no control >> over. >>> If "E19" compatibility is something that we are concerned with, the 19.7 >>> release from last week resolves those issues and will have already been >> out for >>> long enough that any distributions which ship EFL should have already >> picked it >>> up by the time the final 1.15 release occurs. >> That's not how it should work. Any release of EFL should not break a >> released software that use the expected behavior of EFL. Especially >> when we only have so few of them. >> > Yeah, we're talking about EFL here, which apparently broke behaviour in > such a way that it broke existing apps (E). > >> If we're concerned with theoretical other applications which may be >> affected by >>> this, I can produce a 19.8 release to remove this codepath in E prior to >> the >>> 1.15 release, assuming that a decision is made which provides me with >> enough >>> time to do so. Ideally anyone who has picked up 19.6-7 will also pick up >> a 19.8 >>> release in time for users to not be affected by any issues. >> I may misunderstand your sentences here, but the issue is in EFL 1.15 >> which is breaking existing software not in E. So I believe we should >> remove the breakage from EFL, and if by reverting things from EFL we >> have E fixed then we are good. That's the main question here. >> > Is there a precise path to observe the original bug? > I'm running E 19.5 with EFL from git but can't see anything special. > Or did you actually fix ecore to restore similar behaviour as before? >
Look at Dave's mail replying to the E 0.19.6 release. He raised the point there. Let me quote it: "Something crazy wrong with the settings dialogs in this release. The first click inside a dialog registers fine, but any subsequent clicks will register exactly the same as the first click. Nothing appears in the .xsession-errors file as it happens. Running efl/elementary 1.14.2 ." I cc'ed Ji-Youn as I'm not sure she is at the latest of this list yet. From my side, with the release hat on, I would say this needs to get corrected before 1.15 final. If it gets a fix that restores the old behaviour and keeps the new code in (if at all possible) depends on how quick a fix can be found. Today and tomorrow Korean time would be fine. After that we should revert and leave the fix for 1.16 to allow Mike reverting his change in E and bring out a 0.19.8 which restores the correct behaviour with the way efl worked before. How does that sound? regards Stefan Schmidt ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
