1 |
On 10/4/06, Luca Longinotti <chtekk@g.o> wrote: |
2 |
|
3 |
> People come and go, I still see Gentoo going forward, packages still get |
4 |
> updated, work gets done |
5 |
|
6 |
The number of opened bugs has always been higher than the number of |
7 |
closed bugs in the bug stats listed in every 2006 GWN. How is this |
8 |
'going forward'? It seems to me like we are falling behind. |
9 |
|
10 |
> > - Cut the number of packages in half (put the removed ebuilds in |
11 |
> > community run overlays) |
12 |
> |
13 |
> Who decides what goes away and what now? Which criteria is used here? |
14 |
|
15 |
Duplicate packages (we don't need more than a few mp3 players), |
16 |
unpopular packages with only a few users, unmaintained packages, and |
17 |
broken packages. We would provide a set of packages for most things a |
18 |
user would want to do and then sunrise/someone else provides ebuilds |
19 |
for the rest. I was thinking something similar to what Ubuntu does, |
20 |
they provide the basics to do most things and then they have universe |
21 |
and multiverse repos for extra stuff. |
22 |
|
23 |
> > - Formal approval process (or at least strict criteria) for adding |
24 |
> > new packages |
25 |
> |
26 |
> Err what? So I, as a dev, that did quizzes, etc., cannot even anymore |
27 |
> just add the package that has got my fancy atm, because there are some |
28 |
> criteria to what is added and what not, and I have to go through a |
29 |
> bureaucratic process just for that? Never! |
30 |
> If for strict criteria you mean "there must be at least a dev or herd |
31 |
> maintaining it", or such stuff, they already exist, they may just need |
32 |
> some more enforcing... ;) |
33 |
|
34 |
I believe that we have too many packages for us to maintain. We have |
35 |
over 11,000 packages (over 24,000 ebuilds) and only about 175 active |
36 |
developers. I don't think its maintainable and I don't think adding |
37 |
more packages will make it any better. |
38 |
|
39 |
> > - Make every dev a member of at least 1 arch team |
40 |
> |
41 |
> Which doesn't mean he will ever keyword stuff stable, other than his |
42 |
> own, which he already can... Let's face it: most devs are mainly |
43 |
> interested in their stuff, getting their stuff keyworded, and many |
44 |
> wouldn't anyway have the time to efficiently work on an arch-team, as |
45 |
> members of such I mean, not just as "I'm a member, so I keyword my |
46 |
> stuff, that's it"... For that I agree with the current practice: if you |
47 |
> want that, ask the arch-team first. ;) |
48 |
|
49 |
Every developer should have access to at least 1 Gentoo system. They |
50 |
should also be able to determine if something is stable or not. It |
51 |
would cut down on the number of keyword/stable bugs if developers did |
52 |
a lot of their own keywording. |
53 |
|
54 |
> > - Double the number of developers with aggressive recruiting |
55 |
> |
56 |
> That's something that goes on since... forever! Gentoo's continuously |
57 |
> recruiting new people, more aggressive recruiting has already been |
58 |
> proposed many times, but it was always agreed to try to maintain a |
59 |
> relatively high standard of new recruits, and if you want quality, |
60 |
> finding loads of people who "just happen" to have the time and |
61 |
> dedication to become a Gentoo dev isn't that easy. |
62 |
|
63 |
Even when someone is found it is hard for them to find mentors. We |
64 |
need to improve this. I had found someone who wanted to join the sound |
65 |
team and I was unable to locate a mentor for him (I wasn't a dev for 6 |
66 |
months then, so I couldn't do it myself). I e-mailed sound@g.o and |
67 |
only one person offered. The person who offered fell through because |
68 |
he didn't have enough free time. |
69 |
|
70 |
> > - No competing projects |
71 |
> |
72 |
> Kills innovation... Who comes first has total monopoly of that branch of |
73 |
> things basically... I'd never agree to something like this, personally. |
74 |
|
75 |
What happened to working together? Should we work together instead of |
76 |
competing against each other? |
77 |
|
78 |
> > - Drop all arches and Gentoo/Alt projects except Linux on amd64, |
79 |
> > ppc32/64, sparc, and x86 |
80 |
> |
81 |
> Uhhh is this real? How would this help at all? |
82 |
|
83 |
We've got tons of keywording/stable bugs. There aren't enough |
84 |
developers to do all the proper testing on all of the architectures |
85 |
supported by Gentoo. Many of the arches are dead or soon to be dead |
86 |
(m68k, alpha, mips, etc). |
87 |
|
88 |
> > - Reduce the number of projects by eliminating the dead, weak, |
89 |
> > understaffed, and unnecessary projects |
90 |
> |
91 |
> Again, who's the judge of that? If there is a project with at least one |
92 |
> person active, it means for him it's not unnecessary... What means weak |
93 |
> project? What's unnecessary? Sure, kill the dead ones with no activity |
94 |
> and no active members, that's easy and I agree with that, but the other, |
95 |
> little ones, who's the one to say "you're understaffed and useless, go |
96 |
> die!"? :S |
97 |
|
98 |
We come up with a list of potential cuts and then the council decides |
99 |
-- |
100 |
gentoo-dev@g.o mailing list |