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. > 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. 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. 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). 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). > 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 > > > >> > > > >> > > > >> -- > > > >> ------------- 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 > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > -- ------------- 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
