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

[Ryan Phillips]

Grant Goodyear <g2boojum@g.o> said:
> 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?

The first thing that we should acomplish is a different SCM system for
the portage tree.  This should be our #1 priority.  This change would
give us more freedom and fix some of the problems I proposed.

SCMs:
git - terrible with lots of tiny little files
darcs - haskel shouldn't be a dependency
mercurial - haven't tried it w/ the tree, has anyone?
svn - seems like the best candidate for now.  2x drive space isn't a
lot.  we don't do entire checkouts very often.

To reiterate, changing SCMs would allow us to work better.  I have
not heard of a proposed change, a date to change, etc.  I strongly
urge that we get something rolling.

-ryan