On Fri, Aug 21, 2015 at 3:16 AM, Sergey Popov <pinkb...@gentoo.org> wrote:
>
> <qa team lead hat>
> While i am all for unification, i do not think that this is the case,
> where QA should be involved. "Dedicated server" is established phrase,
> that all users, who wants to maintain such services, know. So, i do not
> think that our direct interaction is needed here. If we want to change
> something in this direction - it should be done in tight connection with
> Games team
> </qa team lead hat>
>
Regardless of QA team involvement, it still sounds like a good
direction to take, and I'm fine with just adding this to the next
council agenda if the QA team declines to take it on (proposal would
be to ban the dedicated flag in favor of client and server or
splitting ebuilds).
I don't actually see this as a "games" thing. If it really were a
games thing then I'd say leave it up to the games team (though as long
as one doesn't actually exist I think we probably should fix huge
eyesores).
I attached lists of all packages that IUSE dedicated, server, and
client. You'll notice that some games actually use server already.
Oh, and on the first ebuild that uses server (turtlearena) that I
checked I found these gems:
BUILD_CLIENT=$(nobuildit dedicated) \
BUILD_SERVER=$(usex dedicated "1" "$(buildit server)") \
...
if ! use dedicated ; then
<< install client >>
fi
if use dedicated || use server ; then
<< install server >>
fi
Please tell me again how this is cleaner than just having a client and
a server USE flag, with appropriate defaults (which can vary by
package already)?
Looks like the one non-game that uses dedicated also users server
(sci-mathematics/rstudio) and its ebuild has more of the same. I
don't suppose we should ask the games team to clean that one up too?
Some things really do make sense as tree-wide defaults, IMHO. That
said, I'm perfectly fine with the QA team wanting to see this handled
by the council - this is on the edges of their responsibility areas.
Please don't look at this as some committee imposing arbitrary rules
or creating work. Inconsistency like this is user-visible and it
violates the principle of least-surprise. I don't fault the games
maintainers for where they ended up - their practice is far older than
the server+client approach. However, the latter seems much cleaner,
and for cases like mysql where the client gets really heavy use I
applaud their decision to go further and split the package.
Somebody made the argument that sometimes having consistency within
domains matters more than global consistency. I can buy that
argument, but I don't think this is one of those cases.
--
Rich
