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