-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon Stelling wrote: > Hi Ryan, > > Ryan Phillips wrote: >> 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. > > I think it actually works quite well. Yes, there is space for > improvement, like always, but the situation is at least not bad.
how do you call it then if the entities in place make a decision, after some long winded strange tribunal, and when they made a decision, people ask "hey where is my vote?", i am not after devrel, what i am saying is, noone appreciates their work it seems, so why couldn't they leave the decision making to a developer vote, with the saved time, they could go on and do something they enjoy/have fun with (those of you in devrel who enjoy your devrel work (wrt to conflict resolution) i am glad you do, i just don't think many at devrel enjoy hearing they are wrong no matter how they decide) the people affected by the vote could accept a developer vote much easier than a devrel decision > >> __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. > > I can only speak for me here, but the quiz wasn't a barrier at all to > me. Instead, it was an interesting way to make sure that I get familiar > with all the stuff I have to. I found it a much better way to answer > questions about a topic where you have to find the answers than just > reading through tons of docs, not knowing whether something is important > to you or completely unrelated. > and we also have lost developers that projects were eager to get on the team, from what i recall over the developer questioning why an official quiz must be answered by finding things in unofficial docs in dev spaces no, that is not hard, but the question was valid, and with the whole process allowing all of gentoo to make this possible or not, a developer should be put in place by the leads of that project, at the project leads discretion, they know the people they plan on hiring much better than we know most people in our AT program, ATs have been turned into devs after a very short time, the quiz is a silly hurdle if it gages your ability to google, not your ability to write ebuilds > Besides that, I think the tree is far too worthy to give it away after 5 > patches. Just because I fixed a bunch of compiling errors, that doesn't > mean I know how to fix ebuilds. Just because I wrote a few ebuilds, that > doesn't mean I understand how eclasses work, which ones to use where and > what profile.bashrc is good for. we are too possessive, if you give out access to a non-live tree, and you see the commits were not fit for merging, and the person in question does not learn from advise given, the person does not have to keep commit access, but it would be nice to be more inviting than to keep our high and mighty attitude, we are not so different from our users, many of which are far better than we are, we just passed some strange test you can pass by cut& paste or paraphrasing from the right docs, you can do that w/o even knowing what you talk about > > I've seen ebuilds from people who have written quite a bunch of ebuilds > and were really interested in understanding how they work, but the work > they produced just was awful and hurt my eyes. I don't mean that the > mean way, I don't expect anything else, and I was just the same. > However, the mentoring process and the quiz have helped me a lot to > understand not-so-obvious problems. > who stops you from fixing something here and there before you merge it, you seem to think having a non live tree would unbind us from our responsibility to help them become better what a non live tree with commits by new people would allow is that teams could check what there is to merge and say "great wrk, i merge that" instead of just that one developer who works with that user, he will be easier part of the family, a team member could approach him and tell him, i merged it after quoting all your paths, please do so next time, and peope still learn if you think passing a test makes you a good driver, then think again, it is constant learning and evolvement that makes you a good driver, and we give out licenses quite easy, then if you are not suited, bye bye license >> All these reasons leave the project stagnant and lacking developers. > > I wouldn't say so. Just about two weeks or so ago, the recruiters had to > defer new requests, because they couldn't deal with them in a timely > fashion. You can now tell me that this makes it even worse, but I just > see that as the proove of the fact that people are interested in helping > us and ready to take the quiz and all the "hassle" involved with > becoming a dev. > > Another good reason to keep the current process is the fact that a lot > of people become dev and vanish a week after their mentoring period > expired. These people would better contribute to the project in a more > distant way IMHO, because it takes up a fair amount of time to clean up > these accounts afterwards. If you don't beleave me, ask kloeri. ;) > read what you wrote closely, you describe how well things work currently...i think not, they are overworked due to how involved their part of the process is, not because they have 300 new devs to process. the hassle is not big, it just delays things, and prooves nothing i can mentor someone and later on end up asking him for advise, because i saw his abilities and know he is good...better than me when it comes to technical issues, him passing the quiz did not tell me that, and neither does it tell you anything, seeing his work tells me and you something, so let their people's work speak for them, not the passing of quizes >> Perhaps its because of a live tree... > > That's surely a big factor. indeed it is, glad people do agree :) > >> __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. > > It doesn't require people to be perfect. It requires people to think > before commiting. If it really required us to be perfect, we wouldn't > exist in the first place, would we? > i don't know how perfection threatens our existence...so yeah it requires many dedicated perfect gentoo users (that's what we are, gentoo users with @gentoo.org email addresses and commit access to a live tree) to make things go smooth, and it could go smoother if we had more people, in more timezones, in more countries, in more states, you can never have to many people, not many have full 56 hours/wk for gentoo, so every 1hr per day can make a difference > Having a stable and unstable branch doesn't have many advantages over > stable and unstable keywords IMHO, but requires a HUUUGE effort to keep > them in sync. It would make things more complicated than necessary. You > say we're lacking developers. Do you really want to spend [insert random > big number here] of these much-needed developer hours to merging an old > with a new tree? > you don't have to merge the whole tree at once, each project has developers who work on packages of the herds they maintain, the Changelog will tell you why there is a change, if it matters to you, you verify and commit, but the nitty gritty of fixing it is long done >> __Problem: CVS__ > > I would like to see us using svn instead of CVS too, but I think that's > just a technical detail, not really fitting here. > well, if cvs keeps us from going to a non-live tree, then it does pertain to the discussion at hand, just if it should be svn or [insertfavoritescmhere] is another point (that could quickly be solved with a better voting structure, give the power back to the people, simplify things, and then get this issue resolved with a vote) >> __Problem: QA Policies__ > >> 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. > > This sounds romantic. However, Gentoo to me isn't 300 people who are all > my friends, all working on a common goal. Gentoo, to me, is a bunch of > very nice people that share a goal with me, some big mailing lists with > flames every now and then and a big mass of people whose work I use and > appreciate but who I don't have a f*cking clue about. I don't know what > they are like, they work on other things than I do. But that's not a > problem at all. > rather than having a QA policy that deals with punishment of devs, we should focus on a system where an accidental commit has less impact, if someone makes a commit in another branch, another set of eyes will have a chance to catch it instead of things being in everyone's --sync in ~2 hours, a QA team could still scan the tree for things, but since they find problems in the branches rather than the live tree will not have to worry about what they do until the issue with the unruly dev is resolved, and if the issues are indeed of magnitude, they can go and ask for a developer removal vote, if someone seconds that proposal, all developers can vote, and if the devs who vote think the problem is big and sizable enough, they can vote +1 for his removal, 0 to abstain or -1 if they disagree with the measure asked for by QA >> Conflict resolution should not be a subproject. It should *not* exist >> at all. > > You mean conflicts or conflict solution shouldn't exist at all? > If the former, that's unrealistic. If the latter, why not? > we shouldn't have an underappreciated overworked entity (not intending to upset the members of said entity, i know there are people behind the alias) that makes the decisions we ask them to make to hear that they did it wrong again (i am sure it gets tiring to hear us say that over and over), instead the developers bring up the issue, if someone seconds that, people vote and the issue gets resolved, one way or another now if the technical issue is brought up by a project lead and does not affect gentoo as a whole, then that project should vote, not all of us who are not affected, if we like it or not >> 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. > > Do you really think just because 60% of the voting devs agreed on > something the other 40% will like it suddenly? Conflicts cannot be > avoided, other than shooting down all people which don't share your > point of view. > in what world do you live in where 100% of members like decisions the group makes? cause i wanna go move there. be realistic. having a majority is enough, you could discuss if needing a simple or super majority based on what is voted on did anyone read the policies Ryan linked to (in particular the voting one?) >> Gentoo should be a fun environment. The previous paragraph should be >> taken as >> a last resort. > > Gentoo is fun to me. > gentoo is too political, to too distanced from the developers (on a decision making basis i mean) to have it be fun, our elitism drives prospects away, when we should embrace them and use our good judgement to decide if someone should have commit access, (for one of our projects to lose a good guy over the rest of us, who have no say over their project, bitching and moaning when our dev quiz gets criticized is wrongi should be left to that project to decide if he will work well for them or not), not some synthetic quiz, the quizes get harder and harder, but does kloeri have less and less quick in and out devs to remove? >> __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. > > I dislike them too. However, you're not addressing the issue IMHO. The > problem is not that the council votes on them. The problem is much more > that they are proposed to the whole dev community. Yes, you read right. > It's mostly a good thing, but it is also a show stopper. I once wrote up > a GLEP, sent it to the dev ml. Some people liked it, others wanted this > or that changed. I re-submitted it, and they criticised this and that > (which is a good thing!). So I fixed all the stuff they pointed out. In > the end, I had a GLEP. But what I documented was not the idea I wanted > to implement. So I lost interest. The GLEP got approved, but it's still > not implemented. I don't know if anybody is working on it, I wont, > because it's no longer what I once wanted to push forward. > > I would like it much more, if the people who are not affected by the > GLEP wouldn't read it at all anyway. Whenever something is discussed I'm > not involved in or affected by at all, I try to keep my mouth shut. I > just trust the guys who submitted it to do their job the right way. And > IMHO, this is exactly the point. Trust the others to do their job > seriously and well. We don't need a whole dev community voting on an > idea. Having everybody vote instead of a 7-headed council won't reduce > politicalness. And that was what all your mail was about, in the end. > i talked about that further up, if the idea only affects your team, bring it up to your team lead for a vote, if gets seconded, your team votes, not us who have an opinion about your idea, although we do not work on anything that is affected by your idea voting is not limited to all of gentoo voting if it does not affect all of gentoo >> __Problem: Voting__ > > Heh, really don't need to comment on that one anymore. ;) > well i guess i put that one into so many other points i will not reiterate but repost the link i would like to see people comment on, since they happened to vote on this while Ryan wrote this email i provided him with the link since it made us go "OMG! that's it!" be fair, nothing i say is final, even if you think i sound like that, those are my ideas, something i would like to see happen the link: http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html mind you, i would like to discuss a voting policy like it, not smgl, they do their thing, and we do ours, i just think their voting policy kicks our behinds.... Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUrvC/aM9DdBw91cRAh/PAKC2pAKFkM6Vp/y8E7LkhlAAkMCYYwCfSdSP HRiQH90C3NwVf49PK9cHckU= =DnLj -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list
