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 1FZcDG-0006Ax-Mb for garchives@archives.gentoo.org; Fri, 28 Apr 2006 23:17:27 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k3SNGrXt004344; Fri, 28 Apr 2006 23:16:53 GMT Received: from watcher.kimaker.com (c-67-169-29-182.hsd1.ca.comcast.net [67.169.29.182]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k3SNEqrm023682 for ; Fri, 28 Apr 2006 23:14:52 GMT Received: by watcher.kimaker.com (Postfix, from userid 1002) id C6C9675858D; Fri, 28 Apr 2006 16:14:51 -0700 (PDT) Date: Fri, 28 Apr 2006 16:14:51 -0700 From: Ryan Phillips To: Simon Stelling Cc: gentoo-dev@lists.gentoo.org, rphillips@gentoo.org Subject: Re: [gentoo-dev] Gentoo: State of the Union Message-ID: <20060428231451.GC65374@watcher.kimaker.com> Mail-Followup-To: Ryan Phillips , Simon Stelling , gentoo-dev@lists.gentoo.org References: <20060428171453.GB62035@watcher.kimaker.com> <445298F5.7070407@gentoo.org> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Uq4LBwYP4y1W6pO" Content-Disposition: inline In-Reply-To: <445298F5.7070407@gentoo.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: 04b3855c-a762-40d8-9cc3-17c677c3f1d2 X-Archives-Hash: 82ae20e48ad5a188f34d4bbf669171da --/Uq4LBwYP4y1W6pO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Simon Stelling said: > Hi Ryan, >=20 > Ryan Phillips wrote: > >__Problem: Developer Growth__ > I've seen ebuilds from people who have written quite a bunch of ebuilds= =20 > and were really interested in understanding how they work, but the work= =20 > they produced just was awful and hurt my eyes. I don't mean that the=20 > mean way, I don't expect anything else, and I was just the same.=20 > However, the mentoring process and the quiz have helped me a lot to=20 > understand not-so-obvious problems. >=20 > >All these reasons leave the project stagnant and lacking developers. >=20 > I wouldn't say so. Just about two weeks or so ago, the recruiters had to= =20 > defer new requests, because they couldn't deal with them in a timely=20 > fashion. You can now tell me that this makes it even worse, but I just=20 > see that as the proove of the fact that people are interested in helping= =20 > us and ready to take the quiz and all the "hassle" involved with=20 > becoming a dev. >=20 > Another good reason to keep the current process is the fact that a lot=20 > of people become dev and vanish a week after their mentoring period=20 > expired. These people would better contribute to the project in a more=20 > distant way IMHO, because it takes up a fair amount of time to clean up= =20 > these accounts afterwards. If you don't beleave me, ask kloeri. ;) I revised my earlier statement to say consistent involvement for ~6 months. That is more reasonable. > >Perhaps its because of a live tree... >=20 > That's surely a big factor. >=20 > >__Problem: Live Tree__ > > > >Having a live tree requires people to be perfect. People are not perfec= t=20 > >and > >requiring it is ridiculous. I love having commits in my local tree with= in=20 > >the > >hour, but having a stable and unstable branch makes a lot of sense. =20 >=20 > It doesn't require people to be perfect. It requires people to think=20 > before commiting. If it really required us to be perfect, we wouldn't=20 > exist in the first place, would we? I disagree. By committing something to the current tree it has the ability to effect a lot of people. What happens when we need to reverse a commit? It isn't that easy with CVS. >=20 > Having a stable and unstable branch doesn't have many advantages over=20 > stable and unstable keywords IMHO, but requires a HUUUGE effort to keep= =20 > them in sync. It would make things more complicated than necessary. You= =20 > say we're lacking developers. Do you really want to spend [insert random= =20 > big number here] of these much-needed developer hours to merging an old= =20 > with a new tree? Stable and unstable keywords are a hack on top of a version control system. We wouldn't have them if gentoo used an SCM that supports true branches. There would be no need. It doesn't take much time for a herd to say that this branch is stable for the production tree and do an svn merge or similar. It isn't a full time job. =20 > >Conflict resolution should not be a subproject. It should *not* exist a= t=20 > >all. >=20 > You mean conflicts or conflict solution shouldn't exist at all? > If the former, that's unrealistic. If the latter, why not? We need a policy so that we can resolve our conflicts. There are two types of conflicts. Personal and Technical. Personal conflicts can be resolved simply; a vote, and be done with it. Technical conflicts need to be resolved by a voting process so that we can move forward. Check out the apache voting page I linked to before. > >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 t= o=20 > >vote) > >and not just the council or devrel makes a lot of sense for most things.= =20 > >If I > >don't like how someone is acting within the project there should be a vo= te=20 > >and > >then see if that person is kicked out. No trial, no anything besides a= =20 > >vote. > >And if I lose I have to deal with it. Either stay with the project, or= =20 > >find > >something else. This solution just works. >=20 > Do you really think just because 60% of the voting devs agreed on=20 > something the other 40% will like it suddenly?=20 yes, a majority rule. > Conflicts cannot be=20 > avoided, other than shooting down all people which don't share your=20 > point of view. We need to minimize the conflict and make it easier to overcome those conflicts. Having a voting structure would do that. > >__Problem: GLEPs__ > > > >I dislike GLEPs. Usually they sit on the website for a long long time n= ot > >doing anything. My vote (+1) is get rid of gleps and do everything by= =20 > >email > >and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad= =20 > >Idea. > >It stifles things from getting done, and there is no ownership of who is= =20 > >going > >to implement the idea. >=20 > I dislike them too. However, you're not addressing the issue IMHO. The=20 > problem is not that the council votes on them. The problem is much more= =20 > that they are proposed to the whole dev community. Yes, you read right.= =20 > It's mostly a good thing, but it is also a show stopper. I once wrote up= =20 > a GLEP, sent it to the dev ml. Some people liked it, others wanted this= =20 > or that changed. I re-submitted it, and they criticised this and that=20 > (which is a good thing!). So I fixed all the stuff they pointed out. In= =20 > the end, I had a GLEP. But what I documented was not the idea I wanted=20 > to implement. So I lost interest. The GLEP got approved, but it's still= =20 > not implemented. I don't know if anybody is working on it, I wont,=20 > because it's no longer what I once wanted to push forward. This is because Gentoo wants to make everyone happy. We will have conflict. We should have a vote and decide. Your example is perfectly stating the frustration I have. > I would like it much more, if the people who are not affected by the=20 > GLEP wouldn't read it at all anyway. Whenever something is discussed I'm= =20 > not involved in or affected by at all, I try to keep my mouth shut. I=20 > just trust the guys who submitted it to do their job the right way. And= =20 > IMHO, this is exactly the point. Trust the others to do their job=20 > seriously and well. We don't need a whole dev community voting on an=20 > idea. Having everybody vote instead of a 7-headed council won't reduce=20 > politicalness. And that was what all your mail was about, in the end. >=20 I didn't mention everyone had to vote. There can be lazy consesus. > >__Problem: Voting__ >=20 > Heh, really don't need to comment on that one anymore. ;) I think it is the solution. -ryan --/Uq4LBwYP4y1W6pO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEUqHr6cLeDQrpxL8RApFkAJ48UrazpQmdEBhQIe9/xBIzSKDOWwCbBCz8 4VnQ8pV1DMY4TaB9UD2wzn0= =KqDe -----END PGP SIGNATURE----- --/Uq4LBwYP4y1W6pO-- -- gentoo-dev@gentoo.org mailing list