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
|
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/sparc/at/procedures.xml,v 1.4 2008/12/08 00:44:56 tcunha Exp $ -->
<!-- The context of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
<guide link="/proj/en/base/sparc/at/procedures.xml" lang="en">
<title>Gentoo/SPARC Arch Testers' Guide</title>
<author title="Author">
<mail link="hparker@gentoo.org">hparker@gentoo.org</mail>
</author>
<abstract>
This Guide shows you how to test packages for stablization/inclusion into the testing tree.
</abstract>
<license/>
<version>1.4</version>
<date>2008-12-08</date>
<chapter>
<title/>
<section>
<title>Marking Stable: When and How?</title>
<body>
<p>
The <uri link="http://dev.gentoo.org/~tcunha/reports/imlate-sparc.txt">imlate</uri>
file is there to show which packages on sparc are lagging
behind on x86 and need to be tested and eventually marked stable. It's
very useful to have people systematically testing these packages - it
helps to keep sparc as up-to-date as possible. The following guidelines
are specifically aimed at Gentoo/SPARC Arch Testers (ATs) doing testing.
</p>
<ul>
<li>
Check the newest version of the package is marked ~sparc (TESTING),
if not please read the next section of the document for the steps
to follow to quickly/efficiently have a package keyworded ~sparc.
<br/><br/>
</li>
<li>
If the package is already ~sparc, then:
<ul>
<li>
Check to see when it was marked ~sparc. There should be a date
in the package changelog, but if there isn't please use the
ViewCVS functionality on http://sources.gentoo.org to look for
the date it was keyworded ~sparc. If it was less than 30 days
ago, the package is not eligible to be marked stable, but
testing and feedback are still greatly appreciated.
</li>
<li>
Check for bugs on this particular version of the package. If a
bug has been open in the last 30 days, it is not eligible.
</li>
<li>
If it has been in testing for more than 30 days, and has not
had an open bug in the last 30 days, you need to test it in a
thorough and systematic manner. Every conceivable permutation
should be checked and rechecked - if it breaks you need to go
onto Bugzilla and open a relevent bug. If it doesn't break and
you are totally satisfied it's stable, continue to the final
step -- but beware, its your head if this package breaks!
</li>
<li>
Assuming it meets all the criteria (tested for 30+ days, no
bugs in the last 30 days, AT tested) you may open a bug with
the title '<category>/<package>-<version> is stable on SPARC'.
Assign the bug directly to sparc@gentoo.org to avoid making
more work for the poor Bug Wranglers. You should include the
output of your 'emerge --info' and keyword the bug <c>STABLE</c>. Just
wait a while, a developer will review the bug, and mark stable.
</li>
</ul>
</li>
</ul>
</body>
</section>
<section>
<title>Marking Testing: What's the drill?</title>
<body>
<p>
In some cases the imlate file may show packages where the latest version is
not yet ~sparc, or a new and popular package needs to be keyworded ~sparc. In
these cases, we need to have them 'marked testing' - so when they're bug free
for thirty days they can be made sparc stable.
</p>
<ul>
<li>
Check the package hasn't already got any open bugs regarding it being
marked testing. Quite often users will prod us about popular packages
needing a keyword before any devs/ATs even notice ;)<br/><br/>
</li>
<li>
If the package doesn't have a bug yet, go ahead and start:<br/><br/>
<ul>
<li>
Check to see whether previous versions of the package were in
testing or stable on SPARC. If the version increment is only a
minor one (1.4.0 to 1.4.1) and previous version was stable, it's
slightly different to where a package has had a major version
increment or has never been ~sparc/sparc.<br/><br/>
<ul>
<li>
<b>
Previous version keyworded, minor version increment</b><br/>
Check the changelog for the version increment, install the package
and test any new, improved or otherwise modified features. Check
the install is smooth, everyday functionality is there and there
are no glaringly obvious bugs. If you see any bugs, file them on
Bugzilla and when they're resolved test again. If everything seems
okay, proceed to the final stage (putting in the ~sparc request).
</li>
<li>
<b>Previous version keyworded, major version increment</b><br/>
Check the changelog, install the package and test all the new and
improved features. Check for bugs in previous versions, see if they
have been fixed and be especially careful to see whether new ones
crept in with all the new code. Test all the other functionality,
even stuff which you 'think' will work - a major version increment
means a lot of changes, and it's treated almost like a new addition
to the tree - everything has to be tested and verified. If you're
happy it seems to be running okay, proceed to the final stage.
</li>
<li>
<b>New package, not keyworded before</b><br/>
Anything which has never been sparc keyworded before is a little
more tricky to process. You don't have a nice changelog to refer
to for a list of things to test, a previous version which worked
to use as reference or much other help. You need to install the
package and then test thoroughly:<br/><br/>
<ol>
<li>
Package should install without errors and be ready to run
'out of the box' with minimal effort on the part of user.
</li>
<li>
Major functionality (which isn't hard to test) should all
work with no significant errors. Minor errors like a typo
are probably acceptable, and we understand you can't go
through every operation possible, but it should work in
an acceptable manner for day-to-day usage by a user.
</li>
<li>
Package shouldn't break anything related...
</li>
</ol><br/>
Assuming it installs, loads and works pretty well with no major
errors - please proceed to the final step and congratulate your
computer on adding yet another package to the expanding arsenal!
</li>
<li>
<b>Package requires patches that are in bugs.gentoo.org</b><br/>
Make a comment in your bug stating that these patches fix issues
with the package, and CC the maintainer of the package. Developers
will then wait 7-30 days to commit if maintainer does not handle
the bug. The types of patches in this category include: arch
specific patches, multi-lib strict, etc.
</li>
</ul>
<br/>
</li>
<li>
Assuming your testing efforts above went well, and all procedures were
followed, you are now ready to open a bug and metaphysically prod a dev
into committing the change.
<br/><br/>
<ul>
<li>
Open a bug with '<category>/<package>-<version> is TESTED on SPARC'
as the title. Assign the bug a keyword: TESTED
</li>
<li>
Assign the bug directly to sparc@gentoo.org - saves giving those
Bug Wranglers yet another grey hair on their already snowy heads.
</li>
<li>
Include a short description of the package, what you tested and
your 'emerge info'. Explicitly specify you wish the ~sparc to be
added to the keywords, it helps us grumpy old developers focus
at 3am in the morning when sleep is probably a good idea ;)
</li>
<li>Sit back and wait, someone will resolve the bug ASAP.</li>
</ul>
</li>
</ul>
</li>
</ul>
</body>
</section>
</chapter>
</guide>
|
GitWeb