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. 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 >> >> >> -- >> ------------- Codito, ergo sum - "I code, therefore I am" -------------- >> The Rasterman (Carsten Haitzler) ras...@rasterman.com >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
