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@gentoo.org mailing list
