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

[Grant Goodyear]

Ryan Phillips wrote: [Fri Apr 28 2006, 12:14:53PM CDT]
> __Problem: Developer Growth__

I've seen suggestions before that one of the things limiting Gentoo's
growth right now is the hurdles involved in becoming a dev.  I don't
really think the dev quiz is all that onerous, but I'm willing to listen
to arguments there.

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

Does it?  How does having a stable and unstable branch differ from
having stable and unstable keywords?

On older idea was peer review.  Any dev could commit to the
not-yet-ready-for-primetime branch, but those commits would have to be
peer-reviewed before being added to the user tree.  It's a great idea,
except (a) nobody wants to do the reviewing job and (b) it would be a
full time job.

>
> CVS doesn't do branching nor tags very well...
>
> __Problem: CVS__
>
> CVS is one of the worst application ever created.  The portage tree
> needs to move to subversion.  A lot of the problems within the project
> would be solved by using a better SCM system.  The previous problems
> regarding the Live Tree and Developer Growth would be solved, IMHO, by
> just switching.  Branches Work.  Tags Work.  Reverts work.  Moves
> work.  I don't see any reason not to use it.  It just plain works.

Have you tried using SVN for the portage tree?  I don't know if anybody
has recently, but in the past when people tried there were two
significant problems: SVN requires at least 2x the tree size for storage
on the local machine, and checkouts take something akin to an order of
magnitude longer than CVS.  The former is annoying, but liveable, but
the latter is a deal-breaker.

> __Problem: QA Policies__
>
> http://article.gmane.org/gmane.linux.gentoo.devel/37544
>
> It seems that the QA Policies are a product of a Live Tree, and going
> partially non-live would solve the problems listed.

QA does help with fixing broken packages, but in my view their most
important mandate is to help devs fix bad habits in writing ebuilds.
Repoman and lists of best-practices help in this regard, but the QA team
tends to be much better at explaining why something is a bad idea.

> Conflict resolution should not be a subproject.  It should *not* exist
> at all.  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.

It's worth noting that with the exception of kicking people out of
Gentoo, much of our practices do, in fact, work just this way, although
without the formality of a vote.  That's what happens when somebody
posts to -dev with an idea, it gets kicked around, and some sort of
consensus is either reached, or it isn't.  In the latter case it's not
ready for prime time, most likely.

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

> A new idea proposal should be mailed to a mailinglist (-innovation?)
> with details of timeline to completion, impact, and who is doing the
> implementation.  If it sounds like a good one, then there is a vote
> and things proceed.  I like progress.

It's not quite true that the Council votes on GLEPs, but that's not
really germane to your overall point.  Despite being the person who
created GLEPs in the first place, I'm quite willing to admit that the
concept doesn't seem to work as well as I had hoped.  I'm not sure that
your idea would work better, however, since the only real difference
would be in the approval process.  Presumably you would still expect to
see the sort of iterative refinement of proposals/innovations on -dev
that we have now, and I believe that part of the project works
reasonably well.  The problem, in my view, is that eventually the
proposal is approved, and the folks involved are told, in essence,
"great idea, go to it", and then it stalls because implementation is
_hard_, in general.

As an aside, the large number of moribund GLEPs was always an intended
outcome.  They represent ideas that never got any traction, and thus
went nowhere.  By having them publicly available we help reduce the
number of "hey, what about this bad idea" posts to -dev.

> __Problem: Voting__
>
> Gentoo has over 200 developers.  People are generally against the
> voting idea, but I'm not sure why.  I think voting should work like
> this:  if 30 developers (or someother specified number) vote yes to an
> idea then that idea passes.  It doesn't require everyone to vote, be
> at home, be on the computer, and not be on vacation.

*Shrug*  I don't really have a problem w/ trying some sort of voting.
At the same time, it's not clear to me that the outcome will be all that
different from what we have now, with the possible exception that debate
might get cut off sooner when some sort of threshold vote is reached.

> What is interesting is that Source Mage Linux has already voted on a
> proposal similar to mine[2].  I truly think that making some changes
> in the "gentoo way" would benefit us and make gentoo a truly better
> distribution.

I tend to agree that our current system is suboptimal, but I'm not quite
convinced that the proposed changes would actually improve things.

There's a lot here, but perhaps we can streamline things a tad.  What's
the major problem that you're looking to solve?  Is it the shortage of
developers, or the lack of progress in a certain area, or the
(perceived?) difficulty in getting "foo" accomplished?

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@g.o
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76