| 1 |
> > > Keeping the big pseudo-category split doesn't make much sense as most |
| 2 |
> > > of the packages can't be fit easily into a specific group and it only |
| 3 |
> > > confuses users. GNOME & KDE aren't very clear either, especially for |
| 4 |
> > > non-core packages (like: is systemd a GNOME package?). Having them |
| 5 |
> > > skip bug-wranglers doesn't sound really helpful. |
| 6 |
> > |
| 7 |
> > Keeping the big desktop environments would be nice; anything that is a |
| 8 |
> > large, logical group of packages maintained by one team. |
| 9 |
> > |
| 10 |
> > Like, auto-assigning kde to kde and gnome to gnome. |
| 11 |
> > |
| 12 |
> > Of course upstream doesn't really help with their destructive tendencies. |
| 13 |
> > ("There is no KDE5, only Frameworks, Plasma and Applications.") |
| 14 |
> |
| 15 |
> But there are non-core KDE apps that are not maintained by KDE team, |
| 16 |
> and GNOME apps that are not maintained by GNOME team. Users usually |
| 17 |
> don't check maintainers before choosing a component... |
| 18 |
|
| 19 |
Well, the point of having a default assignee of categories is to remove load |
| 20 |
from the bug wranglers. [*] |
| 21 |
|
| 22 |
(Who haven't pitched in yet here afaics, maybe we should hear them out.) |
| 23 |
|
| 24 |
I see a value for a separate category if there is |
| 25 |
|
| 26 |
1) a user-recognizable large group of packages |
| 27 |
2) that is to an overwhelming degree maintained (or at least co-maintained) by |
| 28 |
one project. |
| 29 |
|
| 30 |
About 1), examples would be |
| 31 |
* the packages of a large desktop environment (like KDE, Gnome, ...) |
| 32 |
* the packages of fringe languages (like Haskell, Erlang, Java, ... :) |
| 33 |
|
| 34 |
About 2) - even if a few packages are maintained by other people, the |
| 35 |
"wrangling" can be done by the project - who probably also know better what |
| 36 |
info to look for compared to the bugwranglers |
| 37 |
|
| 38 |
|
| 39 |
[*] No, I'm NOT opposed to bug auto-assignment. I just think we should run and |
| 40 |
test it first, and once we've concluded that it works fine, then tear down our |
| 41 |
old auxiliary constructs. |
| 42 |
|
| 43 |
Usually you don't tear down the old bridge over the river before building the |
| 44 |
new one. |
| 45 |
|
| 46 |
|
| 47 |
-- |
| 48 |
|
| 49 |
Andreas K. Huettel |
| 50 |
Gentoo Linux developer |
| 51 |
dilfridge@g.o |
| 52 |
http://www.akhuettel.de/ |
Archives