1 |
On Fri, Aug 21, 2015 at 3:16 AM, Sergey Popov <pinkbyte@g.o> wrote: |
2 |
> |
3 |
> <qa team lead hat> |
4 |
> While i am all for unification, i do not think that this is the case, |
5 |
> where QA should be involved. "Dedicated server" is established phrase, |
6 |
> that all users, who wants to maintain such services, know. So, i do not |
7 |
> think that our direct interaction is needed here. If we want to change |
8 |
> something in this direction - it should be done in tight connection with |
9 |
> Games team |
10 |
> </qa team lead hat> |
11 |
> |
12 |
|
13 |
Regardless of QA team involvement, it still sounds like a good |
14 |
direction to take, and I'm fine with just adding this to the next |
15 |
council agenda if the QA team declines to take it on (proposal would |
16 |
be to ban the dedicated flag in favor of client and server or |
17 |
splitting ebuilds). |
18 |
|
19 |
I don't actually see this as a "games" thing. If it really were a |
20 |
games thing then I'd say leave it up to the games team (though as long |
21 |
as one doesn't actually exist I think we probably should fix huge |
22 |
eyesores). |
23 |
|
24 |
I attached lists of all packages that IUSE dedicated, server, and |
25 |
client. You'll notice that some games actually use server already. |
26 |
|
27 |
Oh, and on the first ebuild that uses server (turtlearena) that I |
28 |
checked I found these gems: |
29 |
BUILD_CLIENT=$(nobuildit dedicated) \ |
30 |
BUILD_SERVER=$(usex dedicated "1" "$(buildit server)") \ |
31 |
... |
32 |
if ! use dedicated ; then |
33 |
<< install client >> |
34 |
fi |
35 |
|
36 |
if use dedicated || use server ; then |
37 |
<< install server >> |
38 |
fi |
39 |
|
40 |
Please tell me again how this is cleaner than just having a client and |
41 |
a server USE flag, with appropriate defaults (which can vary by |
42 |
package already)? |
43 |
|
44 |
Looks like the one non-game that uses dedicated also users server |
45 |
(sci-mathematics/rstudio) and its ebuild has more of the same. I |
46 |
don't suppose we should ask the games team to clean that one up too? |
47 |
|
48 |
Some things really do make sense as tree-wide defaults, IMHO. That |
49 |
said, I'm perfectly fine with the QA team wanting to see this handled |
50 |
by the council - this is on the edges of their responsibility areas. |
51 |
|
52 |
Please don't look at this as some committee imposing arbitrary rules |
53 |
or creating work. Inconsistency like this is user-visible and it |
54 |
violates the principle of least-surprise. I don't fault the games |
55 |
maintainers for where they ended up - their practice is far older than |
56 |
the server+client approach. However, the latter seems much cleaner, |
57 |
and for cases like mysql where the client gets really heavy use I |
58 |
applaud their decision to go further and split the package. |
59 |
|
60 |
Somebody made the argument that sometimes having consistency within |
61 |
domains matters more than global consistency. I can buy that |
62 |
argument, but I don't think this is one of those cases. |
63 |
|
64 |
-- |
65 |
Rich |