1 |
On 06/15/2016 12:11 PM, Michał Górny wrote: |
2 |
> Hello, everyone. |
3 |
> |
4 |
> On bug #577398, Pacho has requested removing the 'Development' |
5 |
> component that's rarely used according to its description. However, I'd |
6 |
> rather not remove a single component when it fits the component split |
7 |
> currently used there. |
8 |
> |
9 |
> Right now we have the following components: |
10 |
> |
11 |
> - Applications, |
12 |
> - baselayout, |
13 |
> - Core system, |
14 |
> - Development, |
15 |
> - Eclasses and Profiles, |
16 |
> - Games, |
17 |
> - GCC Porting, |
18 |
> - GNOME, |
19 |
> - Hardened, |
20 |
> - Java, |
21 |
> - KDE, |
22 |
> - Keywording & Stabilization, |
23 |
> - Library, |
24 |
> - New packages ('New ebuilds' previously), |
25 |
> - Printing, |
26 |
> - SELinux, |
27 |
> - Server, |
28 |
> - Unspecified. |
29 |
> |
30 |
> This basically is a mix of two component types: functional (like |
31 |
> keywording, new packages...) and ebuild category (app, baselayout, core |
32 |
> system...). |
33 |
> |
34 |
> Out of those components, GNOME, Hardened, Java, KDE and SELinux don't |
35 |
> go through bug-wranglers. All other components don't have a specific |
36 |
> default assignee. |
37 |
> |
38 |
> Of course, users are pretty much confused about which component to use, |
39 |
> except for simple cases. The more experienced ones know that it doesn't |
40 |
> matter most of the time, and choose a random one. |
41 |
> |
42 |
> Applications have around 100k bugs, new packages 128k (mostly wrong |
43 |
> filled because of the old 'ebuilds' name), other components are less |
44 |
> than 20k. |
45 |
> |
46 |
> |
47 |
> I would personally go for the following layout: |
48 |
> |
49 |
> - All packages, |
50 |
> - Core system [includes baselayout], |
51 |
> - Eclasses and Profiles, |
52 |
> - GCC Porting, |
53 |
> - Hardened, |
54 |
> - Keywording & Stabilization, |
55 |
> - New packages ('New ebuilds' previously), |
56 |
> - SELinux. |
57 |
> |
58 |
> The goals would be: |
59 |
> |
60 |
> a. have something that would fit most bugs going through bug-wranglers |
61 |
> on the top, |
62 |
> |
63 |
> b. leave the functional split for 'eclasses and profiles' and 'new |
64 |
> packages', |
65 |
> |
66 |
> c. leave the special team components such as 'gcc porting', 'hardened'... |
67 |
> |
68 |
> Keeping the big pseudo-category split doesn't make much sense as most |
69 |
> of the packages can't be fit easily into a specific group and it only |
70 |
> confuses users. GNOME & KDE aren't very clear either, especially for |
71 |
> non-core packages (like: is systemd a GNOME package?). Having them |
72 |
> skip bug-wranglers doesn't sound really helpful. |
73 |
> |
74 |
> |
75 |
> Your thoughts? |
76 |
> |
77 |
> |
78 |
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=577398 |
79 |
> |
80 |
A smaller set of categories goes a long way to helping people figure out |
81 |
how they should be filed, and ensures the right people look at them. |
82 |
Anything to make that process smoother for both devs and users sounds |
83 |
good to me. Even as a developer I feel there's too much divide among |
84 |
things and it can be hard to decide where a bug goes. |
85 |
|
86 |
Ultimately it's up to the people who have to deal with the most bugs, |
87 |
though. |
88 |
|
89 |
-- |
90 |
Daniel Campbell - Gentoo Developer |
91 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
92 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |