From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FZYzZ-0008Fr-Ua for garchives@archives.gentoo.org; Fri, 28 Apr 2006 19:51:06 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k3SJncUQ018709; Fri, 28 Apr 2006 19:49:38 GMT Received: from mail.fl.dk (mail2.fl.dk [193.88.152.131]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k3SJidvM007842 for ; Fri, 28 Apr 2006 19:44:43 GMT Received: from kloeri by mail.fl.dk with local (Exim 4.60) (envelope-from ) id 1FZYrh-0001tm-Nq; Fri, 28 Apr 2006 21:42:57 +0200 Date: Fri, 28 Apr 2006 21:42:57 +0200 From: Bryan =?utf8?Q?=C3=98stergaard?= To: Ryan Phillips , Jon Portnoy , gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo: State of the Union Message-ID: <20060428194257.GA22098@mail.fl.dk> References: <20060428171453.GB62035@watcher.kimaker.com> <20060428175248.GA28444@cerberus.oppresses.us> <20060428182205.GA62866@watcher.kimaker.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Disposition: inline In-Reply-To: <20060428182205.GA62866@watcher.kimaker.com> User-Agent: Mutt/1.5.11 Sender: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id k3SJncW8018709 X-Archives-Salt: b4199501-6f8e-4366-940f-f93da8c6a3b6 X-Archives-Hash: dc51102062843f8094d0b3e8a97bbad9 On Fri, Apr 28, 2006 at 11:22:05AM -0700, Ryan Phillips wrote: > Jon Portnoy said: > > On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote: > > >=20 > > > I find that developer growth as being a problem. Adding a develope= r to gentoo > > > should be as easy as 1. has the user contributed numerous (~5+) pat= ches 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 re= asons why > > > this is a problem: having a live tree, taking a test, and not defin= ing within > > > policy when a person could possibly get commit access.=20 > > >=20 > > > All these reasons leave the project stagnant and lacking developers. > > >=20 > >=20 > > Maybe certain projects are (and maybe there are a lot of undermaintai= ned=20 > > packages) but overall I would say we are not really lacking developer= s;=20 > > what areas would you say we're lacking devs in exactly? > >=20 > > The recruitment process should be tightened further to ensure we have= a=20 > > solid, educated dev base. This isn't about shutting people out, it's=20 > > about ensuring that anyone with commit access is well-versed in how w= e=20 > > do things. >=20 > I believe we have a problem enticing new devlopers to join. It > shouldn't be difficult in learning how to commit changes to a tree. >=20 > What is "well versed"? Understanding the ways on how to break the tree= ? If that=20 > is the case, then we are doing something wrong.=20 >=20 I come from a different background being a recruiter and having done most, if not all, the work to clean up the current developer base so far. And from what I'm seeing we have to make it *harder* to become a gentoo developer if we want to keep any quality at all. It's not that we don't get lots of new developers but looking back at all the developers I've been retiring due to inactivity it's fairly clear that a huge part of them never did more than 5 commits or so.. And it takes a good deal more than 5 commits before you know all the intricacies of portage/gentoo and are able to do quality work on a consistent basis. I've mentored quite a few developers myself and I believe I did a fairly good job as a mentor but there's still quite some difference between first few commits and later commits from those devs as they gain experience. Personally, I don't want Gentoo to be characterised by "revolving door" developers and I'd expect users would be fairly unhappy with that as well. > > > Why do people have to take a test? Is it to make sure they won't b= reak 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 i= s all we > > > need. As long as a person is adding value to gentoo and they have = "proven" > > > themselves, then they *should* have commit access.=20 > > >=20 > >=20 > > Many people with useful contributions can commit garbage due to not=20 > > quite knowing what they're doing. > > The quiz process is an attempt to address that. We used to recruit th= e=20 > > way you suggest and it worked for years; we've since outgrown that.=20 > > "Testing" recruits provides further education. > >=20 > > Admittedly the quiz as it stands is archaic and needs reworking. I=20 > > believe the recruiters team is working on addressing that. >=20 > I am arguing that we don't need testing of potential developers. It > is bad for the community. It is saying that we don't have any faith > with our recruiting process. If we only only worried about tree breaka= ge, > then this is the wrong solution. The Arch Tester / Herd Tester projects solves many of the current problems but I very much believe we need something akin to the current tests. We *will* try to improve those tests but I'm going to fight "making it easier to become a developer" hard as that's a very bad direction from my point of view. >=20 > > > 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 as= sistance; 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. > > >=20 > >=20 > > OK, well, realistically we are composed of projects working on variou= s=20 > > areas of Gentoo that must work together with one another to form a=20 > > whole. Gentoo is not and should not be one big amorphous blob. >=20 > I agree. The mentality should be one project, even if the herds are > split into more project. I do not like when people say that someone > has stepped on their toes when committing a change to another herd.. > Typically people are trying to help. If there is a breakage then it > is a problem for Gentoo, not just a herd. Having a live tree just > adds to this problem. >=20 > > > Conflict resolution should not be a subproject. It should *not* ex= ist at all. > > > Rules need to be in place to avoid conflict. Having some sort of v= oting > > > structure for all the developers (this doesn't mean requiring every= one to vote) > > > and not just the council or devrel makes a lot of sense for most th= ings. > > > 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 besid= es 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. > >=20 > > Why should conflict resolution be a popularity contest? >=20 > It isn't. It is how a job works. If someone isn't getting along with > the team, they are fired. Same principle. You know, I could probably swing a few votes if I wanted to and so could many other devs.. I'd call that a popularity contest as opposed to the currently proposed (see gentoo-devrel ML) conflict resolution policy that have developers interested in conflict resolution working out the solution (as opposed to a large but random selection of developers who could probably care less). >=20 > > >=20 > > > Gentoo should be a fun environment. The previous paragraph should = be taken as > > > a last resort. > > >=20 > > > __Problem: GLEPs__ > > >=20 > > > I dislike GLEPs. Usually they sit on the website for a long long t= ime 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 w= ho is going > > > to implement the idea. > > >=20 > > > A new idea proposal should be mailed to a mailinglist (-innovation?= ) with > > > details of timeline to completion, impact, and who is doing the imp= lementation. > > > If it sounds like a good one, then there is a vote and things proce= ed. I like > > > progress. > >=20 > > Well, I think we all like progress. The council votes on GLEPs; I don= 't=20 > > see how extending voting to include _all of Gentoo_ would speed thing= s=20 > > up or contribute to progress... this is why we elect representatives. > >=20 > > Overall I think this would be a regression. >=20 > The council should not vote on gleps are provide policy. They should > be there to handle the money and world-wide problems. >=20 > The developers should drive innovation; not the council. >=20 > As in all democracies things get done slowly. We don't need a > democracy within Gentoo, just a clear way of creating progress. >=20 > -Ryan The developers (and many users) *are* driving innovation but we still need some kind of checks and balances in a 300+ group of developers. If we were only 20 developers this would probably come naturally from irc discussions but we're no longer a small, tightly nit group of developers. As part of "growing up" we (naturally) need more communication between developers before running off with the newest, crazy idea. Gentoo is no longer a playground - we have some 10k+ packages in the tree and 100k+ users at least afaik. We *need* to take our responsibility seriously and not play hazard with all those users/system. So.. What can we do to improve things? There's lots of things that can be improved in my opinion. Developer relations is currently pushing out a new proposed conflict resolution policy for public discussion on the gentoo-devrel ML. It's been out for a couple days already and I have yet to see a single comment on it. Likewise, we're trying to come up with a proposal for improving recruitment / quizzes. I'd love to see people (both users and developers) get involved in these discussions instead of posting general rants on the current state of gentoo. Working on small corners of gentoo can make a big difference (in a short amount of time) and I'm sure I'm not the only one who'd love to see that :) Regards, Bryan =C3=98stergaard --=20 gentoo-dev@gentoo.org mailing list