1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
|
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!DOCTYPE project SYSTEM "/dtd/project.dtd">
<project>
<name>Games</name>
<longname>Gentoo Games Project</longname>
<date>27 July 2006</date>
<author title="Author">Chris Gianelloni</author>
<description>
The Gentoo Games Project manages the game categories (dev-games, games-*)
in Portage.
</description>
<longdescription><p>
The Gentoo Games Project manages all games that are added into the Portage
tree. We're the guys that put the fun into Gentoo. We also manage a few
utilities that are used heavily in many games, such as the SDL* libraries.
Please note that we don't manage heavily integrated games packages such
as 'gnome-games' or 'kdegames'.
</p></longdescription>
<goals><p>
The games project aims to turn Gentoo into the premiere Linux gaming
platform. We strive to have the best compatibility not only for free
games, but also for commercial titles.
</p></goals>
<dev role="lead" description="Team Lead">vapier</dev>
<dev role="member" description="everything except games-fps">Mr_Bones_</dev>
<dev role="member" description="general games ninja">Tupone</dev>
<dev role="member" description="general games ninja">nyhm</dev>
<herd name="games"/>
<extrachapter position="bottom">
<title>Gentoo Games Bugs FAQ</title>
<section>
<body>
<ol>
<li><uri link="#doc_chap5_sect2">Which Product/Component should
I pick?</uri></li>
<li><uri link="#doc_chap5_sect3">What severity should I use for
version bumps or new game requests?</uri></li>
<li><uri link="#doc_chap5_sect4">Why shouldn't I mark a Games
bug as "blocker"?</uri></li>
<li><uri link="#doc_chap5_sect5">How long should I wait before
filing a version bump request?</uri></li>
<li><uri link="#doc_chap5_sect6">Should I attach an ebuild to a
version bump request?</uri></li>
<li><uri link="#doc_chap5_sect7">What information do I need to
post with my bug report?</uri></li>
<li><uri link="#doc_chap5_sect8">What if I am not running on an
x86 kit?</uri></li>
<li><uri link="#doc_chap5_sect9">When should I open a new bug
rather than comment on an old one?</uri></li>
<li><uri link="#doc_chap5_sect10">When is it appropriate to ask
when a bug will be resolved/a new ebuild will be added?</uri></li>
<li><uri link="#doc_chap5_sect11">Should I report a bug on an
ebuild that does not have the proper KEYWORDS for my
architecture?</uri></li>
<li><uri link="#doc_chap5_sect12">This download is too big. Can we
make it download the patches?</uri></li>
</ol>
</body>
</section>
<section>
<title>Which Product/Component should I pick?</title>
<body>
<p>
You should always select the "Gentoo Linux" product and the "Games"
component when filing any bug for an ebuild in <c>games-*</c> or
<c>dev-games</c>. This ensures that the bug is immediately
assigned to the Games team, which allows for us to get the bug as
quickly as possible.
</p>
</body>
</section>
<section>
<title>What severity should I use for version bumps or new game
requests?</title>
<body>
<p>
Requests for having an ebuild bumped to the latest version or to
have an ebuild for a new game written or added to the portage tree
should always be filed with a severity of "enhancement" since these
are not bugs affecting functionality.
</p>
</body>
</section>
<section>
<title>Why shouldn't I mark a Games bug as "blocker"?</title>
<body>
<p>
This one is not only quite common, but also quite simple to answer.
A bug in a Games ebuild will never cause your system to be
destroyed or otherwise unusable. Games are for entertainment
purposes and as such, immediately get a lower priority than more
important aspects of a Gentoo system, such as the toolchain.
</p>
</body>
</section>
<section>
<title>How long should I wait before filing a version bump
request?</title>
<body>
<p>
We typically follow the development of many of the more popular
games. In many cases, we maintain contact with the authors and are
active in the community. We are generally aware of new events in
the Linux gaming community before the public. A good rule of thumb
is to wait at least 48 hours before posting an enhancement request
for a new game or a version upgrade to an existing game. This
allows the developers time to work bugs which are possibly of
higher priority than the game request. It also allows us to verify
that the game passes at least preliminary quality assurance.
Remember once again that all of us have other functions in Gentoo
which usually take a higher priority.
</p>
</body>
</section>
<section>
<title>Should I attach an ebuild to a version bump request?</title>
<body>
<p>
Usually, no. If simply copying the ebuild to the new name and
creating a new digest works for the upgrade, then please mention
that in the bug. It will save us time from looking at an ebuild
and trying to determine what has changed. If there has been a few
minor changes, then a diff between the two ebuilds using
<c>diff -u old.ebuild new.ebuild</c> is perfect. If there has been
major changes between versions, then an ebuild is appropriate and
appreciated.
</p>
</body>
</section>
<section>
<title>What information do I need to post with my bug report?</title>
<body>
<p>
As in any bug report, you should <b>always</b> post the output
of <c>emerge --info</c> into every bug report that you submit. If
you think there are other pertinent pieces of information that
could possibly help us in tracking down the bug, then be sure to
include that information, too. One example is the opengl
implementation that you are using when filing a bug against an
opengl-based game. Anything you can provide us could possibly be
the one piece of information that we need to accurately and quickly
resolve the bug. This could include information such as your
method of installation in a CD-based install, or the situation in
which the bug occurs.
</p>
</body>
</section>
<section>
<title>What if I am not running on an x86 kit?</title>
<body>
<p>
You should be sure to make note of your using a non-x86
architecture. You should also set the platform to your appropriate
platform. Last, you should add the architecture team alias to the
CC list for the bug. This is the architecture name at gentoo.org,
ex. <c>amd64@gentoo.org</c>. This ensures that not only the Games
team, but also the developers on the architecture team which your
problem is occurring get all of the information as quickly as
possible.
</p>
</body>
</section>
<section>
<title>When should I open a new bug rather than comment on an old
one?</title>
<body>
<p>
You should always open a new bug unless your problem is producing
the exact same error, you have tried the workarounds or fixes in
the ebuild, and your error is occurring on a same-versioned ebuild.
Do not make comments on an already resolved bug if you are seeing a
similar problem in a newer version of a game, as this makes it hard
to track individual problems. You should also never add a comment
about a new version of to an existing bug about the same package.
</p>
</body>
</section>
<section>
<title>When is it appropriate to ask when a bug will be resolved/a new
ebuild will be added?</title>
<body>
<p>
Never. Bugs are worked on by their priority given to them by
the developers themselves. All of the Games team are also
developers in other areas of Gentoo, and Games bugs are
<b>never</b> as critical as a toolchain or release bug. Bugs do
not get forgotten. They will go in eventually. If the bug is for
a new ebuild, we suggest putting the ebuild into a local overlay
and adding yourself to the CC on the bug. Asking when the bug will
be closed is not only selfish, but quite rude to the developers
that volunteer their time to try to make Gentoo better for
everyone. While your bug may be very important to you, we have a
larger view of what we have on our own plates and are better able
to make decisions on how to spend our own precious time to best
help Gentoo.
</p>
</body>
</section>
<section>
<title>Should I report a bug on an ebuild that does not have the
proper KEYWORDS for my architecture?</title>
<body>
<p>
Not if you want the games developers to like you. We will not
support games that do not have proper KEYWORDS. More than likely,
the game does not work on that architecture, which is why it
doesn't have KEYWORDS. The only exception to this rule is if you
are also providing a patch to fix the game for your architecture.
Patches are always welcome.
</p>
</body>
</section>
<section>
<title>This download is too big. Can we make it download the
patches?</title>
<body>
<p>
No. In general, ebuilds are designed to be used as if one is
not upgrading from a previous version. As soon as we start having
people download version $foo and patch $bar, people complain that
there is a $foo-$bar distfile. We can't please both camps, so we
simply do not offer incremental downloads. While this can be a
pain for users on dial-up, it makes things easier on us.
</p>
</body>
</section>
</extrachapter>
<extrachapter position="bottom">
<title>Want to help?</title>
<section>
<body>
<p>
If you want to get involved with improving Gentoo's gaming
experience, we'd like to hear from you! The main thing you'll want
to do is be active on <uri link="http://bugs.gentoo.org">
Gentoo's Bugzilla</uri>. A good start is to provide patches or ebuilds to bug
reports that have already been filed by other users. Simply adding new bug
reports is helpful in getting problems resolved in the long term, but does not
help get them resolved in the near term. Also, please join games project
members in #gentoo-games on irc.freenode.net.
</p>
<p>
There is also a <uri link="games-ebuild-howto.xml">HOWTO</uri>
for writing proper games ebuilds. You will definitely want to read
it if you plan on contributing as it is the standard by which games ebuilds are
written. This information is in addition to the standard ebuild policies and
procedures.
</p>
</body>
</section>
</extrachapter>
</project>
|
GitWeb