Rev 1892 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
3931 | Serge | 1 | Pixman is a library that provides low-level pixel manipulation |
1892 | serge | 2 | features such as image compositing and trapezoid rasterization. |
3 | |||
3931 | Serge | 4 | Questions, bug reports and patches should be directed to the pixman |
1892 | serge | 5 | mailing list: |
6 | |||
7 | http://lists.freedesktop.org/mailman/listinfo/pixman |
||
8 | |||
3931 | Serge | 9 | You can also file bugs at |
1892 | serge | 10 | |
11 | https://bugs.freedesktop.org/enter_bug.cgi?product=pixman |
||
12 | |||
3931 | Serge | 13 | For real time discussions about pixman, feel free to join the IRC |
14 | channels #cairo and #xorg-devel on the FreeNode IRC network. |
||
1892 | serge | 15 | |
3931 | Serge | 16 | |
17 | Contributing |
||
18 | ------------ |
||
19 | |||
20 | In order to contribute to pixman, you will need a working knowledge of |
||
21 | the git version control system. For a quick getting started guide, |
||
22 | there is the "Everyday Git With 20 Commands Or So guide" |
||
23 | |||
24 | http://www.kernel.org/pub/software/scm/git/docs/everyday.html |
||
25 | |||
26 | from the Git homepage. For more in depth git documentation, see the |
||
27 | resources on the Git community documentation page: |
||
28 | |||
29 | http://git-scm.com/documentation |
||
30 | |||
31 | Pixman uses the infrastructure from the freedesktop.org umbrella |
||
32 | project. For instructions about how to use the git service on |
||
33 | freedesktop.org, see: |
||
34 | |||
35 | http://www.freedesktop.org/wiki/Infrastructure/git/Developers |
||
36 | |||
37 | The Pixman master repository can be found at: |
||
38 | |||
1892 | serge | 39 | git://anongit.freedesktop.org/git/pixman |
40 | |||
3931 | Serge | 41 | and browsed on the web here: |
1892 | serge | 42 | |
3931 | Serge | 43 | http://cgit.freedesktop.org/pixman/ |
1892 | serge | 44 | |
3931 | Serge | 45 | |
46 | Sending patches |
||
47 | --------------- |
||
48 | |||
49 | The general workflow for sending patches is to first make sure that |
||
50 | git can send mail on your system. Then, |
||
51 | |||
52 | - create a branch off of master in your local git repository |
||
53 | |||
54 | - make your changes as one or more commits |
||
55 | |||
56 | - use the |
||
57 | |||
58 | git send-email |
||
59 | |||
60 | command to send the patch series to pixman@lists.freedesktop.org. |
||
61 | |||
62 | In order for your patches to be accepted, please consider the |
||
63 | following guidelines: |
||
64 | |||
65 | - This link: |
||
66 | |||
67 | http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#patch-series |
||
68 | |||
69 | describes how what a good patch series is, and to create one with |
||
70 | git. |
||
71 | |||
72 | - At each point in the series, pixman should compile and the test |
||
73 | suite should pass. |
||
74 | |||
75 | The exception here is if you are changing the test suite to |
||
76 | demonstrate a bug. In this case, make one commit that makes the |
||
77 | test suite fail due to the bug, and then another commit that fixes |
||
78 | the bug. |
||
79 | |||
80 | You can run the test suite with |
||
81 | |||
82 | make check |
||
83 | |||
84 | It will take around two minutes to run on a modern PC. |
||
85 | |||
86 | - Follow the coding style described in the CODING_STYLE file |
||
87 | |||
88 | - For bug fixes, include an update to the test suite to make sure |
||
89 | the bug doesn't reappear. |
||
90 | |||
91 | - For new features, add tests of the feature to the test |
||
92 | suite. Also, add a program demonstrating the new feature to the |
||
93 | demos/ directory. |
||
94 | |||
95 | - Write descriptive commit messages. Useful information to include: |
||
96 | - Benchmark results, before and after |
||
97 | - Description of the bug that was fixed |
||
98 | - Detailed rationale for any new API |
||
99 | - Alternative approaches that were rejected (and why they |
||
100 | don't work) |
||
101 | - If review comments were incorporated, a brief version |
||
102 | history describing what those changes were. |
||
103 | |||
104 | - For big patch series, send an introductory email with an overall |
||
105 | description of the patch series, including benchmarks and |
||
106 | motivation. Each commit message should still be descriptive and |
||
107 | include enough information to understand why this particular commit |
||
108 | was necessary. |
||
109 | |||
110 | Pixman has high standards for code quality and so almost everybody |
||
111 | should expect to have the first versions of their patches rejected. |
||
112 | |||
113 | If you think that the reviewers are wrong about something, or that the |
||
114 | guidelines above are wrong, feel free to discuss the issue on the |
||
115 | list. The purpose of the guidelines and code review is to ensure high |
||
116 | code quality; it is not an exercise in compliance. |