Gentoo World Domination. a 10 step guide

classic Classic list List threaded Threaded
106 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Gentoo World Domination. a 10 step guide

Thomas Cort-2
There have been a number of developers leaving Gentoo in the past 6
months as well as a number of news stories on DistroWatch, Slashdot,
LWN, and others about Gentoo's internal problems. No one seems to have
pin pointed the problem, but it seems glaringly obvious to me. We
simply don't have enough developers to support the many projects that
we have. Here are my ideas for fixing this problem:

- Cut the number of packages in half (put the removed ebuilds in
community run overlays)

- Formal approval process (or at least strict criteria) for adding
new packages

- Make every dev a member of at least 1 arch team

- Double the number of developers with aggressive recruiting

- No competing projects

- New projects must have 5 devs, a formal plan, and be approved by the
council

- Devs can only belong to 5 projects at most

- Drop all arches and Gentoo/Alt projects except Linux on amd64,
ppc32/64, sparc, and x86

- Reduce the number of projects by eliminating the dead, weak,
understaffed, and unnecessary projects

- Project status reports once a month for every project

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Diego Elio Pettenò-3
On Wednesday 04 October 2006 13:00, Thomas Cort wrote:
> - Drop all arches and Gentoo/Alt projects except Linux on amd64,
> ppc32/64, sparc, and x86
I would say to drop everything bug sparc and ppc64, that seems to be the only
arch teams that actually respond in a timely fashion to keywording requests.

Sounds crazy, but both amd64 and x86 are bottlenecks here...

I don't even want to comment on your mail, I looked at the calendar to see if
it was April 1st already, maybe I ended up in a timedrift.

--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Luca Barbato
In reply to this post by Thomas Cort-2
Thomas Cort wrote:
> There have been a number of developers leaving Gentoo in the past 6
> months as well as a number of news stories on DistroWatch, Slashdot,
> LWN, and others about Gentoo's internal problems. No one seems to have
> pin pointed the problem, but it seems glaringly obvious to me. We
> simply don't have enough developers to support the many projects that
> we have. Here are my ideas for fixing this problem:
>
> - Cut the number of packages in half (put the removed ebuilds in
> community run overlays)

No, thank you. We are already decimating packages in certain areas but
isn't a good solution.

>
> - Formal approval process (or at least strict criteria) for adding
> new packages

let the herds decide...

>
> - Make every dev a member of at least 1 arch team

Ok

>
> - Double the number of developers with aggressive recruiting

NO! I want to know people I'm working with. Double the people doing
recruiting and evaluation! (I have at least one guy in wait phase)

>
> - No competing projects

No projects that don't coordinate between them.

>
> - New projects must have 5 devs, a formal plan, and be approved by the
> council

some projects starts by one and then grow...

>
> - Devs can only belong to 5 projects at most

No.

>
> - Drop all arches and Gentoo/Alt projects except Linux on amd64,
> ppc32/64, sparc, and x86

No.

>
> - Reduce the number of projects by eliminating the dead, weak,
> understaffed, and unnecessary projects

too much subjective so, No.

>
> - Project status reports once a month for every project

bureocracy....

In short, interesting ideas, I don't like more than half of them.

what about:

let treecleaners do their job,

recruiters get more people,

put the devmanual where it belongs,

have better coordination between projects to the point stepping on
others feet is quite hard and not dead easy as today?

those point and less noise on gentoo-dev.

lu

--

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Christian Heim
In reply to this post by Thomas Cort-2
On Wednesday, 04. October. 2006 13:00, Thomas Cort wrote:
> There have been a number of developers leaving Gentoo in the past 6
> months as well as a number of news stories on DistroWatch, Slashdot,
> LWN, and others about Gentoo's internal problems. No one seems to have
> pin pointed the problem, but it seems glaringly obvious to me. We
> simply don't have enough developers to support the many projects that
> we have. Here are my ideas for fixing this problem:
>
> - Cut the number of packages in half (put the removed ebuilds in
> community run overlays)

We (treecleaner, poke Alec about that) are currently working on something
alike. A user / Alec suggested putting removed packages into a seperate
overlay, so the ebuilds would be still accessible (without using
sources.gentoo.org and putting it into a local overlay).

> - Formal approval process (or at least strict criteria) for adding
> new packages
>
> - Make every dev a member of at least 1 arch team

I think that would solve the understaffing of some of the arch teams (iirc
amd64 and x86 are having enough devs / at's right now)

> - Double the number of developers with aggressive recruiting

Before you do that, you'll have to double the number of recruiters. Otherwise
you're creating a pretty bottleneck.

> - No competing projects
>
> - New projects must have 5 devs, a formal plan, and be approved by the
> council
>
> - Devs can only belong to 5 projects at most

Reducing the stress on people ? No clue what that would solve.

> - Drop all arches and Gentoo/Alt projects except Linux on amd64,
> ppc32/64, sparc, and x86

I guess at least Diego and Fabian are going to yell at you right now.

> - Reduce the number of projects by eliminating the dead, weak,
> understaffed, and unnecessary projects
>
> - Project status reports once a month for every project

That would be great, but to whom should they report ? The council ? Or
via -core ?

--
Christian Heim <phreak at gentoo.org>
GPG key ID: 9A9F68E6
Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6

Your friendly treecleaner/mobile/kernel/vserver/openvz monkey
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Ciaran McCreesh-3
In reply to this post by Thomas Cort-2
On Wed, 4 Oct 2006 07:00:14 -0400 Thomas Cort <[hidden email]> wrote:
| - Double the number of developers with aggressive recruiting

Aggressive recruiting isn't going to find you more competent people.
All it's going to do is increase the moron quotient from its current
50% to 75%.

| - Reduce the number of projects by eliminating the dead, weak,
| understaffed, and unnecessary projects

So just how *do* you plan to replace Portage, which is definitely weak,
definitely understaffed, probably getting close to dead and entirely
not unnecessary?

| - Project status reports once a month for every project

Who's going to read them and follow up on it? All this will do is
create more noise.

--
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Luca Longinotti
In reply to this post by Thomas Cort-2
Thomas Cort wrote:
> There have been a number of developers leaving Gentoo in the past 6
> months as well as a number of news stories on DistroWatch, Slashdot,
> LWN, and others about Gentoo's internal problems.

People come and go, I still see Gentoo going forward, packages still get
updated, work gets done... So I'm really beginning to think people read
toooo much into a few people leaving over 6 months and a few, generally
wrong articles based on misinterpreting someones blog...

> simply don't have enough developers to support the many projects that
> we have. Here are my ideas for fixing this problem:

Maybe, maybe not... Projects exist, so there is at least _someone_
that's interested in them... If that's not true, then ok, just remove
that project... Let's start the comments on the 10 points (all imho):

> - Cut the number of packages in half (put the removed ebuilds in
> community run overlays)

Who decides what goes away and what now? Which criteria is used here?
Btw, this is already being done splendidly by the TreeCleaners project,
and Sunrise and other overlays are already absorbing stuff from the
community.

> - Formal approval process (or at least strict criteria) for adding
> new packages

Err what? So I, as a dev, that did quizzes, etc., cannot even anymore
just add the package that has got my fancy atm, because there are some
criteria to what is added and what not, and I have to go through a
bureaucratic process just for that? Never!
If for strict criteria you mean "there must be at least a dev or herd
maintaining it", or such stuff, they already exist, they may just need
some more enforcing... ;)

> - 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... Let's face it: most devs are mainly
interested in their stuff, getting their stuff keyworded, and many
wouldn't anyway have the time to efficiently work on an arch-team, as
members of such I mean, not just as "I'm a member, so I keyword my
stuff, that's it"... For that I agree with the current practice: if you
want that, ask the arch-team first. ;)

> - Double the number of developers with aggressive recruiting

That's something that goes on since... forever! Gentoo's continuously
recruiting new people, more aggressive recruiting has already been
proposed many times, but it was always agreed to try to maintain a
relatively high standard of new recruits, and if you want quality,
finding loads of people who "just happen" to have the time and
dedication to become a Gentoo dev isn't that easy.

> - No competing projects

Kills innovation... Who comes first has total monopoly of that branch of
things basically... I'd never agree to something like this, personally.

> - New projects must have 5 devs, a formal plan, and be approved by the
> council

New projects do always have a plan, they wouldn't be created else... ;)
Making it formal, be approved by the council... How to slow everything
down? We continuously see how adding bureaucratic stuff just suffocates
innovation, I totally agree with discussion et all, but not really on
the need to have everything approved by someone (the council in this
case)... The council may kill the project later on if it's doing totally
crazy shit, but that's another thing entirely...

> - Devs can only belong to 5 projects at most

Why? If someone has time to dedicate and work on a lot of projects, why not?

> - 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? Hell, it would make
things worse to an extent, we've already seen that at least Gentoo/BSD
helped in finding problems in ebuilds using too GNUish stuff, other
arches may help in finding broken code, etc.. I'd agree with some
proposal to relax keywording policy for all arches you've not listed,
since on those others, sadly, not soo many people are active, and you
get to wait on keywords for months sometimes... This is something we
should imo address from an arch-team PoV, some kind of "if they don't
react in time, I can drop their keyword back to unstable or entirely",
or something like that, that would help many package maintainers I think.

> - 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

> - Project status reports once a month for every project

Totally agree on this one!
--
Best regards,
Luca Longinotti aka CHTEKK

LongiTEKK Networks Admin: [hidden email]
Gentoo Dev: [hidden email]
SysCP Dev: [hidden email]
TILUG Supporter: [hidden email]


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Simon Stelling
In reply to this post by Christian Heim
Christian Heim wrote:
>> - Make every dev a member of at least 1 arch team
>
> I think that would solve the understaffing of some of the arch teams (iirc
> amd64 and x86 are having enough devs / at's right now)

No. We don't need more people on our dev lists, because it won't change
anything. What we need is more people who do actual testing. If you're
forced to be in an arch team you're just a <dev> tag in a project page,
not more. This is not going to help at all, in fact it will only hide
the problems even more.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Brandon Low-2
As usual, sweeping new policies or procedures WILL NOT FIX THINGS.

Pretty much every commercial enterprize learns this eventually.  New
rules from above don't fix problems, peolpe fix problems from below.
Gentoo has always been about close cooperation between core devs, new
devs and non devs.  I think the best thing that can possibly be done is
to help to foster that kind of connection again.  The bigget problem
that I see facing that effort is that #gentoo is no longer a manageable
place for devs to talk to users.  Remember when every developer could be
found in there?  Remember when #gentoo was _the_ place for gentoo
related discussions, and new ideas could be implemented and handed to
the very users who would be impacted by the changes right in #gentoo?
Remember when committing a big bug into the tree just wasn't that big of
a deal, because it'd get fixed soon, and the people who updated often
enough to care in the meantime would just laugh about it with you in
#gentoo?

What if the problem is too many devs instead of too few?  Slackware
Linux is a comparatively simple to maintain distribution, but ONE person
does it.  How many devs are on Gentoo now?  200? more?  A close knit
group of college students and bored professionals should be able to
maintain this distribution.

The biggest point that I do agree with from the original email is that
projects like stage 4s, the installer and pretty much anything other
than the portage program, the portage tree and the stage[123] live CDs
should not be officially part of the Gentoo project.  That's not Gentoo.
Gentoo was started as a meta-distribution for good reason and it's good
at that, keep it that way.  If people want to wrap an installer and
stage 4s around that meta distribution, more power to them -- they
should name their distro and credit Gentoo, but that is _not_ Gentoo.
The great thing about being a meta distribution and not a full
pretty-installer binary distribution is that some of the quirky one-off
package incompatibilities become not really Gentoo's problem.  They are
now the person who wants to distribute a binary distro that contains
that particular weird set of packages problem.  Hopefully they fix it
and submit a patch upstream to Gentoo, and maybe they request a portage
feature (cuz there aren't enough already) to improve it.

Rant!

Meh, I'm part of the problem, so I should shut up now.

--Brandon

On 2006-10-04 (Wed) at 13:44:01 +0200, Simon Stelling wrote:

> Christian Heim wrote:
> >>- Make every dev a member of at least 1 arch team
> >
> >I think that would solve the understaffing of some of the arch teams (iirc
> >amd64 and x86 are having enough devs / at's right now)
>
> No. We don't need more people on our dev lists, because it won't change
> anything. What we need is more people who do actual testing. If you're
> forced to be in an arch team you're just a <dev> tag in a project page,
> not more. This is not going to help at all, in fact it will only hide
> the problems even more.
>
> --
> Kind Regards,
>
> Simon Stelling
> Gentoo/AMD64 developer
> --
> [hidden email] mailing list
>
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Ioannis Aslanidis-2
In reply to this post by Thomas Cort-2
Thomas Cort wrote:
> - Cut the number of packages in half (put the removed ebuilds in
> community run overlays)
>
Removing part of the market will make us weaker, not stronger.

> - Formal approval process (or at least strict criteria) for adding
> new packages
Though I doubt bureaucracy will help, adding some strict criteria
doesn't seem a bad idea.

>
> - Make every dev a member of at least 1 arch team
That's a sound idea, that way some herds (see KDE) won't have to be
searching for testers in every arch because _strangely_ one of the most
daily used desktop environments doesn't have many users among the testers.

>
> - Double the number of developers with aggressive recruiting
Do you plan on sacrificing quality?

>
> - No competing projects
If the projects are small, that shouldn't be an issue. (i.e. does not
imply much effort)

>
> - New projects must have 5 devs, a formal plan, and be approved by the
> council
What are the reasons for a minimum of 5 developers? Any argument for
that? What do you understand for 'formal plan'?

>
> - Devs can only belong to 5 projects at most
What if the projects are small enough? How about belonging to the
infrastructure project for instance, does it count?

>
> - Drop all arches and Gentoo/Alt projects except Linux on amd64,
> ppc32/64, sparc, and x86
Again, reducing the market isn't the way IMHO.

>
> - Reduce the number of projects by eliminating the dead, weak,
> understaffed, and unnecessary projects
Please define 'unnecessary projects'.

>
> - Project status reports once a month for every project
I agree with this one. A monthly report might bring some order and light :)


--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Thomas Cort
In reply to this post by Christian Heim
On 10/4/06, Christian Heim <[hidden email]> wrote:
> On Wednesday, 04. October. 2006 13:00, Thomas Cort wrote:

> > - Devs can only belong to 5 projects at most
>
> Reducing the stress on people ? No clue what that would solve.

There are developers who belong to many projects and do very little or
no work for some. This would make them more focused and active on each
project. A team with 5 really active members is a lot nicer than one
with 30 people who aren't active.

> > - Project status reports once a month for every project
>
> That would be great, but to whom should they report ? The council ? Or
> via -core ?

They would report to the community in general by posting status
reports on their project pages.

-Tom

PS Sorry for not using my @gentoo.org e-mail address. I don't have
access to my Gentoo e-mail where I am right now.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Thomas Cort
In reply to this post by Ciaran McCreesh-3
On 10/4/06, Ciaran McCreesh <[hidden email]> wrote:
> On Wed, 4 Oct 2006 07:00:14 -0400 Thomas Cort <[hidden email]> wrote:
> | - Double the number of developers with aggressive recruiting
>
> Aggressive recruiting isn't going to find you more competent people.
> All it's going to do is increase the moron quotient from its current
> 50% to 75%.

There are plenty of competent people out there. We just aren't getting them.

> | - Reduce the number of projects by eliminating the dead, weak,
> | understaffed, and unnecessary projects
>
> So just how *do* you plan to replace Portage, which is definitely weak,
> definitely understaffed, probably getting close to dead and entirely
> not unnecessary?

I think you know the answer to that question ;)

> | - Project status reports once a month for every project
>
> Who's going to read them and follow up on it? All this will do is
> create more noise.

People in the community who are wondering what is going on are going
to read them. Userrel/pr would follow up.

-Tom
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Kevin F. Quinn (Gentoo)
In reply to this post by Thomas Cort-2
On Wed, 4 Oct 2006 07:00:14 -0400
Thomas Cort <[hidden email]> wrote:

> There have been a number of developers leaving Gentoo in the past 6
> months as well as a number of news stories on DistroWatch, Slashdot,
> LWN, and others about Gentoo's internal problems.

Regarding the news stories - they're just ill-informed
sensationalist press (nothing new there, then).  If a news site feels
the need to report when dev X leaves in a tantrum, it says more about
the amount and quality of news they have to report than it does about
us.

> No one seems to have
> pin pointed the problem, but it seems glaringly obvious to me. We
> simply don't have enough developers to support the many projects that
> we have.

One problem is that some expect all work to be done immediately.  The
only stuff that has to be done asap is security fixes; everything else
can be done when it's good and ready.

> Here are my ideas for fixing this problem:
>
> - Cut the number of packages in half (put the removed ebuilds in
> community run overlays)

We already have TreeCleaners who have a managed approach to removing
unmaintained&broken ebuilds.  What cuts are you proposing in addition
to that, and why?

> - Formal approval process (or at least strict criteria) for adding
> new packages

Yuck.  Devs should be free to add whatever packages they like,
provided they're willing to maintain them.

I'd support stronger QA of ebuilds.  Of course that's down to finding
enough clue-ful people willing to join the QA team and do the reviews.

> - Make every dev a member of at least 1 arch team

Why?  The only people on arch teams should be those actually doing arch
work.  Many devs don't get involved in stable keywording, and there's
no reason they should be - why should they be on an arch team?

> - Double the number of developers with aggressive recruiting

Assuming we need more devs, the issues are (1) supply of good people and
(2) resource in recruiters.  (1) is the crux of the problem.  No amount
of wand waving is going to change that.

> - No competing projects

Absolutely disagree.  At worst, if two projects cannot physically
co-exist in the same tree then they should go into overlay, but we've
yet to see that.

> - New projects must have 5 devs, a formal plan, and be approved by the
> council

To what end?  Just to make new projects harder to form?

There is rather a lot of argument about nascent projects - I'd rather
see such discussion happen when projects reach the stage that they have
something solid to add.

Support for dev and project overlays helps a lot, as it provides a
workspace for progressing projects without causing daily disruption to
the tree.

> - Devs can only belong to 5 projects at most

Why?  That achieves nothing.  The number of projects a dev belongs to
is down to the dev and the projects involved.

> - Drop all arches and Gentoo/Alt projects except Linux on amd64,
> ppc32/64, sparc, and x86

You are joking, aren't you?  If you're worried about keywording, the
critical arches are x86, ppc, amd64 - which is where you see most
comments about slowness of stabilisation.  The "minority" arches like
mips, sparc etc seem to get along quite happily.

> - Reduce the number of projects by eliminating the dead, weak,
> understaffed, and unnecessary projects

Dead: if you mean projects that no-one uses anymore and are no longer
developed, then fine, they're candidates for deletion.

Weak: Be more specific.  What are the "weak" projects, and why?

Understaffed: this issue manifests itself as a project being slow to
update.  However the only place this is an issue is for security issue
management.  Another solution to under-staffing is to reduce
expectations.

Unnecessary: again, be more specific. What are the "unnecessary"
projects, and why?

> - Project status reports once a month for every project

We've discussed this before.  Project status reports make sense if
they're going to be read.  Personally I think each project should
organise its own status reporting schedule.

--
Kevin F. Quinn

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Natanael Copa-3
In reply to this post by Brandon Low-2
Hi, everyone.

I'm not gentoo dev (yet), but I take the chance to vent an idea I have a
while, based on my personal experience in bugzilla.

On Wed, 2006-10-04 at 07:15 -0500, Brandon Low wrote:

> What if the problem is too many devs instead of too few?  Slackware
> Linux is a comparatively simple to maintain distribution, but ONE person
> does it.  How many devs are on Gentoo now?  200? more?  A close knit
> group of college students and bored professionals should be able to
> maintain this distribution.

I think the challenge is the amount of packages. One person could not
maintain all packages in gentoo.

What you didn't need to be a gentoo dev to be a package maintainer? Lets
say anyone could be marked as maintainer in an ebuild. When there is a
bug, the package maintainer fixes the bug and submits an updated
ebuild/patch whatever. This person has no commit access.

Then a "committer", a gentoo-dev (someone with little more experience),
just take a quick look at it and commit it.

This way fewer dev with commit access is needed, and more people from
community are able to offload the dev's.

This would also make the threshold lower for people to become a
maintainer.

Personally there are a few packages I could maintain, but I don't think
its worth becomming a developer to just maintain 1 single package.

I think this how the do with the freebsd ports tree. I am maintainer for
1 single freebsd port without being a committer.

--
Natanael Copa

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Thomas Cort
In reply to this post by Luca Longinotti
On 10/4/06, Luca Longinotti <[hidden email]> wrote:

> People come and go, I still see Gentoo going forward, packages still get
> updated, work gets done

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.

> > - Cut the number of packages in half (put the removed ebuilds in
> > community run overlays)
>
> 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 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.

> > - Formal approval process (or at least strict criteria) for adding
> > new packages
>
> Err what? So I, as a dev, that did quizzes, etc., cannot even anymore
> just add the package that has got my fancy atm, because there are some
> criteria to what is added and what not, and I have to go through a
> bureaucratic process just for that? Never!
> If for strict criteria you mean "there must be at least a dev or herd
> maintaining it", or such stuff, they already exist, they may just need
> some more enforcing... ;)

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.

> > - 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... Let's face it: most devs are mainly
> interested in their stuff, getting their stuff keyworded, and many
> wouldn't anyway have the time to efficiently work on an arch-team, as
> members of such I mean, not just as "I'm a member, so I keyword my
> stuff, that's it"... For that I agree with the current practice: if you
> want that, ask the arch-team first. ;)

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.

> > - Double the number of developers with aggressive recruiting
>
> That's something that goes on since... forever! Gentoo's continuously
> recruiting new people, more aggressive recruiting has already been
> proposed many times, but it was always agreed to try to maintain a
> relatively high standard of new recruits, and if you want quality,
> finding loads of people who "just happen" to have the time and
> dedication to become a Gentoo dev isn't that easy.

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 [hidden email] and
only one person offered. The person who offered fell through because
he didn't have enough free time.

> > - No competing projects
>
> Kills innovation... Who comes first has total monopoly of that branch of
> things basically... I'd never agree to something like this, personally.

What happened to working together? Should we work together instead of
competing against each other?

> > - 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).

> > - 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
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Thomas Cort
In reply to this post by Brandon Low-2
On 10/4/06, Brandon Low <[hidden email]> wrote:

> What if the problem is too many devs instead of too few?  Slackware
> Linux is a comparatively simple to maintain distribution, but ONE person
> does it.  How many devs are on Gentoo now?  200? more?  A close knit
> group of college students and bored professionals should be able to
> maintain this distribution.

Slackware != Gentoo

On Gentoo we have to provide support for each possible combination of
USE flags, CFLAGS, and compiler versions on 32-bit and 64-bit systems,
on little endian and big endian systems, and with mix of stable and
testing packages. Slackware just has to get things to compile and work
once.

-Tom
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Ciaran McCreesh-3
In reply to this post by Kevin F. Quinn (Gentoo)
On Wed, 4 Oct 2006 15:02:17 +0200 "Kevin F. Quinn"
<[hidden email]> wrote:
| Yuck.  Devs should be free to add whatever packages they like,
| provided they're willing to maintain them.

There're already some restrictions:

http://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs-in-the-tree?

Perhaps they should be enforced...

--
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Thomas Cort
In reply to this post by Kevin F. Quinn (Gentoo)
>  The "minority" arches like mips, sparc etc seem to get along quite happily.

Not the "minority" arches like m68k, s390, alpha, ...

> > - Reduce the number of projects by eliminating the dead, weak,
> > understaffed, and unnecessary projects
>
> Weak: Be more specific.  What are the "weak" projects, and why?

Projects that don't achieve anything, have no goals, and don't show
any promise of doing anything productive.

> Understaffed: this issue manifests itself as a project being slow to
> update.  However the only place this is an issue is for security issue
> management.  Another solution to under-staffing is to reduce
> expectations.

The more we reduce expectations, the more it will hurt users. We
should be raising expectations and following through.

> Unnecessary: again, be more specific. What are the "unnecessary"
> projects, and why?

Projects that aren't needed to further Gentoo and are not helpful to
users or developers.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Diego Elio Pettenò-3
In reply to this post by Thomas Cort
Okay, I didn't want to answer anymore to this thread because I really find it
suited for April 1st, not October 4th, but seems like I cannot...

On Wednesday 04 October 2006 15:10, Thomas Cort wrote:
> 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.
And one of the main thing that new users like of Gentoo when compared to
Debian, Ubuntu and Fedora is that you have almost everything available out of
the box.
Not counting that a good deal of the packages in the tree does not really
require much maintainership.

> 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.
Let's see, about 400 packages are handled by KDE herd. Not sure how many are
currently handled by X11 herd after modular Xorg was addded, at least 20
packages are handled by BSD herd, and I think I maintain directly about 40
packages; we have about 30 kernel sources packages, and a uncounted number of
minor or micro packages.
I think my stuff is pretty well maintained, too. The problem is not the
quantity, the problem is the coverage.

> 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.
Cut the crap, if you allow me. I have four systems: AMD64, PowerPC and two
i386 (FreeBSD) boxes. I run ~amd64 and ~ppc, I cannot stable anything for
those two, and I don't want to waste time in a stable overlay.
I've resigned from AMD64 team for that reason, too.

> Even when someone is found it is hard for them to find mentors. We
> need to improve this.
Well, happens to me that I always found enough mentors to do the job.. even if
it required to wait some weeks.

> What happened to working together? Should we work together instead of
> competing against each other?
Competing does not mean "try to kill the other", means "try to do a similar
thing in a different way", that is something that we are already doing by
being a (mostly) Linux distribution...
Why don't you go help Ubuntu, if you think that competing is bad?

> 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).
Yeah and as others said, x86 and AMD64 are way more of a bottleneck than
Alpha, Sparc or PPC64 .....
I've asked two days ago a re-keywording of libao and libao-pulse. ~amd64 and
~x86-fbsd keywords are mine; the only keyword added after those was ~ppc64 up
to now.
If I look through the PulseAudio packages, x86 is missing everywhere, even if
users asked for keywording. Sure, killing Gentoo/FreeBSD will improve x86
support, yeah sure, keep on tryin'.

--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Diego Elio Pettenò-3
In reply to this post by Thomas Cort
On Wednesday 04 October 2006 15:14, Thomas Cort wrote:
> On Gentoo we have to provide support for each possible combination of
> USE flags, CFLAGS, and compiler versions on 32-bit and 64-bit systems,
> on little endian and big endian systems, and with mix of stable and
> testing packages. Slackware just has to get things to compile and work
> once.
No. You don't support each possible combination of CFLAGS, nor of compiler
versions. Arch teams takes care of arch differences.
Sorry, but I think I cope well enough on xine-lib (which is a kinda strange
package with many arch differences), and I don't really spend much time on
the ebuild (or Gentoo maintenance) anymore for it, after cleaning it up one
time. It required time but it was feasible, or I wouldn't be able to do it.

--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo World Domination. a 10 step guide

Simon Stelling
In reply to this post by Thomas Cort
Thomas Cort 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.

Take a closer look at the statistics. The numbers seem drastic, but once
you've seen the queries behind them you know how to interprete them and
things don't look that bad anymore.

>> > - 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... Let's face it: most devs are mainly
>> interested in their stuff, getting their stuff keyworded, and many
>> wouldn't anyway have the time to efficiently work on an arch-team, as
>> members of such I mean, not just as "I'm a member, so I keyword my
>> stuff, that's it"... For that I agree with the current practice: if you
>> want that, ask the arch-team first. ;)
>
> 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.

We had this model already, the x86 arch team did not always exist. We
could revert to the old one, would be less bureaucratic. Would also take
quite some load off the arch teams. Would also result in worse overall
quality of the tree. *shrug*

>> > - Double the number of developers with aggressive recruiting
>>
>> That's something that goes on since... forever! Gentoo's continuously
>> recruiting new people, more aggressive recruiting has already been
>> proposed many times, but it was always agreed to try to maintain a
>> relatively high standard of new recruits, and if you want quality,
>> finding loads of people who "just happen" to have the time and
>> dedication to become a Gentoo dev isn't that easy.
>
> 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 [hidden email] and
> only one person offered. The person who offered fell through because
> he didn't have enough free time.
>
>> > - No competing projects
>>
>> Kills innovation... Who comes first has total monopoly of that branch of
>> things basically... I'd never agree to something like this, personally.
>
> What happened to working together? Should we work together instead of
> competing against each other?

Sometimes you want to achieve the same goal by totally different means.
Sometimes there are good reasons for a complete new start. It does not
even mean you don't communicate anymore. Brian Harring, although working
on pkgcore which basically competes portage, communicates a lot with the
portage team and vice versa, in a very productive manner. Nevertheless,
you won't find anybody on the portage or pkgcore team saying that it
would have been better to incorporate the ideas of pkgcore into portage.
Sometimes it's simply better to start all over again.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
[hidden email] mailing list

1234 ... 6