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

[Bryan Østergaard]

On Fri, Apr 28, 2006 at 08:05:06PM -0500, Daniel Goller wrote:
> -----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
You're probably able to answer the quiz questions correctly by googling
(that's on of the goals as we don't want every new developer reading
through all the portage code..) but you're not going to become a
developer that way. After having the quiz answers approved by your
mentor you'll have to talk to your recruiter who'll gauge whether or not
to add you as a new developer. As part of that we're asking additional
questions (usually both technical and organisational questions). I
sometimes think of this as a very condensed form of "super mentoring" as
it also very much helps prepare new developers getting their commit
access.

I often ask new people that I recruit if they think I'm being too hard
on them (after approving them as new devs). So far they've all said it
was very good and that they learned some important things that way. This
is of course a very informal survey but I think it shows that new
developers (in general) don't think the process is too hard.
>
> > 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
>
You're wrong, see above :)
> >
> > 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
>
I'm going to contradict myself slightly here.. Yes, we need more
developers to keep up with all the bugs, package bumping etc. At the
same time I think more developers is the last thing we need.

Why? Simply because more developers means we need to spend a lot more
time communicating with each other, discussing directions of this and
that project etc. If we *really* want to improve we need fewer, more
active developers.

That's one of the goals of my little project cleaning up the developer
base. I'm not going to retire anybody putting "only" 1hr/wk into gentoo
but retiring inactive devs is one small part of raising overall
"quality" of gentoo developers imo.
> > 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
I strongly disagree with voting, be it by all developers or just the
affected project(s). In the first case the only thing we'll gain is
(relatively) quick, random decisions with no strong base in the
complaint(s). In the second case, we'll have quick decisions made by
obviously biased people - in effect a popularity contest set up to be
unfair in advance.

Now, as developer relations lead I'm obviously biased but I were of the
same opinion even before joining devrel. After devrel have handled a
few conflicts I think the current conflict resolution policy leaves a
lot to be desired. But moving conflict resolution from devrel to more
general voting is the wrong direction.

<snip rest of mail>

Regards,
Bryan Østergaard
-- 
gentoo-dev@g.o mailing list