On 06/30/2016 06:17 AM, Michał Górny wrote: > On Wed, 29 Jun 2016 21:54:44 -0700 > Daniel Campbell <z...@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
Description: OpenPGP digital signature