On 06/30/2016 05:24 PM, Rich Freeman wrote: > On Thu, Jun 30, 2016 at 7:19 PM, Daniel Campbell <z...@gentoo.org> wrote: >> 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. > > QA has authority over the Gentoo repository, but their scope for > exercising this authority is relatively narrow. Ultimately we expect > them to police themselves, but if they become a problem any developer > can appeal to the Council. For the most part the policies they > enforce have either been the sorts of things almost anybody would > agree with, or they're Council decisions. > > If the Council decides on a policy, then QA is completely within their > rights to take action to enforce that policy. If somebody wants to > appeal they can, but of course they're going to be appealing to the > Council that set the policy. That is by design. The whole point of > the Council is to have some way to reach a "final" decision when there > isn't consensus. Of course, Councils can change their mind, but in > practice this has been rare. > >> But ripping out the >> eclass is a "solution" that creates more problems than it solves. > > Trust me, this wasn't something the Council undertook lightly. > > >> >> 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? > > Ultimately the Council, by sole virtue of election. It isn't perfect, > but it is a process that has a form of accountability and it at least > is capable of yielding a final decision. On a lot of issues either A > or B is better than endlessly bickering between them. Of course, the > Gentoo way is to support choice and if somebody comes up with a good > way to push the decision into the hands of the end user then we can > just argue over the most sane default. No matter how you slice it, > there will always be decisions that people disagree over. > > Personally, I don't really buy into the SSD use case. It isn't that I > don't agree with the virtues of SSDs, but the most straightforward > solution to this is to stick / and /usr on the SSD so that all > applications benefit from this. An entire Gentoo install is only a > few GB worth of binaries/libraries/etc and it is probably a lot more > straightforward to indiscriminately put these on the SSD than to pick > and choose. Plus, your system will boot a LOT faster. This is what I > do - basically / is on an SSD and then I mount stuff on top from hard > drives when I need space.
I'm not sure the SSD-for-games-only is the most effective solution either, but there are plenty of use cases that I disagree with that tend to get by without issue. Are / or /usr on SSD the proposed solution for someone who's aiming for the speed boost? > > In an earlier email you mentioned that this wasn't a big concern for > you personally but you were concerned for our end users. One bit of > advice that I'll offer is that if this is the case, let them speak for > themselves. Speaking personally, I'm interested in feedback from > anybody I get it from. However, when somebody comes to the Council > with an argument like "somebody, somewhere, might disagree" and nobody > is actually saying "this affects me" then it probably won't get a lot > of weight. > > Ultimately, though, you're going to have to trust the judgment of the > council. Or, whether you trust it or not, you will ultimately have to > abide by it for anything you do using your commit access. How are we certain that users will speak up for their cause when it's lacking support? Don't we risk alienating people without considering use cases? I understand where you're coming from wrt council decisions. I've corrected that and started a thread on gentoo-user that will give us some insight to how many users' use cases were affected by this decision and which use cases they were. Then we can either set a goal to make that use case possible, or give quality advice or write good documentation for that use case. >> 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? > > QA is enforcing a Council policy. Whether something is considered > breakage ultimately is up to the Council. Who is on the Council is of > course up to all of us. While I don't advise turning an election into > a referendum on one particular decision I certainly encourage > developers to be selecting Council members based upon their ability to > strike an appropriate balance here. The Council's ability to dictate > tree-wide policies like these are probably the area where it has the > biggest impact on developers being able to scratch their itches. So, > this stuff is really important. > > The Council also confirms the lead of QA. And of course there is the > ability to appeal. There are of course issues with any human-run > organization but I struggle to think of conflicts the QA team has had > with developers which weren't addressed by the QA lead or the team. > Certainly I don't recall actually getting any actual appeals (for QA, > and in my time on the Council I've only seen one Comrel appeal). I > don't want to get into Comrel but the principle is the same with that > organization, just with a different scope of operations. > >> 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. > > There is no intent to stifle discussion. You're welcome to state your > opinion. The Council can always reverse the decision, or the next > Council can do so. I personally consider either unlikely, but Gentoo > is never compelled to jump off a cliff because of a past mistake. > However, at this point this is a fairly established decision, so while > you can discuss, this isn't considered something on-hold for debate. > That could change if a majority of the Council decides to issue a > stay/etc, but certainly I'm not calling for one based on what I've > heard so far. > > Ultimately I feel one of the key purposes of the Council is to remove > obstacles to progress by making calls when they need to be made. A > call has been made, and there cannot be obstacles for those > implementing the decision. > >> 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. > > The Council is not bound to the options presented to it, and Council > members can propose Council agenda items the same as anybody else > (we're developers too!). Speaking personally I certainly try to think > of our developers and users as a whole, and I'm confident my peers > tend to do so as well. We don't always agree, but I've never had > occasion to question anybody's motives. > > Sure, we're more likely to take up a topic that somebody is > complaining about than one that nobody is complaining about. And of > course we're going to tend to judge dissatisfaction by opposition. > However, we don't pull up the 100-email debate and count the number of > posts on each side. Ultimately we're going to tend to use our > judgment, which is what we're supposed to be selected for (and really, > what else can we do?). Persuasive arguments will of course tend to > persuade, but this shouldn't be viewed as a bug. > > In this case I can assure you that people were frustrated that it took > as long as it did to end up with a decision, and it largely was > because we recognized the controversy. There were multiple rounds of > meetings and numerous opportunities to provide feedback. Ultimately, > however, providing feedback does not guarantee any particular result. > >> 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. > > QA isn't forcing anybody to do anything. They put out a call for > help. People can choose to answer it or not at their discretion. The > Council didn't attempt to force anybody to do anything for precisely > the reasons you state. We made a decision to clear the way, but > ultimately the people that are most bothered by the eclass will > probably be the ones to implement the decisions. As long as nobody > interferes with them, it can take however long it needs to take. So, agenda gets pushed to council -> council votes in favor of motion -> QA acts on council decision -> decisions empower them to prohibit blocking them -> somehow this is not forcing. The last jump in logic is questionable to me. > FOSS ultimately comes down to "patches welcome." If it bothers you > that much, go fix it. The Council can get the roadblocks out of your > way, but the ultimate test of your resolve is whether you're willing > to put in the work. Anybody can put out an appeal for volunteers. I > know some have complained that removing the games eclass has taken as > long as it has, and ultimately it comes down to willingness to put in > the work. If the eclass doesn't bother you, then by all means sit > back and let others take care of it. > Patches *wouldn't* be welcome in this case, however. The patch in question would change default games.eclass variables to standard Gentoo paths. I know with certainty it wouldn't be accepted or welcomed. And with that knowledge, what would motivate me (or someone else, like someone with a relevant use case) to work toward getting that done? It would end up relegated to an overlay. There's nothing wrong with that, technically speaking, but it belies the story of "Patches welcome, everyone can contribute." Ignoring the use cases of others ensures that one day my use case will be on the stake. I wouldn't have worked toward becoming a developer if I was apathetic. --- To all other points, thanks for clarifying the operating structure of Gentoo. I'm going to wait on my gentoo-user survey to give us some concrete results to work with; be they in favor of games.eclass or apathetic. It will at least reflect reality. -- 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
