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

[Ryan Phillips]

Simon Stelling <blubb@g.o> said:
> Hi Ryan,
>
> Ryan Phillips wrote:

> >__Problem: Developer Growth__

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

I revised my earlier statement to say consistent involvement for ~6
months.  That is more reasonable.

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

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.

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

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.  

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

yes, a majority rule.

> Conflicts cannot be
> avoided, other than shooting down all people which don't share your
> 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 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.

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
> 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 didn't mention everyone had to vote.  There can be lazy consesus.

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

I think it is the solution.

-ryan