Alec Warner <[EMAIL PROTECTED]> 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
pgpC5BuYWRIuL.pgp
Description: PGP signature
