On 12/30/2015 02:59 PM, Cedric BAIL wrote: > On Wed, Dec 30, 2015 at 8:44 PM, Mike Blumenkrantz > <michael.blumenkra...@gmail.com> wrote: >> On Tue, Dec 29, 2015 at 7:33 PM Carsten Haitzler <ras...@rasterman.com> >> wrote: >>> On Tue, 29 Dec 2015 19:10:00 +0000 Mike Blumenkrantz >>> <michael.blumenkra...@gmail.com> said: >>>> On Mon, Dec 28, 2015 at 7:13 PM Carsten Haitzler <ras...@rasterman.com> >>>> wrote: >>>> >>>>> On Mon, 28 Dec 2015 19:36:53 +0000 Mike Blumenkrantz >>>>> <michael.blumenkra...@gmail.com> said: >>>>> >>>>>> Changing the option only affects users of git, so it's not the >>> highest >>>>> >>>>> it affects users of git until the next release,, then it affects those >>>>> building >>>>> a release too. changing it every release is probably what should be >>>>> happening >>>>> to make it effective. >>>> >>>> >>>>>> priority for many people to look at immediately after it has been >>>>> changed. >>>>>> Given that the removal of sleep is guaranteed to work for all stable >>>>>> releases (since configure options don't change during this time) it >>> means >>>>>> that the only ones being penalized here are users of git directly. >>>>>> >>>>>> It has indeed been some time since the option was last changed, but I >>>>> don't >>>>>> think changing it more frequently is the answer; this will only cause >>>>>> people who maintain ebuilds to begin updating them more frequently >>> since >>>>> it >>>>>> will become a "routine change". This is assuming that they don't just >>>>> read >>>>>> the configure script and disable the check for the option >>> entirely--far >>>>>> easier for them to do than to continually update some option which is >>>>> known >>>>>> to be volatile. >>>>> >>>>> actually to do that they have to patch, and the patch to disable it >>>>> depends on >>>>> the option itself, so a new patch has to be generated every time it is >>>>> changed. >>>>> it's less work to just change the option to configure itself. again - >>> as i >>>>> said. for builds that build stable sw this needs changing to encode sw >>>>> version >>>>> anyway. every release they have to update from 1.16 to 1.17 to 1.18 - >>>>> there is >>>>> a routine change needed anyway for any packaging of a stable release. >>> for >>>>> a git >>>>> build where you don't care about version then yes - these break and >>> need >>>>> maintenance. >>>>> >>>> >>>> At a glance I can easily come up with two ways to completely disable the >>>> failure using only sed and to do it in such a way that any future changes >>>> by you are completely ignored. I imagine anyone writing build scripts or >>> >>> but they way they do it is via patch. that wouldn't work. that is the >>> current >>> ebuild workaround - patch. >>> >>>> ebuilds is far more inventive and/or skilled with shell scripting than I >>>> am, so this is certainly not an accurate statement if the only thing you >>>> are doing to "get attention" is to change this configure flag. >>> >>> sure. they could use sed instead of patching. >>> >>>> Given that any new release version update can inherit from the git build, >>>> this has even less impact since whatever changes you've made will have >>> been >>>> long solved by the time a release occurs. >>> >>> then it probably should change just before release - when it needs to >>> change. >>> >>>>>> Any solution with configure flags really just results in more work >>> for >>>>> you >>>>>> on the development side as well as more hassle for every other >>> non-Gentoo >>>>>> user of git who changes a default option while knowing what they are >>>>> doing. >>>>> >>>>> i will go back to my original example. ecore-x in xcb code is not >>> complete. >>>>> certain things will not work. for example xinput2 is not supported. >>> this >>>>> will >>>>> mean things like touch may not work or work properly when you build >>> with >>>>> xcb. >>>>> if you are ok with this, then fine - use xcb, BUT you must be fully >>> aware >>>>> of it >>>>> and the tradeoffs you are making. >>>>> >>>> >>>> Applications where this is relevant can and should notify the user that >>>> this is an issue. >>> >>> that is every single app. touch support is an "everywhere" thing. you >>> expect >>> every app dev to go write support to detect/display this? (assuming we >>> provide >>> ways to detect at runtime certain build configs that would break features). >>> physics in edje for example - another one. ... any theme for any app could >>> be >>> using it. every app has to pop up dialogs just in case? no - stdout isnt >>> viable >>> due to stdio being a comms channel often (sure stderr we kind of steal), >>> and >>> most users dont SEE stderr - they click an icon and an app comes up and is >>> not >>> working right. that theme they downloaded doesnt work right because it uses >>> pyshics (or sounds) and now the user wonders why its broken? >>> >> >> stderr is a viable minimalist option that I've seen several apps and >> toolkits use. At a minimum, it's a record which can be retrieved and >> examined in order to diagnose issues related to missing features. >> >> >>> >>>>> if you disable pulse support you break audio support and users reading >>> that >>>>> "this sound happens when i click this" then have no sound and wonder >>> why >>>>> the >>>>> app or efl is broken... at least have an ability to have been warned >>> of it. >>>>> >>>> >>>> See above. >>>> >>>> >>>>> >>>>> the reason isn't build breaks only but also functionality changes. >>> these >>>>> choices ad build time affect functionality and a user may not be aware >>> of >>>>> those >>>>> tradeoffs and thus the point is to encourage them to think carefully on >>>>> their >>>>> choices that stray from what is "known to be safe". at least we can do >>>>> this at >>>>> compile time and warn the person making the choices (the one providing >>> the >>>>> configure options). >>>>> >>>> >>>> There are other toolkits which allow disabling or absence of support >>>> features, but their applications still function mostly normally and >>> provide >>>> info to the user that various features have been disabled due to build >>>> changes. It's much easier for an application or toolkit developer to know >>>> and understand various internal features than an end user, and--by your >>> own >>>> admission--the target users of this don't even read build outputs, so >>> even >>>> your attempt at "encourag[ing] them to think carefully on their choices" >>> is >>>> moot here. >>> >>> the user using the ebuild doesnt. the person WRITING the ebuild does. they >>> are >>> the ones then providing the options. it is for THEM. that is the user i >>> speak >>> of for whom this kind of thing is targetted. >>> >>>>> the alternative is we just remove options so people cant create a >>> "broken >>>>> builds" and let people actually patch efl code and build files to try >>> and >>>>> get >>>>> their broken builds back. that or just live with people who have broken >>>>> systems >>>>> and go around all day saying "e is broken., it sucks" probably because >>> they >>>>> shot themselves in the foot by choosing to have it be broken (they or >>>>> whoever >>>>> decided on the packaging/builds of efl). >>>>> >>>> >>>> We've already lost developers because of build feature removals during >>> the >>>> big tree merge, I'd rather not provide further reasons for people to not >>>> use EFL. >>>> >>>> I'd rather have users who claim that "e is broken., it sucks" than no >>>> users. Ignorance can be easily remedied, frustration and apathy >>> frequently >>>> cannot. >>> >>> well then you might want to work on at least a way at runtim to detetc all >>> possible build settings in efl and as to which then may or may not be >>> broken at >>> runtime, and go and actually make code - eg ein e, to detect these and >>> "annoy >>> the user with dialogs (make less annoying with 'dont display this again')". >>> >> >> Enlightenment already has checks that you added for various crucial (but >> optional) image loaders. If there are other important-but-optional features >> that are now used in Enlightenment, checks should indeed be added for them. >> >> >>> >>> i wonder how many users will go away due to annoyance now? for every 1 >>> person >>> making spec files, deb packages or ebuilds, there are 1000's of users who >>> will >>> now be annoyed. >>> >>> making app developers write even more code to handle niche options >>> decreases >>> the likelihood people will want to write apps with efl. in fact they just >>> wont >>> do this at al because its extra work and they don't even know they need to >>> do >>> it. write lots of docs as to what to detect and how. and then all the >>> possible >>> things it may affect and in what way. >>> >> >> I think you're overestimating how many application developers are going to >> be depending on optional features (eg. xcb, pulseaudio, physics) for core >> functionality in their applications. > > Just a though on physics, if an edje file is using physics, we should > fail opening it and rely on our infrastructure to properly fallback. > Of course a debug message would be useful, but we should be able to > degrade nicely. In the case of missing ecore_audio and an edje file > using it, we should also be able to degrade nicely and display a > warning in the console and maybe even generate a signal that both the > application and the theme could react on. > > The main issue here is mostly xcb, which is not going forward anytime > soon as you at the end always need xlib.
Only if you are using GL for rendering. Maybe removing that code > would solve our main problem here and reduce user facing issue. If we > do drop our support for xcb, which I am in fully in favor, we could > also remove that long configure command. > I think the long configure command is there for more than just xcb usage... dh >> Regardless, if you're truly targeting distribution (Gentoo) packagers with >> this flag then I think a much better solution is to try working directly >> with them. The alternative is that things like >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f8dcc8ef38e94ef3942f6c71820cbc6503550c5 >> will >> continue to happen, and this flag will continue to make some of our own >> core developers mad for questionable gains in quality. >> >> >>> >>> >>>>>> On Thu, Dec 24, 2015 at 9:04 PM Carsten Haitzler < >>> ras...@rasterman.com> >>>>>> wrote: >>>>>> >>>>>>> On Thu, 24 Dec 2015 19:11:28 +0000 Mike Blumenkrantz >>>>>>> <michael.blumenkra...@gmail.com> said: >>>>>>> >>>>>>>> As further proof of how unsuccessful this has been, here's the >>>>> downstream >>>>>>>> patch that Gentoo's core repo ebuilds use: >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=422cf597b84d3553eac42dd8b1faa8257af5941f >>>>>>>> >>>>>>>> It removes the sleep entirely, making the entire thing (and all >>>>> future >>>>>>>> attempts at "getting attention") a complete waste of time for >>>>> everyone. >>>>>>> >>>>>>> that specifically isn't going to change anything as in my >>> experience no >>>>>>> gentoo >>>>>>> "user" reads build output. they pastebin it and have someone else >>> read >>>>> it >>>>>>> for >>>>>>> them. so a sleep is being patched out only to "make the build >>> faster". >>>>>>> >>>>>>> changing the "i know what i am doing" option stops the build >>> entirely >>>>> and >>>>>>> such >>>>>>> patches are not a workaround for that. >>>>>>> >>>>>>> we havent changed that option for maybe 2 years. ok - checking log. >>>>> last >>>>>>> change >>>>>>> was 1.5 years ago - july 2014. so perhaps the "its not working" is >>> a >>>>>>> result of >>>>>>> not changing it often enough? the builds settle in and then dont >>>>> change? >>>>>>> >>>>>>>> On Thu, Dec 24, 2015 at 12:22 PM Mike Blumenkrantz < >>>>>>>> michael.blumenkra...@gmail.com> wrote: >>>>>>>> >>>>>>>>> After having read these mails, as well as the past mails on >>> this >>>>> topic, >>>>>>>>> I'm beginning to see a pattern. >>>>>>>>> >>>>>>>>> This option was originally implemented because a Gentoo user >>> came >>>>> into >>>>>>> #e >>>>>>>>> last year asking why something in Enlightenment didn't work >>>>> (possibly >>>>>>> mouse >>>>>>>>> cursors, since the eet image loader is/was optional). It was >>>>> determined >>>>>>>>> that changing any "default" configure option would require this >>>>> flag so >>>>>>>>> that Gentoo users would then come to #e to ask why their >>> ebuild was >>>>>>> broken >>>>>>>>> instead of lacking features in their applications. >>>>>>>>> >>>>>>>>> Having seen the flag at work for almost two years, I can only >>> say >>>>>>> that, in >>>>>>>>> my opinion, the objective has not been met. Trying to filter >>> Gentoo >>>>>>> users >>>>>>>>> (since yes, it was directed specifically at blocking them from >>>>> toggling >>>>>>>>> features) in this way is, in a word, impossible. To understand >>> why, >>>>>>> it's >>>>>>>>> necessary to examine the state of Enlightenment packaging in >>>>> Gentoo. >>>>>>>>> Currently, Gentoo "provides" Enlightenment. Looking at the >>>>> available >>>>>>>>> packages ( >>>>> https://packages.gentoo.org/packages/x11-wm/enlightenment >>>>>>>>> https://packages.gentoo.org/packages/dev-libs/efl), it's easy >>> to >>>>> see >>>>>>> that >>>>>>>>> updates are not frequent since none of the packages are even >>> close >>>>> to >>>>>>>>> up-to-date. Users can easily figure out what the latest >>> version of >>>>>>>>> available software is, and they will typically want to use it, >>> even >>>>>>> more so >>>>>>>>> on Gentoo. So how do Gentoo users usually install >>> Enlightenment to >>>>> get >>>>>>>>> these latest versions? They use third party repositories. >>>>>>>>> Checking the list of (public) repositories for Enlightenment >>>>> packages >>>>>>>>> yields significantly more results ( >>>>>>>>> http://gpo.zugaina.org/x11-wm/enlightenment >>>>>>>>> http://gpo.zugaina.org/dev-libs/efl). These repositories are >>>>>>> maintained >>>>>>>>> by users (anyone), and are updated MUCH more frequently than >>> the >>>>> core >>>>>>>>> repository, typically by someone who is more in-tune with >>> upstream >>>>>>>>> development. According to the overlays listed, none have yet >>>>> updated >>>>>>> to the >>>>>>>>> flag's name change, but I'd guess this is more likely related >>> to >>>>> lack >>>>>>> of >>>>>>>>> time due to holidays/end of year than not having noticed the >>>>> change or >>>>>>>>> having been notified of it. Regardless, once they update, and >>> they >>>>>>> will, >>>>>>>>> breaking this option will have been a waste of time for >>> everyone, >>>>>>> including >>>>>>>>> the time that I spent writing this mail. >>>>>>>>> >>>>>>>>> Furthermore, I'd like to address what may be an oversight from >>> the >>>>>>>>> statement that "it's to try and force whoever is maintaing the >>>>> build to >>>>>>>>> sit and think for a bit about what they are doing and possibly >>>>>>>>> re-evaluate their choices and be reminded that what they are >>> doing >>>>> is >>>>>>> likely >>>>>>>>> problematic" from Carsten. I think the fact that all the >>> ebuilds >>>>>>> contain >>>>>>>>> the previous flag, specifically the updated version, indicates >>> that >>>>>>> either >>>>>>>>> nobody is reevaluating anything here or nobody cares. So, in >>>>> effect, >>>>>>> all >>>>>>>>> that's happening here is that we're annoying everybody else >>>>>>> permanently so >>>>>>>>> that we can annoy Gentoo users for a period of a couple weeks >>> after >>>>>>>>> changing the flag. >>>>>>>>> >>>>>>>>> I'm not affected by this personally, but I don't think this >>> makes >>>>>>>>> promoting our projects any easier. Given the size of our >>> userbase, >>>>> I'd >>>>>>> have >>>>>>>>> expected us to be working harder to make things easier for >>> anyone >>>>> and >>>>>>>>> everyone to use our code, not adding small speed bumps like >>> this >>>>> for >>>>>>> people >>>>>>>>> to potentially be affected by simply because eg. their system >>>>> doesn't >>>>>>>>> distribute a -devel package for Bullet. >>>>>>>>> >>>>>>>>> To me, perhaps a more user-friendly and packager-friendly >>> approach >>>>>>> would >>>>>>>>> have been to pop an error in applications which use optional >>>>> features >>>>>>> about >>>>>>>>> a feature being missing. While this puts a small burden on >>>>> application >>>>>>>>> developers, it's a much smaller overall burden than this >>> configure >>>>> flag >>>>>>>>> experiment, which I can only view as a debacle. >>>>>>>>> >>>>>>>>> On Thu, Dec 24, 2015 at 8:34 AM Carsten Haitzler < >>>>> ras...@rasterman.com >>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Thu, 24 Dec 2015 11:10:30 +0100 Boris Faure <bo...@fau.re> >>>>> said: >>>>>>>>>> >>>>>>>>>>> On 15-12-15 11:13, Carsten Haitzler wrote: >>>>>>>>>>>> On Mon, 14 Dec 2015 21:41:04 +1030 Simon Lees < >>>>> si...@simotek.net> >>>>>>>>>> said: >>>>>>>>>>>> >>>>>>>>>>>>> Now waiting for the script that auto changes the flag >>>>> whenever >>>>>>> the >>>>>>>>>>>>> gentoo wiki gets updated >>>>>>>>>>>> >>>>>>>>>>>> we need to get more imaginative then. :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> What is the intent behind that? >>>>>>>>>>> What's the point in pissing off people (myself included) ? >>>>>>>>>> >>>>>>>>>> thhe point is that an option is enabled or disabled that is >>> not >>>>>>>>>> recommended. >>>>>>>>>> then someone complains of "my build broke" or "this doesn't >>> work". >>>>>>> and we >>>>>>>>>> have >>>>>>>>>> to field endless questions only to find out it is this >>> problem. >>>>>>>>>> >>>>>>>>>> so as in the past, a gentoo user turned up and complained his >>>>> ebuild >>>>>>> is >>>>>>>>>> broken. >>>>>>>>>> i ask "did you enable/disable x/y/z?" the answer: "i don't >>> know - >>>>> i >>>>>>> just >>>>>>>>>> copied >>>>>>>>>> the ebuild and didn't look - i don't know what that option >>> even >>>>> means, >>>>>>>>>> but it's >>>>>>>>>> a use flag" etc. etc. >>>>>>>>>> >>>>>>>>>> you can blame the gentoo user mentality of "omg. i need to >>>>> customize >>>>>>> every >>>>>>>>>> possible option if it at all exists, and i won't read any >>> docs on >>>>> it >>>>>>> or >>>>>>>>>> what it >>>>>>>>>> does or how it works or interacts with the codebase". this is >>> why >>>>> that >>>>>>>>>> option >>>>>>>>>> is there to begin with and why it gets changed - it's to try >>> and >>>>> force >>>>>>>>>> whoever >>>>>>>>>> is maintaing the build to sit and think for a bit about what >>> they >>>>> are >>>>>>>>>> doing and >>>>>>>>>> possibly re-evaluate their choices and be reminded that what >>> they >>>>> are >>>>>>>>>> doing is >>>>>>>>>> likely problematic. >>>>>>>>>> >>>>>>>>>> you are not the target for this, but reality is that there >>> isnt' >>>>>>> another >>>>>>>>>> way to >>>>>>>>>> address the issue. if we make it an environment variable that >>>>> bypasses >>>>>>>>>> the need >>>>>>>>>> for this option "only for advanced people" then ebuilds just >>>>>>> eventually >>>>>>>>>> have >>>>>>>>>> that embedded into them without anyone knowing why: "just set >>> this >>>>>>> and you >>>>>>>>>> never have to deal with that option again". >>>>>>>>>> >>>>>>>>>> once every year or 2 this option may change. is that THAT >>> much of >>>>> a >>>>>>>>>> burden for >>>>>>>>>> you? >>>>>>>>>> >>>>>>>>>>> Now I have to change my script since I disable pulseaudio, >>>>>>> physics and >>>>>>>>>>> gstreamer. Yes, I do send patches when things break. >>>>>>>>>>> Do we really have the luxury to piss off maintainers when >>> we >>>>> look >>>>>>> at >>>>>>>>>>> the state of the packaging in various distributions? >>> Debian is >>>>> far >>>>>>>>>>> out-dated it's not even funny, even arch did update to >>> efl-1.16 >>>>>>> just a >>>>>>>>>>> week ago and stayed way too long with 1.15.1 while 1.15.2 >>> was >>>>> out >>>>>>> and >>>>>>>>>>> fixed a bug reported few times about terminology's settings >>>>> panel. >>>>>>>>>>> If you just want not to waste your time on bugs from >>> people who >>>>>>> used >>>>>>>>>>> that option, just do like the linux kernel does with the >>>>> "tainted" >>>>>>> flag. >>>>>>>>>>> Pissing off people is not the way to do. You just look >>> arrogant. >>>>>>> You're >>>>>>>>>>> just throwing a wrench into the gears of people who try to >>> port >>>>> efl >>>>>>> to >>>>>>>>>>> not supported platforms like windows, mac, the *BSD… >>>>>>>>>> >>>>>>>>>> and how do you know it's tainted? you expect every efl app to >>>>> print >>>>>>> some >>>>>>>>>> error >>>>>>>>>> debug? or you expect an invisible "this is tainted" log on >>> build? >>>>> do >>>>>>> you >>>>>>>>>> know >>>>>>>>>> that people don't even READ their logs? they pastebin them and >>>>> let us >>>>>>>>>> read them >>>>>>>>>> for them? when they clearly state something like "cannot find >>> pkg >>>>> x >>>>>>>>>> between >>>>>>>>>> version Y and Z". they never read a log even when a build >>> fails, >>>>> let >>>>>>>>>> alone when >>>>>>>>>> it succeeds. and most of them never have or keep the logs, so >>> it's >>>>>>> runtime >>>>>>>>>> then... >>>>>>>>>> >>>>>>>>>> package maintainers HAVE to update their build files when they >>>>> update >>>>>>> a >>>>>>>>>> package. this option and it changing has NOTHING to do with >>> the >>>>> lack >>>>>>> of >>>>>>>>>> packages. they have to change version number, probably >>> changelog, >>>>> and >>>>>>>>>> quite >>>>>>>>>> possibly the file include list if we added new install files >>> and >>>>> they >>>>>>>>>> were very >>>>>>>>>> strict on their package file lists. proper packaging requires >>>>> this. >>>>>>>>>> >>>>>>>>>> so you got angry because a build failed and you have to >>> change 1 >>>>> char >>>>>>> in >>>>>>>>>> the >>>>>>>>>> options? billiob. i thought better of you. >>>>>>>>>> >>>>>>>>>> that option exists because many options are untested, or >>>>> experimental >>>>>>> or >>>>>>>>>> buggy. >>>>>>>>>> example - xcb. i know for certain it does not fully implement >>>>> every >>>>>>>>>> ecore-x >>>>>>>>>> function. in some cases we actually cant implement with xcb. >>> this >>>>>>> option >>>>>>>>>> changing serves as a reminder that making these kinds of >>> options >>>>> ... >>>>>>> an >>>>>>>>>> option >>>>>>>>>> and changing them is dangerous leading to a broken system. if >>> we >>>>>>> don't do >>>>>>>>>> this, >>>>>>>>>> those that have far less clue than you simply never know >>> because >>>>> they >>>>>>>>>> blindly >>>>>>>>>> use some build script and swizzle options THAT script tells >>> them >>>>> they >>>>>>> can >>>>>>>>>> with >>>>>>>>>> no warning. it's not arrogance - it's trying hard to help >>> those >>>>> tho >>>>>>> don't >>>>>>>>>> know >>>>>>>>>> any better - to really point out the advice that their options >>>>> may be >>>>>>>>>> problematic. >>>>>>>>>> >>>>>>>>>> the other option is we remove all build options that are >>> untested >>>>> or >>>>>>>>>> supported. >>>>>>>>>> then we can't have any "bad builds" and then people like you >>> have >>>>> no >>>>>>>>>> option but >>>>>>>>>> to patch the src code or go away. i have seriously considered >>> this >>>>>>> many >>>>>>>>>> times >>>>>>>>>> but chose to keep at least the most useful options so people >>> like >>>>> you >>>>>>> can >>>>>>>>>> make >>>>>>>>>> the choice. you don't think that this small bit of work on >>> your >>>>> part >>>>>>> is >>>>>>>>>> not >>>>>>>>>> worth the ability to have the option to disable pulse audio >>> for >>>>>>> example? >>>>>>>>>> (disabling the support disables audio support in edje and that >>>>> then >>>>>>> means >>>>>>>>>> that >>>>>>>>>> a whole edje feature doesn't work as advertised. YOU know >>> this and >>>>>>> accept >>>>>>>>>> that >>>>>>>>>> - but do others who don't even read the README and make an >>>>> informed >>>>>>>>>> decision?) >>>>>>>>>> >>>>>>>>>>> /me got angry >>>>>>>>>>> -- >>>>>>>>>>> Boris Faure >>>>>>>>>>> Pointer Arithmetician >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
