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? > > 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')". 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. > > > 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 -- ------------- 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
