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

[Ryan Phillips <rphillips@gentoo.org>]

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

Alec Warner <antarus@gentoo.org> said:
> 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:
> 

Ok, so maybe not 5 patches commit access.. How about an active
contributor for 6 months.  I am throwing out ideas. 

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

So this is a problem with having 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... 
> 
> More details on how Branches and Tags solve the Live Tree problem would
> be good.

We could have a trunk/ and stable/ branch. The stable branch gets
exported to the rsync mirrors.  Trunk/ is where we do the changes,
then merge to stable/ the changes we want.  Should be pretty simple.

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

Thats fine. I replied to Alec's email about this.

We have to trust eachother to do the right thing.

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

The GLEPs first have to get passed by the council.  Wrong order of
operations.  It shouldn't be their job; it's ours.

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

It's not whether people vote.  They don't have to.  Apache calls this
lazy consensus.

-ryan

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