On Fri, Jul 1, 2016 at 5:10 AM, Daniel Campbell <z...@gentoo.org> wrote: > > 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? >
Well, that's certainly what I would do. But, you can ask the games team if they have a better idea, or feel free to join it. > > 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 specifically said that the Council is NOT limited to considering only the use cases that come up in the discussion. Obviously we consider every use case that people suggest or that we think up. We probably don't consider use cases that nobody has come up with. In any case, if you come up with a good reason not to move forward with the decision and the Council agrees with you, I'm sure the decision would be changed. The fact is that ANY decision can turn out to be a bad one in retrospect. That isn't a reason to never make a decision. If you can think of a good reason why we're wrong, I'm sure we're going to be interested (or more likely the next Council will be). However, decisions that were made months ago after lengthy discussion don't get on hold because somebody /might/ come up with another argument (so far you've only advanced the SSD concern, and I don't see anybody biting on that one). > 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. If something important that wasn't considered comes up I'll certainly listen if I'm on the Council, or argue for it if I'm not. However, Gentoo is not obligated to sustain every possible edge case just because somebody claims it is useful, even if that edge case happened to be supported in the past. I'm skeptical that something will come up that hasn't been thought of already, but it isn't like any of us have some kind of personal hate for the eclass. If something important comes up we'll think about it. > > 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. > Nobody is forcing anybody to DO anything. Nobody is forced to go around editing ebuilds to remove the eclass. Now, we ARE forcing people to NOT DO things. If somebody removes the games eclass from an ebuild you're forbidden to add it back. You're forbidden to port the eclass to EAPI6. And so on. I'm not pretending that the Council decision isn't binding. That's the whole point of having the Council. If every decision were made on unanimous consensus we wouldn't need one. Obviously it isn't the outcome we want but if people do oppose Council decisions they're subject to QA/Comrel actions including temporary or permanent commit access removal, and their ultimate appeal is to the Council they opposed. Democracy isn't anarchy. > 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. Patches to remove games.eclass from ebuilds would be welcome, and that was my point. The reason it is still around is that nobody has done the work to get rid of it yet. And if you want to suggest a better way, feel free. If you want to try to resurrect the games team, please do so. Heaven only knows we tried to get devs to revitalize it numerous times in the last year. I don't know if the Council would accept a games eclass that was a no-op by default but which exposed functionality to users via environment variables. I'd be interested into a discussion of the pros/cons if you're volunteering to do the work to make it happen. I'd be inclined to continue the policy that it is up to maintainers to decide whether they're going to use it, otherwise we'll have endless debates as to whether ktuberling or c-intercal fall under "games" or not. Something more generic and Gentoo Prefix-like might make it into PMS and even become mandatory (and indeed Prefix is already a potential solution which is fairly well-supported). > 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. Gentoo has never claimed to offer a solution for every possible use case, and every distro has its pros and cons. I think Gentoo goes a lot further than most distros to accommodate use cases. If you thought this debate was bad, you should go read the reaction when the decision was made that not having /usr mounted during early boot was not considered supported (though multiple mechanisms to get it mounted during early boot exist). Decisions like these don't mean that we actively go out looking for ways to make our users lives miserable, but it does mean that when somebody's bluetooth keyboard doesn't work in single user mode we can WONTFIX them if they're not mounting /usr early. In any case, I think we'll get further looking for some way to move forward than look backwards. If you come up with a use case you consider important, let's see if we can come up with a good way to deal with it that is more sustainable. You were the one to first suggest looking at something like Prefix for a solution to your SSD use case, and there is probably something to work with there. Personally I think it is probably easier to just stick everything that isn't huge on an SSD than to pick and choose package categories, but you could of course run your games in a prefix, or something prefix-like, or even in a container (though that might be less ideal unless you're sticking X11 and everything else in there too, at which point you might as well just stick your root on an SSD). I understand where you're coming from. There have been times at the past where a package was being treecleaned and I'd tend to go on a crusade to rescue it because somebody might still want to use it. The reality is that such reprieves tend to be temporary at best, unless somebody who is genuinely interested in investing in the package is willing to put the time in. We want to help our users because we care about them, but in the end if their itches aren't our own itches it tends to fizzle out sooner or later. Sometimes a use case gets dropped not because it is a bad one, but simply because nobody cares enough to make it work. Instead, time gets put into maintaining other things that are more interesting. Java isn't in a pitiful state in Gentoo because we all want to see it fail, it simply is the case that most of us aren't interested enough to make it otherwise. All it takes to turn Gentoo into a Java paradise is a few really eager volunteers to step in and make it so. On the other hand, there are other projects where Gentoo could probably be held up as a model distro. If you manage to drum up more interest in games and more active contributions, I think that would be a good thing. -- Rich
