This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and
seemant's letter on herds, teams, and projects.

I believe the way Gentoo is doing things is broken.  There I have said it.  The
entire project has reached a level of being too political and trying to solve
certain problems in the wrong way.

Some of these problems are intermixed.  Please consider them starting points
for discussion.

__Problem: Developer Growth__

I find that developer growth as being a problem.  Adding a developer to gentoo
should be as easy as 1. has the user contributed numerous (~5+) patches that
helps the project move forward.  If yes, then commit access should be given.
Adding a developer is usually quite a chore.  There are numerous reasons why
this is a problem: having a live tree, taking a test, and not defining within
policy when a person could possibly get commit access. 

All these reasons leave the project stagnant and lacking developers.

Why do people have to take a test?  Is it to make sure they won't break the
tree?  If it is, then the solution of a test is wrong.  We do want to make sure
our developers understand gentoo, but I argue that the bugtracker is all we
need.  As long as a person is adding value to gentoo and they have "proven"
themselves, then they *should* have commit access. 

Perhaps its because of a live tree...

__Problem: Live Tree__

Having a live tree requires people to be perfect.  People are not perfect and
requiring it is ridiculous.  I love having commits in my local tree within the
hour, but having a stable and unstable branch makes a lot of sense.  

CVS doesn't do branching nor tags very well... 

__Problem: CVS__

CVS is one of the worst application ever created.  The portage tree needs to
move to subversion.  A lot of the problems within the project would be solved
by using a better SCM system.  The previous problems regarding the Live Tree
and Developer Growth would be solved, IMHO, by just switching.  Branches Work.
Tags Work.  Reverts work.  Moves work.  I don't see any reason not to use it.
It just plain works.

Projects (gentoo/bsd, embedded, hardened) could choose to keep their own
branches of the portage tree and merge with trunk as needed.  Projects could
stick to traditional solutions like profiles if they so wished. 

Some will probably ask who will merge between branches.  We can do that easily
ourselves.  If I think a package is good to go, then svn merge -r1123:1124 to
the branch. 

Huge projects like Apache, GCC, and KDE already use SVN.

__Problem: QA Policies__ 

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

It seems that the QA Policies are a product of a Live Tree, and going partially
non-live would solve the problems listed. 

Everyone here is on the same team.  There will be some breakages in the tree
and those can be dealt with.  Like Seemant [1] said, herds are just groups of
like *packages*.  The QA Policy is wrong when it says cross-team assistance; we
are all on the *same* team.  The tree should naturally work.  If it doesn't
then that is a bug for all of us.

Conflict resolution should not be a subproject.  It should *not* exist at all.
Rules need to be in place to avoid conflict.  Having some sort of voting
structure for all the developers (this doesn't mean requiring everyone to vote)
and not just the council or devrel makes a lot of sense for most things.  If I
don't like how someone is acting within the project there should be a vote and
then see if that person is kicked out.  No trial, no anything besides a vote.
And if I lose I have to deal with it.  Either stay with the project, or find
something else.  This solution just works.

Gentoo should be a fun environment.  The previous paragraph should be taken as
a last resort.

__Problem: GLEPs__

I dislike GLEPs.  Usually they sit on the website for a long long time not
doing anything.  My vote (+1) is get rid of gleps and do everything by email
and a vote by the developers.  AFAIK, the board votes on the GLEPs.  Bad Idea.
It stifles things from getting done, and there is no ownership of who is going
to implement the idea.

A new idea proposal should be mailed to a mailinglist (-innovation?) with
details of timeline to completion, impact, and who is doing the implementation.
If it sounds like a good one, then there is a vote and things proceed.  I like
progress.

__Problem: Voting__

Gentoo has over 200 developers.  People are generally against the voting idea,
but I'm not sure why.  I think voting should work like this:  if 30 developers
(or someother specified number) vote yes to an idea then that idea passes.  It
doesn't require everyone to vote, be at home, be on the computer, and not be on
vacation.

The Apache Foundation already has a decent page regarding this:
http://www.apache.org/foundation/voting.html

The Apache Foundation has over 1300 developers; they must be doing something
right.

If someone misses a vote, too bad.  You weren't there and progress has been
made.  I equate this to leaving on vacation from work.  My input is missed
while away, but decisions have been made in my absence.

=-=-=-=-=-

What is interesting is that Source Mage Linux has already voted on a proposal
similar to mine[2].  I truly think that making some changes in the "gentoo way"
would benefit us and make gentoo a truly better distribution.

Ryan
Gentoo Developer

[1] http://article.gmane.org/gmane.linux.gentoo.devel/37599 
[2] http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html