Re: [gentoo-dev] Gentoo: State of the Union

[Alec Warner <antarus@gentoo.org>]

Ryan Phillips wrote:
> 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...
> 

I am relatively new, I lurked for quite some time on IRC ( a yearish )
before finally becoming a dev, and the quiz was not particularly
difficult, and the questions I didn't know, I asked my Mentor about.  I
think Mentors in general don't do a very good job ( not complaining
about mine, mind, just in general ).  I think in some cases, people are
afraid to ask questions.

We have the madly successful AT project, and a new Herd Tester project
is in the works.  I find both of these to be very good ideas and have
aided in developer growth.

As for your suggestion, with a "Live Tree" you cannot give random users
who contribute "5 patches" commit access.  Commiting comes with it an
inherit responsibility.  The following is an example only:

I can go in right now and commit something that destroys anyone's box
not running SElinux, just bump portage and then watch anyone that uses
the new version destroy their machine.  Part of this involves having a
reputation based system.  IMHO this is part of our own tree security.
I have worked hard in the community to become a developer, and throwing
that all away to ruin some boxes is silly.  Sure once my changes are
found they can be revert and a new portage thrown into the tree, but how
many boxes were ruined first?  What if my commit was unintentional?

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

More details on how Branches and Tags solve the Live Tree problem would
be good.

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

We have people looking into this.  Once more testing is done it will
probably be proposed in an official capacity, for now I think a test svn
with the whole tree plus tools porting from cvs to svn is the priority.

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

How many people are going to actively vote?  What keeps "Me n' my
Posse'" from just voting out random people we hate; assuming my Posse'
is large enough to do so?

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

Uhhh Your E-mail basically states what a GLEP is, aside from the fact
that it's on the web instead of being done via E-mail.  The problem we
currently have is:

A) Many of the GLEPS require someone to do the work.
B) No one has volunteered.

Can you address these problems?

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

I could do with a shorter voting period where we vote on more things.
I'd like to see at least a few issues voted on at least to see how many
people actually show up and vote.

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