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

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

[Thomas Cort]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

On Wednesday 04 October 2006 07:21, Diego 'Flameeyes' Pettenò wrote:
> 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.

too bad sparc is tied to old kernels and ppc64 toolchain is useless
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

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

[Jason Wever]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

On Wed, 4 Oct 2006 09:46:31 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> too bad sparc is tied to old kernels and ppc64 toolchain is useless

Depends on your sparc64 box.  Most of them are fairly stable now.  Its
just the SBUS boxes and some of the pricier hardware that may be
problematic.

Cheers,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Luca Barbato]

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

-- 
gentoo-dev@gentoo.org mailing list

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

[Christian Heim]

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
-- 
gentoo-dev@gentoo.org mailing list

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

[Simon Stelling]

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
-- 
gentoo-dev@gentoo.org mailing list

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

[Brandon Low]

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
> -- 
> gentoo-dev@gentoo.org mailing list
> 
-- 
gentoo-dev@gentoo.org mailing list

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

[Natanael Copa]

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

-- 
gentoo-dev@gentoo.org mailing list

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

[Steve Long]

Natanael Copa wrote:
> 
> 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.
> 
That makes a lot of sense, to me at least.

> Then a "committer", a gentoo-dev (someone with little more experience),
> just take a quick look at it and commit it.
> 
Which would be similar to a proxy-dev, I guess, but if you're drawing people
into helping maintain ebuilds that could only be a good thing. It'd be
easier to run as well. (Maybe some scripts to check eg rm -fR / stuff.)

> 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.
> 
FWIW I think it's a good idea.

-- 
gentoo-dev@gentoo.org mailing list

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

On Wed, 04 Oct 2006 15:09:06 +0200
Natanael Copa <natanael.copa@gmail.com> wrote:

> 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 already happens on some packages (in particular where the upstream
author is happy to maintain the Gentoo ebuild).  One very important
thing is for the Gentoo "proxy" dev to be listed in metadata.xml (as
well as the non-Gentoo maintainer).

The Gentoo dev takes formal responsibility for any commits.  The trick
is to find a Gentoo dev who is prepared to proxy for you; that involves
a trust relationship between the dev and the maintainer.  The amount of
work the dev has to do depends on how well the maintainer follows the
Gentoo ebuild rules.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Thomas Cort]

On 10/4/06, Brandon Low <lostlogic@gentoo.org> 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
-- 
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Wed, 2006-10-04 at 07:15 -0500, Brandon Low wrote:
> 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?

This is definitely something that we've lost.  Major bugs sit waiting
for the maintainer to fix them, when really, anyone who spots the bug
should be free to fix it, so long as they inform the maintainer.  Yes,
commenting to the effect of "I fixed this by doing $blah" on a bug
report *is* informing the maintainer.

> 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 really want to see another checking of the CVS logs (without names, of
course) to see just how much work how many developers do.  I'd be
interested to know if it really is a very few doing most of the work.  I
would venture to say that it is, and CIA stats seem to agree.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Bryan Østergaard]

On Wed, Oct 04, 2006 at 10:36:37AM -0400, Chris Gianelloni wrote:
> 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 really want to see another checking of the CVS logs (without names, of
> course) to see just how much work how many developers do.  I'd be
> interested to know if it really is a very few doing most of the work.  I
> would venture to say that it is, and CIA stats seem to agree.
I've just blogged about this including a fancy graph of commit activity
versus devs. See http://kloeri.livejournal.com for the glory details or
wait for it to show up on http://planet.gentoo.org.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

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

[Duncan]

Bryan Østergaard <kloeri@gentoo.org> posted
20061004225352.GY12566@woodpecker.gentoo.org, excerpted below, on  Wed, 04
Oct 2006 22:53:52 +0000:

> On Wed, Oct 04, 2006 at 10:36:37AM -0400, Chris Gianelloni wrote:
>> 
>> I really want to see another checking of the CVS logs (without names, of
>> course) to see just how much work how many developers do.  I'd be
>> interested to know if it really is a very few doing most of the work.  I
>> would venture to say that it is, and CIA stats seem to agree.

> I've just blogged about this including a fancy graph of commit activity
> versus devs. See http://kloeri.livejournal.com for the glory details or
> wait for it to show up on http://planet.gentoo.org.

Good example of the currently popular "long tail" concept.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

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

[Wernfried Haas]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Wed, Oct 04, 2006 at 07:15:16AM -0500, Brandon Low wrote:
> As usual, sweeping new policies or procedures WILL NOT FIX THINGS.

I fully agree to this.
While some of the ideas may be good, and some not, each of them should
be discussed seperately and eventually something good will come out of
it. A list of 10 big changes (some of them even affect our current
metastructure) is hardly something that will get clear yes/no support
from anyone.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Roy Bamford]

On 2006.10.04 13:15, Brandon Low wrote:
> As usual, sweeping new policies or procedures WILL NOT FIX THINGS.
> 
> 
[snip]
> --Brandon

Since I have been a Gentoo user, there have been two completely  
different management styles in use. When drobbins was around, he was  
like the MD and Gentoo was managed as if it were a single project.
Since that time, Gentoo has grown into a loose knit collection of  
smaller projects all doing their own thing. Higher level collaboration  
must be happening because releng relay on all the bits coming together  
but its not much in evidence.

There are two options for Gentoo. We can add some reporting and control  
to make Gentoo appear as a single cohesive project, the price for that  
is some bureaucracy. Or we can continue management by tribal warfare,  
as is evidenced by the flame fests on this list.

Both take about the same amount of effort from the participants.
What we lack to manage Gentoo as a single project is a proactive  
management body.

Regards,

Roy Bamford
(NeddySeagoon)

-- 
gentoo-dev@gentoo.org mailing list

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

[Thomas Cort]

On 10/4/06, Christian Heim <phreak@gentoo.org> 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.
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On Wed, 4 Oct 2006 07:00:14 -0400 Thomas Cort <tcort@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Thomas Cort]

On 10/4/06, Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> On Wed, 4 Oct 2006 07:00:14 -0400 Thomas Cort <tcort@gentoo.org> 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
-- 
gentoo-dev@gentoo.org mailing list

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

[Luca Longinotti]

[-- Attachment #1: Type: text/plain, Size: 5109 bytes --]

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: chtekk@longitekk.com
Gentoo Dev: chtekk@gentoo.org
SysCP Dev: chtekk@syscp.org
TILUG Supporter: chtekk@tilug.ch


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Thomas Cort]

On 10/4/06, Luca Longinotti <chtekk@gentoo.org> 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 sound@g.o 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
-- 
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 3317 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

Diego 'Flameeyes' Pettenò wrote:
> 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,

Around 300, by Josh and me. The number of packages is completely
irrelevant on its own, you need to combine it with the amount of work
per package to get anything that matters.

It would be more useful to figure out which packages are
"packager-intensive," because those are the big time sinks or the things
that require at least one full-time developer to maintain.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Simon Stelling]

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 sound@g.o 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
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]

On Wed, 2006-10-04 at 15:34 +0200, Simon Stelling wrote:
> > 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.

Right.

> Sometimes it's simply better to start all over again.

I completely agree here.  I do want to note, though, that Brian is
working on pkgcore outside of Gentoo, much like how Paludis is being
done.  Now, at some point in the future, we might all decide that
pkgcore (or paludis, or something else, entirely) would be a better
official package manager than portage.  So we switch.  I think this
model for "competing projects" works out quite well.  At the same time,
I dislike us having so much "competition" internally, as I think it
helps to foster some of the conflict and ill will that many of us have
towards each other.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Wednesday 04 October 2006 17:10, Chris Gianelloni wrote:
> At the same time,
> I dislike us having so much "competition" internally, as I think it
> helps to foster some of the conflict and ill will that many of us have
> towards each other.
It probably depends to which level of competition we're referring to.

Gentoo/FreeBSD can be considered as a competitor for Gentoo Linux, because we 
try to get the same result (an usable distribution) in a different way 
(different kernel and userland).

KDE is a competitor for GNOME, too, but there's space for both of them in 
Gentoo.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Luca Longinotti]

[-- Attachment #1: Type: text/plain, Size: 8100 bytes --]

Thomas Cort wrote:
> On 10/4/06, Luca Longinotti <chtekk@gentoo.org> 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@longitekk.com
Gentoo Dev: chtekk@gentoo.org
SysCP Dev: chtekk@syscp.org
TILUG Supporter: chtekk@tilug.ch


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo World Domination. *lol*

[Jeroen Roovers]

On Wed, 04 Oct 2006 15:44:24 +0200
Luca Longinotti <chtekk@gentoo.org> wrote:

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

Maybe we could all move toward a more productive use of this metaphor
of an actual tree.

Stuff lives in trees, birds nest there, leaves grow, twigs spring,
branches, er branch off, dead leaves fall to the ground, new leaves
bud, buds even bud, all kinds of stuff goes on throughout the life of a
tree, yet I have really never come across a tree that "stagnates". It
just isn't something that trees get up to. Maybe it's only when birds
start getting territorial about stuff (official maintainership through
metadata during longe leaves of absence, wanting to stop some kinds of
birds nesting, forbidding new suns to grow toward) that the tree starts
looking ugly and useless and perhaps might starve.

This tree is rooted in an openly available and usable plenty of soil. It
is this "software"'s use to the tree as well as the tree's use to the
software that keeps the tree alive, and there is an entire ecosystem
that revolves around keeping itself alive, with a vivid interest in
keeping even this tree. Us devs are perhaps the tiny ants that milk the
plant lice that live on the leaves of our tree. We may not always see
the whole of the tree and the height and breadth it reaches, seeing as
we are climbing the branches far from the furthest reaches of twigs and
roots , but we do continously work to clean up our tree and make it
more useful to at least ourselves, helping many others as we go along
to find their way among the many branches, and see better horizons.


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

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

[Christian 'Opfer' Faulhammer]

Tach Thomas,                                  0x2B859DE3 (PGP-PK-ID)

Thomas Cort schrieb:
> 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.

 As others already told: Most devs run ~arch and are surprised when arch  
testers spot problems on an entire stable system with a package going to  
be stabled.  I see that a lot when testing for x86, most of the time minor  
issues sometimes graver things.

V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/
-- 
gentoo-dev@gentoo.org mailing list

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

[Josh Saddler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian 'Opfer' Faulhammer wrote:
> Most devs run ~arch
Says who? Did you pull that fact out of a hat, or something? Do you have any
hard numbers to back that statement?

Let's have an informal poll some time: I know I don't run ~arch, and there are
many more devs who also run primarily stable systems.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD4DBQFFJRndrsJQqN81j74RApEAAJ0TYaDiye0YWgX7XgoWEllw0sW5bwCTBZnn
QupVOdDJr1bRcOGj4vATvw==
=L0gr
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Christian 'Opfer' Faulhammer]

Tach Josh,                                  0x2B859DE3 (PGP-PK-ID)

Josh Saddler schrieb:
> Christian 'Opfer' Faulhammer wrote:
>> Most devs run ~arch
> Says who? Did you pull that fact out of a hat, or something? Do you have
> any hard numbers to back that statement?

 "A lot of devs run ~arch" is more accurate.  Or at least their  
package.keywords is very big.

> Let's have an informal poll some time: I know I don't run ~arch, and
> there are many more devs who also run primarily stable systems.

 During testing I often hear "I don't run stable, so I need someone to  
test ebuild X for verification my bug fix worked"

V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

> > - Project status reports once a month for every project
> 
> Totally agree on this one!

OK.

I'll give you Release Engineering's "status reports" for September,
October, and November:

September: taking a well-deserved break
October: taking a well-deserved break
November: taking a well-deserved break

How about other projects that rely on things like upstream's release
cycle?  What about projects that just maintain ebuilds?

Here's the games team's "status reports" for every month:

"Fixed more bugs, added more packages, cleaned up some ebuilds."

Now, perhaps what everyone would like, instead, would be status reports
*where necessary* from certain projects?

In fact, the council has been discussing asking a few projects about the
status on some of their tasks.  The main reason for this is for
communications purposes.  Basically, we'd just get a "Hey, where are you
at on $x?" response from the teams.

I don't *want* to drown projects in bureaucracy and paperwork.  I want
them to *accomplish* things, instead.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Josh Saddler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Gianelloni wrote:
>>> - Project status reports once a month for every project
>> Totally agree on this one!
> 
> OK.
> 
> I'll give you Release Engineering's "status reports" for September,
> October, and November:
> 
> September: taking a well-deserved break
> October: taking a well-deserved break
> November: taking a well-deserved break
> 
> How about other projects that rely on things like upstream's release
> cycle?  What about projects that just maintain ebuilds?
> 
> Here's the games team's "status reports" for every month:
> 
> "Fixed more bugs, added more packages, cleaned up some ebuilds."
> 
> Now, perhaps what everyone would like, instead, would be status reports
> *where necessary* from certain projects?
> 
> In fact, the council has been discussing asking a few projects about the
> status on some of their tasks.  The main reason for this is for
> communications purposes.  Basically, we'd just get a "Hey, where are you
> at on $x?" response from the teams.
> 
> I don't *want* to drown projects in bureaucracy and paperwork.  I want
> them to *accomplish* things, instead.
> 
Hear, hear! ++
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFI8ZJrsJQqN81j74RAt5GAJ9UletQJrSllbOuk4WG1Ro+XEvlLQCfY9VE
bLWnmc2rJ6Z6Mx9dmvnEQ7I=
=JbqS
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Chris Gianelloni wrote:
> Now, perhaps what everyone would like, instead, would be status reports
> *where necessary* from certain projects?
> 
> In fact, the council has been discussing asking a few projects about the
> status on some of their tasks.  The main reason for this is for
> communications purposes.  Basically, we'd just get a "Hey, where are you
> at on $x?" response from the teams.
> 
> I don't *want* to drown projects in bureaucracy and paperwork.  I want
> them to *accomplish* things, instead.

I really like the concept of answering questions rather than giving
arbitrary reports. The problem is, sometimes nobody outside your project
knows the right questions to ask.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

Donnie Berkholz wrote:
> Chris Gianelloni wrote:
>> Now, perhaps what everyone would like, instead, would be status reports
>> *where necessary* from certain projects?
>>
>> In fact, the council has been discussing asking a few projects about the
>> status on some of their tasks.  The main reason for this is for
>> communications purposes.  Basically, we'd just get a "Hey, where are you
>> at on $x?" response from the teams.
>>
>> I don't *want* to drown projects in bureaucracy and paperwork.  I want
>> them to *accomplish* things, instead.
> 
> I really like the concept of answering questions rather than giving
> arbitrary reports. The problem is, sometimes nobody outside your project
> knows the right questions to ask.

I was thinking more about this. What if, instead of these periodic
status reports, you just send out a note when something interesting
happens? There's no point in holding it back till your monthly required
report, and it saves the trouble of the report when nothing's happening.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]

On Wed, 2006-10-04 at 12:21 -0700, Donnie Berkholz wrote:
> Donnie Berkholz wrote:
> > Chris Gianelloni wrote:
> >> Now, perhaps what everyone would like, instead, would be status reports
> >> *where necessary* from certain projects?
> >>
> >> In fact, the council has been discussing asking a few projects about the
> >> status on some of their tasks.  The main reason for this is for
> >> communications purposes.  Basically, we'd just get a "Hey, where are you
> >> at on $x?" response from the teams.
> >>
> >> I don't *want* to drown projects in bureaucracy and paperwork.  I want
> >> them to *accomplish* things, instead.
> > 
> > I really like the concept of answering questions rather than giving
> > arbitrary reports. The problem is, sometimes nobody outside your project
> > knows the right questions to ask.
> 
> I was thinking more about this. What if, instead of these periodic
> status reports, you just send out a note when something interesting
> happens? There's no point in holding it back till your monthly required
> report, and it saves the trouble of the report when nothing's happening.

That's really a good idea.  When I was writing, I was thinking more
along the lines of things like:

What's the status of bugs getting updated?
What's the status of anonsvn/anoncvs?
What's the status of QA's policy document?

These are things that either are interesting to a large number of
developers, and easier to answer once rather than 300 times, or things
the council itself has asked a group to do based on one of our
decisions.  Of course, we could/would take ideas for things to ask, and
again, all we need really is something like this (mock) answer:

"Well, we have all the hardware in place and have gotten access to the
systems.  We've installed the OS and setup the main databases, but we're
still having some issues with the virtual IP scheme, and that's slowing
us down on getting this implemented."

That's it.  No long "report" or anything is necessary.  Just a simple,
short few sentences on the current status is all that's really needed
for the long ongoing projects.  For other things, like, xorg 7.1 going
stable or KDE 3.5.5 being unmasked, a simple announcement from the team
when it happens should really cover it.  That isn't even necessary from
most projects, as they simply do maintenance tasks which don't really
need an announcement.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Mike Pagano]

On 10/4/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> On Wed, 2006-10-04 at 12:21 -0700, Donnie Berkholz wrote:
> > Donnie Berkholz wrote:
> > > Chris Gianelloni wrote:
> > >> Now, perhaps what everyone would like, instead, would be status reports
> > >> *where necessary* from certain projects?
> > >>
> > >> In fact, the council has been discussing asking a few projects about the
> > >> status on some of their tasks.  The main reason for this is for
> > >> communications purposes.  Basically, we'd just get a "Hey, where are you
> > >> at on $x?" response from the teams.
> > >>
> > >> I don't *want* to drown projects in bureaucracy and paperwork.  I want
> > >> them to *accomplish* things, instead.
> > >
> > > I really like the concept of answering questions rather than giving
> > > arbitrary reports. The problem is, sometimes nobody outside your project
> > > knows the right questions to ask.
> >
> > I was thinking more about this. What if, instead of these periodic
> > status reports, you just send out a note when something interesting
> > happens? There's no point in holding it back till your monthly required
> > report, and it saves the trouble of the report when nothing's happening.
>
> That's really a good idea.  When I was writing, I was thinking more
> along the lines of things like:
>
> What's the status of bugs getting updated?
> What's the status of anonsvn/anoncvs?
> What's the status of QA's policy document?
>
> These are things that either are interesting to a large number of
> developers, and easier to answer once rather than 300 times, or things
> the council itself has asked a group to do based on one of our
> decisions.  Of course, we could/would take ideas for things to ask, and
> again, all we need really is something like this (mock) answer:
>
> "Well, we have all the hardware in place and have gotten access to the
> systems.  We've installed the OS and setup the main databases, but we're
> still having some issues with the virtual IP scheme, and that's slowing
> us down on getting this implemented."
>
> That's it.  No long "report" or anything is necessary.  Just a simple,
> short few sentences on the current status is all that's really needed
> for the long ongoing projects.  For other things, like, xorg 7.1 going
> stable or KDE 3.5.5 being unmasked, a simple announcement from the team
> when it happens should really cover it.  That isn't even necessary from
> most projects, as they simply do maintenance tasks which don't really
> need an announcement.
>
> --
> Chris Gianelloni
> Release Engineering Strategic Lead
> Alpha/AMD64/x86 Architecture Teams
> Games Developer/Council Member/Foundation Trustee
> Gentoo Foundation
>
>
>

How about something in the "planet" format that where each group
reporting status could do so at their schedule when they feel an
update is necessary or warrented.

Then users could just read the website for the latest status updates.

There are a few "hot" items many people are interested in such as kde
or gnome stablization, for example.  A simple line like "Don't expect
KDE 5.0 to go stable before the end of the year" provides transparency
and a bit of communication to the user community.
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

On Wed, 2006-10-04 at 17:43 -0400, Mike Pagano wrote:
> How about something in the "planet" format that where each group
> reporting status could do so at their schedule when they feel an
> update is necessary or warrented.
> 
> Then users could just read the website for the latest status updates.
> 
> There are a few "hot" items many people are interested in such as kde
> or gnome stablization, for example.  A simple line like "Don't expect
> KDE 5.0 to go stable before the end of the year" provides transparency
> and a bit of communication to the user community.

Again, there's nothing wrong with that, but that isn't so much the sort
of thing where the council is concerned.  I was speaking more of
long-term and short-term projects that directly affect the developers.
I'm seeking more to improve inter-project communication, rather than
developer-user communications.  It isn't that I don't think dev-user
communications are important, it is just that I don't see it as one of
Gentoo's "problems" currently.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Wernfried Haas]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Wed, Oct 04, 2006 at 10:27:17AM -0400, Chris Gianelloni wrote:
> Here's the games team's "status reports" for every month:
> 
> "Fixed more bugs, added more packages, cleaned up some ebuilds."

You forgot to mention the weekly team meeting including a motivational
speech. Shame on you!

Apart from that, i guess a lot of reports will look like that, so i
don't really see the point in making them, too.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Mike Kelly]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On Wed, 04 Oct 2006 10:27:17 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> > > - Project status reports once a month for every project
> > 
> > Totally agree on this one!
> 
> OK.
> 
> I'll give you Release Engineering's "status reports" for September,
> October, and November:
> 
> September: taking a well-deserved break
> October: taking a well-deserved break
> November: taking a well-deserved break

Well, in the past, I've found that even getting brief reports like that
is very helpful when I've been running meetings. It's just generally
good to know that folks are alive and such, and a brief "Hi, we're
still here" kinda report every month is nice for that. Just a quick
email before the meeting works fine. Also, it gets everyone in the
habit of giving reports, so that they remember to report when something
new happens.

> I don't *want* to drown projects in bureaucracy and paperwork.  I want
> them to *accomplish* things, instead.

Sending a brief "All's well with releng" email isn't exactly what I
would call "drowning in bureaucracy".

-- 
Mike Kelly

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Wed, 2006-10-04 at 22:00 -0400, Mike Kelly wrote:
> > I don't *want* to drown projects in bureaucracy and paperwork.  I want
> > them to *accomplish* things, instead.
> 
> Sending a brief "All's well with releng" email isn't exactly what I
> would call "drowning in bureaucracy".

Of course not, but that's where it starts.  Forcing projects to really
do anything on a regular set schedule that isn't internally set is
bureaucracy and pointless.  I don't *want* to have to spend my time
thinking about which projects I'm supposed to be sending status reports
on that haven't done anything.  I'd *much* rather spend my time actually
*developing* on the projects that *are* currently moving.

This is my *entire* point.  Forcing a project to send in worthless
little "we're still here" messages doesn't do anything.  Of *course*
they're still there.  They have a project page.  They have members.
They're doing commits.

Rather than wasting time trying to get everybody out giving each other
warm fuzzies, I'd prefer we focus on the areas where we truly need to
improve communications.  A couple good examples of projects/teams that
affect everyone are infrastructure and the trustees.  These are two good
places for status reports.  Things like the games team are not.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Luis Francisco Araujo]

Chris Gianelloni wrote:
>>> - Project status reports once a month for every project
>> Totally agree on this one!
> 
> OK.
> 
> I'll give you Release Engineering's "status reports" for September,
> October, and November:
> 
> September: taking a well-deserved break
> October: taking a well-deserved break
> November: taking a well-deserved break
> 
> How about other projects that rely on things like upstream's release
> cycle?  What about projects that just maintain ebuilds?
> 
> Here's the games team's "status reports" for every month:
> 
> "Fixed more bugs, added more packages, cleaned up some ebuilds."
> 
> Now, perhaps what everyone would like, instead, would be status reports
> *where necessary* from certain projects?
> 
> In fact, the council has been discussing asking a few projects about the
> status on some of their tasks.  The main reason for this is for
> communications purposes.  Basically, we'd just get a "Hey, where are you
> at on $x?" response from the teams.
> 
> I don't *want* to drown projects in bureaucracy and paperwork.  I want
> them to *accomplish* things, instead.
> 

I think the problem with reports is "how often would they be posted?" , 
and exactly "what kind of info would they contain?".

I propose the following:

To post a Gentoo Project report every six months, (yes, accompanying 
every Gentoo release, *be careful*, i am not saying you releng guys 
should take care of this).

This report would be like a way of ChangeLog for our Gentoo project, 
which could contain the following:

- Herds news: Each herd could write a 1-2 page report about the main 
changes they have done in these last 6 months. Including news about 
interesting packages added, new eclasses for sustaining the herd 
packages, any useful comment for the users of the herds, etc etc.

- Project news: This could include projects like releng, pr, userel. 
Which could post general news about the main things happening for these 
last 6 months too. For example, releng could post about some new 
techniques involved to release this new Gentoo release; which packages 
were more problematic for building it and why? , in other words, the 
kind of info our users (and devel too) would be interested on.

Now, this kind of report could be very very useful, both for users as 
for our developers. And making its release every 6 months, i think the 
time and what-to-comment problem shouldn't be a concern at all.

I already can hear some of you saying "No, i don't want to write 
anything for X  or Y!" ; fine, just don't do it. Nobody would be forced 
to do it. This would be a paper for those herds/projects/developers 
willing to communicate their work during the past 6 months to our 
community, and which could become in a very informative source to give a 
general overview of what it is going on in Gentoo land.

"Fine , i won't write anything .. but .. mm .. Who would read this 
anyway?" , i hear this question too ... Sorry, i can't give you names of 
who are going to read this. But i think a big portion of our community 
would do it, if we post it on gentoo.org every 6 months surely someone 
would pick it and read it, don't doubt it. (myself included.)

"Ok .. mmm fine .. mm.. wait, this is the same than GWN, isnt this?"; no 
it isn't ; i don't see a common pattern of Herds/Projects reports 
(check, it is report, *not* news) released every week on GWN; and that's 
because, GWN is for general weekly news .. mmmm that is very evidently 
on its name indeed.

Suggestions and constructive criticisms are welcome.

Regards,


-- 


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


-- 
gentoo-dev@gentoo.org mailing list

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

[Roy Bamford]

On 2006.10.04 15:27, Chris Gianelloni wrote:

[snip]

> 
> I'll give you Release Engineering's "status reports" for September,
> October, and November:
> 
> September: taking a well-deserved break
> October: taking a well-deserved break
> November: taking a well-deserved break
> 
> How about other projects that rely on things like upstream's release
> cycle?  What about projects that just maintain ebuilds?
> 
> Here's the games team's "status reports" for every month:
> 
> "Fixed more bugs, added more packages, cleaned up some ebuilds."
> 
> Now, perhaps what everyone would like, instead, would be status
> reports
> *where necessary* from certain projects?
> 
> In fact, the council has been discussing asking a few projects about
> the
> status on some of their tasks.  The main reason for this is for
> communications purposes.  Basically, we'd just get a "Hey, where are
> you
> at on $x?" response from the teams.
> 
> I don't *want* to drown projects in bureaucracy and paperwork.  I want
> them to *accomplish* things, instead.
> 
> --
> Chris Gianelloni
> Release Engineering Strategic Lead
> Alpha/AMD64/x86 Architecture Teams
> Games Developer/Council Member/Foundation Trustee
> Gentoo Foundation
> 

Before you can have useful reports, you need a plan to report against.
Like a target date for 2007.0 and its contents. Such a plan depends on  
other projects delivering the contents in accordance with their own  
plans. Like real life, these plans will have external dependencies on  
$UPSTREAM, that Gentoo has little or no control over.

With progress reports against plans and updated plans, everyone can see  
whats happened, why some things haven't and what the fallback is, if  
one is required.

The old saw, "If you don't have a plan, then plan to fail" remains true  
for volunteer projects as well as funded ones.

The content and update rate of plans/reports can vary from project to  
project and it need not be onerous. Reporting can even be by exception,  
so to take your "well-deserved break" example, if it was in your plan,  
no report would be needed.

Regards,

Roy Bamford
(NeddySeagoon)


-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On Fri, 2006-10-06 at 10:24 +0100, Roy Bamford wrote:
> Before you can have useful reports, you need a plan to report against.
> Like a target date for 2007.0 and its contents. Such a plan depends on  
> other projects delivering the contents in accordance with their own  
> plans. Like real life, these plans will have external dependencies on  
> $UPSTREAM, that Gentoo has little or no control over.

Please stop assuming that Release Engineering has any control over what
goes on in the tree.  Not only do we not have any such control, we also
do not *want* any such control.

A release is a *snapshot* of the Gentoo repository at a given time.  We
don't "plan" its contents because we *know* that we cannot make any
guarantees.  There's no point in saying "we're going to have Gnome 2.18"
when we have zero control over it.  Instead, as time nears for our
planned snapshot date, we work with other teams to determine if they
have things that are *close* to that snapshot date.  For example, if we
plan on doing a snapshot on Monday, and KDE plans on making a new
version stable on Wednesday, we might hold off until Wednesday to
accommodate them, but we don't pressure anyone to try to meet some
arbitrary deadlines.  We might also adjust the snapshot itself (as we
did this release with Gnome).

I'll be honest, Release Engineering work is *very* stressful.  My
primary goal as the lead is to try to come up with ways to make working
on a release easier for the guys doing the work.  I don't see how doing
reporting improves their lives.  After all, we put out four "reports" a
year, two releases, and two meetings between the releases where we plan
the next release.  Anything more than that is wasteful.

;]

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

On Saturday 07 October 2006 01:26, Chris Gianelloni wrote:
> I'll be honest, Release Engineering work is *very* stressful.  My
> primary goal as the lead is to try to come up with ways to make working
> on a release easier for the guys doing the work.
If anyone had still any doubt about this, he can easily try to tweak a 
release :P
I've been doing releng-like work lately to build Gentoo/FreeBSD stages with 
catalyst and I have to say that releng is doing a heck of an hard job to 
produce the releases, and my requirements are waaay more open than their own 
(as Gentoo/FreeBSD is still highly experimental)...

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Stuart Herbert]

On 10/7/06, Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> wrote:
> If anyone had still any doubt about this, he can easily try to tweak a
> release :P
> I've been doing releng-like work lately to build Gentoo/FreeBSD stages with
> catalyst and I have to say that releng is doing a heck of an hard job to
> produce the releases, and my requirements are waaay more open than their own
> (as Gentoo/FreeBSD is still highly experimental)...

And if anyone's still not convinced, try remembering what it was like
before Chris started getting releng into some semblence of shape.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

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

[Roy Bamford]

On 2006.10.07 00:26, Chris Gianelloni wrote:
> On Fri, 2006-10-06 at 10:24 +0100, Roy Bamford wrote:
> > Before you can have useful reports, you need a plan to report  
> against.
> > Like a target date for 2007.0 and its contents. Such a plan depends
> on
> > other projects delivering the contents in accordance with their own
> 
> > plans. Like real life, these plans will have external dependencies
> on
> > $UPSTREAM, that Gentoo has little or no control over.
> 
> Please stop assuming that Release Engineering has any control over
> what goes on in the tree.  Not only do we not have any such control,  
> we also do not *want* any such control.
> 
[snip]

> I'll be honest, Release Engineering work is *very* stressful.  My
> primary goal as the lead is to try to come up with ways to make
> working on a release easier for the guys doing the work.  I don't see  
> how doing reporting improves their lives.  After all, we put out four  
> "reports" a year, two releases, and two meetings between the releases  
> where we plan the next release.  Anything more than that is wasteful.
> 
> ;]
> 
> --
> Chris Gianelloni
> Release Engineering Strategic Lead
> Alpha/AMD64/x86 Architecture Teams
> Games Developer/Council Member/Foundation Trustee
> Gentoo Foundation

Chris,

I understand you don't have any control over what goes on in the tree.  
In Gentoo, nobody outside of the individual projects does. My post was  
not intended as a crit of yourself or the Release Engineering team.
I replied in your part of the thread because Release Engineering are  
the obvious users of the mooted plans and reports.

As long as Gentoo is organised as an anarchy, which I have seen work  
well in other groups, then the status quo is fine. If Gentoo is to be  
organised as a single project, then some bureaucracy to oil the wheels  
is needed. In turn, that would mean setting up a management body of  
some sort (not Release Engineering) but that's a whole new thread. No  
replies to that here please.

Either organisation can work providing the contributors want it to make  
it work but there will always be some dissenters discussing change  
(change != improvement). That's a healthy sign in any group.

Regards,

Roy Bamford
(NeddySeagoon)



-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

On Sat, 2006-10-07 at 09:58 +0100, Roy Bamford wrote:
> I replied in your part of the thread because Release Engineering are  
> the obvious users of the mooted plans and reports.

That was kinda my point.  We aren't.  We really don't care what version
of Gnome/KDE/kernel get in the release.  We just care that whatever it
is, it works.  We work with the respective teams, but we leave it up to
them what we use.  It happens to work out quite well this way.  Reports
from teams such as Gnome and KDE would be more useful to users, I would
think, than to most developers.  Any developers that it would impact are
likely already in the know.

Again, the last thing that I want to do is enforce some arbitrary
reporting where it isn't necessary.  I do agree that it definitely is
necessary in some places, though.  It just isn't necessary ubiquitously.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ioannis Aslanidis]

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


-- 
gentoo-dev@gentoo.org mailing list

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

[Christian 'Opfer' Faulhammer]

Tach Ioannis,                                  0x2B859DE3 (PGP-PK-ID)

Ioannis Aslanidis schrieb:
>> - 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.

 That is a problem of the herd actually.  They should look out for a  
person (be it dev or recruit) who is willing to join an arch team for KDE  
and do the work.  Or place an active user as arch tester in the arch  
projects, which is very simple.
 Testers are needed and I try to support KDE even when using Gnome. To  
bring Gentoo forward, but you have seen the konqburn problems, so just  
having someone to keyword without proper testing does not help anyone.

V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/
-- 
gentoo-dev@gentoo.org mailing list

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 4152 bytes --]

On Wed, 4 Oct 2006 07:00:14 -0400
Thomas Cort <tcort@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On Wed, 4 Oct 2006 15:02:17 +0200 "Kevin F. Quinn"
<kevquinn@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Wed, 4 Oct 2006 14:18:54 +0100
Ciaran McCreesh <ciaranm@ciaranm.org> wrote:

> On Wed, 4 Oct 2006 15:02:17 +0200 "Kevin F. Quinn"
> <kevquinn@gentoo.org> 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...

Yes, I have no objections to there being rules about what can and
cannot be added to the tree, and the ones in your devmanual are
clearly sensible and should be applied.  I do however object to the
suggestion that adding a package to the tree be subject to formal
approval (by whom, for a start...).

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Thomas Cort]

>  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.
-- 
gentoo-dev@gentoo.org mailing list

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On Wed, 4 Oct 2006 09:21:08 -0400
"Thomas Cort" <linuxgeek@gmail.com> wrote:

> >  The "minority" arches like mips, sparc etc seem to get along quite
> > happily.
> 
> Not the "minority" arches like m68k, s390, alpha, ...

I haven't seen any significant numbers of complaints. What exactly
about those arches do you think is a problem?

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

By "specific" I meant which projects exactly - i.e name some, and
explain how the weakness you perceive is a problem.

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

You should only raise expectations when you know you can follow through,
not the other way around.  Raising expectations before being able to
follow through leads to disappointment, which is bad.

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

Again, by "specific" I meant which projects, by name, do you think meet
those criteria.  Explain why you consider those projects to be a
hindrance to users or developers.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Thomas Cort]

On 10/4/06, Kevin F. Quinn <kevquinn@gentoo.org> wrote:
> On Wed, 4 Oct 2006 09:21:08 -0400
> "Thomas Cort" <linuxgeek@gmail.com> wrote:
>
> > >  The "minority" arches like mips, sparc etc seem to get along quite
> > > happily.
> >
> > Not the "minority" arches like m68k, s390, alpha, ...
>
> I haven't seen any significant numbers of complaints. What exactly
> about those arches do you think is a problem?

The speed at which bugs are resolved is the problem. Keywording/stable
bugs can sit for months and sometimes over a year without being
touched. Some people think the amount of time some arches lag behind
is acceptable, I don't. The primary reason why arches lag is that we
don't have enough people doing the testing and keywording.

> You should only raise expectations when you know you can follow through,
> not the other way around.  Raising expectations before being able to
> follow through leads to disappointment, which is bad.

I think that if we implement my suggestions (drastically reducing the
workload), we will be able to meet those expectations.
-- 
gentoo-dev@gentoo.org mailing list

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

On Wed, 4 Oct 2006 11:39:07 -0400
"Thomas Cort" <linuxgeek@gmail.com> wrote:

> On 10/4/06, Kevin F. Quinn <kevquinn@gentoo.org> wrote:
> > On Wed, 4 Oct 2006 09:21:08 -0400
> > "Thomas Cort" <linuxgeek@gmail.com> wrote:
> >
> > > >  The "minority" arches like mips, sparc etc seem to get along
> > > > quite happily.
> > >
> > > Not the "minority" arches like m68k, s390, alpha, ...
> >
> > I haven't seen any significant numbers of complaints. What exactly
> > about those arches do you think is a problem?
> 
> The speed at which bugs are resolved is the problem. Keywording/stable
> bugs can sit for months and sometimes over a year without being
> touched.

So?  Who is complaining?  Open stabilisation bugs are a concern for the
relevant arches, not for everyone. Once an arch has actioned a
stabilisation bug, they remove themselves from CC, after which they
don't care.

> Some people think the amount of time some arches lag behind
> is acceptable, I don't. The primary reason why arches lag is that we
> don't have enough people doing the testing and keywording.
> 
> > You should only raise expectations when you know you can follow
> > through, not the other way around.  Raising expectations before
> > being able to follow through leads to disappointment, which is bad.
> 
> I think that if we implement my suggestions (drastically reducing the
> workload), we will be able to meet those expectations.

All that will happen if you ditch the minority arches, is that the devs
involved will take their work into overlay or possibly leave Gentoo
altogether.  It won't improve anything for other arches.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

Thomas Cort wrote:
>> 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.

Since Gentoo doesn't have any global goals, it's impossible to tell
what's furthering them and what isn't.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 3873 bytes --]

On Wed, 2006-10-04 at 07:00 -0400, 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)

I'm not sure that this really would solve much of anything.  I do agree
that putting removed ebuilds in community-run overlays isn't a bad idea,
but reducing the number of packages for the sake of reducing does
nothing more than decrease the usefulness of Gentoo to many people.

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

This sounds like too much overhead.

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

Absolutely not.  The last thing that we need from a QA standpoint is
having every single developer allowed "free reign" for marking their own
packages stable, then completely ignoring bugs for any packages that are
not their own.

> - Double the number of developers with aggressive recruiting

Why do people think that this is a good idea?  I have a different one.
How about we *half* the number of developers, keeping the people who do
the most work, and let everyone else contribute as members of the
community?  Having developers on projects/teams/herds/whatever that do
only a few commits a year doesn't do anything but artificially inflate
our numbers.

> - No competing projects

I wouldn't mind this.  The idea of competing *official* projects seems
rather ludicrous.  Of course, to counter this, we would need some way to
create "semi-official" projects.  Projects that are supported within
themselves but not by "Gentoo" as a whole.  This would allow for
multiple teams to create projects that competed, but then let time and
actual usage decide which (if any) becomes official.

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

I only agree to the second of these three points.  Projects should have
a plan.  The council definitely should not be a bottleneck in starting
new projects, unless someone was going to start paying us so we can meet
all the time to make all these decisions.  ;]

> - Devs can only belong to 5 projects at most

This is a really bad idea.  Some developers simply work
harder/faster/more than others.  Setting up some artificial limitation
on how many projects one can belong to won't help.  Perhaps a better
solution here is that all developers must belong to at least one
project?  Coupled with this would be that there would be certain
expectations within the project for work completed.  Developers who do
not meet the "quota" are removed from the project.  Get removed from all
your projects and get retired.  Simple as that.

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

Quite honesty, Gentoo/BSD (for example) has been excellent in finding
issues with quality on many packages/ebuilds.  The same can be said for
many of the architectures.  Also, remember that there's a difference
between our supported architectures/projects and our unsupported ones.

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

This would be highly subjective.  Who would do this?

> - Project status reports once a month for every project

To whom?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Thomas Cort]

> > - Double the number of developers with aggressive recruiting
>
> Why do people think that this is a good idea?  I have a different one.
> How about we *half* the number of developers, keeping the people who do
> the most work, and let everyone else contribute as members of the
> community?  Having developers on projects/teams/herds/whatever that do
> only a few commits a year doesn't do anything but artificially inflate
> our numbers.

Even if someone only does a little bit of work (maintaining a package
or two and only doing one or two commits per month), it is better than
none. Does having active accounts for these people produce very much
extra work for infra or anyone else? I only see it as a benefit to
users (things get done faster) and developers (one less bug to fix).
The only problem I have with low activity developers is when they
don't commit fixes for bugs that are assigned to them in a timely
manner.

> > - Devs can only belong to 5 projects at most
>
> This is a really bad idea.  Some developers simply work
> harder/faster/more than others.  Setting up some artificial limitation
> on how many projects one can belong to won't help.  Perhaps a better
> solution here is that all developers must belong to at least one
> project?  Coupled with this would be that there would be certain
> expectations within the project for work completed.  Developers who do
> not meet the "quota" are removed from the project.  Get removed from all
> your projects and get retired.  Simple as that.

I really like your idea.
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

On Wed, 2006-10-04 at 10:38 -0400, Thomas Cort wrote:
> > > - Double the number of developers with aggressive recruiting
> >
> > Why do people think that this is a good idea?  I have a different one.
> > How about we *half* the number of developers, keeping the people who do
> > the most work, and let everyone else contribute as members of the
> > community?  Having developers on projects/teams/herds/whatever that do
> > only a few commits a year doesn't do anything but artificially inflate
> > our numbers.
> 
> Even if someone only does a little bit of work (maintaining a package
> or two and only doing one or two commits per month), it is better than
> none. Does having active accounts for these people produce very much
> extra work for infra or anyone else? I only see it as a benefit to
> users (things get done faster) and developers (one less bug to fix).
> The only problem I have with low activity developers is when they
> don't commit fixes for bugs that are assigned to them in a timely
> manner.

Basically, the person doing one or two commits a month *do not* need CVS
access.  They can still *contribute* at their current pace without
having CVS access and a nice @gentoo.org email address.  All they need
is for someone to commit for them, just like every other person who
contributes by adding ebuilds/patches/etc to bugzilla.

I saw bring in people that *want* to work harder and let the ones that
don't contribute like any other user.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Caleb Tennis]

> Basically, the person doing one or two commits a month *do not* need CVS
> access.  They can still *contribute* at their current pace without
> having CVS access and a nice @gentoo.org email address.

Sorry, but as a dev who has lurked in the shadows for a long time, this
simply isn't globally true.  Sometimes there are packages which the dev
takes over that nobody else who is a developer wants or has time to work
on.  This happened to me when all of a sudden nobody was on the ruby herd
anymore.  All of my requests went unanswered.  So I simply took it over.

I really appreciate the handful of devs who do the most commits, but why
would you want to add even more to their plates by removing a bunch of the
developers who handle smaller stuff.  I simply don't have the time anymore
to be as active as I used to be years ago.  But I still do contribute as
much as I can: I keep Qt, Ruby, Ice, and some KDE packages updated.  If
you want to take away my CVS access because I'm not a power committer
anymore it won't hurt my feelings, but I can't imagine how it helps Gentoo
in any way.

I'll offer a counter proposal: I don't play games on the computer, and
they're definitely not required for a working Linux distribution, so I
think we should just get rid of all games packages.  Let's focus our
efforts more on the necessities.

My point is that as long as it's of sufficient quality, it's silly not to
accept the gratis work that someone's willing to do, be it in putting
games into the distribution or making a small number of commits to keep a
certain subset of packages up to date.

Caleb

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]

On Wed, 2006-10-04 at 13:20 -0400, Caleb Tennis wrote:
> > Basically, the person doing one or two commits a month *do not* need CVS
> > access.  They can still *contribute* at their current pace without
> > having CVS access and a nice @gentoo.org email address.
> 
> Sorry, but as a dev who has lurked in the shadows for a long time, this
> simply isn't globally true.  Sometimes there are packages which the dev
> takes over that nobody else who is a developer wants or has time to work
> on.  This happened to me when all of a sudden nobody was on the ruby herd
> anymore.  All of my requests went unanswered.  So I simply took it over.

Looking at CIA, you're nowhere near the target of my comment.  I am
talking about the people that disappear for months on end, then suddenly
come back for a commit or two to keep from being retired.  People who
ignore their bugs also fit into this category.

> I'll offer a counter proposal: I don't play games on the computer, and
> they're definitely not required for a working Linux distribution, so I
> think we should just get rid of all games packages.  Let's focus our
> efforts more on the necessities.

I'll be honest.  I don't care.

A counter proposal such as this is pretty much given entirely to provoke
an emotional response, which I'm simply not going to do.

> My point is that as long as it's of sufficient quality, it's silly not to
> accept the gratis work that someone's willing to do, be it in putting
> games into the distribution or making a small number of commits to keep a
> certain subset of packages up to date.

Nobody is saying that we shouldn't accept work from people.  However,
there's a difference between accepting one's work and giving them the
keys to the castle.  Many people also seem to think that someone has to
be a developer to do good work.  This is absolutely untrue.  After all,
where do all of our recruits come from?

With the increase in developer and project overlays, I see the
possibility for reducing work needed to maintain many packages.  As
Natanael Copa, it would be nice for him to be able to maintain packages
without having CVS access.  The idea of formalizing and promoting "proxy
developers" has come up a few times before, and I think it is a great
idea.  Work is done in the overlays, tested, improved, then committed
into the main tree once the kinks have been worked out.  We get a
stronger core tree with fewer "developers" and a better interaction with
the community.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Stuart Herbert]

On 10/4/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> Work is done in the overlays, tested, improved, then committed
> into the main tree once the kinks have been worked out.  We get a
> stronger core tree with fewer "developers" and a better interaction with
> the community.

And a Gentoo that's so deeply loved by those who enact this plan that
they've strangled it with their love.

Ugh.  No thanks.

Gentoo's not just a project, it's a community.  Those of us who work
within it have a moral duty to preserve it, and all the opportunities
it offers people, for the developers who will come after us.  It is
_not_ for us to steal those opportunities from future generations.

Gentoo isn't ours.  We just hold it in trust for the moment.

Best regards,
Stu
--
-- 
gentoo-dev@gentoo.org mailing list

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

[Duncan Coutts]

On Wed, 2006-10-04 at 17:13 -0400, Chris Gianelloni wrote:

> With the increase in developer and project overlays, I see the
> possibility for reducing work needed to maintain many packages.  As
> Natanael Copa, it would be nice for him to be able to maintain packages
> without having CVS access.  The idea of formalizing and promoting "proxy
> developers" has come up a few times before, and I think it is a great
> idea.  Work is done in the overlays, tested, improved, then committed
> into the main tree once the kinks have been worked out.  We get a
> stronger core tree with fewer "developers" and a better interaction with
> the community.

Some projects/herds already work this way with good results. We
regularly get contributions from users that go into our overlay, get
tested by us and other users and then get into the main portage tree
some time later.

We have a very low barrier to entry, it's just darcs record; darcs send.
Then one of the devs reviews and applies/rejects the patch. Easy.

For some of our ebuilds we already have de-facto "proxy developers".

-- 
Duncan Coutts : Gentoo Developer (Haskell team lead)
email         : dcoutts at gentoo dot org

-- 
gentoo-dev@gentoo.org mailing list

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

[Natanael Copa]

On Thu, 2006-10-05 at 00:00 +0100, Duncan Coutts wrote:
> On Wed, 2006-10-04 at 17:13 -0400, Chris Gianelloni wrote:
> 
> > With the increase in developer and project overlays, I see the
> > possibility for reducing work needed to maintain many packages.  As
> > Natanael Copa, it would be nice for him to be able to maintain packages
> > without having CVS access.  The idea of formalizing and promoting "proxy
> > developers" has come up a few times before, and I think it is a great
> > idea.  Work is done in the overlays, tested, improved, then committed
> > into the main tree once the kinks have been worked out.  We get a
> > stronger core tree with fewer "developers" and a better interaction with
> > the community.
> 
> Some projects/herds already work this way with good results. We
> regularly get contributions from users that go into our overlay, get
> tested by us and other users and then get into the main portage tree
> some time later.
> 
> We have a very low barrier to entry, it's just darcs record; darcs send.
> Then one of the devs reviews and applies/rejects the patch. Easy.

If the "proxy maintainer" is specified as contact person in the ebuild,
and will be added to the CC list on bugs posted, the official developer
will not need to care about it until he gets a response from the proxy
developer.

> For some of our ebuilds we already have de-facto "proxy developers".

If it would be possible to become a proxy developer, I'd be maintainer
for several packages. Its not the first time I'm offering that:
https://bugs.gentoo.org/show_bug.cgi?id=76213#c2

Nobody has ever showed interest and I'm not pushing my services on
anyone.

But I'd like to do official portage and not any overlay. I have
submitted ebuilds to bugzilla that ended up in an overlay somehwere (bug
got closed) and has dissapeared for ever. I can't post bugs about
overlays in bugzilla, (I suppose) so no updated ebuild have been
submitted and I ended up just running my own local overlay.

--
Natanael Copa

-- 
gentoo-dev@gentoo.org mailing list

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

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

Natanael Copa wrote:
> Nobody has ever showed interest and I'm not pushing my services on
> anyone.
>   
Why exactly you don't want to become a Gentoo dev? The whole "proxy
maintainer" thing is a bunch of crap. The Gentoo developer will still be
expected to be responsible of his/her commits, which means 2 maintainers
will spend (approximately) same amount of time testing it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Proxy maintainers (was: Gentoo World Domination. a 10 step guide)

[Natanael Copa]

On Thu, 2006-10-05 at 09:52 +0300, Alin Nastac wrote:
> Natanael Copa wrote:
> > Nobody has ever showed interest and I'm not pushing my services on
> > anyone.
> >   
> Why exactly you don't want to become a Gentoo dev? 

Because of the byrocracy? Is it worth it to only maintain one single
package?

Because of gentoo devs always seems to fight?

> The whole "proxy maintainer" thing is a bunch of crap.

Thanks.

Seems to work just fine in freebsd ports.

> The Gentoo developer will still be
> expected to be responsible of his/her commits, which means 2 maintainers
> will spend (approximately) same amount of time testing it.

The Gentoo developer would have the final reposability, so yes, he/she
might need to test it. But if it doesn't work the Gentoo developer sends
an email to the (proxy) maintainer: "It doesn't work. Please fix or I
won't commit" or: "The code is too ugly. Please improve or I won't
commit".

The Gentoo dev can establish a relationship with the maintainer so after
a while he/she knows the (proxy) maintainer is trustable and can commit
after just a look. This in contrast to dealing with thousands unknown
bug reporters.

If the (proxy) maintainer doesn't answer, the gentoo dev can either fix
it himself/herself or find an new maintainer - which I believe is easier
than requiting a new dev, since it does not *feel* like as much
responsability, even if it is.

Its funny, I use gentoo much more that FreeBSD, I'm a freebsd port
maintainer, but nothing for Gentoo (well, im an active bugreporter...)

When I submit a fix/version bumb (I submit as "maintainer update") to
freebsd ports, its normally committed within hours, even if its not a
popular port. When I submit fixes for packages in Gentoo bugzilla it get
stuck for months. They must have done something right.

--
Natanael Copa

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Proxy maintainers (was: Gentoo World Domination. a 10 step guide)

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On Thursday 05 October 2006 10:06, Natanael Copa wrote:
> When I submit a fix/version bumb (I submit as "maintainer update") to
> freebsd ports, its normally committed within hours, even if its not a
> popular port. When I submit fixes for packages in Gentoo bugzilla it get
> stuck for months. They must have done something right.
I keep from stating my uncensored opinion about a good part of FreeBSD ports, 
and just say that their patch policy, as well as the one of pkgsrc that is 
another comparable system, is totally different from ours, and does not 
consider upstream presence.

And I suppose I can say that with quite enough information at hand, 
considering that I deal with ports every time a package fails to build on 
G/FBSD .. the problem is most of the times I cannot make use of the patches 
used by ports because they are, if not broken, sub-optimal.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Proxy maintainers (was: Gentoo World Domination. a 10 step guide)

[Natanael Copa]

On Thu, 2006-10-05 at 10:18 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 05 October 2006 10:06, Natanael Copa wrote:
> > When I submit a fix/version bumb (I submit as "maintainer update") to
> > freebsd ports, its normally committed within hours, even if its not a
> > popular port. 
...
> And I suppose I can say that with quite enough information at hand, 
> considering that I deal with ports every time a package fails to build on 
> G/FBSD .. the problem is most of the times I cannot make use of the patches 
> used by ports because they are, if not broken, sub-optimal.

I buy that one.

Can I become a Gentoo dev, even if I'm only maintainer of 1-3 packages?
I'm trying to be realistic.

--
Natanael Copa

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Proxy maintainers

[Christian 'Opfer' Faulhammer]

Tach Natanael,                                  0x2B859DE3 (PGP-PK-ID)

Natanael Copa schrieb:
> Can I become a Gentoo dev, even if I'm only maintainer of 1-3 packages?
> I'm trying to be realistic.

 You can.  And you can even keep out of dev fights here on the mailing  
list.  On IRC you normally have a good working atmosphere, I always found  
a person who could do what was needed and they get testing back.



V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Proxy maintainers

[Natanael Copa]

On Thu, 2006-10-05 at 00:00 +0000, Christian 'Opfer' Faulhammer wrote:
> Tach Natanael,                                  0x2B859DE3 (PGP-PK-ID)
> 
> Natanael Copa schrieb:
> > Can I become a Gentoo dev, even if I'm only maintainer of 1-3 packages?
> > I'm trying to be realistic.
> 
>  You can.  And you can even keep out of dev fights here on the mailing
> list.  On IRC you normally have a good working atmosphere, I always found
> a person who could do what was needed and they get testing back.

Ok. Where's the dev form?

I'm initially only interested in maintaining packages where I'm the
upstream maintainer as well. 

Do I have to do the dev quiz etc? If so, I'm not doing it today.

--
Natanael Copa

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Proxy maintainers

[Christian 'Opfer' Faulhammer]

Tach Natanael,                                  0x2B859DE3 (PGP-PK-ID)

Natanael Copa schrieb:
> On Thu, 2006-10-05 at 00:00 +0000, Christian 'Opfer' Faulhammer wrote:
>> Natanael Copa schrieb:
>>> Can I become a Gentoo dev, even if I'm only maintainer of 1-3 packages?
>>> I'm trying to be realistic.
>> You can.  And you can even keep out of dev fights here on the mailing
>> list.  On IRC you normally have a good working atmosphere, I always found
>> a person who could do what was needed and they get testing back.
> Ok. Where's the dev form?

 http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml

> I'm initially only interested in maintaining packages where I'm the
> upstream maintainer as well.

 Nobody will force you to join any projects you don't want to join.

> Do I have to do the dev quiz etc? If so, I'm not doing it today.

 It takes a bit longer...

V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Proxy maintainers

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On Thu, 05 Oct 2006 16:39:50 +0200 Natanael Copa
<natanael.copa@gmail.com> wrote:
| I'm initially only interested in maintaining packages where I'm the
| upstream maintainer as well. 

Ick. Rarely a good idea. That removes a layer of QA.

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Proxy maintainers

[Natanael Copa]

On Thu, 2006-10-05 at 15:47 +0100, Ciaran McCreesh wrote:
> On Thu, 05 Oct 2006 16:39:50 +0200 Natanael Copa
> <natanael.copa@gmail.com> wrote:
> | I'm initially only interested in maintaining packages where I'm the
> | upstream maintainer as well. 
> 
> Ick. Rarely a good idea. That removes a layer of QA.

ok. whatever...

so, I have learned alot today.

* I can't become a proxy maintainer. (you guys will continue your
"fight" if its a good or bad idea having proxy maintainers and meanwhile
nothing will happen)

* It's a bad idea for me to become a dev since I only want to maintain
stuff I know I will be able to maintain. (I cant start small and take
more and more packages over time, when/if I feel I'm able to do more)

That leaves me with the conclution that its best to just continue to run
my own local portage tree and submit bugreports once in a while and hope
for the best, just like I have always been doing.

Thanks!

--
Natanael Copa


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Proxy maintainers

[Christian 'Opfer' Faulhammer]

Tach Natanael,                                  0x2B859DE3 (PGP-PK-ID)

Natanael Copa schrieb:
> On Thu, 2006-10-05 at 15:47 +0100, Ciaran McCreesh wrote:
>> On Thu, 05 Oct 2006 16:39:50 +0200 Natanael Copa
>> <natanael.copa@gmail.com> wrote: | I'm initially only interested in
>> maintaining packages where I'm the | upstream maintainer as well. Ick.
>> Rarely a good idea. That removes a layer of QA.
[...]
> * I can't become a proxy maintainer. (you guys will continue your
> "fight" if its a good or bad idea having proxy maintainers and meanwhile
> nothing will happen)

 You can become a proxy maintainer.  If you find a dev who trusts you  
enough to commit for you.  Did you actually read the comments on proxy  
maintainers as for FreeBSD ports?
 The discussion about world domination is very friendly so why not answer  
to the thread's arguments?

> * It's a bad idea for me to become a dev since I only want to maintain
> stuff I know I will be able to maintain. (I cant start small and take
> more and more packages over time, when/if I feel I'm able to do more)

 Just because Ciaran made a point, you give up?  Sure it would be nicer to  
have devs involved in the project itself and not only with their small  
task.

> That leaves me with the conclution that its best to just continue to run
> my own local portage tree and submit bugreports once in a while and hope
> for the best, just like I have always been doing.

 I get the feeling you just stood up to complain, not to help the  
situation.  To get a feeling for the work to be done in Gentoo, become an  
arch tester or get involved with project Sunrise, which might be what you  
are looking for.

V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Proxy maintainers

[Steve Dibb]

Natanael Copa wrote:
> That leaves me with the conclution that its best to just continue to run
> my own local portage tree and submit bugreports once in a while and hope
> for the best, just like I have always been doing.
No matter what community you decide to participate in (Gentoo, local, 
church, whatever) there is always going to be a presence of power 
struggles, red tape, beuracracy, etc.  Sure there are people that are 
vocal, but that doesn't imply that they represent the majority.  There's 
still a great deal of people who quietly work on improving things in the 
background that never get noticed and don't make much noise.

If you don't like all the wang-fests, then just ignore them and get back 
to developing.

Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Proxy maintainers

[Bryan Østergaard]

On Thu, Oct 05, 2006 at 05:08:29PM +0200, Natanael Copa wrote:
> On Thu, 2006-10-05 at 15:47 +0100, Ciaran McCreesh wrote:
> > On Thu, 05 Oct 2006 16:39:50 +0200 Natanael Copa
> > <natanael.copa@gmail.com> wrote:
> > | I'm initially only interested in maintaining packages where I'm the
> > | upstream maintainer as well. 
> > 
> > Ick. Rarely a good idea. That removes a layer of QA.
> 
> ok. whatever...
> 
> so, I have learned alot today.
> 
> * I can't become a proxy maintainer. (you guys will continue your
> "fight" if its a good or bad idea having proxy maintainers and meanwhile
> nothing will happen)
Yes you can. I'm a fan of proxy maintaining and would be happy to proxy
commits for you. Please poke me on irc.freenode.net (nick kloeri).
> 
> * It's a bad idea for me to become a dev since I only want to maintain
> stuff I know I will be able to maintain. (I cant start small and take
> more and more packages over time, when/if I feel I'm able to do more)
Devs only maintaining one or two packages rarely get the needed
experience to maintain a high QA imo. I think proxy maintaining in those
cases are a much better idea.
> 
> That leaves me with the conclution that its best to just continue to run
> my own local portage tree and submit bugreports once in a while and hope
> for the best, just like I have always been doing.
See above.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Proxy maintainers

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Natanael Copa wrote:
> Because of gentoo devs always seems to fight?
>
>   
You don't have to fight.
> Its funny, I use gentoo much more that FreeBSD, I'm a freebsd port
> maintainer, but nothing for Gentoo (well, im an active bugreporter...)
>
> When I submit a fix/version bumb (I submit as "maintainer update") to
> freebsd ports, its normally committed within hours, even if its not a
> popular port. When I submit fixes for packages in Gentoo bugzilla it get
> stuck for months. They must have done something right.
>   
I don't know anything about freebsd, but I think they have a lot less
packages than us.

Since we have a vast territory to cover with just 200 (semi-)active
developers, there are portions of the tree neglected by the dev corpus.
The solution is quite simple: new devs assigned to those part of the
tree. The only problem is that is very hard to find motivated peeps.

As a guy that maintains stuff for which I don't have the slightest
interest (other than serving Gentoo community, of course), I find the
"let the others do the job" attitude pretty infuriating.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Proxy maintainers (was: Gentoo World Domination. a 10 step guide)

[Andrej Kacian]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Thu, 05 Oct 2006 10:06:39 +0200
Natanael Copa <natanael.copa@gmail.com> wrote:

> Because of gentoo devs always seems to fight?

Don't get confused by all the flames. It's only 10-20 devs out of ~150 who are
always fighting - and that's usually only on mailinglists, they work together
quite well outside of certain "hot" mailinglist topics (day-to-day tree
maintenance).

Kind regards,
-- 
Andrej "Ticho" Kacian <ticho at gentoo dot org>
Gentoo Linux Developer - net-mail, antivirus, sound, x86

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Duncan Coutts]

On Thu, 2006-10-05 at 09:52 +0300, Alin Nastac wrote:
> Natanael Copa wrote:
> > Nobody has ever showed interest and I'm not pushing my services on
> > anyone.
> >   
> Why exactly you don't want to become a Gentoo dev? The whole "proxy
> maintainer" thing is a bunch of crap. The Gentoo developer will still be
> expected to be responsible of his/her commits, which means 2 maintainers
> will spend (approximately) same amount of time testing it.

It does mean you can sometimes offload work onto other people, eg
upstream maintainers - who are themselves not interested in becoming
devs but are more than happy to maintain their single ebuild.

And it does actually mean less work for us because although we still
have to test it, we can rely to some extent on the testing done by that
maintainer and by other users who regularly build from our overlay. Also
it means we don't have to look out for upstream releases because they
'darcs send' in their updates and we just take responsibility for QA and
getting things into portage cvs.

-- 
Duncan Coutts : Gentoo Developer (Haskell team lead)
email         : dcoutts at gentoo dot org

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On Thu, 2006-10-05 at 09:52 +0300, Alin Nastac wrote:
> Natanael Copa wrote:
> > Nobody has ever showed interest and I'm not pushing my services on
> > anyone.
> >   
> Why exactly you don't want to become a Gentoo dev? The whole "proxy
> maintainer" thing is a bunch of crap. The Gentoo developer will still be
> expected to be responsible of his/her commits, which means 2 maintainers
> will spend (approximately) same amount of time testing it.

Maybe he doesn't want to deal with the politics?  Maybe he doesn't want
to deal with the flame wars?  Maybe, he just wants his package in the
tree and hopes to find a developer who thinks the same?

Personally, I proxy maintain 3 packages.  I don't actively *use* these
packages.  In this case, I'm mostly just a "commit monkey" though I do
check the packages for things similarly to what is done by Arch Testers.

Now, I wouldn't take on a very large number of such packages, simply due
to my own time constraints.  In this case, I proxy maintain for a former
Gentoo ebuild developer, so I have a strong level of trust that he knows
what he's doing.  Even then, I still give them a once-over.  It is so
little effort on my part to "maintain" the packages that, if I so chose,
I could probably proxy 100 of these.  The brunt of the work, such as
keeping up with upstream, writing patches, etc. are done by the person
whom I proxy for, and not by me.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

On Thu, 2006-10-05 at 08:34 +0200, Natanael Copa wrote:
> If the "proxy maintainer" is specified as contact person in the ebuild,
> and will be added to the CC list on bugs posted, the official developer
> will not need to care about it until he gets a response from the proxy
> developer.

Well, look at sys-auth/bioapi.  The ebuild is written (and maintained)
by an ex-developer, SeJo.  He sends me the updates, and I commit them.
About the only thing that I do is run them through repoman and check
that they're not doing fun things like "rm -rf /" in pkg_preinst.  ;]

Of course, they're super-new, so there's no bugs, but once a bug gets
filed on it, I'll be sure that SeJo is added to CC, if he isn't added by
the bug wrangler.  At that point, I'll expect him to fix it.  In the
end, *I* am ultimately responsible for the package, since I am the
developer that "maintains" it, but the workload on me is minimal, at
most.

> But I'd like to do official portage and not any overlay. I have
> submitted ebuilds to bugzilla that ended up in an overlay somehwere (bug
> got closed) and has dissapeared for ever. I can't post bugs about
> overlays in bugzilla, (I suppose) so no updated ebuild have been
> submitted and I ended up just running my own local overlay.

If your package was added to an overlay and the bug was closed, it was
closed in error.  Bug reports (unless they pertain to an overlay itself)
don't get closed until the bug is "FIXED" in the main tree.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Luis Francisco Araujo]

Chris Gianelloni wrote:
> On Wed, 2006-10-04 at 13:20 -0400, Caleb Tennis wrote:
> With the increase in developer and project overlays, I see the
> possibility for reducing work needed to maintain many packages.  As
> Natanael Copa, it would be nice for him to be able to maintain packages
> without having CVS access.  The idea of formalizing and promoting "proxy
> developers" has come up a few times before, and I think it is a great
> idea.  Work is done in the overlays, tested, improved, then committed
> into the main tree once the kinks have been worked out.  We get a
> stronger core tree with fewer "developers" and a better interaction with
> the community.
> 


http://article.gmane.org/gmane.linux.gentoo.devel/40744

I am still willing to cooperate with this project idea if there exist 
enough interest in our users and devels base.

-- 


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


-- 
gentoo-dev@gentoo.org mailing list

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

[Josh Saddler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Cort wrote:
> [. . ]

My, that's an awful lot of work on top of everything else we have to do. D'you
plan on getting us all paid, as well? That'd be motivation to stay and be even
more productive.

Also, it's not necessary for every dev to also be a member of an arch team --
it's better that developers can choose *where* they want to focus their energy
and time -- otherwise people'd be bugging deves who're primarily infra (in their
heads, at least) about bumping firefox, userrel would be badgered about broken
kde stuff, and GDP would have to field new ebuild requests.

Separation of responsibilities is obviously a much better solution.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFI8P3rsJQqN81j74RAhp6AJoCgWipvFO0BKZpU3KW84DvgrxoIQCglEsO
GhfVtGcx0gohh2lmFyixcAg=
=a+M/
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Thomas Cort]

On 10/4/06, Alec Warner <antarus@gentoo.org> wrote:

> > - No competing projects
> do we have any competing projects now?

I believe seeds competes with releng (since they both want to release
stage tarballs). Some people don't believe that the two projects
compete, but it isn't up for discussion in this thread.  PR and User
Relations used to do pretty much the same thing (interact with the
public), but they have since merged. I haven't looked at the list of
projects lately to identify any others.

I mainly wrote "No competing projects" because there aren't any rules
preventing competing projects. Since top level projects don't need
discussion or formal approval from anyone, any dev could make their
own Gentoo/x86 project. I think that's crazy.
-- 
gentoo-dev@gentoo.org mailing list

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

Thomas Cort wrote:
> I mainly wrote "No competing projects" because there aren't any rules
> preventing competing projects. Since top level projects don't need
> discussion or formal approval from anyone, any dev could make their
> own Gentoo/x86 project. I think that's crazy.

Sure, you could in theory, but that doesn't except you from any of our
other rules relating to QA etc. I expect it would get old and become too
much work very fast. Why do we need a rule for self-correcting problems?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On Wed, 04 Oct 2006 09:41:45 -0400
Alec Warner <antarus@gentoo.org> wrote:

> Thomas Cort wrote:
> > - Drop all arches and Gentoo/Alt projects except Linux on amd64,
> > ppc32/64, sparc, and x86
> 
> I can perhaps see some of this stuff dying.  Like all of SPanKY's
> weird ass arches; I have no idea why they are in the tree.  Cool
> yes...Useful? debatable.

My view is that while they're being actively supported, there's no
reason to remove them.  Granted their mostly SpanKY's babies, but so
what?  If you're not using those arches, you don't need to get
involved.  Incidentally you only have to lurk in #gentoo-embedded to
see there are users trying Gentoo on all sorts of bizarre boxes; it's
something that is much less painful and much more flexible with Gentoo
than with any other distribution.

I don't like the idea that only stuff used by large groups should be in
the tree.  I think the criteria should hinge primarily on whether stuff
has an active Gentoo maintainer.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Duncan]

"Thomas Cort" <linuxgeek@gmail.com> posted
3b09e8e90610040844y400d744bpb3c4e4b41b56fdeb@mail.gmail.com, excerpted
below, on  Wed, 04 Oct 2006 11:44:07 -0400:

> My view is that currently we cannot offer the same level of support
> for the minority arches as the majority arches because we don't have
> enough people involved. I think that spreading the developers too thin
> leads to conflict and burnout. Look at NetBSD and debian. They are
> trying to be everything for everyone. How is that working for them,
> how is it working for us? I think we should be more focused, but
> that's just my opinion.

There are two separate problems with simply removing them, however.

One, it has already been mentioned that the minority archs don't tend to
be the bottleneck, so removing them isn't likely to help.  In addition,
the minority archs don't bother anyone not on them, except for maintainers
looking to dump old versions, and that could arguably be better and more
directly addressed with a policy of time-limitting the holdup effect -- if
there has been no updates on a keyword bug in (say) 90 days, dropping the
last arch or ~arch keyworded version is allowed.

As it's related, it should be pointed out that simply forcing every dev
onto at least one arch team isn't going to help much either -- as long as
Gentoo is staffed by volunteers, you aren't going to be able to force them
to do anything substancial on a team they aren't voluntarily on anyway,
and all the inactive arch-team devs will only hide the problem. 
Additionally, that was the de facto situation with x86 previously, and it
simply didn't work.

Two and potentially far worse, you have the demotivation problem.  Picking
on a rather active dev as a prime example, Flameeyes' Gentoo/alt-freebsd
is certainly a minority arch, one that he spends a decent amount of time
on that could arguably be spent on more mainline projects.  Yet he remains
very active in other areas as well, and simply telling him to packup his
Gentoo/fbsd project as it's not wanted would be incredibly demotivating,
and could eventually cause us to lose him and all the stuff he does for
the /rest/ of the tree (a quite a lot, from where I sit as a user, and
I'm very likely missing the largest share of it).  That's not even
counting how his work on Gentoo/FBSD has improved the quality of the tree
for everyone, including those like me who have no direct interest in FBSD
at all.  Flameeyes isn't the only one.  If you shut down all the minority
archs and projects, you demotivate some of our best and brightest, and
will very likely eventually lose them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

On Thu, 2006-10-05 at 04:09 +0000, Duncan wrote:
> Two and potentially far worse, you have the demotivation problem.  Picking
> on a rather active dev as a prime example, Flameeyes' Gentoo/alt-freebsd
> is certainly a minority arch, one that he spends a decent amount of time
> on that could arguably be spent on more mainline projects.  Yet he remains
> very active in other areas as well, and simply telling him to packup his
> Gentoo/fbsd project as it's not wanted would be incredibly demotivating,
> and could eventually cause us to lose him and all the stuff he does for
> the /rest/ of the tree (a quite a lot, from where I sit as a user, and
> I'm very likely missing the largest share of it).  That's not even
> counting how his work on Gentoo/FBSD has improved the quality of the tree
> for everyone, including those like me who have no direct interest in FBSD
> at all.  Flameeyes isn't the only one.  If you shut down all the minority
> archs and projects, you demotivate some of our best and brightest, and
> will very likely eventually lose them.

$ cat commits.txt 
<kloeri> top 10 is: agriffis, vapier, flameeyes, eradicator, mcummings,
mrbones, gustavoz, corsair, kloeri and wolf31o2 (in that order)

Let's see...

Aron works on alpha and ia64.
Mike works on arm, hppa, s390, sh.
Diego works on x86-fbsd.
Gustavo works on sparc.
Bryan works on alpha.
I work on alpha.

All of these are architectures/alt project that people are talking about
dropping, yet the most productive people for Gentoo also happen to work
on these and still manage to improve the "core" of Gentoo daily.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

On Wed, 4 Oct 2006 11:44:07 -0400
"Thomas Cort" <linuxgeek@gmail.com> wrote:

> On 10/4/06, Kevin F. Quinn <kevquinn@gentoo.org> wrote:
> > On Wed, 04 Oct 2006 09:41:45 -0400
> > Alec Warner <antarus@gentoo.org> wrote:
> 
> > My view is that while they're being actively supported, there's no
> > reason to remove them.  Granted their mostly SpanKY's babies, but so
> > what?
> 
> My view is that currently we cannot offer the same level of support
> for the minority arches as the majority arches because we don't have
> enough people involved.

We don't need to.  Gentoo isn't just one single thing, and I see no
reason to require that all projects and arches offer the same level of
support.  Each project and arch can make their own determination about
what level of support they can and will offer.  Embedded users, for
example, are generally more technically-oriented to start with so need
far less support than, say, non-technical x86 users.

> I think that spreading the developers too thin
> leads to conflict and burnout. Look at NetBSD and debian. They are
> trying to be everything for everyone. How is that working for them,
> how is it working for us? I think we should be more focused, but
> that's just my opinion.

Minority arches don't affect devs who aren't interested in them, so
they have no impact on how spread out the developers are.  Effectively
you're saying that those involved in the minority arches should stop
messing about with that and commit all their Gentoo time to mainline
activities, which is obviously not sensible.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

On Wed, 4 Oct 2006 11:44:07 -0400
"Thomas Cort" <linuxgeek@gmail.com> wrote:

> On 10/4/06, Kevin F. Quinn <kevquinn@gentoo.org> wrote:
> > On Wed, 04 Oct 2006 09:41:45 -0400
> > Alec Warner <antarus@gentoo.org> wrote:
> 
> > My view is that while they're being actively supported, there's no
> > reason to remove them.  Granted their mostly SpanKY's babies, but so
> > what?
> 
> My view is that currently we cannot offer the same level of support
> for the minority arches as the majority arches because we don't have
> enough people involved.

We don't need to.  Gentoo isn't just one single thing, and I see no
reason to require that all projects and arches offer the same level of
support.  Each project and arch can make their own determination about
what level of support they can and will offer.  Embedded users, for
example, are generally more technically-oriented to start with so need
far less support than, say, non-technical x86 users.

> I think that spreading the developers too thin
> leads to conflict and burnout. Look at NetBSD and debian. They are
> trying to be everything for everyone. How is that working for them,
> how is it working for us? I think we should be more focused, but
> that's just my opinion.

Minority arches don't affect devs who aren't interested in them, so
they have no impact on how spread out the developers are.  Effectively
you're saying that those involved in the minority arches should stop
messing about with that and commit all their Gentoo time to mainline
activities, which is obviously not sensible.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

On Thu, 5 Oct 2006 12:52:14 +0200 "Kevin F. Quinn"
<kevquinn@gentoo.org> wrote:
| Minority arches don't affect devs who aren't interested in them

Actually, they do. Minority archs lead to much better tree QA being
done, more bugs in packages being identified and more ebuild and
package bugs being fixed.

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

On Thursday 05 October 2006 13:48, Ciaran McCreesh wrote:
> Actually, they do. Minority archs lead to much better tree QA being
> done, more bugs in packages being identified and more ebuild and
> package bugs being fixed.
Hell is gonna break loose, I agree with Ciaran!

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:
> On Thursday 05 October 2006 13:48, Ciaran McCreesh wrote:
>> Actually, they do. Minority archs lead to much better tree QA being
>> done, more bugs in packages being identified and more ebuild and
>> package bugs being fixed.
> Hell is gonna break loose, I agree with Ciaran!
> 
Not today, not today, 1/2 of the devils are on a strike because of the
recent freezes in the latest months, the others are still recovering
from the flu caused by the change in the climate...

lu
-- 
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Thursday 05 October 2006 14:04, Luca Barbato wrote:
> Not today, not today, 1/2 of the devils are on a strike because of the
> recent freezes in the latest months, the others are still recovering
> from the flu caused by the change in the climate...
What if I call as a reinforcement the BSD daemons I have here around?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:
> On Thursday 05 October 2006 14:04, Luca Barbato wrote:
>> Not today, not today, 1/2 of the devils are on a strike because of the
>> recent freezes in the latest months, the others are still recovering
>> from the flu caused by the change in the climate...
> What if I call as a reinforcement the BSD daemons I have here around?
> 

They got all taken for the next pokemon film, seems that the new logo
rang a bell to the producers...

lu
-- 
gentoo-dev@gentoo.org mailing list

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

[Seemant Kulleen]

On Thu, 2006-10-05 at 12:48 +0100, Ciaran McCreesh wrote:
> On Thu, 5 Oct 2006 12:52:14 +0200 "Kevin F. Quinn"
> <kevquinn@gentoo.org> wrote:
> | Minority arches don't affect devs who aren't interested in them
> 
> Actually, they do. Minority archs lead to much better tree QA being
> done, more bugs in packages being identified and more ebuild and
> package bugs being fixed.

You see this is the problem with being perceived as a "minority"
architecture.  And it's something that gets completely overlooked --
before we had a QA team, the "minority" architectures served a similar
purpose.  Countless packages have had build-system fixes, compile fixes,
runtime fixes all *because* we had ppc, sparc, mips and others (ppc and
sparc being the more major of them, in terms of long-term impact to
Gentoo).  IOW, +1 on Ciaran's statement.

I think it's perfectly fine to think about pruning/thinning out Gentoo
to its core, but first we have to actually decide what its core actually
is.  Hint: majority architectures are *not*.  Gentoo, at heart, is a
meta-distribution, and all that that implies.

Thanks,
-- 
Seemant Kulleen
Developer, Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Kumba]

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)

I doubt this'll work.  I sorta see the portage tree like a starfish -- cut it in 
half, and within time, you get two starfish.  Cut it into three parts, and you 
eventually get three starfish.  You wind up back at square one with double the 
trouble and none of the fun.



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

This might work, but it depends on what criteria/process, and how well its enforced.


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

This won't work -- especially if the dev lacks access to the hardware.  Some 
arches are so complex, you need several types of hardware.  In mips, for 
example, if a dev's got access to a low-end box like an Indy or an O2, then 
letting them help out on basic keywording on common packages probably won't 
hurt, but it would be much better if they had access to say, more than one type 
of mips hardware (say, an Octane, and a Cobalt).

Also, not every dev would want to have to maintain another box of some 
obscure/strange arch.  It's opposite in my case -- I have 1 x86 box running 
Linux (not counting my main desktop since its in windows), and everything else 
is an SGI box (or my one cobalt).  I've got spare parts lying around to build 
two more functional x86 systems, but I've never seen a need to put'em together 
and run them continuously.


> - Double the number of developers with aggressive recruiting

This can become a slippery slope real fast.


> - Devs can only belong to 5 projects at most

I can see this having its uses, but this is more of a personal thing on a 
per-dev basis.


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

Uh, no?  Although we sometimes seem as inactive as hell, mips is very much an 
alive arch.  We're a tad guilty of going off and doing our own thing sometimes, 
but then again, most of us are guilty of that at some point in our devship.

I would instead opt for more interaction among archs, probably through dev 
sharing and such.  sparc and mips share several developers (or did, I think I'm 
one of the few left), and encouraging more publicity for the lesser archs.  I 
occasionally post an announcement about some neat new whizbang thing I do (like 
the X LiveCD for SGI systems I might post about tomorrow), and though I rarely 
see a response, I feel it gets the word out.


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

Depends on the definition of "unnecessary".


> - Project status reports once a month for every project

Hmm, could be useful.  Depends on whether one defines a report as needing to 
match some obscure DoD specification, or whether a simple paragraph or two works 
fine.



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Treecleaner meeting summary

[Elfyn McBratney]

Ciao,

The treecleaner project held a meeting today on IRC (#gentoo-treecleaners
on Freenode, log attached) to discuss the goals of the project, why it
was frozen and ways in which to improve the process - treecleaning
without a vengence, maybe? ;)

The outcome of the meeting is, basically, that we need to be a lot more
careful/cautious when it comes to punting packages from the tree.  For
example, in cases where packages work but the ebuilds themselves do not,
we should fixing those up where possible.  Same goes for packages that
are widely used e.g., XMMS (that one just came into my head, honest!).

In addition to this, we'll also be following a process similar to that
used by the security team: file a bug (assigned to maintainer-needed
with treecleaners on the CC) detailing why exactly package foo should be
masked/removed; X yes votes from treecleaner members will result in the
package getting package.mask-ed and/or removed from the tree.

That about sums it up; see the attached log if anything is unclear, or
reply to this mail. :)

Best,
Treecleaner team

-- 
Elfyn McBratney,
Gentoo Developer,
Nutty between the hours of 3AM and 14AM...
+----------------------------------+
|  irc.freenode.net / beu          |
|  beu [@] gentoo [.] org          |
+-------------------------- o.0 ---+

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Treecleaner meeting summary

[Bryan Østergaard]

On Sun, Dec 17, 2006 at 07:22:13PM +0000, Elfyn McBratney wrote:
> Ciao,
> 
> The outcome of the meeting is, basically, that we need to be a lot more
> careful/cautious when it comes to punting packages from the tree.  For
> example, in cases where packages work but the ebuilds themselves do not,
> we should fixing those up where possible.  Same goes for packages that
> are widely used e.g., XMMS (that one just came into my head, honest!).
> 
> In addition to this, we'll also be following a process similar to that
> used by the security team: file a bug (assigned to maintainer-needed
> with treecleaners on the CC) detailing why exactly package foo should be
> masked/removed; X yes votes from treecleaner members will result in the
> package getting package.mask-ed and/or removed from the tree.
> 
Thanks, I believe many users (and devs) will be happy to see improved
policies regarding package removals. I'm also personally very much
looking forward to an official Proxy Maintainers project -proxy
maintaining is one of the things I've been advertising in my own small
way for a long time now and I've been very happy working with several
proxy maintainers the last couple of years.

Finally, I hope this can lead to a good discussion about future policies
and not concentrate on past package removals and possible mistakes in
that regard. We want to look forward and improve the processes.

Thanks for the summary and good luck on both projects.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Proxy maintainers

[Steve Long]

Bryan Østergaard wrote:
> Thanks, I believe many users (and devs) will be happy to see improved
> policies regarding package removals. I'm also personally very much
> looking forward to an official Proxy Maintainers project -proxy
> maintaining is one of the things I've been advertising in my own small
> way for a long time now and I've been very happy working with several
> proxy maintainers the last couple of years.
> 
Yeah, I'd like to see something come of this too; I spoke to someone on IRC
(I've forgotten the login, began with `a') who was really helpful, as I was
asking about p-ming synfig packages. He (I remember it was a bloke)
mentioned I think mailing to devrel@g.o and also mentioned that he'd be
working on the project in the new year.

In any case, I think it'd be much better if there wasn't such a distinction
between ebuild maintainers and ordinary users, or at least a gentler path
to bring people in.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Proxy maintainers

[Christian Heim]

On Monday, 18. December. 2006 08:12, Steve Long wrote:

> Yeah, I'd like to see something come of this too; I spoke to someone on IRC
> (I've forgotten the login, began with `a') who was really helpful, as I was
> asking about p-ming synfig packages. He (I remember it was a bloke)
> mentioned I think mailing to devrel@g.o and also mentioned that he'd be
> working on the project in the new year.

That would have been antarus (Alec), current treecleaner/proxy-maint lead.

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

[gentoo-dev] Re: Proxy maintainers

[Steve Long]

Christian Heim wrote:
> That would have been antarus (Alec), current treecleaner/proxy-maint lead.
> 
Thanks, astinus pointed me in the right direction of getting the right herd
to mail to.

-- 
gentoo-dev@gentoo.org mailing list