| 1 |
As usual, sweeping new policies or procedures WILL NOT FIX THINGS. |
| 2 |
|
| 3 |
Pretty much every commercial enterprize learns this eventually. New |
| 4 |
rules from above don't fix problems, peolpe fix problems from below. |
| 5 |
Gentoo has always been about close cooperation between core devs, new |
| 6 |
devs and non devs. I think the best thing that can possibly be done is |
| 7 |
to help to foster that kind of connection again. The bigget problem |
| 8 |
that I see facing that effort is that #gentoo is no longer a manageable |
| 9 |
place for devs to talk to users. Remember when every developer could be |
| 10 |
found in there? Remember when #gentoo was _the_ place for gentoo |
| 11 |
related discussions, and new ideas could be implemented and handed to |
| 12 |
the very users who would be impacted by the changes right in #gentoo? |
| 13 |
Remember when committing a big bug into the tree just wasn't that big of |
| 14 |
a deal, because it'd get fixed soon, and the people who updated often |
| 15 |
enough to care in the meantime would just laugh about it with you in |
| 16 |
#gentoo? |
| 17 |
|
| 18 |
What if the problem is too many devs instead of too few? Slackware |
| 19 |
Linux is a comparatively simple to maintain distribution, but ONE person |
| 20 |
does it. How many devs are on Gentoo now? 200? more? A close knit |
| 21 |
group of college students and bored professionals should be able to |
| 22 |
maintain this distribution. |
| 23 |
|
| 24 |
The biggest point that I do agree with from the original email is that |
| 25 |
projects like stage 4s, the installer and pretty much anything other |
| 26 |
than the portage program, the portage tree and the stage[123] live CDs |
| 27 |
should not be officially part of the Gentoo project. That's not Gentoo. |
| 28 |
Gentoo was started as a meta-distribution for good reason and it's good |
| 29 |
at that, keep it that way. If people want to wrap an installer and |
| 30 |
stage 4s around that meta distribution, more power to them -- they |
| 31 |
should name their distro and credit Gentoo, but that is _not_ Gentoo. |
| 32 |
The great thing about being a meta distribution and not a full |
| 33 |
pretty-installer binary distribution is that some of the quirky one-off |
| 34 |
package incompatibilities become not really Gentoo's problem. They are |
| 35 |
now the person who wants to distribute a binary distro that contains |
| 36 |
that particular weird set of packages problem. Hopefully they fix it |
| 37 |
and submit a patch upstream to Gentoo, and maybe they request a portage |
| 38 |
feature (cuz there aren't enough already) to improve it. |
| 39 |
|
| 40 |
Rant! |
| 41 |
|
| 42 |
Meh, I'm part of the problem, so I should shut up now. |
| 43 |
|
| 44 |
--Brandon |
| 45 |
|
| 46 |
On 2006-10-04 (Wed) at 13:44:01 +0200, Simon Stelling wrote: |
| 47 |
> Christian Heim wrote: |
| 48 |
> >>- Make every dev a member of at least 1 arch team |
| 49 |
> > |
| 50 |
> >I think that would solve the understaffing of some of the arch teams (iirc |
| 51 |
> >amd64 and x86 are having enough devs / at's right now) |
| 52 |
> |
| 53 |
> No. We don't need more people on our dev lists, because it won't change |
| 54 |
> anything. What we need is more people who do actual testing. If you're |
| 55 |
> forced to be in an arch team you're just a <dev> tag in a project page, |
| 56 |
> not more. This is not going to help at all, in fact it will only hide |
| 57 |
> the problems even more. |
| 58 |
> |
| 59 |
> -- |
| 60 |
> Kind Regards, |
| 61 |
> |
| 62 |
> Simon Stelling |
| 63 |
> Gentoo/AMD64 developer |
| 64 |
> -- |
| 65 |
> gentoo-dev@g.o mailing list |
| 66 |
> |
| 67 |
-- |
| 68 |
gentoo-dev@g.o mailing list |
Archives