Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)

[Stuart Herbert]

Hi Ryan,

I hope you find these comments useful.

On Fri, 2006-04-28 at 10:14 -0700, Ryan Phillips wrote:
> __Problem: Developer Growth__
>
> Why do people have to take a test?

There are certain skills we need a developer to demonstrate before we
can give them commit access.  There is currently no opportunity for a
would-be-developer to demonstrate all of those skills before they get
commit access.

This is where working in overlays has helped some groups.  It gives
would-be-devs an opportunity to learn and develop the skills they would
need to become Gentoo developers.

But I don't see overlays as a replacement for our tests ... they're only
a training ground to help get people ready to take the tests.

The magic thing about Gentoo is that everything finds its own level.
That's our secret formula.  If an area of working with Linux is
important enough to enough people, Gentoo becomes strong in that area,
and its weaknesses reflect where something simply isn't important enough
for people to make an effort.  It's a beautiful thing when it works.

It's also the thing that puts a lot of people off.  Many people fear
uncertainty.  They need to exist within a plan or some sort of structure
in order to be able to function.  Our approach is uncertainty in motion.
Your only guarantee is what rsync delivered this morning.  

The master plan is simply to deliver what $UPSTREAM invents, as close to
what $UPSTREAM intended as possible.  That's a different world to what
most people know, and it's a message we do a piss poor job of
communicating to anyone and everyone.

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

We have one live tree that is trying to be all things to all people.
It's a development tree (package.mask), it's a testing tree (~arch),
it's a production tree (one tree per arch).  The tree isn't robust or
resilient - one mistake intended for the development tree can break the
other two trees.

Splitting up the tree into two - development/testing & arch trees -
would be the sensible thing to do.  The counter argument here is that
the arch trees would wither and die, because all the fun would be
happening in the other trees.  I don't buy that for an instant.  Simply
make the arch trees the default on the install media, and 80% of the
userbase will never even notice that the other tree even exists.

> __Problem: CVS__
>
> CVS is one of the worst application ever created.

Hear, hear.

I'd like to see a move to Subversion made a priority for 2006.  If there
are problems with Subversion's performance with our tree, engage with
its authors to obtain improvements.  But get it done.

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

I can see the point, but I don't agree.  

Those behind that proposal mean well, but I personally feel that their
focus isn't where it will do the most good.  The proposals that Mark has
posted on -dev are for a reactive, enforcement-first team that's focused
on applying coding standards across all our packages.  A proactive,
education-led team that's focused on finding out what's actually hurting
our users will deliver more benefit to Gentoo in a shorter period of
time.  Give a man a fish, and you feed him for a day.  Teach him how to
fish, and you feed him for a lifetime.  It's not hokum.

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

Man is a political animal, and this sort of voting structure I find too
simplistic and too naive.  How does it cope with the malicious dev who
takes every opportunity to slander another one behind their back?  If
you tell someone something often enough, people accept it as the truth -
even if it's a lie.  And people are lazy.  They'll take information from
someone they trust, and not take the trouble to learn whether or not
that information is true.  That's why advertising works :)

In any organisation, you have to have key people who understand what the
organisation is about, and who police it to get rid of those people who
from the inside are subverting and attacking the organisation's culture.
An organisation's culture is it's immune system - it's what keeps things
together when everything else is falling apart - and those who undermine
it are exceedingly dangerous to the organisation as a whole.

In any walk of life, it's a sad but true fact that most of the staff in
most organisations do not "get" what the organisation is, and what its
culture is, to the extent that they can be trusted to preserve it
without assistance.  Every one of us has a unique perspective on the
world, and no two of us have an identical perspective.

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

Gentoo should be a fun environment.  I don't see how turning it into a
popularity contest brings back the fun.

And I don't see how it benefits our users.

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

How many of the changes that are covered by the 50 or so GLEPs that
exist today have been held up because of the GLEP process?  How many of
them would have been delivered today under your proposals?

I don't think that your argument will stand up to that analysis.

I do agree that the GLEP process isn't working.  Would we miss it?

> __Problem: Voting__
>
> Gentoo has over 200 developers.  People are generally against the voting idea,
> but I'm not sure why.

I've explained my personal reasons above.

> The Apache Foundation has over 1300 developers; they must be doing something
> right.

I don't see how the size of a workforce is a measurement of success,
unless you're a middle manager in a firm who needs an empire underneath
you to justify the existance of your own job.

In fact, I'd go as far as saying that it's our growth that has become
our problem.  Too often we've taken on people because we were grateful
for the extra pair of hands, and haven't taken the time to see whether -
technically and socially - they were right for Gentoo.

But I don't feel that we're in any sort of crisis at the moment.  We're
continuing to deliver packages to our users, who are continuing to use
what we produce.

We're going through a patch where there are more disputes than some
people are comfortable with; but as long as all involved continue to
respect each other and to learn from each other, the individual issues
will get resolved.

It's the breakdown in respect between people that's the real issue that
needs addressing.  Too many of us only know each other from looking at
pixels on a screen.  I think it's time we got off our collective rears,
and did our best to get all of us face to face at the same time.

I'm offering to lead the effort to establish a global Gentoo developer
conference, and to do whatever it takes to get everything we need to
make this happen.  Now who's up for this? :)

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@g.o
Gentoo Developer                                  http://www.gentoo.org/
                                          http://blog.stuartherbert.com/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--