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

[Simon Stelling]

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.

> __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.

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.

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.

> 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. ;)

> Perhaps its because of a live tree...

That's surely a big factor.

> __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?

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?

> __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.

> __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.

> 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?

> 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.

> Gentoo should be a fun environment.  The previous paragraph should be taken as
> a last resort.

Gentoo is fun to me.

> __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.

> __Problem: Voting__

Heh, really don't need to comment on that one anymore. ;)

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@g.o mailing list