1 |
On Monday 27 September 2004 05:58, Collins Richey wrote: |
2 |
> Now is your chance to provide suggestions. If you know about common |
3 |
> Bugzilla mistakes, tricks to make the process of entering bugs easier, |
4 |
> additional data that should be entered with each bug, keywords that |
5 |
> will help in searching, etc., please let me know. Your suggestions |
6 |
> will help me produce a better document. |
7 |
|
8 |
Besides the points that the old HOWTO makes I would like to add the |
9 |
following gripes: |
10 |
- If compilation fails in a package that does not mean that your bug is |
11 |
the same bug as another compilation failure in that package with a |
12 |
different error message (especially not in complicated packages like |
13 |
openoffice). Handling two different issues in one bugzilla bug is very |
14 |
difficult. |
15 |
- Do not be affraid to attach full build logs to bugs (and your emerge |
16 |
INFO of course). If they are too big use gzip (not tar cfz). Don't put |
17 |
them inline. |
18 |
- Error numbers from make mean absolutely nothing for diagnosing a bug. |
19 |
Even though problems seem to surface in the last 25 lines of output from |
20 |
emerge that does not mean that the real cause can be found hundreds of |
21 |
lines earlier. |
22 |
- Avoid attaching tarballs, preferably provide each file separately. |
23 |
- Please please provide the right mime type, it makes reading/downloading |
24 |
much easier. |
25 |
- Use the latest ebuild to base the new patch/ebuild of, nothing is more |
26 |
annoying than reintroducing bugs because an older version was used as |
27 |
base. |
28 |
- Keep your hands of the priority settings that increase priority, when a |
29 |
compilation fails for you it does not mean that it is a blocker. |
30 |
- If submitting an ebuild, follow the guidelines (yes, that seems obvious) |
31 |
|
32 |
Paul |
33 |
|
34 |
-- |
35 |
Paul de Vrieze |
36 |
Gentoo Developer |
37 |
Mail: pauldv@g.o |
38 |
Homepage: http://www.devrieze.net |