| 1 |
fmccor 07/09/14 20:21:03 |
| 2 |
|
| 3 |
Added: index.xml procedures.xml |
| 4 |
Log: |
| 5 |
Populate the at/ directory. |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/proj/en/base/sparc/at/index.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/base/sparc/at/index.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/base/sparc/at/index.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: index.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version="1.0" encoding="UTF-8"?> |
| 16 |
<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?> |
| 17 |
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> |
| 18 |
<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd"> |
| 19 |
<project> |
| 20 |
|
| 21 |
<name>Gentoo/SPARC ATs</name> |
| 22 |
|
| 23 |
<longname>Gentoo/AMD64 Arch Testers</longname> |
| 24 |
|
| 25 |
<description> |
| 26 |
The Gentoo/SPARC AT Project is devoted to help the developers with time-consuming testing. |
| 27 |
</description> |
| 28 |
|
| 29 |
<longdescription> |
| 30 |
<p>The Gentoo/SPARC Arch Testers (ATs) assist the developers with the time-consuming testing to help |
| 31 |
keeping the Portage tree up to date. They mainly communicate with the developers through |
| 32 |
<uri link="http://bugs.gentoo.org/">Gentoo's Bugzilla</uri> and IRC. The ATs are also on the |
| 33 |
<c>sparc@g.o</c> mail alias so they can watch the bugzilla traffic closely.</p> |
| 34 |
</longdescription> |
| 35 |
|
| 36 |
<extrachapter position="top"> |
| 37 |
<title>Participating</title> |
| 38 |
<section> |
| 39 |
<body> |
| 40 |
<p>We are constantly looking for new arch testers. If you meet the following criterias, you are |
| 41 |
likely our ideal candidate:</p> |
| 42 |
<ul> |
| 43 |
<li>You are running Gentoo/SPARC.</li> |
| 44 |
<li>You like tinkering around with new software.</li> |
| 45 |
<li>You want to get involved in Gentoo development, help to make the distribution better every day.</li> |
| 46 |
</ul> |
| 47 |
<p>If you want to participate, email <mail link="fmccor@g.o">hparker@g.o</mail> or |
| 48 |
<mail link="jmbsvicetto@g.o">dang@g.o</mail>. They will lead you through the process and |
| 49 |
help you with the <uri link="/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild quiz</uri> |
| 50 |
which is a requirement for all ATs.</p> |
| 51 |
<note>Arch testers might not be official Gentoo developers. They are, however, a recognized |
| 52 |
part of the Gentoo/SPARC arch team.</note> |
| 53 |
</body> |
| 54 |
</section> |
| 55 |
</extrachapter> |
| 56 |
|
| 57 |
<extrachapter> |
| 58 |
<title>Arch Testers Policy</title> |
| 59 |
<section> |
| 60 |
<body> |
| 61 |
<p>There are a few rules which must be followed to assure a certain quality level. Gentoo/AMD64 arch testers |
| 62 |
must fulfill these requirements:</p> |
| 63 |
<ul> |
| 64 |
<li>Use a stable system or a stable chroot environment for testing</li> |
| 65 |
<li>Use reasonable <c>CFLAGS</c></li> |
| 66 |
<li>Enable at least the following <c>FEATURES</c>: <c>collision-protect</c>, |
| 67 |
<c>sandbox</c>, <c>test</c></li> |
| 68 |
<li>Test thoroughly</li> |
| 69 |
<li>Before requesting a stablization, check that the ebuild is at least 30 days old and without modifications</li> |
| 70 |
<li>Use the <c>category/package-version</c> format when reporting success or failure</li> |
| 71 |
<li>Always append <c>emerge --info</c> to bug reports</li> |
| 72 |
</ul> |
| 73 |
</body> |
| 74 |
</section> |
| 75 |
</extrachapter> |
| 76 |
|
| 77 |
<extrachapter> |
| 78 |
<title>Gentoo/SPARC AT Listing</title> |
| 79 |
<section> |
| 80 |
<body> |
| 81 |
<p>The following people are currently contributing to this project:</p> |
| 82 |
<table> |
| 83 |
|
| 84 |
<tr> |
| 85 |
<th>Full Name</th> |
| 86 |
<th>Nickname</th> |
| 87 |
<th>Status</th> |
| 88 |
<th>Email</th> |
| 89 |
</tr> |
| 90 |
|
| 91 |
<tr> |
| 92 |
<ti>Jorge Manual B S Vicetto</ti> |
| 93 |
<ti>jmbsvicetto</ti> |
| 94 |
<ti>Staff Dev</ti> |
| 95 |
<ti>jmbsvicetto@g.o</ti> |
| 96 |
</tr> |
| 97 |
|
| 98 |
<tr> |
| 99 |
<ti>Tiago Cunha</ti> |
| 100 |
<ti>tcuhna</ti> |
| 101 |
<ti>Active</ti> |
| 102 |
<ti>me@××××××××××.org</ti> |
| 103 |
</tr> |
| 104 |
|
| 105 |
</table> |
| 106 |
</body> |
| 107 |
</section> |
| 108 |
</extrachapter> |
| 109 |
|
| 110 |
|
| 111 |
<dev role="Strategic Lead">fmccor</dev> |
| 112 |
|
| 113 |
</project> |
| 114 |
|
| 115 |
|
| 116 |
|
| 117 |
1.1 xml/htdocs/proj/en/base/sparc/at/procedures.xml |
| 118 |
|
| 119 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/base/sparc/at/procedures.xml?rev=1.1&view=markup |
| 120 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/base/sparc/at/procedures.xml?rev=1.1&content-type=text/plain |
| 121 |
|
| 122 |
Index: procedures.xml |
| 123 |
=================================================================== |
| 124 |
<?xml version='1.0' encoding="UTF-8"?> |
| 125 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 126 |
|
| 127 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/sparc/at/procedures.xml,v 1.1 2007/09/14 20:21:02 fmccor Exp $ --> |
| 128 |
|
| 129 |
<!-- The context of this document is licensed under the CC-BY-SA license --> |
| 130 |
<!-- See http://creativecommonds.org/licenses/by-sa/1.0 --> |
| 131 |
|
| 132 |
<guide link="/proj/en/base/sparc/at/procedures.xml" lang="en"> |
| 133 |
<title>Gentoo/SPARC Arch Testers' Guide</title> |
| 134 |
|
| 135 |
<author title="Author"> |
| 136 |
<mail link="hparker@g.o">hparker@g.o</mail> |
| 137 |
</author> |
| 138 |
|
| 139 |
<abstract> |
| 140 |
This Guide shows you how to test packages for stablization/inclusion into the testing tree. |
| 141 |
</abstract> |
| 142 |
|
| 143 |
<license/> |
| 144 |
|
| 145 |
<version>1.0</version> |
| 146 |
<date>2007-09-14</date> |
| 147 |
|
| 148 |
<chapter> |
| 149 |
<title/> |
| 150 |
<section> |
| 151 |
<title>Marking Stable: When and How?</title> |
| 152 |
<body> |
| 153 |
|
| 154 |
|
| 155 |
<ul> |
| 156 |
<li> |
| 157 |
Check the newest version of the package is marked ~sparc (TESTING), |
| 158 |
if not please read the next section of the document for the steps |
| 159 |
to follow to quickly/efficiently have a package keyworded ~sparc. |
| 160 |
<br/><br/> |
| 161 |
</li> |
| 162 |
|
| 163 |
<li> |
| 164 |
If the package is already ~sparc, then: |
| 165 |
<ul> |
| 166 |
<li> |
| 167 |
Check to see when it was marked ~sparc. There should be a date |
| 168 |
in the package changelog, but if there isn't please use the |
| 169 |
ViewCVS functionality on http://sources.gentoo.org to look for |
| 170 |
the date it was keyworded ~sparc. If it was less than 30 days |
| 171 |
ago, the package is not eligible to be marked stable, but |
| 172 |
testing and feedback are still greatly appreciated. |
| 173 |
</li> |
| 174 |
<li> |
| 175 |
Check for bugs on this particular version of the package. If a |
| 176 |
bug has been open in the last 30 days, it is not eligible. |
| 177 |
</li> |
| 178 |
<li> |
| 179 |
If it has been in testing for more than 30 days, and has not |
| 180 |
had an open bug in the last 30 days, you need to test it in a |
| 181 |
thorough and systematic manner. Every conceivable permutation |
| 182 |
should be checked and rechecked - if it breaks you need to go |
| 183 |
onto Bugzilla and open a relevent bug. If it doesn't break and |
| 184 |
you are totally satisfied it's stable, continue to the final |
| 185 |
step -- but beware, its your head if this package breaks! |
| 186 |
</li> |
| 187 |
<li> |
| 188 |
Assuming it meets all the criteria (tested for 30+ days, no |
| 189 |
bugs in the last 30 days, AT tested) you may open a bug with |
| 190 |
the title '<category>/<package>-<version> is stable on sparc'. |
| 191 |
Assign the bug directly to SPARC@g.o to avoid making |
| 192 |
more work for the poor Bug Wranglers. You should include the |
| 193 |
output of your 'emerge --info' and keyword the bug <c>stable</c>. Just |
| 194 |
wait a while, a developer will review the bug, and mark stable. |
| 195 |
</li> |
| 196 |
</ul> |
| 197 |
</li> |
| 198 |
</ul> |
| 199 |
|
| 200 |
</body> |
| 201 |
</section> |
| 202 |
|
| 203 |
<section> |
| 204 |
<title>Marking Testing: What's the drill?</title> |
| 205 |
<body> |
| 206 |
|
| 207 |
<p> |
| 208 |
In some cases the imlate file may show packages where the latest version is |
| 209 |
not yet ~sparc, or a new and popular package needs to be keyworded ~sparc. In |
| 210 |
these cases, we need to have them 'marked testing' - so when they're bug free |
| 211 |
for thirty days they can be made sparc stable. |
| 212 |
</p> |
| 213 |
|
| 214 |
<ul> |
| 215 |
<li> |
| 216 |
Check the package hasn't already got any open bugs regarding it being |
| 217 |
marked testing. Quite often users will prod us about popular packages |
| 218 |
needing a keyword before any devs/ATs even notice ;)<br/><br/> |
| 219 |
</li> |
| 220 |
|
| 221 |
<li> |
| 222 |
If the package doesn't have a bug yet, go ahead and start:<br/><br/> |
| 223 |
<ul> |
| 224 |
<li> |
| 225 |
Check to see whether previous versions of the package were in |
| 226 |
testing or stable on SPARC. If the version increment is only a |
| 227 |
minor one (1.4.0 to 1.4.1) and previous version was stable, it's |
| 228 |
slightly different to where a package has had a major version |
| 229 |
increment or has never been ~SPARC/SPARC.<br/><br/> |
| 230 |
<ul> |
| 231 |
<li> |
| 232 |
<b> |
| 233 |
Previous version keyworded, minor version increment</b><br/> |
| 234 |
Check the changelog for the version increment, install the package |
| 235 |
and test any new, improved or otherwise modified features. Check |
| 236 |
the install is smooth, everyday functionality is there and there |
| 237 |
are no glaringly obvious bugs. If you see any bugs, file them on |
| 238 |
Bugzilla and when they're resolved test again. If everything seems |
| 239 |
okay, proceed to the final stage (putting in the ~SPARC request). |
| 240 |
</li> |
| 241 |
<li> |
| 242 |
<b>Previous version keyworded, major version increment</b><br/> |
| 243 |
Check the changelog, install the package and test all the new and |
| 244 |
improved features. Check for bugs in previous versions, see if they |
| 245 |
have been fixed and be especially careful to see whether new ones |
| 246 |
crept in with all the new code. Test all the other functionality, |
| 247 |
even stuff which you 'think' will work - a major version increment |
| 248 |
means a lot of changes, and it's treated almost like a new addition |
| 249 |
to the tree - everything has to be tested and verified. If you're |
| 250 |
happy it seems to be running okay, proceed to the final stage. |
| 251 |
</li> |
| 252 |
<li> |
| 253 |
<b>New package, not keyworded before</b><br/> |
| 254 |
Anything which has never been SPARC keyworded before is a little |
| 255 |
more tricky to process. You don't have a nice changelog to refer |
| 256 |
to for a list of things to test, a previous version which worked |
| 257 |
to use as reference or much other help. You need to install the |
| 258 |
package and then test thoroughly:<br/><br/> |
| 259 |
<ol> |
| 260 |
<li> |
| 261 |
Package should install without errors and be ready to run |
| 262 |
'out of the box' with minimal effort on the part of user. |
| 263 |
</li> |
| 264 |
<li> |
| 265 |
Major functionality (which isn't hard to test) should all |
| 266 |
work with no significant errors. Minor errors like a typo |
| 267 |
are probably acceptable, and we understand you can't go |
| 268 |
through every operation possible, but it should work in |
| 269 |
an acceptable manner for day-to-day usage by a user. |
| 270 |
</li> |
| 271 |
<li> |
| 272 |
Package shouldn't break anything related... |
| 273 |
</li> |
| 274 |
</ol><br/> |
| 275 |
Assuming it installs, loads and works pretty well with no major |
| 276 |
errors - please proceed to the final step and congratulate your |
| 277 |
computer on adding yet another package to the expanding arsenal! |
| 278 |
</li> |
| 279 |
<li> |
| 280 |
<b>Package requires patches that are in bugs.gentoo.org</b><br/> |
| 281 |
Make a comment in your bug stating that these patches fix issues |
| 282 |
with the package, and CC the maintainer of the package. Developers |
| 283 |
will then wait 7-30 days to commit if maintainer does not handle |
| 284 |
the bug. The types of patches in this category include: arch |
| 285 |
specific patches, multi-lib strict, etc. |
| 286 |
</li> |
| 287 |
</ul> |
| 288 |
<br/> |
| 289 |
</li> |
| 290 |
|
| 291 |
<li> |
| 292 |
Assuming your testing efforts above went well, and all procedures were |
| 293 |
followed, you are now ready to open a bug and metaphysically prod a dev |
| 294 |
into committing the change. |
| 295 |
<br/><br/> |
| 296 |
<ul> |
| 297 |
<li> |
| 298 |
Open a bug with '<category>/<package>-<version> is TESTED on SPARC' |
| 299 |
as the title. Assign the bug a keyword: TESTED |
| 300 |
</li> |
| 301 |
<li> |
| 302 |
Assign the bug directly to SPARC@g.o - saves giving those |
| 303 |
Bug Wranglers yet another grey hair on their already snowy heads. |
| 304 |
</li> |
| 305 |
<li> |
| 306 |
Include a short description of the package, what you tested and |
| 307 |
your 'emerge info'. Explicitly specify you wish the ~SPARC to be |
| 308 |
added to the keywords, it helps us grumpy old developers focus |
| 309 |
at 3am in the morning when sleep is probably a good idea ;) |
| 310 |
</li> |
| 311 |
<li>Sit back and wait, someone will resolve the bug ASAP.</li> |
| 312 |
</ul> |
| 313 |
</li> |
| 314 |
</ul> |
| 315 |
</li> |
| 316 |
</ul> |
| 317 |
</body> |
| 318 |
</section> |
| 319 |
</chapter> |
| 320 |
</guide> |
| 321 |
|
| 322 |
|
| 323 |
|
| 324 |
-- |
| 325 |
gentoo-commits@g.o mailing list |
Archives