[gentoo-dev] RFD: new global USE flag gtk3

[Ulrich Mueller]

Following up to today's QA meeting: The gtk3 USE flag is used by
27 packages, so I suggest making it a global flag:

gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3

Ulrich

[Samuli Suominen]

that would suggest it's fine to use, and is anything but temporary

-1 from here

[Steev Klimaszewski]

MATE desktop (which I hope to bring in to Portage soon) can be built
against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
me. Just because gtk+ 3 is the latest, does not mean it's the greatest,
and I really wish people would realize that newest != bestest.

[Michał Górny]

Dnia 2014-02-20, o godz. 01:44:17
Steev Klimaszewski <st...@gentoo.org> napisał(a):

> On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
> > On 20/02/14 00:23, Ulrich Mueller wrote:
> > > Following up to today's QA meeting: The gtk3 USE flag is used by
> > > 27 packages, so I suggest making it a global flag:
> > >
> > > gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> > >
> > > Ulrich
> >
> > that would suggest it's fine to use, and is anything but temporary
> >
> > -1 from here
> >
> MATE desktop (which I hope to bring in to Portage soon) can be built
> against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
> me.

Except that now users have to use USE='gtk gtk3' to get GUIs in random
applications that support only one toolkit. And then handle
REQUIRED_USE mess for packages that support choosing one of the two.

> Just because gtk+ 3 is the latest, does not mean it's the greatest,
> and I really wish people would realize that newest != bestest.

Yet it's supported, unlike GTK+2. I really wish people would actually
step up to fix bugs when the time comes rather than shouting about their
right to choose.

--
Best regards,
Michał Górny

[Lars Wendler]

+1

gtk+:3 still is a mess even in its tenth incarnation...

--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC

[Samuli Suominen]

Then you pick whatever is best supported for MATE, and ship it using that.
Later when they have completed their support for GTK+-3, and it's the
best supported, you ship that. It's not rocket science.

[Steev Klimaszewski]

OR, since I'm the maintainer, I decide that I'm willing to deal with
both, instead of you telling me that I need to pick one or the other.
Upstream says both are supported and viable, and I'm willing to deal
with the headaches. Just because you're unwilling doesn't mean others
aren't. kthx.

[Ulrich Mueller]

>>>>> On Thu, 20 Feb 2014, Michał Górny wrote:

> Except that now users have to use USE='gtk gtk3' to get GUIs in
> random applications that support only one toolkit. And then handle
> REQUIRED_USE mess for packages that support choosing one of the two.

Why REQUIRED_USE? A package can prefer one of the alternatives if both
flags are specified. Probably it's a good idea to emit a warning,
though.

Ulrich

[Steev Klimaszewski]

On Thu, 2014-02-20 at 09:11 +0100, Michał Górny wrote:
> Dnia 2014-02-20, o godz. 01:44:17
> Steev Klimaszewski <st...@gentoo.org> napisał(a):
>
> > On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
> > > On 20/02/14 00:23, Ulrich Mueller wrote:
> > > > Following up to today's QA meeting: The gtk3 USE flag is used by
> > > > 27 packages, so I suggest making it a global flag:
> > > >
> > > > gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> > > >
> > > > Ulrich
> > >
> > > that would suggest it's fine to use, and is anything but temporary
> > >
> > > -1 from here
> > >
> > MATE desktop (which I hope to bring in to Portage soon) can be built
> > against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
> > me.
>
> Except that now users have to use USE='gtk gtk3' to get GUIs in random
> applications that support only one toolkit. And then handle
> REQUIRED_USE mess for packages that support choosing one of the two.
>

Sorry? Still better than forcing things on because it allows me to be
lazy.

> > Just because gtk+ 3 is the latest, does not mean it's the greatest,
> > and I really wish people would realize that newest != bestest.
>
> Yet it's supported, unlike GTK+2. I really wish people would actually
> step up to fix bugs when the time comes rather than shouting about their
> right to choose.
>

Who is shouting about right to choose? In fact, I see only MATE in
capital letters there, and that's because that's the way that it's
written by upstream. Just because you enjoy forcing people to do things
your way, doesn't mean everyone feels the need to be controlling. I'm
cool with giving the users choice, it doesn't HAVE to be done, but I'm
not so against it that I insist they follow my one true way...

[Alexandre Rostovtsev]

On Thu, 2014-02-20 at 02:47 -0600, Steev Klimaszewski wrote:
> OR, since I'm the maintainer, I decide that I'm willing to deal with
> both, instead of you telling me that I need to pick one or the other.
> Upstream says both are supported and viable, and I'm willing to deal
> with the headaches. Just because you're unwilling doesn't mean others
> aren't. kthx.

And this is an example of why everyone on the gnome team doesn't like
the "gtk3" flag. Because well-meaning developers will be looking at
their one corner of the portage tree, deciding that they are going to
handle the choice of gtk version without slotting, and not consider the
effect on the distro as a whole.

You know what's going to happen now, after the QA team decision?

First of all, lots of developers will start renaming "gtk" to "gtk3" in
their ebuilds' IUSE.

Which means "gtk gtk3" will soon have to be added to USE in
targets/desktop/gnome/make.defaults (currently, the gnome profile
globally only has USE="gtk" because the "gtk3" flag is evil).

And users of non-gnome profiles who use gnome applications will of
course manually add "gtk gtk3" to USE in their local make.conf.

Unfortunately, at the same time, lots of other developers are going to
start adding support for building against gtk2 XOR gtk3. Because of
course "Gentoo is about choice", and the more choices, the merrier, and
the gtk3 flag has been declared as supported by the QA team. And that
means lots of REQUIRED_USE="^^ ( gtk gtk3 )".

For the gnome team this results in a headache: maintaining a big list of
"-gtk" / "-gtk3" entries in targets/desktop/gnome/package.use so that
gnome users get a sensible choice and don't need to edit /etc/portage/*
just to emerge widely used desktop tools.

But for non-gnome users who manually added USE=gtk3 to make.conf, this
means regular emerge conflicts after sync, forcing them to *guess*
whether "-gtk" or "-gtk3" in pacakge.use is the better choice. Maybe
with portage auto-suggesting the wrong solution just to add to the
wonderful user experience :/

[Ulrich Mueller]

>>>>> On Thu, 20 Feb 2014, Alexandre Rostovtsev wrote:

> Unfortunately, at the same time, lots of other developers are going
> to start adding support for building against gtk2 XOR gtk3. Because
> of course "Gentoo is about choice", and the more choices, the
> merrier, and the gtk3 flag has been declared as supported by the QA
> team. And that means lots of REQUIRED_USE="^^ ( gtk gtk3 )".

No, in most cases REQUIRED_USE would be against policy. The actual
policy is to "pick one of the USE flags in conflict to favour and
should alert the user that a particular flag is being used instead",
see the devmanual:
http://devmanual.gentoo.org/general-concepts/use-flags/index.html

> For the gnome team this results in a headache: maintaining a big
> list of "-gtk" / "-gtk3" entries in
> targets/desktop/gnome/package.use so that gnome users get a sensible
> choice and don't need to edit /etc/portage/* just to emerge widely
> used desktop tools.

Right, and that's exactly the reason why REQUIRED_USE should not be
used, except where it's forced be reverse USE dependencies. Quoting
the devmanual again:
"Note: In order to avoid forcing users to micro-manage flags too much,
REQUIRED_USE should be used sparingly. Follow the normal policy
whenever it is possible to do a build that will presumably suit the
user's needs."

Ulrich

[Steev Klimaszewski]

See, now this is an example of a good email as to why supporting both
can be a hassle for more than just one desktop. Instead of telling me
that I'm dumb for thinking it's a good idea to follow upstream's
supported ideas, and that we should force one or the other.

The KDE team seems to be able to deal with it just fine, but somehow
it's impossible and hard for the GNOME team. Why is that? What does
KDE do differently that makes it feasible?

[Samuli Suominen]

Bye bye distribution level consistency :-(

It's sad that few stubborn developers can do that.

- Samuli

[Samuli Suominen]

No, they didn't manage it, at all, which why we don't see Qt3/KDE3 in
tree anymore.

[Alexandre Rostovtsev]

On Thu, 2014-02-20 at 03:23 -0600, Steev Klimaszewski wrote:
> The KDE team seems to be able to deal with it just fine, but somehow
> it's impossible and hard for the GNOME team. Why is that? What does
> KDE do differently that makes it feasible?

The KDE ecosystem moved from qt3 to qt4 around 2007-2009, when Gentoo
was at EAPI1 and EAPI2 (so no REQUIRED_USE), plus it happened so long
ago that any pain from the transition period has been forgotten :)

[Alex Alexander]

The main idea here is to create a system that is consistent.

Yes, gtk2 is still used and IMO we need to provide support for it as long as there are apps linked to it with no real alternatives.

But we also need to think about the future. The situation today is a total mess.

In an ideal world, gtk3 would replace gtk2 everywhere in an instant, making this discussion pointless. Unfortunately, this is not the case.

Versioned USE flags solve most of the problems with minimum fuss, while paving the road for a much cleaner gtk3 -> gtk4 transition.

We don't really need generic use flags anyway. Adding gtk3 to your USE is really easy and I expect our user base to be able to handle these things with ease.

Alex

[Duncan]

Samuli Suominen posted on Thu, 20 Feb 2014 07:55:44 +0200 as excerpted:

You must have missed the news implied by that "following up" wording,
then. See the announcement/thread "February 2014 QA policy updates",
posted by creffett, just a few minutes before this thread started.

http://permalink.gmane.org/gmane.linux.gentoo.devel/90291


Thus indeed, "anything but temporary" it appears to be.

(Personally, FWIW, while I understood the previous policy and wasn't
complaining, as a user who doesn't yet have gtk3 installed and who hopes
to convert all my installed gtk dependers to gtk3 at once and kill gtk2
at the same time I install gtk3 when the time comes, I do appreciate the
new policy, as it'll be that much easier to track what's pulling in one
or the other during the transition period.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

[Alexandre Rostovtsev]

I see. So you want USE="gtk gtk3" to mean the same thing that gnome team
had intended USE="gtk" to mean, which is to say, "pick whichever gtk
version that is the most sensible".

That could work. There are already a few ebuilds, e.g. audacious, with
REQUIRED_USE="^^ ( gtk gtk3 )" - so before this unfortunate practice
spreads further, the gnome team would need to note on the wiki to make
sure other developers know why this is especially undesirable for the
gtk/gtk3 flag pair.

The other unfortunate aspect of the gtk3 flag is that it encourages
using flags instead of slotting for libraries that can support both gtk
and gtk3, resulting in needless rebuilds of when one of the flags is
switched on/off. But again, that could be addressed with a bit of
documentation.

[Samuli Suominen]

On 20/02/14 12:07, Duncan wrote:
> Samuli Suominen posted on Thu, 20 Feb 2014 07:55:44 +0200 as excerpted:
>
>> On 20/02/14 00:23, Ulrich Mueller wrote:
>>> Following up to today's QA meeting: The gtk3 USE flag is used by 27
>>> packages, so I suggest making it a global flag:
>>>
>>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
>>>
>>> Ulrich
>> that would suggest it's fine to use, and is anything but temporary
>>
>> -1 from here
> You must have missed the news implied by that "following up" wording,
> then. See the announcement/thread "February 2014 QA policy updates",
> posted by creffett, just a few minutes before this thread started.

I find it sad the QA team has been taken over by some of the new and
semi-new
developers who don't completely understand the implications of this
decision yet
since they haven't lived through the older transitions.

[Lars Wendler]

Very bad excuse... They punted kde3 because they didn't have the
manpower to stem both KDEs...

[Ulrich Mueller]

>>>>> On Thu, 20 Feb 2014, Alexandre Rostovtsev wrote:

> I see. So you want USE="gtk gtk3" to mean the same thing that gnome
> team had intended USE="gtk" to mean, which is to say, "pick
> whichever gtk version that is the most sensible".

Exactly.

> That could work. There are already a few ebuilds, e.g. audacious,
> with REQUIRED_USE="^^ ( gtk gtk3 )" - so before this unfortunate
> practice spreads further, the gnome team would need to note on the
> wiki to make sure other developers know why this is especially
> undesirable for the gtk/gtk3 flag pair.

Devs should really follow the policy outlined in the devmanual.
REQUIRED_USE was introduced to solve a specific problem with USE
dependencies (which can break if a USE flag is ignored in an ebuild
because it is superseded by another one). It shouldn't be used all
over the place.

We don't want users having to solve a Zebra Puzzle [1] (or, for the
more theoretically inclined, a satisfiability problem [2]) to find
an acceptable combination of their USE flags.

Ulrich

[1] http://en.wikipedia.org/wiki/Zebra_Puzzle
[2] http://en.wikipedia.org/wiki/Boolean_satisfiability_problem

[Andreas K. Huettel]

>
> I find it sad the QA team has been taken over by some of the new and
> semi-new
> developers who don't completely understand the implications of this
> decision yet
> since they haven't lived through the older transitions.

As far as I can remember, the "experienced" and "older" developers were unable
to work together in a QA team and actually stick to the policies themselves.

--
Andreas K. Huettel
Gentoo Linux developer
kde, council

[Matt Turner]

On Thu, Feb 20, 2014 at 4:21 AM, Andreas K. Huettel
<dilf...@gentoo.org> wrote:
>> I find it sad the QA team has been taken over by some of the new and
>> semi-new
>> developers who don't completely understand the implications of this
>> decision yet
>> since they haven't lived through the older transitions.
>
> As far as I can remember, the "experienced" and "older" developers were unable
> to work together in a QA team and actually stick to the policies themselves.

That's not necessarily worse. :)

[Alex Alexander]

Well, I find it sad that Gentoo is trying really hard to resist change - although things have been improving lately.

Honestly, I really like the new QA team, we actually push things forward! Sure, not everyone will always agree with us, but that is natural.

By the way, we did not take over. We were entrusted with this role, we discuss everything with the community and try to take decisions that are good for Gentoo. We don't have some secret ulterior motive to take over the world through Gentoo.

For what it's worth, as a QA member I always vote with what I believe is best for Gentoo in mind.

Cheers,
Alex

[Ciaran McCreesh]

On Thu, 20 Feb 2014 11:48:11 +0100
Ulrich Mueller <u...@gentoo.org> wrote:
> We don't want users having to solve a Zebra Puzzle [1] (or, for the
> more theoretically inclined, a satisfiability problem [2]) to find
> an acceptable combination of their USE flags.

Actually, REQUIRED_USE was introduced precisely to require users to
solve SAT without help... As you may recall, we *were* going to use
pkg_pretend for this sort of thing to give the users a friendly error
message, but this was replaced at the last minute with REQUIRED_USE to
force package manglers to reduce the quality of error message that's
produced.

So really we should just scrap REQUIRED_USE in EAPI 6, and migrate any
ebuilds currently using it to a sane alternative.

--
Ciaran McCreesh

[Tom Wijsman]

"'Ey! Have you heard about it. Gentoo doesn't provide X with support
for Y, then what are their USE flags even for; what a shame, ..."

If people want to support and use multiple things, let them do so. It is
pretty much what Gentoo and its philosophy are about; which somewhat
can be summarized as providing choices such that we fit the users'
need, and not force our one true way upon them...

Greetings from someone who runs GNOME 3 and MATE simultaneously; you can
intentionally break it, but why would you? It takes away our happiness.
On the other hand, there's the part where you want to break it for a
reason, perhaps for your happiness; but then I'd like to hear why.

--
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address : Tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ciaran McCreesh:

One thing that bothers me most about gentoo is a discussion I had with
a colleague who uses FreeBSD. It ended up like... gentoo is
interesting, but wtf all those USE flags and no idea how to even get
something to build without reading through forum threads, mailing
lists, et c. ... and finally trying to get help on IRC.
That guy is not new to linux. And he is right.

Usability is not our strongest thing. That's why I pushed for a clear
decision on this matter, because the whole thing is already confusing
and weird enough for new users. The new python eclasses and multilib
added to that complexity (but that will hopefully be gone when the
transition is over, more or less). People who regularly hack and play
with gentoo don't have any problem with those things and quickly get
ideas about emerge conflicts based on experience... where a new user
would never get to the root of the problem and just give up.

But the question is... what sane alternative to REQUIRED_USE? That
will also have impact on a lot of eclasses.


Also... I find mgornys idea not too bad, meaning USE flag naming
should be feature oriented and not implementation oriented. That is
definitely an issue QA has to comment on. But I really feel we will
get some hate from people who try to avoid certain implementations for
one or another reason. And there can be valid reasons. So those people
will have to use alternatives like package.mask.
Another problem I see is that e.g. "gui" could be a bit too generic.
If some dev uses it for an ncurses gui in his ebuild... then we have
successfully screwed up easy setup of X-less servers, because "-gui"
will also kill all non-X guis.
Anyway... what we can do to improve the overall situation while
discussing this: use proper local USE flag descriptions.
"Add support for x11-libs/gtk+ (The GIMP Toolkit)" is totally useless
in 95% of the cases. Still... a lot of ebuilds don't override that
description. So I often end up actually unpacking the source tarball
and reading the configure description. Fail.
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJTBjBWAAoJEFpvPKfnPDWza6EIAIoctpgmuUN8m793AtkaLExI
WvI85BzjxLZ/71w4wNC2Fgeqid4qvTMlopCnqfqSrXBJqXPwiuhsDMTh2DPQOuRU
hm3DvZSbApCJnGXqwE3XeJSarQnmBZ+Ynbkv/keqLWsErG/6BxRxsK4a1DW36vhf
MB60Ysb2bpI/vn+ihtbHUCC/Z5LzzY8CtvC4cqydoVfl4hPxbi+oZaaoBM8Ul9AJ
no9Ql7lK6J5SRuLqs8vB5XAYdt+crm76fzg0kMpNm4zkNNMqOLDIUYy/tLXqibwl
TnGvah9PeN9mxo72iURIhXbnIUeoabShr3ELKSgu22QZ1l7yG3WGhoGMGoOTqIU=
=LaFD
-----END PGP SIGNATURE-----

[Ciaran McCreesh]

On Thu, 20 Feb 2014 16:41:58 +0000
hasufell <hasu...@gentoo.org> wrote:
> But the question is... what sane alternative to REQUIRED_USE? That
> will also have impact on a lot of eclasses.

Either pkg_pretend, or Exherbo's MYOPTIONS.

--
Ciaran McCreesh

[Tom Wijsman]

The older transitions came up a few times during the discussions on
this (in and out of meeting); we're aware of it to a certain extent,
as for whether that is understood I'd say that if around 7 people vote
on the matter that that is based on a necessary amount of understanding.

Feel free to point out further concerns from older transitions.

[Ryan Hill]

On Thu, 20 Feb 2014 11:26:18 +0200
Samuli Suominen <ssuo...@gentoo.org> wrote:

> Bye bye distribution level consistency :-(

The last time we had distribution level consistency was the moment between the
first and second packages getting committed to the tree.


--
Ryan Hill psn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463

[Ryan Hill]

On Thu, 20 Feb 2014 05:16:55 -0500
Alexandre Rostovtsev <tetr...@gentoo.org> wrote:

> The other unfortunate aspect of the gtk3 flag is that it encourages
> using flags instead of slotting for libraries that can support both gtk
> and gtk3, resulting in needless rebuilds of when one of the flags is
> switched on/off. But again, that could be addressed with a bit of
> documentation.

Slotting a library by toolkit rather than by version just doesn't work in a lot
of cases. Having multiple versions of a library installed is common enough
practice and upstreams will often take that into account and version their
library names, include paths, pkgconfig files, etc. Most don't do that for
different toolkits. So if you're slotting by toolkit you have to start
installing one in a non-standard location to prevent file collisions (and it's
always the newer toolkit since you don't want to break existing packages), and
every new ebuild using that toolkit needs to be changed to look in the right
place, and you have to start futzing around with symlinks, and wrapper scripts,
and eselect, and eclasses, and every time some dev uses the wrong depend atom
you get a bug about it, and it goes on and on and on.

Or you can add USE=gtk3, deal with collisions internally, install one set of
headers, and go do something productive with your life.

wxGTK not only splits up libraries by version and toolkit, but also by charset
and debug/release. If we had to use different SLOTs rather than USE flags we
would need eight of them for 2.8 alone. And I don't know how we would name the
ebuilds (-r100,-r200,... ugh).

[Alexandre Rostovtsev]

On Sat, 2014-02-22 at 14:57 -0600, Ryan Hill wrote:
> wxGTK not only splits up libraries by version and toolkit, but also by charset
> and debug/release. If we had to use different SLOTs rather than USE flags we
> would need eight of them for 2.8 alone. And I don't know how we would name the
> ebuilds (-r100,-r200,... ugh).

Remember, a single process cannot load both gtk2 and gtk3 - you *will*
get random crashes. If you think that dealing with interesting bug
reports - e.g. caused by application foo which was built against your
wxGTK[gtk3] and then crashed after enumerating its plugin directory
because of the presence of binary plugin bar which links to libbaz which
sometimes dlopens gtk2 at runtime when USE=wombat is enabled - is more
fun than doing a bit of work at the start and slotting wxGTK, then
please go ahead ;)

[Ryan Hill]

Yeah and package built against wxGTK (gtk2) could dlopen gtk3 at runtime
today. That's already the case. But what does that have to do with slotting?

[Ryan Hill]

On Sat, 22 Feb 2014 15:50:17 -0600
Ryan Hill <dirt...@gentoo.org> wrote:

> On Sat, 22 Feb 2014 16:09:53 -0500
> Alexandre Rostovtsev <tetr...@gentoo.org> wrote:
>
> > On Sat, 2014-02-22 at 14:57 -0600, Ryan Hill wrote:
> > > wxGTK not only splits up libraries by version and toolkit, but also by
> > > charset and debug/release. If we had to use different SLOTs rather than
> > > USE flags we would need eight of them for 2.8 alone. And I don't know how
> > > we would name the ebuilds (-r100,-r200,... ugh).
> >
> > Remember, a single process cannot load both gtk2 and gtk3 - you *will*
> > get random crashes. If you think that dealing with interesting bug
> > reports - e.g. caused by application foo which was built against your
> > wxGTK[gtk3] and then crashed after enumerating its plugin directory
> > because of the presence of binary plugin bar which links to libbaz which
> > sometimes dlopens gtk2 at runtime when USE=wombat is enabled - is more
> > fun than doing a bit of work at the start and slotting wxGTK, then
> > please go ahead ;)
>
> Yeah and package built against wxGTK (gtk2) could dlopen gtk3 at runtime
> today. That's already the case. But what does that have to do with slotting?

Oh. The libs are named explicitly:

/usr/lib64/libwx_gtk2u_core-3.0.so
/usr/lib64/libwx_gtk3u_core-3.0.so

You can't load the wrong one.

[Alexandre Rostovtsev]

Ah, I see. I was afraid you were proposing to use the same library name
for wxGTK+gtk2 and wxGTK+gtk3.

[Peter Stuge]

Tom Wijsman wrote:
> I'd say that if around 7 people vote on the matter that that is
> based on a necessary amount of understanding.

That is just incredibly naïve.

In another project five people reviewed an experimental change
written by me that someone else proposed for inclusion into the
project without my knowledge or consent.

Not a single person thought to communicate with me about the change
and not a single person realized that there were enormous fundamental
problems with the change. (Why *I* hadn't proposed it for inclusion.)

In history lessons you may have learned about majorities of populations
supporting something the same individuals consider a pretty darn bad
idea in hindsight, but which they were unable to decide on correctly
at the time.

You need to learn to respect what you don't know that you don't know.


//Peter

[Peter Stuge]

Tom Wijsman wrote:
> > > I'd say that if around 7 people vote on the matter that that is
> > > based on a necessary amount of understanding.
> >
> > That is just incredibly naïve.

..

> > You need to learn to respect what you don't know that you don't know.
>

> Or you apply knowledge codification and mark it as experimental.

No, that's what you *know* that you don't know.


//Peter

[Tom Wijsman]

Or you apply knowledge codification and mark it as experimental.

[Tom Wijsman]

Exactly, which effectively keeps us away from unknown unknowns; by
turning them into efficient known knowns. This is how risk prevention
works, which makes the person whom does risk analysis see a sunny day.

[Peter Stuge]

Tom Wijsman wrote:
> > > > You need to learn to respect what you don't know that you don't
> > > > know.
> > >
> > > Or you apply knowledge codification and mark it as experimental.
> >
> > No, that's what you *know* that you don't know.
>
> Exactly, which effectively keeps us away from unknown unknowns;

I'm afraid that's utter nonsense.

There's no point in repeating myself so I'll stop here.

I should have known better than to try to tell you something.


Sorry about the noise everyone

//Peter

[Tom Wijsman]

On Mon, 24 Feb 2014 03:16:44 +0100
Peter Stuge <pe...@stuge.se> wrote:

> Tom Wijsman wrote:
> > > > > You need to learn to respect what you don't know that you
> > > > > don't know.
> > > >
> > > > Or you apply knowledge codification and mark it as experimental.
> > >
> > > No, that's what you *know* that you don't know.
> >
> > Exactly, which effectively keeps us away from unknown unknowns;
>
> I'm afraid that's utter nonsense.

It is as much nonsense as your example that doesn't work out for that.

> I should have known better than to try to tell you something.

Communication with all the parties, looking into history cases, looking
into other cases and more was done by the QA team; if there is still an
unknown unknown, it is due to the lack of knowledge codification.

It is what brought the QA team to a slow start, as there were barely
documents available besides a GLEP and a small set of documentation;
this is noticeable in other areas of our distribution as well, your
example demonstrates the importance of knowledge codification here.

Marking it as experimental keeps everyone happy.

[Alex Alexander]

On Sun, Feb 23, 2014 at 6:59 PM, Peter Stuge <pe...@stuge.se> wrote:

Tom Wijsman wrote:
> I'd say that if around 7 people vote on the matter that that is
> based on a necessary amount of understanding.

That is just incredibly naïve.

[...]

In history lessons you may have learned about majorities of populations
supporting something the same individuals consider a pretty darn bad
idea in hindsight, but which they were unable to decide on correctly
at the time.

You need to learn to respect what you don't know that you don't know.

You assume too much. Which is ironic, considering that you're calling us naive.

We are not playing guessing games here.

Making a decision means that we have the proper knowledge on the matter at hand. We can't guarantee that our decision will be correct, but we can sleep at night knowing we did our best, with the best of intentions.

Cheers,

--

Alex Alexander
+ wired
+ www.linuxized.com
+ www.leetworks.com

[Samuli Suominen]

So, no more setting USE="gtk" and assuming the best packaged software
will be get installed,
be it with what version of the toolkit, 1, 2 or 3
Instead, now you have to selectively do the maintainers job for figuring
out which one
is the best supported one
Despite already picking up a modern theme with both GTK+ 2.x and GTK+
3.x looks, now you
might end up with half-crippled software just because some stubborn
people choose the
looks, not the functionality, to be their motivation

Such people really don't deserve to own a packager status if they can't
take the time to
determine / examine the package's best supported graphical toolkit
If multiple ones with similar feature set is supported, then the latest
toolkit is preferred

But seems like I'm repeating common sense which the GNOME guideline
layed out long ago
Bunch of new QA developers shoudn't have any power to override that

[Tom Wijsman]

On Tue, 25 Feb 2014 17:28:41 +0200

What is "best"? What you would deem best, could be worst for the user.

> Instead, now you have to selectively do the maintainers job for
> figuring out which one is the best supported one

The maintainer can use IUSE flag defaults for this; but, there are
users that want to control which toolkit is installed. Going further,
they want to decide which toolkit the software is built with.

> Despite already picking up a modern theme with both GTK+ 2.x and GTK+
> 3.x looks, now you might end up with half-crippled software just
> because some stubborn people choose the looks, not the functionality,
> to be their motivation

You need to mask that as a packager.

> Such people really don't deserve to own a packager status if they
> can't take the time to determine / examine the package's best
> supported graphical toolkit

What is "best"? If upstream provides both and claims they both are
well supported, I consider both are.

> If multiple ones with similar feature set is supported, then the
> latest toolkit is preferred

What is "preferred"? What you prefer can be different than the user.

> But seems like I'm repeating common sense which the GNOME guideline
> layed out long ago

The GNOME guideline fits just the GNOME team and developers whom follow
that; however, in the bigger picture, there are maintainers that do not
follow that and do something different. Looking at the tracker [1]; it
appears that it is more common for such a bug to be marked as INVALID
or WONTFIX, than it is to be marked as FIXED.

As a result of this, the users get an inconsistent USE flag presented.

The "common sense" is just another wording of "opinion" here; if it
wants to be real "common sense" shared amongst almost everyone, it'll
need a bit more than a guideline.

[1]:
https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL%20blocked%3A420493

[Raymond Jennings]

If I may ask, isn't usage by 27 packages ample grounds on its own to make it a global use flag?

This is one of the questions I noticed on the ebuild quiz, and there the ballpark is around 5 packages sharing a use flag.  we're way over that mark.

my two cents.

[Tom Wijsman]

On Sat, 15 Mar 2014 11:55:45 -0700
Raymond Jennings <shen...@gmail.com> wrote:

> If I may ask, isn't usage by 27 packages ample grounds on its own to
> make it a global use flag?
>
> This is one of the questions I noticed on the ebuild quiz, and there
> the ballpark is around 5 packages sharing a use flag. we're way over
> that mark.
>
> my two cents.

What is mentioned there is criteria; however, the very last sentence is
what makes the actual global USE flag be able to happen. Quote:

"Before introducing a new global USE flag, it must be discussed on
the gentoo-dev mailing list."

So, for people to agree on something to be a global USE flag; amongst
other things, they need to agree that the USE flag is useful and
something we acknowledge we want to use globally. Otherwise I would
for instance be able to start a bad idea in the added MATE packages...

For reference, http://devmanual.gentoo.org/general-concepts/use-flags

PS: Can you avoid top posting? Like this mail, on mailing lists people
commonly type their response after the message such that the context
comes first and it is more understandable what is being responded to.