Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

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


> DESCRIPTION="The strongest chess engine in the world"

This isn't very informative. I'd suggest
DESCRIPTION="Free UCI chess engine derived from Glaurung 2.1"

> HOMEPAGE="http://stockfishchess.org/"

Probably add the github link here too.

> 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

> RDEPEND=""
>
> S=${WORKDIR}/${P}-src/src
>
> src_prepare() {
> sed -e 's:-strip $(BINDIR)/$(EXE)::' -i Makefile
> }
>

missing "|| die"... I'd also rather make this a patch, so it doesn't
silently break on version bump

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

Fixing this should definitely be done in a revbump.

> }
>
> src_install() {
> emake PREFIX="${D}/usr" install
> dodoc ../AUTHORS ../Readme.md
> }


Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

hasufell
Rich Freeman:

> On Fri, Feb 6, 2015 at 11:59 AM, hasufell <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

Michał Górny-5
Dnia 2015-02-06, o godz. 17:20:48
hasufell <[hidden email]> napisał(a):

> Rich Freeman:
> > On Fri, Feb 6, 2015 at 11:59 AM, hasufell <[hidden email]> 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

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 2:45 PM, Michał Górny <[hidden email]> wrote:

> Dnia 2015-02-06, o godz. 17:20:48
> hasufell <[hidden email]> napisał(a):
>
>> Rich Freeman:
>> > On Fri, Feb 6, 2015 at 11:59 AM, hasufell <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

hasufell
In reply to this post by Michał Górny-5
Michał Górny:

> Dnia 2015-02-06, o godz. 17:20:48
> hasufell <[hidden email]> napisał(a):
>
>> Rich Freeman:
>>> On Fri, Feb 6, 2015 at 11:59 AM, hasufell <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

Ben de Groot-2
In reply to this post by hasufell
On 7 February 2015 at 00:59, hasufell <[hidden email]> 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)
>>

First off: thank you for the review!

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

>
>> DESCRIPTION="The strongest chess engine in the world"
>
> This isn't very informative. I'd suggest
> DESCRIPTION="Free UCI chess engine derived from Glaurung 2.1"

I just took the description from upstream's website. But you are
right, it could be more informative. Will fix.

>> HOMEPAGE="http://stockfishchess.org/"
>
> Probably add the github link here too.

I will unify the live and release ebuilds.

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

>> RDEPEND=""
>>
>> S=${WORKDIR}/${P}-src/src
>>
>> src_prepare() {
>>       sed -e 's:-strip $(BINDIR)/$(EXE)::' -i Makefile
>> }
>>
>
> missing "|| die"... I'd also rather make this a patch, so it doesn't
> silently break on version bump

The die would not accomplish anything, unless the file wasn't there
anymore. I thought this was too simple for a patch, but see below.

>> 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?

> Fixing this should definitely be done in a revbump.

Obviously. Will do.

--
Cheers,

Ben | yngwin
Gentoo developer

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

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



Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

Ben de Groot-2
On 7 February 2015 at 23:06, hasufell <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

Rich Freeman
In reply to this post by hasufell
On Sat, Feb 7, 2015 at 10:06 AM, hasufell <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

hasufell
Rich Freeman:

> On Sat, Feb 7, 2015 at 10:06 AM, hasufell <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

Sergey Popov
In reply to this post by hasufell
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 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

hasufell
In reply to this post by Rich Freeman
Rich Freeman:

> On Sat, Feb 7, 2015 at 3:12 PM, hasufell <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

hasufell
Rich Freeman:

> On Sun, Feb 8, 2015 at 12:38 PM, hasufell <[hidden email]> 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?

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

Tim Harder-5
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 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

Rich Freeman
In reply to this post by hasufell
On Tue, Feb 10, 2015 at 12:38 PM, hasufell <[hidden email]> wrote:

> Rich Freeman:
>> On Sun, Feb 8, 2015 at 12:38 PM, hasufell <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

hasufell
In reply to this post by Tim Harder-5
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?


Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

Peter Stuge-4
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

12