Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Cedric BAIL]

On Wed, Dec 30, 2015 at 8:44 PM, Mike Blumenkrantz
 wrote:
> On Tue, Dec 29, 2015 at 7:33 PM Carsten Haitzler 
> wrote:
>> On Tue, 29 Dec 2015 19:10:00 + Mike Blumenkrantz
>>  said:
>> > On Mon, Dec 28, 2015 at 7:13 PM Carsten Haitzler 
>> > wrote:
>> >
>> > > On Mon, 28 Dec 2015 19:36:53 + Mike Blumenkrantz
>> > >  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 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Mike Blumenkrantz]

On Tue, Dec 29, 2015 at 7:33 PM Carsten Haitzler 
wrote:

> On Tue, 29 Dec 2015 19:10:00 + Mike Blumenkrantz
>  said:
>
> > On Mon, Dec 28, 2015 at 7:13 PM Carsten Haitzler 
> > wrote:
> >
> > > On Mon, 28 Dec 2015 19:36:53 + Mike Blumenkrantz
> > >  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

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Christopher Michael]

On 12/30/2015 02:59 PM, Cedric BAIL wrote:
> On Wed, Dec 30, 2015 at 8:44 PM, Mike Blumenkrantz
>  wrote:
>> On Tue, Dec 29, 2015 at 7:33 PM Carsten Haitzler 
>> wrote:
>>> On Tue, 29 Dec 2015 19:10:00 + Mike Blumenkrantz
>>>  said:
 On Mon, Dec 28, 2015 at 7:13 PM Carsten Haitzler 
 wrote:

> On Mon, 28 Dec 2015 19:36:53 + Mike Blumenkrantz
>  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 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Mike Blumenkrantz]

On Mon, Dec 28, 2015 at 7:13 PM Carsten Haitzler 
wrote:

> On Mon, 28 Dec 2015 19:36:53 + Mike Blumenkrantz
>  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
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.

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.


>
> > 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.


>
> 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 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 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[The Rasterman]

On Tue, 29 Dec 2015 19:10:00 + Mike Blumenkrantz
 said:

> On Mon, Dec 28, 2015 at 7:13 PM Carsten Haitzler 
> wrote:
> 
> > On Mon, 28 Dec 2015 19:36:53 + Mike Blumenkrantz
> >  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 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Mike Blumenkrantz]

Changing the option only affects users of git, so it's not the highest
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.

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.

On Thu, Dec 24, 2015 at 9:04 PM Carsten Haitzler 
wrote:

> On Thu, 24 Dec 2015 19:11:28 + Mike Blumenkrantz
>  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: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[The Rasterman]

On Mon, 28 Dec 2015 19:36:53 + Mike Blumenkrantz
 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 
> wrote:
> 
> > On Thu, 24 Dec 2015 19:11:28 + Mike Blumenkrantz
> >  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 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[The Rasterman]

On Thu, 24 Dec 2015 19:11:28 + Mike Blumenkrantz
 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.
> >
> > 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Mike Blumenkrantz]

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 
> wrote:
>
>> On Thu, 24 Dec 2015 11:10:30 +0100 Boris Faure  said:
>>
>> > On 15-12-15 11:13, Carsten Haitzler wrote:
>> > > On Mon, 14 Dec 2015 21:41:04 +1030 Simon Lees 
>> 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 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Mike Blumenkrantz]

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 
wrote:

> On Thu, 24 Dec 2015 11:10:30 +0100 Boris Faure  said:
>
> > On 15-12-15 11:13, Carsten Haitzler wrote:
> > > On Mon, 14 Dec 2015 21:41:04 +1030 Simon Lees 
> 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
> 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Boris Faure]

On 15-12-15 11:13, Carsten Haitzler wrote:
> On Mon, 14 Dec 2015 21:41:04 +1030 Simon Lees  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) ?
  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…

/me got angry
-- 
Boris Faure
Pointer Arithmetician


signature.asc
Description: Digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[The Rasterman]

On Thu, 24 Dec 2015 11:10:30 +0100 Boris Faure  said:

> On 15-12-15 11:13, Carsten Haitzler wrote:
> > On Mon, 14 Dec 2015 21:41:04 +1030 Simon Lees  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 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Adrien Nader]

You're painful.

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[The Rasterman]

On Mon, 14 Dec 2015 21:41:04 +1030 Simon Lees  said:

> Now waiting for the script that auto changes the flag whenever the 
> gentoo wiki gets updated

we need to get more imaginative then. :)

> On 12/14/2015 08:00 PM, Daniel Juyung Seo wrote:
> > Hahaha you made my day!
> >
> > On Fri, Dec 11, 2015, 11:07 AM Carsten Haitzler 
> > wrote:
> >
> >> raster pushed a commit to branch master.
> >>
> >>
> >> http://git.enlightenment.org/core/efl.git/commit/?id=44260b69e263407cc66ed9ccb9de1a502b9f7cbb
> >>
> >> commit 44260b69e263407cc66ed9ccb9de1a502b9f7cbb
> >> Author: Carsten Haitzler (Rasterman) 
> >> Date:   Fri Dec 11 09:51:00 2015 +0900
> >>
> >>  efl -break the "i really know what i'm doing" option to get attention
> >>
> >>  so .. more gentoo "i just copy and pasted and dont know what i'm
> >>  doing" land has hit again.
> >> ---
> >>   configure.ac | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index 00d6cb9..05b836c 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -4692,7 +4692,7 @@ AM_CONDITIONAL([ALWAYS_BUILD_EXAMPLES], [test
> >> "${want_always_build_examples}" =
> >>
> >>   BARF_OK="xno"
> >>   # Harfbuzz
> >>
> >> -AC_ARG_ENABLE
> >> ([i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-aba],
> >>
> >> +AC_ARG_ENABLE
> >> ([i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-abb],
> >> [ You will be told when this is needed ], [
> >>   if test "x${enableval}" = "xyes" ; then
> >>
> >> --
> >>
> >>
> >>
> > --
> > ___
> > 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


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Simon Lees]

Now waiting for the script that auto changes the flag whenever the 
gentoo wiki gets updated

On 12/14/2015 08:00 PM, Daniel Juyung Seo wrote:
> Hahaha you made my day!
>
> On Fri, Dec 11, 2015, 11:07 AM Carsten Haitzler 
> wrote:
>
>> raster pushed a commit to branch master.
>>
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=44260b69e263407cc66ed9ccb9de1a502b9f7cbb
>>
>> commit 44260b69e263407cc66ed9ccb9de1a502b9f7cbb
>> Author: Carsten Haitzler (Rasterman) 
>> Date:   Fri Dec 11 09:51:00 2015 +0900
>>
>>  efl -break the "i really know what i'm doing" option to get attention
>>
>>  so .. more gentoo "i just copy and pasted and dont know what i'm
>>  doing" land has hit again.
>> ---
>>   configure.ac | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 00d6cb9..05b836c 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -4692,7 +4692,7 @@ AM_CONDITIONAL([ALWAYS_BUILD_EXAMPLES], [test
>> "${want_always_build_examples}" =
>>
>>   BARF_OK="xno"
>>   # Harfbuzz
>>
>> -AC_ARG_ENABLE([i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-aba],
>>
>> +AC_ARG_ENABLE([i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-abb],
>>  [ You will be told when this is needed ],
>>  [
>>   if test "x${enableval}" = "xyes" ; then
>>
>> --
>>
>>
>>
> --
> ___
> 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

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Daniel Juyung Seo]

Hahaha you made my day!

On Fri, Dec 11, 2015, 11:07 AM Carsten Haitzler 
wrote:

> raster pushed a commit to branch master.
>
>
> http://git.enlightenment.org/core/efl.git/commit/?id=44260b69e263407cc66ed9ccb9de1a502b9f7cbb
>
> commit 44260b69e263407cc66ed9ccb9de1a502b9f7cbb
> Author: Carsten Haitzler (Rasterman) 
> Date:   Fri Dec 11 09:51:00 2015 +0900
>
> efl -break the "i really know what i'm doing" option to get attention
>
> so .. more gentoo "i just copy and pasted and dont know what i'm
> doing" land has hit again.
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 00d6cb9..05b836c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -4692,7 +4692,7 @@ AM_CONDITIONAL([ALWAYS_BUILD_EXAMPLES], [test
> "${want_always_build_examples}" =
>
>  BARF_OK="xno"
>  # Harfbuzz
>
> -AC_ARG_ENABLE([i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-aba],
>
> +AC_ARG_ENABLE([i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-abb],
> [ You will be told when this is needed ],
> [
>  if test "x${enableval}" = "xyes" ; then
>
> --
>
>
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel