Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Dnia 2015-02-15, o godz. 09:43:24 Rich Freeman ri...@gentoo.org napisał(a): On Fri, Feb 13, 2015 at 3:10 PM, hasufell hasuf...@gentoo.org wrote: Rich Freeman: On Wed, Feb 11, 2015 at 2:15 PM, hasufell hasuf...@gentoo.org wrote: A team is clearly violating GLEP39 and you don't care: When did I claim to not care? That's my interpretation of the council mocking those who have brought up issues by saying: * we cannot hold votes, because no one wants to join To me it sounds like an excuse, because you really were unable to make them actually do a vote. First, the council isn't holding votes FOR the games team. The council is giving the opportunity for people to join the games team and vote. That didn't happen. What's your proposed solution? Clearly we're unable to make them actually do a vote, which everybody knew going into this. It might not have occurred to you, but nobody in Gentoo can make anybody do anything. Let's lastrite all games. This will solve all our issues, and perhaps when someone is actually willing to start over we'll get things into sane state. -- Best regards, Michał Górny pgp08kxBTc1bV.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Fri, Feb 13, 2015 at 3:10 PM, hasufell hasuf...@gentoo.org wrote: Rich Freeman: On Wed, Feb 11, 2015 at 2:15 PM, hasufell hasuf...@gentoo.org wrote: A team is clearly violating GLEP39 and you don't care: When did I claim to not care? That's my interpretation of the council mocking those who have brought up issues by saying: * we cannot hold votes, because no one wants to join To me it sounds like an excuse, because you really were unable to make them actually do a vote. First, the council isn't holding votes FOR the games team. The council is giving the opportunity for people to join the games team and vote. That didn't happen. What's your proposed solution? Clearly we're unable to make them actually do a vote, which everybody knew going into this. It might not have occurred to you, but nobody in Gentoo can make anybody do anything. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Rich Freeman: On Wed, Feb 11, 2015 at 2:15 PM, hasufell hasuf...@gentoo.org wrote: A team is clearly violating GLEP39 and you don't care: When did I claim to not care? That's my interpretation of the council mocking those who have brought up issues by saying: * we cannot hold votes, because no one wants to join To me it sounds like an excuse, because you really were unable to make them actually do a vote. It may have one or many leads, and the leads are selected by the members of the project. This selection must occur at least once every 12 months, and may occur at any time. Instead we are getting tree inconsistency, because people start to ignore the team. That is the worst that could happen. You clearly lack imagination. There are many things that could happen that are far worse than this. Gentoo not having anybody maintaining any games would be a worse outcome, for starters. What punishment would you deem appropriate for a team not following GLEP39? We could disband it, but we're not in any hurry to do so, because we're not convinced that doing this will make things any better. I don't need imagination to see that it can't get worse. There is pretty much only one active member left and some who commit a few things all 3-5 months. But I'm not going to repeat things. If you think everything will break and people will stop working on gentoo if you fix a dysfunctional project, then let me tell you that this already happens... things break right now and people stop working on gentoo (or at least some areas of it) right now. This isn't even a big deal... but because you are incapable of action you are making it one. Maybe the solution is point 3 of GLEP39 under the rationale section: If the council does a lousy job handling global issues (or has no global vision), vote out the bums Which would be why I've encouraged you to run for Council a few times now if you think you'll do better. I'm not going to apologize for being elected. If you really think that games.eclass is the hill we should all be dying on, you can put that in your manifesto. I think the urgent part of the crisis was dealt with (a conflict between individual maintainers and the games team, and a concern that people couldn't join the games team even if they wanted to). We can afford to take our time to deal with the rest, and it is best left to those who actually care about the issue. Nothing was dealt with. You just told people they should go ahead ignoring a dysfunctional team (but you called it positively everyone may commit games to the tree or somesuch). If you think that is a solution, then that's exactly what gentoo will be dying on. And no, this isn't the only incident that shows this way of thinking. The others went similarly bad.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Andreas K. Huettel: Tim Harder: Also, I would advise caution on considering it dysfunctional and disbanding it due to this. I cannot follow that argumentation. Because no one wants to join, the team is functional? I'm seeing a lot of commits by mr_bones and tupone recently. Doesn't look defunct to me. So let's summarize: * the council agreed that there are problems with the project * the council said it will deal with it * the council said there will be votes for a new lead What we have now is: * the council says there is no problem * the council didn't deal with it * there have been no votes errr... wat? Seriously?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Wed, Feb 11, 2015 at 11:08 AM, hasufell hasuf...@gentoo.org wrote: So let's summarize: * the council said it will deal with it Cite? I just posted what the council ACTUALLY said, and this wasn't on it. I'd re-post it, but I think it was only two posts ago for my part. What we have now is: * the council says there is no problem Cite? A random council member posting that they don't think that we should take drastic action isn't the council saying something. Even all seven council members posting random posts on lists isn't the council saying something. Believe it or not, the council is composed of mortal human beings who tend to discuss ideas openly and some turn out to be good and some turn out to be bad, and they tend to not vote on things until it is pretty clear that it is the right thing to do. If a council member posts an idea on the list and a non-council member replies pointing out the issues and offering a better proposal in response, that is a good thing. * the council didn't deal with it * there have been no votes There have been no candidates to vote for, and voting for candidates to lead the games team is the responsibility of the games team, not the Council. The Council DID vote to place an interim lead in charge of the games team for the purpose of facilitating an election. However, there was no response to repeated calls to join the team. This whole issue seems to be a tempest in a teapot, honestly. I don't really consider it ideal, but there is little in Gentoo I would consider ideal. Ultimately we all tend to step up and work on things we think are important to us, and this item is no different. If somebody really cares about this issue, they'll join the games team. Pointing out issues on lists that people aren't aware of is helpful. Harping on them repeatedly isn't. If you want to offer solutions, do it. If you just want to boss people around, try running for Council and see how well it works out even if you do get elected. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
A team is clearly violating GLEP39 and you don't care: It may have one or many leads, and the leads are selected by the members of the project. This selection must occur at least once every 12 months, and may occur at any time. Instead we are getting tree inconsistency, because people start to ignore the team. That is the worst that could happen. I wonder why you were not so picky about the QA team back then. Maybe the solution is point 3 of GLEP39 under the rationale section: If the council does a lousy job handling global issues (or has no global vision), vote out the bums
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Wed, Feb 11, 2015 at 2:15 PM, hasufell hasuf...@gentoo.org wrote: A team is clearly violating GLEP39 and you don't care: When did I claim to not care? It may have one or many leads, and the leads are selected by the members of the project. This selection must occur at least once every 12 months, and may occur at any time. Instead we are getting tree inconsistency, because people start to ignore the team. That is the worst that could happen. You clearly lack imagination. There are many things that could happen that are far worse than this. Gentoo not having anybody maintaining any games would be a worse outcome, for starters. What punishment would you deem appropriate for a team not following GLEP39? We could disband it, but we're not in any hurry to do so, because we're not convinced that doing this will make things any better. I wonder why you were not so picky about the QA team back then. QA has authority over the entire tree. The games team does not. It is important that teams that have authority over the entire distro be selected in a way that makes them accountable. I don't think QA was doing anything horribly wrong, but having the Council confirm the QA lead helps to provide this accountability, since ultimately we are accountable. Maybe the solution is point 3 of GLEP39 under the rationale section: If the council does a lousy job handling global issues (or has no global vision), vote out the bums Which would be why I've encouraged you to run for Council a few times now if you think you'll do better. I'm not going to apologize for being elected. If you really think that games.eclass is the hill we should all be dying on, you can put that in your manifesto. I think the urgent part of the crisis was dealt with (a conflict between individual maintainers and the games team, and a concern that people couldn't join the games team even if they wanted to). We can afford to take our time to deal with the rest, and it is best left to those who actually care about the issue. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
hasufell wrote: from what comments I got back no one really wanted to join (at least under the current system). I wasn't going to force the games team to elect a new lead when it appears none cared much at that point who the lead was. Also, I would advise caution on considering it dysfunctional and disbanding it due to this. I cannot follow that argumentation. Because no one wants to join, the team is functional? You're verging on trolling. :\ Noone wanting to join does not automatically mean that the team is not functional. //Peter
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Tim Harder: Also, I would advise caution on considering it dysfunctional and disbanding it due to this. I cannot follow that argumentation. Because no one wants to join, the team is functional? I'm seeing a lot of commits by mr_bones and tupone recently. Doesn't look defunct to me. -- Andreas K. Huettel Gentoo Linux developer perl, office, comrel, council
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Rich Freeman: On Sun, Feb 8, 2015 at 12:38 PM, hasufell hasuf...@gentoo.org wrote: The council has (at least implicitly) stated that people may stop using common eclasses that standardize stuff in gentoo if they don't like them (that includes python, ruby, perl... eclasses as well, FYI). Maybe we should both step back a bit. The Council has said this, no more or less: - Motion: Every developer is allowed to commit and maintain games ebuilds, without the need to ask for permission or review from the games team. The games team does not have authority to override maintainer decisions on packages they don't maintain. Accepted unanimously. Note: This should be understood as clarification of existing policy. So can I commit to any category such as ruby, perl, haskell, sound, gnome without any sort of review too, no matter if I follow any sort of project standards (except following PMS)? - There is consensus amongst council members that specific policies (e.g., games group, /usr/games hierarchy, and games.eclass) should be settled by the QA team. They were not settled. - Motion: The council encourages the games team to accept join requests and elect a lead. In the event they don't elect a lead within 6 weeks, we will consider the team as dysfunctional and thus disband it. Accepted with 6 yes votes and 1 abstention. This is offtopic, but what's the status? Who is the new lead?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On 2015-02-10 12:38, hasufell wrote: - Motion: The council encourages the games team to accept join requests and elect a lead. In the event they don't elect a lead within 6 weeks, we will consider the team as dysfunctional and thus disband it. Accepted with 6 yes votes and 1 abstention. This is offtopic, but what's the status? Who is the new lead? This was mostly contingent on new people joining the games herd, from what comments I got back no one really wanted to join (at least under the current system). I wasn't going to force the games team to elect a new lead when it appears none cared much at that point who the lead was. Also, I would advise caution on considering it dysfunctional and disbanding it due to this. To reinforce the point that's been said before, if people want the status quo to change the most direct route is often joining and making changes, not standing on the sidelines asking for change. Thanks, Tim signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Tim Harder: On 2015-02-10 12:38, hasufell wrote: - Motion: The council encourages the games team to accept join requests and elect a lead. In the event they don't elect a lead within 6 weeks, we will consider the team as dysfunctional and thus disband it. Accepted with 6 yes votes and 1 abstention. This is offtopic, but what's the status? Who is the new lead? This was mostly contingent on new people joining the games herd, from what comments I got back no one really wanted to join (at least under the current system). I wasn't going to force the games team to elect a new lead when it appears none cared much at that point who the lead was. Also, I would advise caution on considering it dysfunctional and disbanding it due to this. I cannot follow that argumentation. Because no one wants to join, the team is functional?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Tue, Feb 10, 2015 at 12:38 PM, hasufell hasuf...@gentoo.org wrote: Rich Freeman: On Sun, Feb 8, 2015 at 12:38 PM, hasufell hasuf...@gentoo.org wrote: The council has (at least implicitly) stated that people may stop using common eclasses that standardize stuff in gentoo if they don't like them (that includes python, ruby, perl... eclasses as well, FYI). Maybe we should both step back a bit. The Council has said this, no more or less: - Motion: Every developer is allowed to commit and maintain games ebuilds, without the need to ask for permission or review from the games team. The games team does not have authority to override maintainer decisions on packages they don't maintain. Accepted unanimously. Note: This should be understood as clarification of existing policy. So can I commit to any category such as ruby, perl, haskell, sound, gnome without any sort of review too, no matter if I follow any sort of project standards (except following PMS)? If you maintain a package that uses ruby/perl/haskell/gnome, or even, heaven forbid, sound, you can maintain it as you wish as long as you generally follow general policy. Of course, if your package doesn't work it is subject to QA, and if you don't follow the guidelines issued by those groups it is more likely to end up not working at some point. Why you'd want to re-invent the wheel vs just using their eclasses is beyond me. That doesn't mean that you can just mess with packages that make up ruby/perl/gnome/haskell, etc (not really sure how sound fits into that). They are maintained by various project teams that operate as a team. The issue here was projects in general claiming monopolies on entire genres of software. You don't need the blessing of the games team to maintain a game. Heck, you'd be hard-pressed to even define what is and isn't a game anyway. We also found that many games were already not using the eclass (such as anything bundled with kde/gnome/etc). Tim's response covered the rest of your email fairly well, so I won't repeat it. QA did note that they're going to be taking a closer look at games in today's Council meeting. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
07.02.2015 23:12, hasufell пишет: In addition... there is no work that needs to be done that has not already been done, other than banning an eclass or stating that it is the way to go. How would you do that without breaking all user apps? Clearly - by slowly migrating away from it and do not use it in newer ebuilds. That's what is done here, so what do you complain on? If the eclass is going to be banned, then there is a deprecation phase with a news items for users and devs will just stop using it. If it is the way to go, then nothing has to change (except disallowing ebuilds that break consistency). You are making it sound like there is some huge work to be done. There isn't. And no one has to step up to change the current situation, except the council. That's clearly up to eclass owner, which is games team. If you think that this is not huge work - deprecating eclass, moving all ebuilds from it and carring that no breakages will happen - then - step up and do this work, as was already suggested. Talk is cheap, show me the code (c) Linux Torvalds -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Rich Freeman: On Sat, Feb 7, 2015 at 3:12 PM, hasufell hasuf...@gentoo.org wrote: You are making it sound like there is some huge work to be done. There isn't. And no one has to step up to change the current situation, except the council. If you feel so strongly about it, then join the games team and get rid of the eclass. Or, if you feel the council should run differently, then by all means feel free to run for it. The council has (at least implicitly) stated that people may stop using common eclasses that standardize stuff in gentoo if they don't like them (that includes python, ruby, perl... eclasses as well, FYI). Maybe I should start dropping python-r1 and multilib eclasses from my ebuilds and do my own thing that may or may not work with the current standards that are enforced through these eclasses? And now you are telling me that in order to fix that wrong sentiment, I have to join a team?? How is any of that related? It seems to me that nobody really cares much about this issue besides you, and if you don't care enough to do anything about it, why should anybody else? You are again mixing facts and topics that don't belong together and are repeatedly pointing to GLEP39 in order to not be responsible. This is not about I like this or that eclass. This is about making DECISIONS and enforcing CONSISTENCY. That's your job in cooperation with the QA team and the relevant projects. Not mine.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Sun, Feb 8, 2015 at 12:38 PM, hasufell hasuf...@gentoo.org wrote: The council has (at least implicitly) stated that people may stop using common eclasses that standardize stuff in gentoo if they don't like them (that includes python, ruby, perl... eclasses as well, FYI). Maybe we should both step back a bit. The Council has said this, no more or less: - Motion: Every developer is allowed to commit and maintain games ebuilds, without the need to ask for permission or review from the games team. The games team does not have authority to override maintainer decisions on packages they don't maintain. Accepted unanimously. Note: This should be understood as clarification of existing policy. - There is consensus amongst council members that specific policies (e.g., games group, /usr/games hierarchy, and games.eclass) should be settled by the QA team. - Motion: The council encourages the games team to accept join requests and elect a lead. In the event they don't elect a lead within 6 weeks, we will consider the team as dysfunctional and thus disband it. Accepted with 6 yes votes and 1 abstention. - Motion: The council appoints radhermit as the interim lead of games until the elections are held. Accepted with 4 yes votes and 3 abstentions. If you have any specific questions as to how this relates to other projects/eclasses/etc, I suggest that you bring them to the Council. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Ben de Groot:
EAPI=5
inherit toolchain-funcs
This breaks consistency. Now users cannot rely on games.eclass anymore.
We should either abandon it completely or follow it consistently.
I thought we had abandoned it already?
Is there anything to be gained from using games.eclass here? It is a
chess engine that simply installs one file in /usr/bin/.
Well, almost everything in games-engines/ uses games.eclass too. Just
the stuff in dev-games/ doesn't, because it's well... development stuff.
The idea behind games.eclass was to unify games installations in gentoo.
That involves common directories like /usr/games/bin and also special
permissions that were meant to aid administrators to restrict access to
games.
A lot of people have expressed that this doesn't look like the right way
in some sense (including me). It has also caused some weird bug, e.g.
for nethack.
But, my point is... whatever we do, we should do it consistently,
otherwise people might get the idea of not caring about abstractions
like python-r1, ruby/java/perl eclasses or whatever, because they don't
like them.
The council just chose the worst way, because it didn't want to upset
either party involved in the discussion.
SRC_URI=https://stockfish.s3.amazonaws.com/${P}-src.zip;
LICENSE=GPL-3
SLOT=0
KEYWORDS=~amd64 ~x86
IUSE=cpu_flags_x86_avx2 cpu_flags_x86_popcnt cpu_flags_x86_sse
DEPEND=
unzip is missing from DEPEND
I thought portage auto-depends on this. But I can add || ( unzip zip )
to be explicit.
I don't know, but it's definitely not in @system. Afair we are only
allowed to omit deps from that set.
src_compile() {
local my_arch
use x86 my_arch=x86-32-old
use cpu_flags_x86_sse my_arch=x86-32
use amd64 my_arch=x86-64
use cpu_flags_x86_popcnt my_arch=x86-64-modern
use cpu_flags_x86_avx2 my_arch=x86-64-bmi2
emake build ARCH=${my_arch} CXX=$(tc-getCXX) CXXFLAGS=${CXXFLAGS}
This currently breaks all cpu flags, because it overwrites anything the
Makefile does to CXXFLAGS, including -msse and -DIS_64BIT and even other
flags that are not CPU specific (e.g. -DNDEBUG).
Thanks for catching this! I guess we do need to patch the Makefile
then, to *also* honour user-set CXXFLAGS and LDFLAGS. Or could we get
away with just letting the Makefile do its thing?
I've hit this bug myself in my overlay... I'll probably get up a pull
request upstream today.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On 7 February 2015 at 23:06, hasufell hasuf...@gentoo.org wrote:
DEPEND=
unzip is missing from DEPEND
I thought portage auto-depends on this. But I can add || ( unzip zip )
to be explicit.
I don't know, but it's definitely not in @system. Afair we are only
allowed to omit deps from that set.
OK, added.
src_compile() {
local my_arch
use x86 my_arch=x86-32-old
use cpu_flags_x86_sse my_arch=x86-32
use amd64 my_arch=x86-64
use cpu_flags_x86_popcnt my_arch=x86-64-modern
use cpu_flags_x86_avx2 my_arch=x86-64-bmi2
emake build ARCH=${my_arch} CXX=$(tc-getCXX) CXXFLAGS=${CXXFLAGS}
This currently breaks all cpu flags, because it overwrites anything the
Makefile does to CXXFLAGS, including -msse and -DIS_64BIT and even other
flags that are not CPU specific (e.g. -DNDEBUG).
Thanks for catching this! I guess we do need to patch the Makefile
then, to *also* honour user-set CXXFLAGS and LDFLAGS. Or could we get
away with just letting the Makefile do its thing?
I've hit this bug myself in my overlay... I'll probably get up a pull
request upstream today.
I think it's okay now. They do += so the user cxxflags and ldflags do
get honoured, but they end their own flags at the end of it. I've
added some more configuration options to the ebuild (optimize and
debug are important here).
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Sat, Feb 7, 2015 at 10:06 AM, hasufell hasuf...@gentoo.org wrote: The council just chose the worst way, because it didn't want to upset either party involved in the discussion. The council simply upheld GLEP 39 - people don't HAVE to work with a project team to work on packages. There is no QA policy that requires any particular package to use any particular eclass, or install its files in any particular directory. FHS compatibility is generally encouraged, but even that has been trending differently in most distros in recent years. Besides, I don't see two parties here. I see the games team which for the most part doesn't say anything, and then I see a bunch of individual maintainers who all have various preferences. The way we do games isn't going to change unless somebody steps up and says hey, I want to run the games team and take it in this direction. You're more than welcome to do that. So far you haven't. So, your repeated protests basically amount to complaining that somebody else isn't doing work the way you'd prefer that they do it. You've made that loud and clear. Now all you need to do is find somebody who actually wants to do the work for you. Don't get me wrong - I don't mind when people point out inconsistency. It is just that when all you do is point it out repeatedly without actually personally doing anything to help change things, it gets a bit old. That is why the Council tends to choose the path of minimal interference. We don't really have the ability to force people to work on things. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Rich Freeman: On Sat, Feb 7, 2015 at 10:06 AM, hasufell hasuf...@gentoo.org wrote: The council just chose the worst way, because it didn't want to upset either party involved in the discussion. The council simply upheld GLEP 39 - people don't HAVE to work with a project team to work on packages. There is no QA policy that requires any particular package to use any particular eclass, or install its files in any particular directory. FHS compatibility is generally encouraged, but even that has been trending differently in most distros in recent years. Besides, I don't see two parties here. I see the games team which for the most part doesn't say anything, and then I see a bunch of individual maintainers who all have various preferences. The way we do games isn't going to change unless somebody steps up and says hey, I want to run the games team and take it in this direction. You're more than welcome to do that. So far you haven't. So, your repeated protests basically amount to complaining that somebody else isn't doing work the way you'd prefer that they do it. You've made that loud and clear. Now all you need to do is find somebody who actually wants to do the work for you. Don't get me wrong - I don't mind when people point out inconsistency. It is just that when all you do is point it out repeatedly without actually personally doing anything to help change things, it gets a bit old. That is why the Council tends to choose the path of minimal interference. We don't really have the ability to force people to work on things. You are mixing some topics here. This is about the eclass. I do not see a single argument why the newly introduced inconsistency is superior and makes anything better for the end user. You are just talking about why you did what. Nothing of that contains a technical reason. Are we that politics driven now? In addition... there is no work that needs to be done that has not already been done, other than banning an eclass or stating that it is the way to go. If the eclass is going to be banned, then there is a deprecation phase with a news items for users and devs will just stop using it. If it is the way to go, then nothing has to change (except disallowing ebuilds that break consistency). You are making it sound like there is some huge work to be done. There isn't. And no one has to step up to change the current situation, except the council.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Sat, Feb 7, 2015 at 3:12 PM, hasufell hasuf...@gentoo.org wrote: You are making it sound like there is some huge work to be done. There isn't. And no one has to step up to change the current situation, except the council. Are we that politics driven now? If you feel so strongly about it, then join the games team and get rid of the eclass. Or, if you feel the council should run differently, then by all means feel free to run for it. It seems to me that nobody really cares much about this issue besides you, and if you don't care enough to do anything about it, why should anybody else? -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Fri, Feb 6, 2015 at 2:45 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-02-06, o godz. 17:20:48 hasufell hasuf...@gentoo.org napisał(a): Rich Freeman: On Fri, Feb 6, 2015 at 11:59 AM, hasufell hasuf...@gentoo.org wrote: Ben de Groot (yngwin): yngwin 15/02/05 20:09:33 Added:stockfish-6.ebuild metadata.xml Manifest ChangeLog Log: Initial commit (bug #318337) EAPI=5 inherit toolchain-funcs This breaks consistency. Now users cannot rely on games.eclass anymore. We should either abandon it completely or follow it consistently. Per the Council decision, this is strictly up to the maintainer's discretion. I am aware of that and I think it was a wrong decision, so I encourage people to do the opposite: not break consistency, unless there is a GOOD reason. Then please stop. You are openly and with full awareness spreading confusion amongst people. ++ If you want to put out games policy proposals on the lists for open discussion by all means do so. If you want to join the games team, by all means do so. If you want to maintain your games ebuilds as you wish until a consistent policy is developed, go ahead and do that (since that was what the Council said you can do). However, comments like this in the context of individual commits aren't a great idea unless you're spotting some kind of breakage. If your comment was you removed games.eclass which changes the installed permissions of this file which means this error will happen by all means point that out. It just makes sense to have the general we need a more sane policy discussion at the policy level. The thing is, you're only going to see a consistent way of handling games if people step up and say, hey, I'm going to help make it happen. The role of the Council is to deal with conflicts that aren't being resolved by the groups/individuals involved, and the resolution to that conflict in this case was to let maintainers have the final call. If there were one completely obvious answer that everybody agreed with then nobody would have escalated it to the Council in the first place. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Dnia 2015-02-06, o godz. 17:20:48 hasufell hasuf...@gentoo.org napisał(a): Rich Freeman: On Fri, Feb 6, 2015 at 11:59 AM, hasufell hasuf...@gentoo.org wrote: Ben de Groot (yngwin): yngwin 15/02/05 20:09:33 Added:stockfish-6.ebuild metadata.xml Manifest ChangeLog Log: Initial commit (bug #318337) EAPI=5 inherit toolchain-funcs This breaks consistency. Now users cannot rely on games.eclass anymore. We should either abandon it completely or follow it consistently. Per the Council decision, this is strictly up to the maintainer's discretion. I am aware of that and I think it was a wrong decision, so I encourage people to do the opposite: not break consistency, unless there is a GOOD reason. Then please stop. You are openly and with full awareness spreading confusion amongst people. -- Best regards, Michał Górny pgps2CcD1oJEH.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Michał Górny: Dnia 2015-02-06, o godz. 17:20:48 hasufell hasuf...@gentoo.org napisał(a): Rich Freeman: On Fri, Feb 6, 2015 at 11:59 AM, hasufell hasuf...@gentoo.org wrote: Ben de Groot (yngwin): yngwin 15/02/05 20:09:33 Added:stockfish-6.ebuild metadata.xml Manifest ChangeLog Log: Initial commit (bug #318337) EAPI=5 inherit toolchain-funcs This breaks consistency. Now users cannot rely on games.eclass anymore. We should either abandon it completely or follow it consistently. Per the Council decision, this is strictly up to the maintainer's discretion. I am aware of that and I think it was a wrong decision, so I encourage people to do the opposite: not break consistency, unless there is a GOOD reason. Then please stop. You are openly and with full awareness spreading confusion amongst people. Sorry, that is not correct. The council started this confusion for the end-user.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Fri, Feb 6, 2015 at 11:59 AM, hasufell hasuf...@gentoo.org wrote: Ben de Groot (yngwin): yngwin 15/02/05 20:09:33 Added:stockfish-6.ebuild metadata.xml Manifest ChangeLog Log: Initial commit (bug #318337) EAPI=5 inherit toolchain-funcs This breaks consistency. Now users cannot rely on games.eclass anymore. We should either abandon it completely or follow it consistently. Per the Council decision, this is strictly up to the maintainer's discretion. I'm all for a more sensible solution. If you want to help form one I suggest joining the games team. As of the last call I don't believe anybody stepped up to join it. The fact that the current state is inconsistent has been pointed out numerous times already, and was known by the Council at the time the interim policy was decided on. The only real virtue of the current state is that it is less broken than the previous state. It was our hope that those interested in Gentoo games would step up and come up with something better, rather than having the council micromanage the games team. If you are interested in games, then I suggest being a part of this. If you aren't interested in games, then I'm not sure why we're having this conversation. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Rich Freeman: On Fri, Feb 6, 2015 at 11:59 AM, hasufell hasuf...@gentoo.org wrote: Ben de Groot (yngwin): yngwin 15/02/05 20:09:33 Added:stockfish-6.ebuild metadata.xml Manifest ChangeLog Log: Initial commit (bug #318337) EAPI=5 inherit toolchain-funcs This breaks consistency. Now users cannot rely on games.eclass anymore. We should either abandon it completely or follow it consistently. Per the Council decision, this is strictly up to the maintainer's discretion. I am aware of that and I think it was a wrong decision, so I encourage people to do the opposite: not break consistency, unless there is a GOOD reason.
