Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

[Luca Longinotti]

Thomas Cort wrote:
> On 10/4/06, Luca Longinotti <chtekk@g.o> wrote:
> The number of opened bugs has always been higher than the number of
> closed bugs in the bug stats listed in every 2006 GWN. How is this
> 'going forward'? It seems to me like we are falling behind.

That's not an indicator you can really trust imo... A lot of those are
"WTF??? segfault? eh?" and/or waiting on user input because they're
irreproducible by the devs involved, but I agree, there are a lot of
open ones because lately it seems that people tend to just go MIA,
return sometimes, do 1-2 commits, then away again... This has to stop
and such people have to be retired, but devrel already does that. And
orphaned/broken ebuilds do get punted from the tree... TreeCleaners!

>> Who decides what goes away and what now? Which criteria is used here?
>
> Duplicate packages (we don't need more than a few mp3 players),
> unpopular packages with only a few users, unmaintained packages, and
> broken packages.

We've all seen how we don't need more than a few mp3 players when trying
to remove XMMS, which is _broken_, _old_ and _dead_. :)
One of Gentoo's strenghts is the "it's all about choice" paradigm, don't
ever remove that, ever. ;) If there are people willing to maintain them,
or if they are not broken and perfectly work, don't kill stuff just
because you think it's duplicate/useless/unpopular.

> We would provide a set of packages for most things a
> user would want to do and then sunrise/someone else provides ebuilds
> for the rest. I was thinking something similar to what Ubuntu does,
> they provide the basics to do most things and then they have universe
> and multiverse repos for extra stuff.

Yes, but we're a meta-distro, we do not know what the user wants to do,
he just does... I myself run desktops and www-servers, mail-servers,
others run embedded-apps, game-servers etc... So the whole breaking
stuff up idea that's cursing atm through the blogs just doesn't cut it,
and would imo in the end only increase maintainance because packages are
spread out and you have to jump through loops to get them like you want.

>> > - Formal approval process (or at least strict criteria) for adding
>> > new packages
>>
>> Err what?
>
> I believe that we have too many packages for us to maintain. We have
> over 11,000 packages (over 24,000 ebuilds) and only about 175 active
> developers. I don't think its maintainable and I don't think adding
> more packages will make it any better.

TreeCleaners, to an extent Security etc. _do_ remove what is dead, what
has reached points of unmaintainability and brokenness that cannot be
anymore supported. The rest still is there because it works (so why
remove it?), or because it has someone that keeps it alive (so why
remove it?). If there's something to do here, it's kicking out old,
broken stuff etc. faster and improving QA (as Kevin already pointed
out), definitely not making it so difficult to add new stuff that no one
will, that only produces stagnation of the tree in the end.

>> > - Make every dev a member of at least 1 arch team
>>
>> Which doesn't mean he will ever keyword stuff stable, other than his
>> own, which he already can...
>
> Every developer should have access to at least 1 Gentoo system. They
> should also be able to determine if something is stable or not. It
> would cut down on the number of keyword/stable bugs if developers did
> a lot of their own keywording.

Cool... But that's exactly what the arch-teams were created "against"...
From what I always understood arch-teams are there to have a second set
of eyes for stabling and testing stuff, even if the maintainer himself
can do that. Then he can stable his own stuff (just ask the arch-team
permission), or not... And the arch-team may or not give permission,
depends on the package in question. That's a relatively good approach
that ensures a measure of peer-review at least on the "important" packages.

>> > - Double the number of developers with aggressive recruiting
>>
>> That's something that goes on since...
>
> Even when someone is found it is hard for them to find mentors. We
> need to improve this. I had found someone who wanted to join the sound
> team and I was unable to locate a mentor for him (I wasn't a dev for 6
> months then, so I couldn't do it myself). I e-mailed sound@g.o and
> only one person offered. The person who offered fell through because
> he didn't have enough free time.

Ok, so I don't see how "aggressive recruiting" would improve that...
Improving recruiters/mentors capacity would have to be done first, so
even if we did some "aggressive recruiting" (which I'm not sure would
bring quality... probably quantity "hey cool Gentoo wants new devs,
let's join cause I like Linux! w0h000!!11!), we wouldn't have the
resources to sustain it.

>> > - No competing projects
>>
>> Kills innovation...
>
> What happened to working together? Should we work together instead of
> competing against each other?

Sure, working together is cool, but it doesn't always work, it never
always worked. That's maybe sad, but it's true. If you have a group of
people with totally opposite ideas than another, but both are, in the
end, good ideas, you cannot just tell one group "hey you cannot, do what
the others want!"... Let projects compete _if they must_, and let's see
how it goes. I thought it implicit that there should be a "let's discuss
it and work together" stage first, but if that fails, competing projects
should and must imo still be allowed.

>> > - Drop all arches and Gentoo/Alt projects except Linux on amd64,
>> > ppc32/64, sparc, and x86
>>
>> Uhhh is this real? How would this help at all?
>
> We've got tons of keywording/stable bugs. There aren't enough
> developers to do all the proper testing on all of the architectures
> supported by Gentoo. Many of the arches are dead or soon to be dead
> (m68k, alpha, mips, etc).

I know we've got tons of stale keywording bugs, I myself often get upset
that I have to wait 6 months on keywords for some package, but otoh I
see that just killing off the arch totally isn't probably the real
solution... As I already said, a relaxing of the current keywording
policy for maintainers is what's needed... If in a month no one from
archX keyworded dev-lol/asd stable, I as a maintainer could just drop
their stable keyword and revert to unstable, or if it's some major
version bump that requires testing for unstable even, just drop support
for that arch entirely. Users will then notice and maybe even help if
the package they were using suddenly has no more keyword for their arch,
or if no one cares... well then, no harm done in dropping that
particular keyword... this would in the end produce a kind of
"self-dekeywording" of the tree, and make it much cleaner.

>> > - Reduce the number of projects by eliminating the dead, weak,
>> > understaffed, and unnecessary projects
>>
>> Again, who's the judge of that? If there is a project with at least one
>> person active, it means for him it's not unnecessary...  What means weak
>> project? What's unnecessary? Sure, kill the dead ones with no activity
>> and no active members, that's easy and I agree with that, but the other,
>> little ones, who's the one to say "you're understaffed and useless, go
>> die!"? :S
>
> We come up with a list of potential cuts and then the council decides

Hmmm still don't see a definition of unnecessary, weak or understaffed.
Dead, sure, kill them on the spot. Unnecessary? Who are you, other devs
or the council to just tell someone that's working on a project as a
volounteer "hey, we think your work is useless, drop it, now!", and
understaffed/weak is too subjective, especially since workload anyway
changes over time.
-- 
Best regards,
Luca Longinotti aka CHTEKK

LongiTEKK Networks Admin: chtekk@×××××××××.com
Gentoo Dev: chtekk@g.o
SysCP Dev: chtekk@×××××.org
TILUG Supporter: chtekk@×××××.ch