[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass
From:       Daniel Campbell <zlg () gentoo ! org>
Date:       2016-06-30 23:19:04
Message-ID: 91d683e1-bc8d-9f92-3aaf-69d055b947c4 () gentoo ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


On 06/30/2016 06:17 AM, Michał Górny wrote:
> On Wed, 29 Jun 2016 21:54:44 -0700
> Daniel Campbell <zlg@gentoo.org> wrote:
> 
>> That's what I think this drama is about; changes being pushed from
>> people who don't work on games, then leaving these game maintainers (and
>> users) in the dark without a "correct" way to achieve what they're
>> after. We can do better than that, and it's solvable in a technical
>> manner, which is why I'm focused on it.
> 
> I'd really appreciate if you did some research before accusing people.

I've read the council meetings that I was able to find on it and have
explored the perspectives of both sides of the subject. What research
are you asking for? I've not attacked anyone.
> 
>> On the political side...
>>
>> Do teams hold any authority (or veto power, whatever you want to call
>> it) over their own ebuilds? Is it reasonable to rip functionality out
>> from under a group of developers and tell them to deal with it?
>>
>> I think teams deserve autonomy over their own ebuilds, [...]
> 
> No, they do not and I will not allow that to happen ever again. And I'm
> pretty sure I'm not the only one here that was unhappy with the way
> Games team pushed everyone around over the years.
> 
> If you want autonomy, fork Gentoo or use your own repository. The core
> Gentoo repository is community-maintained -- either live with it, or
> leave. We do not need more people causing massive community damage for
> years with nobody being bold enough to stop them.
Our ebuilds are maintained by developers, with the occasional
proxy-maintainer or contributor. Your previous statement combined with
this amounts to "QA owns and manages the Gentoo repository." You just
said teams have no autonomy over their own ebuilds, which naturally
extends to individual developers lacking autonomy for their ebuilds, as
well.

This has little to do with what I want. I don't seek any of the use
cases that games.eclass made possible, but that doesn't mean my use
cases won't be axed in the future with the same lack of care and for
similarly petty reasons.

> 
> People and teams have reasonable right to develop policies and maintain
> their own packages. However, they have no right to assume sole
> ownership of all packages with generic characteristic, and hold it
> for years while preventing anyone from having any saying on anything.
> 
> Rephrasing Rich's words, how would you feel if I established 'Text
> editors' project and claimed final saying on every single text editor
> in Gentoo? Then I would develop policies I find useful, ignore any
> input, ignore join requests and discourage anyone from contributing.
> Is that the Gentoo you desire?
No, it's not the Gentoo I desire. I've seen that claim thrown around and
I've not seen any evidence of it happening follow it. I get it if you or
others have a vendetta against the games team -- I don't know any of
them really -- sometimes people don't get along. But ripping out the
eclass is a "solution" that creates more problems than it solves.
Changing its default prefix values to follow Gentoo's standard and
allowing users to change it meets the needs of both parties, and yet it
seems nobody considered that option. Rich suggested maybe its
functionality could be put into a later EAPI, but as he noted there are
hurdles in generalizing that behavior. If its values default to match
Gentoo's, then only the people who need the path flexibility will need
to change it. That's one of the recent trends for us lately, isn't it?
Leave sane defaults, but if people want to change them and/or break
things, they're free to.

I expect to be told that use case is poor or irrelevant. Who decides
which use cases are valid and what qualifies them to make those claims?
> 
>> and should
>> ideally follow QA guidelines *where reasonable*. Any good QA team should
>> have iron-clad reasons behind their decisions, and answers for
>> 'what-ifs' that exist outside of the ideal perfection that QA tends to
>> operate in.
> 
> The whole point of QA is to provide good quality *everywhere*, and it
> is *unacceptable* to have developers decide if they want to follow
> policies or not. It is reasonable to adjust the policies as necessary,
> or allow grace periods. But there is no point in having policies that
> are fully optional depending on the mood of the developer.
And how is a QA group taken seriously if they don't address breakage
that they introduce? Is QA not held to a standard at all? Is it a set of
arbitrary rules laid down from this separate project that nobody else
can examine or call for re-examination?

A key ingredient to QA is knowing quality code when one sees it, and
fully understanding the use cases that a given set of code makes
possible. Ideally, they also understand and suggest best practices so
people are aware of how to 'color inside the lines'.

This games.eclass decision breaks use cases, supplies no replacement or
forward-facing route for users, and is being swept under the rug as
quickly as possible.
> 
> That said, this is completely irrelevant to the topic at hand. This
> isn't QA's decision. It's a long process started by individual
> developers *interested in helping out with games* years ago, which
> ended up with Council appeal. The source of the policy is the Council,
> not QA.
Those are weasel words. It was QA's decision to bring the topic to the
Council, was it not? And it had a vested interest in a favorable ruling
by the Council, no? If the answer to both is "yes", then QA was just as
responsible bringing the decision to fruition as the council itself. The
council doesn't make decisions on its own based on what I've read; they
make decisions when options or challenges are brought to them.
Therefore, people who make the most noise get heard and from the looks
of it, their way as well.
> 
> QA is merely concerned with the fact that Games team ignores
> the policies established by the Council. This results in two different
> layouts being deployed over the repository which results in increased
> confusion (which you are victim of), and decreased quality. QA offers
> to help in solving that.
> 
>> Removing eclasses without really good reason and without replacements
>> for missing use cases simply shouldn't happen. I wouldn't want that done
>> to me, and I'd definitely not (knowingly) help someone else do it.
> 
> Your disagreement with the rationale does not make it bad.
> 
The rationale goes against what QA supposedly stands for (Quality
Assurance). It breaks use cases and breaks ebuilds that use the eclass.
In what way does the quality improve that changing games.eclass's
default prefixes to match the rest of the tree doesn't also solve?

Have you read the eclass? All the variables are at the top and we can
change the defaults with no issue, while people who depend on that
eclass can set the variables in make.conf or some other place. For
those, there are news items.

Instead, with things as they are now, ebuilds get broken and user
expectations get turned on their head, upstream (us) doesn't give them
any hints on how to go forward, and until every games.eclass-depending
ebuild gets fixed, it'll have warnings and/or die() calls. The *only*
benefit gained from this is the unicorn "every package is treated the
same", except when they're not (@system target, coreutils and friends
ring a bell?).

In short, QA pushed the decision onto the council, the council ruled in
favor of QA, so now QA gets to deal with the fallout of their decision.
If the QA team doesn't want that, perhaps they should handle breaking
changes better. Or elect better leadership.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]