Re: [E-devel] Behavior break
Hi, On Wed, Jul 29, 2015 at 1:54 PM, Cedric BAIL wrote: > On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz > wrote: > > On Wed, 29 Jul 2015 12:21:07 +0900 > > Jean-Philippe André 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 > >> > 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 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? -- Jean-Philippe André
Re: [E-devel] Behavior break
On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz wrote: > On Wed, 29 Jul 2015 12:21:07 +0900 > Jean-Philippe André 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 >> > 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 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. > 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. -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
On Wed, 29 Jul 2015 12:21:07 +0900 Jean-Philippe André wrote: > Hi, > > 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 > > wrote: > > > > > >> Hello, > > >> > > >> 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. > > >> > > >> Cheers, > > >> -- > > >> Cedric BAIL > > >> > > >> > > >> > > -- > > >> ___ > > >> enlightenment-devel mailing list > > >> enlightenment-devel@lists.sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >> > > > > > > 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. > > If I understand correctly, E 19.6+ are compatible with EFL < 1.15, but only > E from git is compatible with EFL 1.15? = 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 > 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. 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 have alerted the author of the offending commit and will check with her. > > Best regards, > -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hi, 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 > wrote: > > > >> Hello, > >> > >> 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. > >> > >> Cheers, > >> -- > >> Cedric BAIL > >> > >> > >> > -- > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > 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? If I understand correctly, E 19.6+ are compatible with EFL < 1.15, but only E from git is compatible with EFL 1.15? 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 have alerted the author of the offending commit and will check with her. Best regards, -- Jean-Philippe André -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote: > On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL wrote: > >> Hello, >> >> 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. >> >> Cheers, >> -- >> Cedric BAIL >> >> >> -- >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > 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. dh -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL wrote: > Hello, > > 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. > > Cheers, > -- > Cedric BAIL > > > -- > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > 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. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Behavior break
Hello, 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. Cheers, -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL + Elementary ABI report v1.15.0 alpha1
On 09/07/15 09:02, Tom Hacohen wrote: > Hey, > > Here again, the new EFL + Elementary ABI reports. > > As usual: > https://devs.enlightenment.org/~tasn/abi/ > > Please take a look and report any issues. I haven't looked at it yet myself. > Up for beta3. -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] A few release statistics
Hello. I was curious how we envolved with our releases regarding number of commits, authors and amout of changes. Here are some infos about it. (I started with 1.9 because we don't have 1.7 tags and it was the first release with our new release style) TL;DR o EFL 1.11 had the most commits o EFL 1.11 + 1.14 had the most authors o EFL 1.14 had the most changes o Elm 1.10 had the most commits o Elm 1.14 had the most authors o Elm 1.10 had the most changes Commits: git log --pretty=oneline v1.14.0..v1.15.0 | wc -l Authors: git shortlog -ns v1.14.0..v1.15.0 | wc -l Changes: git diff --stat v1.14.0..v1.15.0 | tail -1 EFL 1.9: -- Commits: 783 Authors: 52 Changes: 598 files changed, 8 insertions(+), 11352 deletions(-) EFL 1.10: -- Commits: 1174 Authors: 58 Changes: 788 files changed, 84946 insertions(+), 41843 deletions(-) EFL 1.11: -- Commits: 1419 Authors: 71 Changes: 843 files changed, 91493 insertions(+), 46811 deletions(-) EFL 1.12: -- Commits: 1144 Authors: 63 Changes: 716 files changed, 50118 insertions(+), 17796 deletions(-) EFL 1.13: -- Commits: 704 Authors: 68 Changes: 709 files changed, 111275 insertions(+), 28292 deletions(-) EFL 1.14: -- Commits: 1269 Authors: 71 Changes: 953 files changed, 77227 insertions(+), 99641 deletions(-) EFL 1.15-beta3: -- Commits: 976 Authors: 59 Changes: 873 files changed, 77003 insertions(+), 42528 deletions(-) --- Elm 1.9: -- Commits: 576 Authors: 49 Changes: 637 files changed, 29482 insertions(+), 13469 deletions(-) Elm 1.10: -- Commits: 713 Authors: 49 Changes: 608 files changed, 54835 insertions(+), 77174 deletions(-) Elm 1.11: -- Commits: 289 Authors: 50 Changes: 481 files changed, 29382 insertions(+), 15579 deletions(-) Elm 1.12: -- Commits: 226 Authors: 41 Changes: 357 files changed, 9475 insertions(+), 8146 deletions(-) Elm 1.13: -- Commits: 377 Authors: 48 Changes: 474 files changed, 15000 insertions(+), 10818 deletions(-) Elm 1.14: -- Commits: 313 Authors: 51 Changes: 224 files changed, 11870 insertions(+), 3366 deletions(-) Elm 1.15-beta3: -- Commits: 422 Authors: 50 Changes: 380 files changed, 18715 insertions(+), 13028 deletions(-) regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Work items for 1.15
Hello. Not even one week left. If you can contribute to any of these bug, be is reproducing or fixing, please do so. Luckily we could at least eliminate a few and are now down to: Phab high: https://phab.enlightenment.org/T2584 100%CPU, spinning in eina_list_data_find_list https://phab.enlightenment.org/T2580 crashes when alt-tabbing https://phab.enlightenment.org/T2395 E19 black screens with custom theme with EFL/Elementary 1.13+ https://phab.enlightenment.org/T2390 Elementary.h includes Evas_GL.h https://phab.enlightenment.org/T2285 Edje_CC does not handle nbsp properly on arm / remove nbsp in whitespace from flipselector.edc causing build issues with edje-cc https://phab.enlightenment.org/T2042 evas_object_geometry_get called on elm_ctxpopup object always returns width and height equals to 0. https://phab.enlightenment.org/T1973 window INLINE_IMAGE cannot be used on its own canvas https://phab.enlightenment.org/T1905 E-git with elf-git crashes on showing settings windows or resizing windows regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
