1 |
Quoting Ciaran McCreesh <ciaranm@g.o>: |
2 |
|
3 |
> Currently, things assigned to maintainer-wanted get the following |
4 |
> keywords (bugzilla, not ebuild): |
5 |
> |
6 |
> * EBUILD if an ebuild is attached |
7 |
> * REQUEST if an ebuild is requested |
8 |
|
9 |
Ah. I didn't know this was part of the bugzilla policy. |
10 |
|
11 |
> I've been going through the EBUILD list at random and providing lists of |
12 |
> things that need to be fixed before the ebuild can be considered for |
13 |
> inclusion. The WONTFIX resolution along with a comment asking for the |
14 |
> submitter to reopen with a fixed ebuild is used when problems are found. |
15 |
> |
16 |
> Note that I'm being pretty strict about quoting, style etc, partly |
17 |
> because one easy way of improving tree QA is by making sure that new |
18 |
> entries are of a high standard and partly because it would be nice for |
19 |
> herds to be able to get a perfect, probably no changes needed ebuild. |
20 |
> Sure, some of the existing tree is far from ideal, but that's no excuse |
21 |
> for adding new shoddy things. |
22 |
> |
23 |
> What I'd like is a new keyword (bugzilla, not ebuild) for indicating |
24 |
> that a developer has done a check on an ebuild and is satisfied that |
25 |
> the ebuild is fine from a style perspective. This does **not** mean |
26 |
> that the developer has tried to actually merge the package. There're |
27 |
> all kinds of things for which I can say "the ebuild looks good", but |
28 |
> not so many for which I can say "the ebuild looks good and installs |
29 |
> something that works", since a lot of them have insanely long |
30 |
> dependency lists or specific hardware requirements. Can anyone suggest |
31 |
> a name? Best I can come up with is STYLE_CHECKED(nickname)... |
32 |
|
33 |
Good idea. That means one could distinguish: |
34 |
|
35 |
1/ Freshly submitted ebuilds that haven't been looked at yet (open bugs, |
36 |
assigned to maintainer-wanted, where keywords field contain the EBUILD |
37 |
substring but doesn't contain the STYLE_CHECKED substring), |
38 |
2/ Submitted ebuilds that have already been looked at, but need some |
39 |
rework to be added to the tree (closed bug, resolved as WONTFIX, |
40 |
assigned to maintainer-wanted, CC-ed to the concerned herd(s), where |
41 |
keywords field contain the EBUILD and the STYLE_CHECKED substrings), |
42 |
3/ Submitted ebuilds that have been verified with success, but haven't |
43 |
been tested nor included int the tree yet (open bugs, assigned to |
44 |
maintainer-needed, CC-ed to the concerned herd(s), where keywords |
45 |
contain the EBUILD and the STYLE_CHECKED substrings). |
46 |
|
47 |
That makes a lot of things to remind when changing bug states. |
48 |
|
49 |
> Hopefully it will reduce herd loads significantly if it can be ensured |
50 |
> that they're only sent high quality ebuilds... |
51 |
|
52 |
Can this be added to the bugzilla-howto, whatever the final decision is? |
53 |
Imho, there are several points missing in this howto, like security |
54 |
status whiteboard policy (which can be found in the Vulnerability |
55 |
Treatment Policy), keywords policy (I wasn't aware of the EBUILD vs |
56 |
REQUEST for maintainer-wanted) and priority (how is it really used?). |
57 |
That would be great, especially for new developers as well as users to |
58 |
better understand what's going on with the bugzilla. |
59 |
|
60 |
Furthermore, could the bugzilla bug lifecycle |
61 |
(http://www.bugzilla.org/docs/2.18/html/lifecycle.html) be referenced |
62 |
in the bugzilla-howto, or even better, updated with Gentoo workflow |
63 |
characteristics and included? |
64 |
|
65 |
Any comments? Thanks, |
66 |
-- |
67 |
Julien Allanos (dju`) |
68 |
Gentoo Linux Developer (web-apps) |
69 |
GnuPG key: 0x1EC6C6C2 |
70 |
-- |
71 |
gentoo-dev@g.o mailing list |