Details | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
5564 | serge | 1 | |
2 | |||
3 | |||
4 | |||
5 |
|
||
6 | |||
7 | |||
8 | |||
9 | |||
10 | |||
11 |
|
||
12 | |||
13 | |||
14 | |||
15 | |||
16 | |||
17 |
|
||
18 | |||
19 | |||
20 |
|
||
21 | |||
22 | |||
23 | To add a new GL extension to Mesa you have to do at least the following. |
||
24 | |||
25 | |||
26 | |||
27 | If glext.h doesn't define the extension, edit include/GL/gl.h and add |
||
28 | code like this: |
||
29 | |||
30 | #ifndef GL_EXT_the_extension_name |
||
31 | #define GL_EXT_the_extension_name 1 |
||
32 | /* declare the new enum tokens */ |
||
33 | /* prototype the new functions */ |
||
34 | /* TYPEDEFS for the new functions */ |
||
35 | #endif |
||
36 | |||
37 | |||
38 | |||
39 | In the src/mapi/glapi/gen/ directory, add the new extension functions and |
||
40 | enums to the gl_API.xml file. |
||
41 | Then, a bunch of source files must be regenerated by executing the |
||
42 | corresponding Python scripts. |
||
43 | |||
44 | |||
45 | Add a new entry to the |
||
46 | |||
47 | |||
48 | Update the |
||
49 | |||
50 | |||
51 | From this point, the best way to proceed is to find another extension, |
||
52 | similar to the new one, that's already implemented in Mesa and use it |
||
53 | as an example. |
||
54 | |||
55 | |||
56 | If the new extension adds new GL state, the functions in get.c, enable.c |
||
57 | and attrib.c will most likely require new code. |
||
58 | |||
59 | |||
60 | The dispatch tests check_table.cpp and dispatch_sanity.cpp |
||
61 | should be updated with details about the new extensions functions. These |
||
62 | tests are run using 'make check' |
||
63 | |||
64 | |||
65 | |||
66 | |||
67 | |||
68 |
|
||
69 | |||
70 | |||
71 | Mesa's code style has changed over the years. Here's the latest. |
||
72 | |||
73 | |||
74 | |||
75 | Comment your code! It's extremely important that open-source code be |
||
76 | well documented. Also, strive to write clean, easily understandable code. |
||
77 | |||
78 | |||
79 | |||
80 | 3-space indentation |
||
81 | |||
82 | |||
83 | |||
84 | If you use tabs, set them to 8 columns |
||
85 | |||
86 | |||
87 | |||
88 | Line width: the preferred width to fill comments and code in Mesa is 78 |
||
89 | columns. Exceptions are sometimes made for clarity (e.g. tabular data is |
||
90 | sometimes filled to a much larger width so that extraneous carriage returns |
||
91 | don't obscure the table). |
||
92 | |||
93 | |||
94 | |||
95 | Brace example: |
||
96 | |||
97 | |||
98 | if (condition) { |
||
99 | foo; |
||
100 | } |
||
101 | else { |
||
102 | bar; |
||
103 | } |
||
104 | |||
105 | switch (condition) { |
||
106 | case 0: |
||
107 | foo(); |
||
108 | break; |
||
109 | |||
110 | case 1: { |
||
111 | ... |
||
112 | break; |
||
113 | } |
||
114 | |||
115 | default: |
||
116 | ... |
||
117 | break; |
||
118 | } |
||
119 | |||
120 | |||
121 | |||
122 | Here's the GNU indent command which will best approximate my preferred style: |
||
123 | (Note that it won't format switch statements in the preferred way) |
||
124 | |||
125 | |||
126 | indent -br -i3 -npcs --no-tabs infile.c -o outfile.c |
||
127 | |||
128 | |||
129 | |||
130 | |||
131 | Local variable name example: localVarName (no underscores) |
||
132 | |||
133 | |||
134 | |||
135 | Constants and macros are ALL_UPPERCASE, with _ between words |
||
136 | |||
137 | |||
138 | |||
139 | Global variables are not allowed. |
||
140 | |||
141 | |||
142 | |||
143 | Function name examples: |
||
144 | |||
145 | |||
146 | glFooBar() - a public GL entry point (in glapi_dispatch.c) |
||
147 | _mesa_FooBar() - the internal immediate mode function |
||
148 | save_FooBar() - retained mode (display list) function in dlist.c |
||
149 | foo_bar() - a static (private) function |
||
150 | _mesa_foo_bar() - an internal non-static Mesa function |
||
151 | |||
152 | |||
153 | |||
154 | Places that are not directly visible to the GL API should prefer the use |
||
155 | of bool, true, and |
||
156 | false over GLboolean, GL_TRUE, and |
||
157 | GL_FALSE. In C code, this may mean that |
||
158 | #include <stdbool.h> needs to be added. The |
||
159 | try_emit_* methods in src/mesa/program/ir_to_mesa.cpp and |
||
160 | src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples. |
||
161 | |||
162 | |||
163 |
|
||
164 | |||
165 | |||
166 | You should always run the Mesa Testsuite before submitting patches. |
||
167 | The Testsuite can be run using the 'make check' command. All tests |
||
168 | must pass before patches will be accepted, this may mean you have |
||
169 | to update the tests themselves. |
||
170 | |||
171 | |||
172 | |||
173 | Patches should be sent to the Mesa mailing list for review. |
||
174 | When submitting a patch make sure to use git send-email rather than attaching |
||
175 | patches to emails. Sending patches as attachments prevents people from being |
||
176 | able to provide in-line review comments. |
||
177 | |||
178 | |||
179 | |||
180 | When submitting follow-up patches you can use --in-reply-to to make v2, v3, |
||
181 | etc patches show up as replies to the originals. This usually works well |
||
182 | when you're sending out updates to individual patches (as opposed to |
||
183 | re-sending the whole series). Using --in-reply-to makes |
||
184 | it harder for reviewers to accidentally review old patches. |
||
185 | |||
186 | |||
187 |
|
||
188 | |||
189 | |||
190 | If you want a commit to be applied to a stable branch, |
||
191 | you should add an appropriate note to the commit message. |
||
192 | |||
193 | |||
194 | |||
195 | Here are some examples of such a note: |
||
196 | |||
197 | |||
198 | |||
199 | |||
200 | |||
201 | |||
202 | |||
203 | Simply adding the CC to the mesa-stable list address is adequate to nominate |
||
204 | the commit for the most-recently-created stable branch. It is only necessary |
||
205 | to specify a specific branch name, (such as "9.2 10.0" or "10.0" in the |
||
206 | examples above), if you want to nominate the commit for an older stable |
||
207 | branch. And, as in these examples, you can nominate the commit for the older |
||
208 | branch in addition to the more recent branch, or nominate the commit |
||
209 | exclusively for the older branch. |
||
210 | |||
211 | This "CC" syntax for patch nomination will cause patches to automatically be |
||
212 | copied to the mesa-stable@ mailing list when you use "git send-email" to send |
||
213 | patches to the mesa-dev@ mailing list. Also, if you realize that a commit |
||
214 | should be nominated for the stable branch after it has already been committed, |
||
215 | you can send a note directly to the mesa-stable@lists.freedesktop.org where |
||
216 | the Mesa stable-branch maintainers will receive it. Be sure to mention the |
||
217 | commit ID of the commit of interest (as it appears in the mesa master branch). |
||
218 | |||
219 | The latest set of patches that have been nominated, accepted, or rejected for |
||
220 | the upcoming stable release can always be seen on the |
||
221 | Mesa Stable Queue |
||
222 | page. |
||
223 | |||
224 |
|
||
225 | |||
226 | Mesa has a designated release manager for each stable branch, and the release |
||
227 | manager is the only developer that should be pushing changes to these |
||
228 | branches. Everyone else should simply nominate patches using the mechanism |
||
229 | described above. |
||
230 | |||
231 | The stable-release manager will work with the list of nominated patches, and |
||
232 | for each patch that meets the crtieria below will cherry-pick the patch with: |
||
233 |
|
||
234 | important so that the picked patch references the comit ID of the original |
||
235 | patch. |
||
236 | |||
237 | The stable-release manager may at times need to force-push changes to the |
||
238 | stable branches, for example, to drop a previously-picked patch that was later |
||
239 | identified as causing a regression). These force-pushes may cause changes to |
||
240 | be lost from the stable branch if developers push things directly. Consider |
||
241 | yourself warned. |
||
242 | |||
243 | The stable-release manager is also given broad discretion in rejecting patches |
||
244 | that have been nominated for the stable branch. The most basic rule is that |
||
245 | the stable branch is for bug fixes only, (no new features, no |
||
246 | regressions). Here is a non-exhaustive list of some reasons that a patch may |
||
247 | be rejected: |
||
248 | |||
249 | |||
250 | |||
251 | regression caused by a particular patch, (game no longer work, piglit test |
||
252 | changes from PASS to FAIL), is justification for rejecting a patch. |
||
253 | |||
254 | |||
255 | |||
256 | |||
257 | functional change should be rejected. |
||
258 | |||
259 | |||
260 | of only a single line, no description of the bug, no mention of bugzilla, |
||
261 | etc. |
||
262 | |||
263 | |||
264 | has no Reviewed-by, Signed-off-by, nor Tested-by tags from anyone but the |
||
265 | author. |
||
266 | |||
267 | |||
268 | fixes should never be applied first to a stable branch. Patches should land |
||
269 | first on the master branch and then be cherry-picked to a stable |
||
270 | branch. (This is to avoid future releases causing regressions if the patch |
||
271 | is not also applied to master.) The only things that might look like |
||
272 | exceptions would be backports of patches from master that happen to look |
||
273 | significantly different. |
||
274 | |||
275 | |||
276 | patches should be self-contained. It sometimes occurs that a single, logical |
||
277 | bug-fix occurs as two separate patches on master, (such as an original |
||
278 | patch, then a subsequent fix-up to that patch). In such a case, these two |
||
279 | patches should be squashed into a single, self-contained patch for the |
||
280 | stable branch. (Of course, if the squashing makes the patch too large, then |
||
281 | that could be a reason to reject the patch.) |
||
282 | |||
283 | |||
284 | features, extensions, etc. should be applied to Mesa master and included in |
||
285 | the next major release. Stable releases are intended only for bug fixes. |
||
286 | |||
287 | Note: As an exception to this rule, the stable-release manager may accept |
||
288 | hardware-enabling "features". For example, backports of new code to support |
||
289 | a newly-developed hardware product can be accepted if they can be reasonably |
||
290 | determined to not have effects on other hardware. |
||
291 | |||
292 | |||
293 | not candidates for the stable branch. The only exception might be a case |
||
294 | where an application's performance was recently severely impacted so as to |
||
295 | become unusable. The fix for this performance regression could then be |
||
296 | considered for a stable branch. The optimization must also be |
||
297 | non-controversial and the patches still need to meet the other criteria of |
||
298 | being simple and self-contained |
||
299 | |||
300 | |||
301 | assert might technically be correct, for example to make Mesa more |
||
302 | conformant, this is not the kind of "bug fix" we want in a stable |
||
303 | release. The potential problem here is that an OpenGL program that was |
||
304 | previously working, (even if technically non-compliant with the |
||
305 | specification), could stop working after this patch. So that would be a |
||
306 | regression that is unaacceptable for the stable branch. |
||
307 | |||
308 | |||
309 |
|
||
310 | |||
311 | |||
312 | These are the instructions for making a new Mesa release. |
||
313 | |||
314 | |||
315 |
|
||
316 | |||
317 | Use git to get the latest Mesa files from the git repository, from whatever |
||
318 | branch is relevant. This document uses the convention X.Y.Z for the release |
||
319 | being created, which should be created from a branch named X.Y. |
||
320 | |||
321 | |||
322 |
|
||
323 | |||
324 | The release manager should, at the very least, test the code by compiling it, |
||
325 | installing it, and running the latest piglit to ensure that no piglit tests |
||
326 | have regressed since the previous release. |
||
327 | |||
328 | |||
329 | |||
330 | The release manager should do this testing with at least one hardware driver, |
||
331 | (say, whatever is contained in the local development machine), as well as on |
||
332 | both Gallium and non-Gallium software drivers. The software testing can be |
||
333 | performed by running piglit with the following environment-variable set: |
||
334 | |||
335 | |||
336 | |||
337 | LIBGL_ALWAYS_SOFTWARE=1 |
||
338 | |||
339 | |||
340 | And Gallium vs. non-Gallium software drivers can be obtained by using the |
||
341 | following configure flags on separate builds: |
||
342 | |||
343 | |||
344 | --with-dri-drivers=swrast |
||
345 | --with-gallium-drivers=swrast |
||
346 | |||
347 | |||
348 | |||
349 | Note: If both options are given in one build, both swrast_dri.so drivers will |
||
350 | be compiled, but only one will be installed. The following command can be used |
||
351 | to ensure the correct driver is being tested: |
||
352 | |||
353 | |||
354 | |||
355 | LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep "renderer string" |
||
356 | |||
357 | |||
358 | If any regressions are found in this testing with piglit, stop here, and do |
||
359 | not perform a release until regressions are fixed. |
||
360 | |||
361 |
|
||
362 | |||
363 | |||
364 | Increment the version contained in the file VERSION at Mesa's top-level, then |
||
365 | commit this change. |
||
366 | |||
367 | |||
368 |
|
||
369 | |||
370 | |||
371 | Create a new file docs/relnotes/X.Y.Z.html, (follow the style of the previous |
||
372 | release notes). Note that the sha256sums section of the release notes should |
||
373 | be empty at this point. |
||
374 | |||
375 | |||
376 | |||
377 | Two scripts are available to help generate portions of the release notes: |
||
378 | |||
379 | |||
380 | ./bin/bugzilla_mesa.sh |
||
381 | ./bin/shortlog_mesa.sh |
||
382 | |||
383 | |||
384 | |||
385 | The first script identifies commits that reference bugzilla bugs and obtains |
||
386 | the descriptions of those bugs from bugzilla. The second script generates a |
||
387 | log of all commits. In both cases, HTML-formatted lists are printed to stdout |
||
388 | to be included in the release notes. |
||
389 | |||
390 | |||
391 | |||
392 | Commit these changes |
||
393 | |||
394 | |||
395 |
|
||
396 | |||
397 | From inside the Mesa directory: |
||
398 | |||
399 | ./autogen.sh |
||
400 | make -j1 tarballs |
||
401 | |||
402 | |||
403 | |||
404 | After the tarballs are created, the sha256 checksums for the files will |
||
405 | be computed and printed. These will be used in a step below. |
||
406 | |||
407 | |||
408 | |||
409 | It's important at this point to also verify that the constructed tar file |
||
410 | actually builds: |
||
411 | |||
412 | |||
413 | |||
414 | tar xjf MesaLib-X.Y.Z.tar.bz2 |
||
415 | cd Mesa-X.Y.Z |
||
416 | ./configure --enable-gallium-llvm |
||
417 | make -j6 |
||
418 | make install |
||
419 | |||
420 | |||
421 | |||
422 | Some touch testing should also be performed at this point, (run glxgears or |
||
423 | more involved OpenGL programs against the installed Mesa). |
||
424 | |||
425 | |||
426 | |||
427 | Create detached GPG signatures for each of the archive files created above: |
||
428 | |||
429 | |||
430 | |||
431 | gpg --sign --detach MesaLib-X.Y.Z.tar.gz |
||
432 | gpg --sign --detach MesaLib-X.Y.Z.tar.bz2 |
||
433 | gpg --sign --detach MesaLib-X.Y.Z.zip |
||
434 | |||
435 | |||
436 | |||
437 | Tag the commit used for the build: |
||
438 | |||
439 | |||
440 | |||
441 | git tag -s mesa-X.Y.X -m "Mesa X.Y.Z release" |
||
442 | |||
443 | |||
444 | |||
445 | Note: It would be nice to investigate and fix the issue that causes the |
||
446 | tarballs target to fail with multiple build process, such as with "-j4". It |
||
447 | would also be nice to incorporate all of the above commands into a single |
||
448 | makefile target. And instead of a custom "tarballs" target, we should |
||
449 | incorporate things into the standard "make dist" and "make distcheck" targets. |
||
450 | |||
451 | |||
452 |
|
||
453 | |||
454 | |||
455 | Edit docs/relnotes/X.Y.Z.html to add the sha256sums printed as part of "make |
||
456 | tarballs" in the previous step. Commit this change. |
||
457 | |||
458 | |||
459 |
|
||
460 | |||
461 | |||
462 | This is the first step that cannot easily be undone. The release is going |
||
463 | forward from this point: |
||
464 | |||
465 | |||
466 | |||
467 | git push origin X.Y --tags |
||
468 | |||
469 | |||
470 |
|
||
471 | |||
472 | |||
473 | The following commands can be used to copy the release archive files and |
||
474 | signatures to the freedesktop.org server: |
||
475 | |||
476 | |||
477 | |||
478 | scp MesaLib-X.Y.Z* people.freedesktop.org: |
||
479 | ssh people.freedesktop.org |
||
480 | cd /srv/ftp.freedesktop.org/pub/mesa |
||
481 | mkdir X.Y.Z |
||
482 | cd X.Y.Z |
||
483 | mv ~/MesaLib-X.Y.Z* . |
||
484 | |||
485 | |||
486 |
|
||
487 | |||
488 | |||
489 | Something like the following steps will do the trick: |
||
490 | |||
491 | |||
492 | |||
493 | cp docs/relnotes/X.Y.Z.html /tmp |
||
494 | git checkout master |
||
495 | cp /tmp/X.Y.Z.html docs/relnotes |
||
496 | git add docs/relnotes/X.Y.Z.html |
||
497 | |||
498 | |||
499 | |||
500 | Also, edit docs/relnotes.html to add a link to the new release notes, and edit |
||
501 | docs/index.html to add a news entry. Then commit and push: |
||
502 | |||
503 | |||
504 | |||
505 | git commit -a -m "docs: Import X.Y.Z release notes, add news item." |
||
506 | git push origin |
||
507 | |||
508 | |||
509 |
|
||
510 | |||
511 | |||
512 | NOTE: The recent release managers have not been performing this step |
||
513 | themselves, but leaving this to Brian Paul, (who has access to the |
||
514 | sourceforge.net hosting for mesa3d.org). Brian is more than willing to grant |
||
515 | the permission necessary to future release managers to do this step on their |
||
516 | own. |
||
517 | |||
518 | |||
519 | |||
520 | Update the web site by copying the docs/ directory's files to |
||
521 | /home/users/b/br/brianp/mesa-www/htdocs/ with: |
||
522 | |||
523 |
|
||
524 | sftp USERNAME,mesa3d@web.sourceforge.net |
||
525 | |||
526 | |||
527 | |||
528 | |||
529 |
|
||
530 | |||
531 | Make an announcement on the mailing lists: |
||
532 | |||
533 | mesa-dev@lists.freedesktop.org, |
||
534 | and |
||
535 | mesa-announce@lists.freedesktop.org |
||
536 | |||
537 | Follow the template of previously-sent release announcements. The following |
||
538 | command can be used to generate the log of changes to be included in the |
||
539 | release announcement: |
||
540 | |||
541 | |||
542 | git shortlog mesa-X.Y.Z-1..mesa-X.Y.Z |
||
543 | |||
544 | |||
545 | |||
546 | |||
547 | |||
548 | !DOCTYPE> |