[gentoo-dev] Gentoo: State of the Union

[gentoo-dev] Gentoo: State of the Union

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 5634 bytes --]

This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and
seemant's letter on herds, teams, and projects.

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.

Some of these problems are intermixed.  Please consider them starting points
for discussion.

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

All these reasons leave the project stagnant and lacking developers.

Why do people have to take a test?  Is it to make sure they won't break the
tree?  If it is, then the solution of a test is wrong.  We do want to make sure
our developers understand gentoo, but I argue that the bugtracker is all we
need.  As long as a person is adding value to gentoo and they have "proven"
themselves, then they *should* have commit access. 

Perhaps its because of a live tree...

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

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.

Projects (gentoo/bsd, embedded, hardened) could choose to keep their own
branches of the portage tree and merge with trunk as needed.  Projects could
stick to traditional solutions like profiles if they so wished. 

Some will probably ask who will merge between branches.  We can do that easily
ourselves.  If I think a package is good to go, then svn merge -r1123:1124 to
the branch. 

Huge projects like Apache, GCC, and KDE already use SVN.

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

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.

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.

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

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

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

The Apache Foundation already has a decent page regarding this:
http://www.apache.org/foundation/voting.html

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

If someone misses a vote, too bad.  You weren't there and progress has been
made.  I equate this to leaving on vacation from work.  My input is missed
while away, but decisions have been made in my absence.

=-=-=-=-=-

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.

Ryan
Gentoo Developer

[1] http://article.gmane.org/gmane.linux.gentoo.devel/37599 
[2] http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Jon Portnoy]

On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote:
> 
> 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. 
> 
> All these reasons leave the project stagnant and lacking developers.
> 

Maybe certain projects are (and maybe there are a lot of undermaintained 
packages) but overall I would say we are not really lacking developers; 
what areas would you say we're lacking devs in exactly?

The recruitment process should be tightened further to ensure we have a 
solid, educated dev base. This isn't about shutting people out, it's 
about ensuring that anyone with commit access is well-versed in how we 
do things.

> Why do people have to take a test?  Is it to make sure they won't break the
> tree?  If it is, then the solution of a test is wrong.  We do want to make sure
> our developers understand gentoo, but I argue that the bugtracker is all we
> need.  As long as a person is adding value to gentoo and they have "proven"
> themselves, then they *should* have commit access. 
> 

Many people with useful contributions can commit garbage due to not 
quite knowing what they're doing.
The quiz process is an attempt to address that. We used to recruit the 
way you suggest and it worked for years; we've since outgrown that. 
"Testing" recruits provides further education.

Admittedly the quiz as it stands is archaic and needs reworking. I 
believe the recruiters team is working on addressing that.

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

OK, well, realistically we are composed of projects working on various 
areas of Gentoo that must work together with one another to form a 
whole. Gentoo is not and should not be one big amorphous blob.

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

Why should conflict resolution be a popularity contest?

> 
> Gentoo should be a fun environment.  The previous paragraph should be taken as
> a last resort.
> 
> __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.

Well, I think we all like progress. The council votes on GLEPs; I don't 
see how extending voting to include _all of Gentoo_ would speed things 
up or contribute to progress... this is why we elect representatives.

Overall I think this would be a regression.

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 5658 bytes --]

Jon Portnoy <avenj@gentoo.org> said:
> On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote:
> > 
> > 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. 
> > 
> > All these reasons leave the project stagnant and lacking developers.
> > 
> 
> Maybe certain projects are (and maybe there are a lot of undermaintained 
> packages) but overall I would say we are not really lacking developers; 
> what areas would you say we're lacking devs in exactly?
> 
> The recruitment process should be tightened further to ensure we have a 
> solid, educated dev base. This isn't about shutting people out, it's 
> about ensuring that anyone with commit access is well-versed in how we 
> do things.

I believe we have a problem enticing new devlopers to join.  It
shouldn't be difficult in learning how to commit changes to a tree.

What is "well versed"?  Understanding the ways on how to break the tree?   If that 
is the case, then we are doing something wrong. 

> > Why do people have to take a test?  Is it to make sure they won't break the
> > tree?  If it is, then the solution of a test is wrong.  We do want to make sure
> > our developers understand gentoo, but I argue that the bugtracker is all we
> > need.  As long as a person is adding value to gentoo and they have "proven"
> > themselves, then they *should* have commit access. 
> > 
> 
> Many people with useful contributions can commit garbage due to not 
> quite knowing what they're doing.
> The quiz process is an attempt to address that. We used to recruit the 
> way you suggest and it worked for years; we've since outgrown that. 
> "Testing" recruits provides further education.
> 
> Admittedly the quiz as it stands is archaic and needs reworking. I 
> believe the recruiters team is working on addressing that.

I am arguing that we don't need testing of potential developers.  It
is bad for the community.  It is saying that we don't have any faith
with our recruiting process.  If we only only worried about tree breakage,
then this is the wrong solution.

> > 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.
> > 
> 
> OK, well, realistically we are composed of projects working on various 
> areas of Gentoo that must work together with one another to form a 
> whole. Gentoo is not and should not be one big amorphous blob.

I agree.  The mentality should be one project, even if the herds are
split into more project.  I do not like when people say that someone
has stepped on their toes when committing a change to another herd..
Typically people are trying to help.  If there is a breakage then it
is a problem for Gentoo, not just a herd.  Having a live tree just
adds to this problem.

> > 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.
> 
> Why should conflict resolution be a popularity contest?

It isn't.  It is how a job works.  If someone isn't getting along with
the team, they are fired.  Same principle.

> > 
> > Gentoo should be a fun environment.  The previous paragraph should be taken as
> > a last resort.
> > 
> > __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.
> 
> Well, I think we all like progress. The council votes on GLEPs; I don't 
> see how extending voting to include _all of Gentoo_ would speed things 
> up or contribute to progress... this is why we elect representatives.
> 
> Overall I think this would be a regression.

The council should not vote on gleps are provide policy.  They should
be there to handle the money and world-wide problems.

The developers should drive innovation; not the council.

As in all democracies things get done slowly.  We don't need a
democracy within Gentoo, just a clear way of creating progress.

-Ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Chris White]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

On Friday 28 April 2006 11:22 am, Ryan Phillips wrote:
> I believe we have a problem enticing new devlopers to join.  It
> shouldn't be difficult in learning how to commit changes to a tree.

There's much more involved than more people think, if you'd like I can send 
you an entire long list of what's supposed to happen.

> What is "well versed"?  Understanding the ways on how to break the tree?  
> If that is the case, then we are doing something wrong.

Well versed is knowing there's more to the process than just commiting. 
There's working with upstream, adding patches, continual maintaining, etc.

> I am arguing that we don't need testing of potential developers.  It
> is bad for the community.  It is saying that we don't have any faith
> with our recruiting process.  If we only only worried about tree breakage,
> then this is the wrong solution.

Sure, then you get this:

"Hey can I join?"
"OK"
"*adds user*"
-- 2 weeks later --
"Anyone heard from user?"
"No"

And heaven forbid they actually took on package maintaining before they left.

-- 
Chris White
Gentoo Developer aka:
ChrisWhite
cpw
ChrisWhite|Work
WhiteChocolate
VanillaWhite
Whitey
WhiteLight
WhiteCheese
WhiteSugar
WhiteButter
WhiteWall
WhiteLemon
WhiteApple
WhiteBlanket
WhiteEnergy
WhiteWhite

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

Chris White <chriswhite@gentoo.org> said:
> 
> Sure, then you get this:
> 
> "Hey can I join?"
> "OK"
> "*adds user*"
> -- 2 weeks later --
> "Anyone heard from user?"
> "No"
> 

The solution is to have them been an active contributor for say 6
months.

-ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Chris White]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Friday 28 April 2006 11:50 am, Ryan Phillips wrote:
> The solution is to have them been an active contributor for say 6
> months.

Ok, but most "active contributors" are people that submit ebuilds to devs and 
know nothing about the structure/policy/whatever about ebuilds.  If you're 
not a dev, you're probably not going to worry about revision bumps.  If 
you're a dev without alternate arches, you're probably not going to know 
about how other arches can get screwed by improper pic handling. 

To conclude, active contributors are generally in a focused environment. The 
quiz is there to help show them the global way of handling things.

> -ryan

-- 
Chris White
Gentoo Developer aka:
ChrisWhite
cpw
ChrisWhite|Work
WhiteChocolate
VanillaWhite
Whitey
WhiteLight
WhiteCheese
WhiteSugar
WhiteButter
WhiteWall
WhiteLemon
WhiteApple
WhiteBlanket
WhiteEnergy
WhiteWhite

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Stephen Bennett]

On Fri, 28 Apr 2006 12:03:29 -0700
Chris White <chriswhite@gentoo.org> wrote:

> Ok, but most "active contributors" are people that submit ebuilds to
> devs and know nothing about the structure/policy/whatever about
> ebuilds.  If you're not a dev, you're probably not going to worry
> about revision bumps.  If you're a dev without alternate arches,
> you're probably not going to know about how other arches can get
> screwed by improper pic handling. 
> 
> To conclude, active contributors are generally in a focused
> environment. The quiz is there to help show them the global way of
> handling things.

That problem can be solved by giving new developers access to a
'sandbox' branch of the tree, and have a more experienced dev merge
their changes into the live tree having checked them for sanity. Once
they've proved themselves there, they can be given access to the main
tree if appropriate.

Of course, this relies upon using a VCS for the tree that handles
branches and merging sanely, which should be doable with Subversion if
the issues it had last time this was tested have been or can be
resolved.
-- 
gentoo-dev@gentoo.org mailing list

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

[Bryan Østergaard]

On Fri, Apr 28, 2006 at 08:35:40PM +0100, Stephen Bennett wrote:
> On Fri, 28 Apr 2006 12:03:29 -0700
> Chris White <chriswhite@gentoo.org> wrote:
> 
> > Ok, but most "active contributors" are people that submit ebuilds to
> > devs and know nothing about the structure/policy/whatever about
> > ebuilds.  If you're not a dev, you're probably not going to worry
> > about revision bumps.  If you're a dev without alternate arches,
> > you're probably not going to know about how other arches can get
> > screwed by improper pic handling. 
> > 
> > To conclude, active contributors are generally in a focused
> > environment. The quiz is there to help show them the global way of
> > handling things.
> 
> That problem can be solved by giving new developers access to a
> 'sandbox' branch of the tree, and have a more experienced dev merge
> their changes into the live tree having checked them for sanity. Once
> they've proved themselves there, they can be given access to the main
> tree if appropriate.
> 
> Of course, this relies upon using a VCS for the tree that handles
> branches and merging sanely, which should be doable with Subversion if
> the issues it had last time this was tested have been or can be
> resolved.
> -- 
This solution also needs experienced developers with lots of free time
on their hands.. And try as I might, I can't think of many people that
fits that description.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

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

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

Ryan Phillips wrote:

>
>The council should not vote on gleps are provide policy.  They should
>be there to handle the money and world-wide problems.
>
>The developers should drive innovation; not the council.
>
>As in all democracies things get done slowly.  We don't need a
>democracy within Gentoo, just a clear way of creating progress.
>
>  
>
Just because we have some elections in our process don't make Gentoo a
democracy.
Since we don't have a leader to make the important decisions, we need
some other form of authority to do the job. A council is the best
solution to the decisional problem.
Obviously it has nothing to do with innovation. As always, this is the
realm of developers.

In the rest, I basically agree with avenj. No point in repeating what
Jon already said...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

Alin Nastac <mrness@gentoo.org> said:
> Ryan Phillips wrote:
> 
> >
> >The council should not vote on gleps are provide policy.  They should
> >be there to handle the money and world-wide problems.
> >
> >The developers should drive innovation; not the council.
> >
> >As in all democracies things get done slowly.  We don't need a
> >democracy within Gentoo, just a clear way of creating progress.
> >
> >  
> >
> Just because we have some elections in our process don't make Gentoo a
> democracy.
> Since we don't have a leader to make the important decisions, we need
> some other form of authority to do the job. A council is the best
> solution to the decisional problem.
> Obviously it has nothing to do with innovation. As always, this is the
> realm of developers.
> 
> In the rest, I basically agree with avenj. No point in repeating what
> Jon already said...

I disagree.  The developers should make *all* the decisions.

Bypass the council.  The council should be there only for when we get
sued, and manage the money we make.

Does anyone agree that having a council is too political?  I strongly
believe it stifles gentoo.

-Ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Donnie Berkholz]

Ryan Phillips wrote:
> Does anyone agree that having a council is too political?  I strongly
> believe it stifles gentoo.

I believe a non-representative democracy is stifling, and buries 
everybody in constant votes etc.

Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Tim Yamin]

On Fri, Apr 28, 2006 at 11:57:30AM -0700, Ryan Phillips wrote:
> Bypass the council.  The council should be there only for when we get
> sued, and manage the money we make.
> 
> Does anyone agree that having a council is too political?  I strongly
> believe it stifles gentoo.

You're confusing Council & Foundation... Foundation handles moolah and
the "we get our asses sued" scenario, not the Council. The Council helps
push Gentoo forward.
-- 
gentoo-dev@gentoo.org mailing list

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

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

Ryan Phillips wrote: [Fri Apr 28 2006, 01:57:30PM CDT]
> I disagree.  The developers should make *all* the decisions.

Originally, Gentoo was effectively a meritocracy.  It's now, in some
respects, a republic.  If you want a democracy, feel free to draft a new
"metastructure" proposal (feel free to name it something less awkward), 
and drum up support to get it voted upon.

> Bypass the council.  The council should be there only for when we get
> sued, and manage the money we make.

For what it's worth, the Council does neither of those things.  That's
what the Gentoo Foundation is for.

> Does anyone agree that having a council is too political?  I strongly
> believe it stifles gentoo.

Do you have some specific examples of how you've seen the Council
stifle Gentoo, or is it mainly just a general impression?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

On Friday 28 April 2006 21:20, Grant Goodyear wrote:
> Ryan Phillips wrote: [Fri Apr 28 2006, 01:57:30PM CDT]
>
> > I disagree.  The developers should make *all* the decisions.
>
> Originally, Gentoo was effectively a meritocracy.  It's now, in some
> respects, a republic.  If you want a democracy, feel free to draft a
> new "metastructure" proposal (feel free to name it something less
> awkward), and drum up support to get it voted upon.
>
> > Bypass the council.  The council should be there only for when we get
> > sued, and manage the money we make.
>
> For what it's worth, the Council does neither of those things.  That's
> what the Gentoo Foundation is for.
>
> > Does anyone agree that having a council is too political?  I strongly
> > believe it stifles gentoo.
>
> Do you have some specific examples of how you've seen the Council
> stifle Gentoo, or is it mainly just a general impression?
>

I generally agree with you. I've not seen the council stifle anything 
(except that it perhaps could have encouraged more). Any stifling is more 
because the large amount of inertia caused by the big amount of 
developers.

As for abolishing the quiz, I'm strongly opposed to that. The quiz is a 
hurdle that is there for a reason. Partly it shows determination. It also 
filters out those people who don't know when they don't know something. 
We have developer documentation for a reason. The quiz ensures that 
everyone knows that we have it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

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

[Bryan Østergaard]

On Fri, Apr 28, 2006 at 11:22:05AM -0700, Ryan Phillips wrote:
> Jon Portnoy <avenj@gentoo.org> said:
> > On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote:
> > > 
> > > 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. 
> > > 
> > > All these reasons leave the project stagnant and lacking developers.
> > > 
> > 
> > Maybe certain projects are (and maybe there are a lot of undermaintained 
> > packages) but overall I would say we are not really lacking developers; 
> > what areas would you say we're lacking devs in exactly?
> > 
> > The recruitment process should be tightened further to ensure we have a 
> > solid, educated dev base. This isn't about shutting people out, it's 
> > about ensuring that anyone with commit access is well-versed in how we 
> > do things.
> 
> I believe we have a problem enticing new devlopers to join.  It
> shouldn't be difficult in learning how to commit changes to a tree.
> 
> What is "well versed"?  Understanding the ways on how to break the tree?   If that 
> is the case, then we are doing something wrong. 
> 
I come from a different background being a recruiter and having done
most, if not all, the work to clean up the current developer base so
far.

And from what I'm seeing we have to make it *harder* to become a gentoo
developer if we want to keep any quality at all. It's not that we don't
get lots of new developers but looking back at all the developers I've
been retiring due to inactivity it's fairly clear that a huge part of
them never did more than 5 commits or so.. And it takes a good deal more
than 5 commits before you know all the intricacies of portage/gentoo and
are able to do quality work on a consistent basis.

I've mentored quite a few developers myself and I believe I did a fairly
good job as a mentor but there's still quite some difference between
first few commits and later commits from those devs as they gain
experience.

Personally, I don't want Gentoo to be characterised by "revolving door"
developers and I'd expect users would be fairly unhappy with that as
well.

> > > Why do people have to take a test?  Is it to make sure they won't break the
> > > tree?  If it is, then the solution of a test is wrong.  We do want to make sure
> > > our developers understand gentoo, but I argue that the bugtracker is all we
> > > need.  As long as a person is adding value to gentoo and they have "proven"
> > > themselves, then they *should* have commit access. 
> > > 
> > 
> > Many people with useful contributions can commit garbage due to not 
> > quite knowing what they're doing.
> > The quiz process is an attempt to address that. We used to recruit the 
> > way you suggest and it worked for years; we've since outgrown that. 
> > "Testing" recruits provides further education.
> > 
> > Admittedly the quiz as it stands is archaic and needs reworking. I 
> > believe the recruiters team is working on addressing that.
> 
> I am arguing that we don't need testing of potential developers.  It
> is bad for the community.  It is saying that we don't have any faith
> with our recruiting process.  If we only only worried about tree breakage,
> then this is the wrong solution.
The Arch Tester / Herd Tester projects solves many of the current
problems but I very much believe we need something akin to the current
tests. We *will* try to improve those tests but I'm going to fight
"making it easier to become a developer" hard as that's a very bad
direction from my point of view.
> 
> > > 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.
> > > 
> > 
> > OK, well, realistically we are composed of projects working on various 
> > areas of Gentoo that must work together with one another to form a 
> > whole. Gentoo is not and should not be one big amorphous blob.
> 
> I agree.  The mentality should be one project, even if the herds are
> split into more project.  I do not like when people say that someone
> has stepped on their toes when committing a change to another herd..
> Typically people are trying to help.  If there is a breakage then it
> is a problem for Gentoo, not just a herd.  Having a live tree just
> adds to this problem.
> 
> > > 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.
> > 
> > Why should conflict resolution be a popularity contest?
> 
> It isn't.  It is how a job works.  If someone isn't getting along with
> the team, they are fired.  Same principle.
You know, I could probably swing a few votes if I wanted to and so could
many other devs.. I'd call that a popularity contest as opposed to the
currently proposed (see gentoo-devrel ML) conflict resolution policy
that have developers interested in conflict resolution working out the
solution (as opposed to a large but random selection of developers who
could probably care less).
> 
> > > 
> > > Gentoo should be a fun environment.  The previous paragraph should be taken as
> > > a last resort.
> > > 
> > > __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.
> > 
> > Well, I think we all like progress. The council votes on GLEPs; I don't 
> > see how extending voting to include _all of Gentoo_ would speed things 
> > up or contribute to progress... this is why we elect representatives.
> > 
> > Overall I think this would be a regression.
> 
> The council should not vote on gleps are provide policy.  They should
> be there to handle the money and world-wide problems.
> 
> The developers should drive innovation; not the council.
> 
> As in all democracies things get done slowly.  We don't need a
> democracy within Gentoo, just a clear way of creating progress.
> 
> -Ryan

The developers (and many users) *are* driving innovation but we still
need some kind of checks and balances in a 300+ group of developers. If
we were only 20 developers this would probably come naturally from irc
discussions but we're no longer a small, tightly nit group of
developers. As part of "growing up" we (naturally) need more
communication between developers before running off with the newest,
crazy idea.

Gentoo is no longer a playground - we have some 10k+ packages in the
tree and 100k+ users at least afaik. We *need* to take our
responsibility seriously and not play hazard with all those
users/system.

So.. What can we do to improve things? There's lots of things that can
be improved in my opinion. Developer relations is currently pushing out
a new proposed conflict resolution policy for public discussion on the
gentoo-devrel ML. It's been out for a couple days already and I have yet
to see a single comment on it.

Likewise, we're trying to come up with a proposal for improving
recruitment / quizzes.

I'd love to see people (both users and developers) get involved in these
discussions instead of posting general rants on the current state of
gentoo. Working on small corners of gentoo can make a big difference (in
a short amount of time) and I'm sure I'm not the only one who'd love to
see that :)

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

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

[Thomas Cort]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

On Fri, 28 Apr 2006 21:42:57 +0200
Bryan Østergaard <kloeri@gentoo.org> wrote:
> So.. What can we do to improve things?

I think that there should be some sort of organized way of connecting potential mentors and potential recruits. There is a very enthusiastic user who has been contributing great work to my overlay, but I cannot find anyone to mentor him (I've e-mailed sound@g.o as well as recruiters@g.o without much success). Maybe we should create a list of developers who are willing to mentor new devs? It would make finding a mentor much easier.

~tcort

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Daniel Goller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Cort wrote:
> On Fri, 28 Apr 2006 21:42:57 +0200
> Bryan Østergaard <kloeri@gentoo.org> wrote:
>> So.. What can we do to improve things?
> 
> I think that there should be some sort of organized way of connecting potential mentors and potential recruits. There is a very enthusiastic user who has been contributing great work to my overlay, but I cannot find anyone to mentor him (I've e-mailed sound@g.o as well as recruiters@g.o without much success). Maybe we should create a list of developers who are willing to mentor new devs? It would make finding a mentor much easier.
> 
> ~tcort
wait till you have your required months at gentoo, then you mentor him,
if you truly like his work, tell him you have to wait before you can
mentor him, iirc 6 months from joining?
he could wait till then, and maybe appreciate your working relationship
even more, 6 months is a nice time to see if his performance is
consitent too

no dev has to refer anyone to someone else unless they are not long
enough with the project, and then it is only a matter of time :)


Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEUpCw/aM9DdBw91cRAkzvAJsFPdeCZzjH5niV9V0TOO2zQN5togCfd/gf
dckrYu+XPRFbIJ0oZLGqhgM=
=v6W5
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Bryan Østergaard]

On Fri, Apr 28, 2006 at 05:01:20PM -0500, Daniel Goller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thomas Cort wrote:
> > On Fri, 28 Apr 2006 21:42:57 +0200
> > Bryan Østergaard <kloeri@gentoo.org> wrote:
> >> So.. What can we do to improve things?
> > 
> > I think that there should be some sort of organized way of connecting potential mentors and potential recruits. There is a very enthusiastic user who has been contributing great work to my overlay, but I cannot find anyone to mentor him (I've e-mailed sound@g.o as well as recruiters@g.o without much success). Maybe we should create a list of developers who are willing to mentor new devs? It would make finding a mentor much easier.
> > 
> > ~tcort
> wait till you have your required months at gentoo, then you mentor him,
> if you truly like his work, tell him you have to wait before you can
> mentor him, iirc 6 months from joining?
Yup, 6 months as an ebuild developer is required before you can mentor
new ebuild developers.

In this case you might consider asking for a mentor on the gentoo-dev
mailinglist seeing as sound@g.o and recruiters@g.o have't been able to
find a mentor.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

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

[Thierry Carrez]

Ryan Phillips wrote:

> The council should not vote on gleps are provide policy.  They should
> be there to handle the money and world-wide problems.
> 
> The developers should drive innovation; not the council.

You apparently confuse the trustees and the council. And you apparently
did miss the metastructure discussion of last year.

Gentoo is made up of projects that do whatever they want inside their
projects. That's where quick innovation should happen.

The council is elected to take decisions on Gentoo-wide issues that
affect multiple projects. GLEPs describe the wanted change, developers
discuss on the idea and finally the council decides (usually it
validates the consensus if there is one).

You don't like them, but they make good references :
http://www.gentoo.org/proj/en/glep/glep-0039.html

That said, I agree we lack developers. We in fact don't lack devs, we
lack active developers. So some cleanup action should be done.

-- 
Koon
-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

Ryan Phillips wrote:
> This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and
> seemant's letter on herds, teams, and projects.
> 
> 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.
> 
> Some of these problems are intermixed.  Please consider them starting points
> for discussion.
> 
> __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. 
> 
> All these reasons leave the project stagnant and lacking developers.
> 
> Why do people have to take a test?  Is it to make sure they won't break the
> tree?  If it is, then the solution of a test is wrong.  We do want to make sure
> our developers understand gentoo, but I argue that the bugtracker is all we
> need.  As long as a person is adding value to gentoo and they have "proven"
> themselves, then they *should* have commit access. 
> 
> Perhaps its because of a live tree...
> 

I am relatively new, I lurked for quite some time on IRC ( a yearish )
before finally becoming a dev, and the quiz was not particularly
difficult, and the questions I didn't know, I asked my Mentor about.  I
think Mentors in general don't do a very good job ( not complaining
about mine, mind, just in general ).  I think in some cases, people are
afraid to ask questions.

We have the madly successful AT project, and a new Herd Tester project
is in the works.  I find both of these to be very good ideas and have
aided in developer growth.

As for your suggestion, with a "Live Tree" you cannot give random users
who contribute "5 patches" commit access.  Commiting comes with it an
inherit responsibility.  The following is an example only:

I can go in right now and commit something that destroys anyone's box
not running SElinux, just bump portage and then watch anyone that uses
the new version destroy their machine.  Part of this involves having a
reputation based system.  IMHO this is part of our own tree security.
I have worked hard in the community to become a developer, and throwing
that all away to ruin some boxes is silly.  Sure once my changes are
found they can be revert and a new portage thrown into the tree, but how
many boxes were ruined first?  What if my commit was unintentional?

> __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.  
> 
> CVS doesn't do branching nor tags very well... 

More details on how Branches and Tags solve the Live Tree problem would
be good.

> 
> __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.
> 
> Projects (gentoo/bsd, embedded, hardened) could choose to keep their own
> branches of the portage tree and merge with trunk as needed.  Projects could
> stick to traditional solutions like profiles if they so wished. 
> 
> Some will probably ask who will merge between branches.  We can do that easily
> ourselves.  If I think a package is good to go, then svn merge -r1123:1124 to
> the branch. 
> 
> Huge projects like Apache, GCC, and KDE already use SVN.

We have people looking into this.  Once more testing is done it will
probably be proposed in an official capacity, for now I think a test svn
with the whole tree plus tools porting from cvs to svn is the priority.

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

How many people are going to actively vote?  What keeps "Me n' my
Posse'" from just voting out random people we hate; assuming my Posse'
is large enough to do so?

> 
> Gentoo should be a fun environment.  The previous paragraph should be taken as
> a last resort.
> 
> __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.

Uhhh Your E-mail basically states what a GLEP is, aside from the fact
that it's on the web instead of being done via E-mail.  The problem we
currently have is:

A) Many of the GLEPS require someone to do the work.
B) No one has volunteered.

Can you address these problems?

> 
> __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.
> 
> The Apache Foundation already has a decent page regarding this:
> http://www.apache.org/foundation/voting.html
> 
> The Apache Foundation has over 1300 developers; they must be doing something
> right.
> 
> If someone misses a vote, too bad.  You weren't there and progress has been
> made.  I equate this to leaving on vacation from work.  My input is missed
> while away, but decisions have been made in my absence.

I could do with a shorter voting period where we vote on more things.
I'd like to see at least a few issues voted on at least to see how many
people actually show up and vote.

> 
> =-=-=-=-=-
> 
> 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.
> 
> Ryan
> Gentoo Developer
> 
> [1] http://article.gmane.org/gmane.linux.gentoo.devel/37599 
> [2] http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html
-- 
gentoo-dev@gentoo.org mailing list

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 7623 bytes --]

Alec Warner <antarus@gentoo.org> said:
> Ryan Phillips wrote:
> > This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and
> > seemant's letter on herds, teams, and projects.
> > 
> > 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.
> > 
> > Some of these problems are intermixed.  Please consider them starting points
> > for discussion.
> > 
> > __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. 
> > 
> > All these reasons leave the project stagnant and lacking developers.
> > 
> > Why do people have to take a test?  Is it to make sure they won't break the
> > tree?  If it is, then the solution of a test is wrong.  We do want to make sure
> > our developers understand gentoo, but I argue that the bugtracker is all we
> > need.  As long as a person is adding value to gentoo and they have "proven"
> > themselves, then they *should* have commit access. 
> > 
> > Perhaps its because of a live tree...
> > 
> 
> I am relatively new, I lurked for quite some time on IRC ( a yearish )
> before finally becoming a dev, and the quiz was not particularly
> difficult, and the questions I didn't know, I asked my Mentor about.  I
> think Mentors in general don't do a very good job ( not complaining
> about mine, mind, just in general ).  I think in some cases, people are
> afraid to ask questions.
> 
> We have the madly successful AT project, and a new Herd Tester project
> is in the works.  I find both of these to be very good ideas and have
> aided in developer growth.
> 
> As for your suggestion, with a "Live Tree" you cannot give random users
> who contribute "5 patches" commit access.  Commiting comes with it an
> inherit responsibility.  The following is an example only:
> 

Ok, so maybe not 5 patches commit access.. How about an active
contributor for 6 months.  I am throwing out ideas. 

> I can go in right now and commit something that destroys anyone's box
> not running SElinux, just bump portage and then watch anyone that uses
> the new version destroy their machine.  Part of this involves having a
> reputation based system.  IMHO this is part of our own tree security.
> I have worked hard in the community to become a developer, and throwing
> that all away to ruin some boxes is silly.  Sure once my changes are
> found they can be revert and a new portage thrown into the tree, but how
> many boxes were ruined first?  What if my commit was unintentional?

So this is a problem with having a live tree.

> > __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.  
> > 
> > CVS doesn't do branching nor tags very well... 
> 
> More details on how Branches and Tags solve the Live Tree problem would
> be good.

We could have a trunk/ and stable/ branch. The stable branch gets
exported to the rsync mirrors.  Trunk/ is where we do the changes,
then merge to stable/ the changes we want.  Should be pretty simple.

> > 
> > __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. 
> > 
> > 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.
> > 
> > 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.
> 
> How many people are going to actively vote?  What keeps "Me n' my
> Posse'" from just voting out random people we hate; assuming my Posse'
> is large enough to do so?

Thats fine. I replied to Alec's email about this.

We have to trust eachother to do the right thing.

> > 
> > Gentoo should be a fun environment.  The previous paragraph should be taken as
> > a last resort.
> > 
> > __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.
> 
> Uhhh Your E-mail basically states what a GLEP is, aside from the fact
> that it's on the web instead of being done via E-mail.  The problem we
> currently have is:
> 
> A) Many of the GLEPS require someone to do the work.
> B) No one has volunteered.
> 
> Can you address these problems?

The GLEPs first have to get passed by the council.  Wrong order of
operations.  It shouldn't be their job; it's ours.

> > 
> > __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.
> > 
> > The Apache Foundation already has a decent page regarding this:
> > http://www.apache.org/foundation/voting.html
> > 
> > The Apache Foundation has over 1300 developers; they must be doing something
> > right.
> > 
> > If someone misses a vote, too bad.  You weren't there and progress has been
> > made.  I equate this to leaving on vacation from work.  My input is missed
> > while away, but decisions have been made in my absence.
> 
> I could do with a shorter voting period where we vote on more things.
> I'd like to see at least a few issues voted on at least to see how many
> people actually show up and vote.

It's not whether people vote.  They don't have to.  Apache calls this
lazy consensus.

-ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 6598 bytes --]

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@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

Grant Goodyear wrote: [Fri Apr 28 2006, 01:55:01PM CDT]
> It's not quite true that the Council votes on GLEPs, but that's not
> really germane to your overall point.  

Oh, that was your point.  Mea culpa.

Okay, to address that point, the way that the current system works is
that a GLEP is sent to the GLEP editors, and assuming that it is not
obviously going to be DOA it's generally added to the website.  At that
point, if they haven't already, the GLEP authors initiate a discussion
on -dev that is supposed to be iterative.  The authors are supposed to
revise their proposal to account for comments and ideas from the
community.  When the authors feel it is ready, they ask for the GLEP to
be approved.  At that point the GLEP is sent to either a project lead
(if it falls under a specific project) or the Council if it crosses
project boundaries for approval.  I assume that the only part of the
process you would really wish to change is who does the approving, and
perhaps removing the initial send-it-to-the-editors step.  In reality,
though, the approval process is rarely the rate-limiting step.  In
almost all cases, a stalled or failed GLEP either never gets sent for
approval, or is approved but never gets implemented.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Tim Yamin]

On Fri, Apr 28, 2006 at 01:55:01PM -0500, Grant Goodyear wrote:
> > 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.

Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org)
And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare
checkout performance on it as well.
-- 
gentoo-dev@gentoo.org mailing list

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

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

Tim Yamin wrote:

>On Fri, Apr 28, 2006 at 01:55:01PM -0500, Grant Goodyear wrote:
>  
>
>>>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.
>>    
>>
>
>Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org)
>And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare
>checkout performance on it as well.
>  
>
Since it is derived from svn, I think it would be x times slower than svn.
Besides, why would we need a decentralized SCM?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

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

[Donnie Berkholz]

Tim Yamin wrote:
> Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org)
> And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare
> checkout performance on it as well.

I've been planning to do a more detailed comparison of all the popular 
SCM's out there for probably 6 months, but I just don't have the time 
right now. If someone wants to pick this up, please let us know.

Recommended reading: http://www.keltia.net/EuroBSDCon/slides.pdf and 
www.keltia.net/EuroBSDCon/paper.pdf

SCMs to test:

monotone
bazaar
bzr
mercurial
cogito
cvs
svn
darcs
svk

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Donnie Berkholz]

Donnie Berkholz wrote:
> cogito

Actually git on its own is pretty usable at this point. I use plain git 
for managing my overlay.

Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

Donnie Berkholz <spyderous@gentoo.org> said:
> Tim Yamin wrote:
> >Speaking of which, has anybody done any tests with svk? 
> >(http://svk.elixus.org)
> >And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare
> >checkout performance on it as well.
> 
> I've been planning to do a more detailed comparison of all the popular 
> SCM's out there for probably 6 months, but I just don't have the time 
> right now. If someone wants to pick this up, please let us know.
> 
> Recommended reading: http://www.keltia.net/EuroBSDCon/slides.pdf and 
> www.keltia.net/EuroBSDCon/paper.pdf
> 
> SCMs to test:

cogito
 - Not practical
    * the lots of little files doesn't scale well with the size
      of the portage tree
    * In addition, git only allows checkins from the project parent.
      A deal breaker in my opinion
cvs
 - Branching sucks
 - Merging is terrible
 - File deletes are bad
 - Atomic Commits
svn
 + Atomic Commits
 + Merging/tagging/brancing is a simple "copy" operation
   http://svnbook.red-bean.com/en/1.1/ch04.html
 + lots of benefits
   http://svnbook.red-bean.com/nightly/en/svn.intro.features.html
   there is more I'm sure people can come up with
 - 2x Drive space
darcs
 - haskell dependency
 - doesn't work on some architectures
   - IMHO, deal breaker
svk
 - not a contender, it is subversion.
   if someone wanted to use svk with the subversion tree they could;
   it is transparent to any other.

-ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Donnie Berkholz]

Ryan Phillips wrote:
>     * In addition, git only allows checkins from the project parent.
>       A deal breaker in my opinion

Could you elaborate on what you mean by this? I don't understand.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

On Fri, Apr 28, 2006 at 01:42:40PM -0700, Ryan Phillips wrote:
> cogito
>  - Not practical
>     * the lots of little files doesn't scale well with the size
>       of the portage tree

Sure, that's why they invented git repack.

>     * In addition, git only allows checkins from the project parent.
>       A deal breaker in my opinion

That's not true at all. Not in any sane Git version.

- ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

"Fernando J. Pereda" <ferdy@gentoo.org> said:
> On Fri, Apr 28, 2006 at 01:42:40PM -0700, Ryan Phillips wrote:
> > cogito
> >  - Not practical
> >     * the lots of little files doesn't scale well with the size
> >       of the portage tree
> 
> Sure, that's why they invented git repack.
> 
> >     * In addition, git only allows checkins from the project parent.
> >       A deal breaker in my opinion
> 
> That's not true at all. Not in any sane Git version.

Ferdy:

What I meant is, if you have a change within one directory pending
a commit, and you have a commit pending in a current directory, both
files will be picked up for the commit.  I think that is bad. That
means you can't have pending changes not ready for commit and commit
something.  

yes. git-commit will allow the commit, it will walk the directories
backwards, but it will find all the pending changes and want to commit
them.

I don't think that is beneficial.  I'm open to comments though.

-ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

Ryan:

I think you are talking about very old versions of Git:

On Fri, Apr 28, 2006 at 02:20:43PM -0700, Ryan Phillips wrote:
> What I meant is, if you have a change within one directory pending
> a commit, and you have a commit pending in a current directory, both
> files will be picked up for the commit.  I think that is bad. That
> means you can't have pending changes not ready for commit and commit
> something.

Of course you can have pending commits. You can even have uncommited
changes in your index since git-commit uses a temporary index when doing
this kind of checkins.

> yes. git-commit will allow the commit, it will walk the directories
> backwards, but it will find all the pending changes and want to commit
> them.

It will if you don't use git-commit correctly :)

> I don't think that is beneficial.  I'm open to comments though.

'git commit' semantics are a bit different from 'cvs commit' and 'svn
commit' semantics. That's probably the reason you faced that problem :)

Cheers,
ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

"Fernando J. Pereda" <ferdy@gentoo.org> said:
> Ryan:
> 
> I think you are talking about very old versions of Git:
> 
> On Fri, Apr 28, 2006 at 02:20:43PM -0700, Ryan Phillips wrote:
> > What I meant is, if you have a change within one directory pending
> > a commit, and you have a commit pending in a current directory, both
> > files will be picked up for the commit.  I think that is bad. That
> > means you can't have pending changes not ready for commit and commit
> > something.
> 
> Of course you can have pending commits. You can even have uncommited
> changes in your index since git-commit uses a temporary index when doing
> this kind of checkins.
> 
> > yes. git-commit will allow the commit, it will walk the directories
> > backwards, but it will find all the pending changes and want to commit
> > them.
> 
> It will if you don't use git-commit correctly :)
> 
> > I don't think that is beneficial.  I'm open to comments though.
> 
> 'git commit' semantics are a bit different from 'cvs commit' and 'svn
> commit' semantics. That's probably the reason you faced that problem :)
> 

the only option I saw was git-commit -o and you had to specify the
files that you wanted to commit.

I tried doing a git-commit paths/ and still everything wants to be
committed.

It isn't pretty.

-Ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

On Fri, Apr 28, 2006 at 02:49:18PM -0700, Ryan Phillips wrote:
> the only option I saw was git-commit -o and you had to specify the
> files that you wanted to commit.
> 
> I tried doing a git-commit paths/ and still everything wants to be
> committed.
> 
> It isn't pretty.
> 

Uh, no... thats certainly not true for git-1.3 series, and I belive the
behavior has been consistent since early february this year when the new
commit semantics where introduced.

See this:

--- 8< ---
[ $ ~/testy/gitty ] git init-db
defaulting to local storage area
[ $ ~/testy/gitty(master) ] echo something > a
[ $ ~/testy/gitty(master) ] mkdir dir
[ $ ~/testy/gitty(master) ] echo other thing > dir/b
[ $ ~/testy/gitty(master) ] git add .
[ $ ~/testy/gitty(master) ] git commit -m "initial import"
Committing initial tree 6dc01ab7eb7f19983ae76e72ccb63e3e60aa2dc3
[ $ ~/testy/gitty(master) ] git status
nothing to commit
[ $ ~/testy/gitty(master) ] echo add something here >> dir/b
[ $ ~/testy/gitty(master) ] echo something there >> a
[ $ ~/testy/gitty(master) ] git status
#
# Changed but not updated:
#   (use git-update-index to mark for commit)
#
#	modified: a
#	modified: dir/b
#
nothing to commit
[ $ ~/testy/gitty(master) ] git commit -m "Only things in dir/?" dir/
[ $ ~/testy/gitty(master) ] git status
#
# Changed but not updated:
#   (use git-update-index to mark for commit)
#
#	modified: a
#
nothing to commit
[ $ ~/testy/gitty(master) ] 
--- 8< ---

It is the same even if you did 'git update-index a' before 'git commit
-m ... dir/'. However that's something you won't do unless you know what
you're doing :)

Cheers,
ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

"Fernando J. Pereda" <ferdy@gentoo.org> said:
> On Fri, Apr 28, 2006 at 02:49:18PM -0700, Ryan Phillips wrote:
> > the only option I saw was git-commit -o and you had to specify the
> > files that you wanted to commit.
> > 
> > I tried doing a git-commit paths/ and still everything wants to be
> > committed.
> > 
> > It isn't pretty.
> > 
> 
> Uh, no... thats certainly not true for git-1.3 series, and I belive the
> behavior has been consistent since early february this year when the new
> commit semantics where introduced.
> 
> See this:
> 
> --- 8< ---
> [ $ ~/testy/gitty ] git init-db
> defaulting to local storage area
> [ $ ~/testy/gitty(master) ] echo something > a
> [ $ ~/testy/gitty(master) ] mkdir dir
> [ $ ~/testy/gitty(master) ] echo other thing > dir/b
> [ $ ~/testy/gitty(master) ] git add .
> [ $ ~/testy/gitty(master) ] git commit -m "initial import"
> Committing initial tree 6dc01ab7eb7f19983ae76e72ccb63e3e60aa2dc3
> [ $ ~/testy/gitty(master) ] git status
> nothing to commit
> [ $ ~/testy/gitty(master) ] echo add something here >> dir/b
> [ $ ~/testy/gitty(master) ] echo something there >> a
> [ $ ~/testy/gitty(master) ] git status
> #
> # Changed but not updated:
> #   (use git-update-index to mark for commit)
> #
> #	modified: a
> #	modified: dir/b
> #
> nothing to commit
> [ $ ~/testy/gitty(master) ] git commit -m "Only things in dir/?" dir/
> [ $ ~/testy/gitty(master) ] git status
> #
> # Changed but not updated:
> #   (use git-update-index to mark for commit)
> #
> #	modified: a
> #
> nothing to commit
> [ $ ~/testy/gitty(master) ] 
> --- 8< ---
> 
> It is the same even if you did 'git update-index a' before 'git commit
> -m ... dir/'. However that's something you won't do unless you know what
> you're doing :)
> 

I'm testing with 1.3.1.  You are correct.  The text the is printed by
git is a bit confusing.  If the portage tree can scale to it, then I'm
for it.

Thanks for the clarification.

-ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Daniel Goller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Phillips wrote:
> Donnie Berkholz <spyderous@gentoo.org> said:
>> Tim Yamin wrote:
>>> Speaking of which, has anybody done any tests with svk? 
>>> (http://svk.elixus.org)
>>> And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare
>>> checkout performance on it as well.
>> I've been planning to do a more detailed comparison of all the popular 
>> SCM's out there for probably 6 months, but I just don't have the time 
>> right now. If someone wants to pick this up, please let us know.
>>
>> Recommended reading: http://www.keltia.net/EuroBSDCon/slides.pdf and 
>> www.keltia.net/EuroBSDCon/paper.pdf
>>
>> SCMs to test:
> 
> cogito
>  - Not practical
>     * the lots of little files doesn't scale well with the size
>       of the portage tree
>     * In addition, git only allows checkins from the project parent.
>       A deal breaker in my opinion
> cvs
>  - Branching sucks
>  - Merging is terrible
>  - File deletes are bad
>  - Atomic Commits
> svn
>  + Atomic Commits
>  + Merging/tagging/brancing is a simple "copy" operation
>    http://svnbook.red-bean.com/en/1.1/ch04.html
>  + lots of benefits
>    http://svnbook.red-bean.com/nightly/en/svn.intro.features.html
>    there is more I'm sure people can come up with
>  - 2x Drive space

Thanks Ryan, what we see is: the only - really is none at all

localhost64 ffmpeg-0.4.9-p20060302-shared # du -csh /cvs/gentoo-x86/
768M    /cvs/gentoo-x86/
768M    total
localhost64 ffmpeg-0.4.9-p20060302-shared # du -csh /cvs/gentoo-x86/
- --apparent-size
224M    /cvs/gentoo-x86/
224M    total

i waste more on the wrong block size with /cvs/gentoo-x86/ being on my
4K block size partition than the file size would add
we could trick around to get all that smaller

but let's be real for a moment, let's double the 768M, 1536M is nothing
on today's machines, drive space is cheap, and if your disk is small,
then you have no business running cvs or svn or anything with lot's of
small files on 4k block size

so looking at the list of SCMs, svn has only plus, and a theoretical -
side that in 2006 is none

"      --apparent-size   print apparent sizes, rather than disk
usage; 		although the apparent size is usually smaller, it may be
             larger due to holes in (`sparse') files, internal
            fragmentation, indirect blocks, and the like"

so put svn on a partition with small blocksizes/inode sizes and let's
get on with the program

Daniel

> darcs
>  - haskell dependency
>  - doesn't work on some architectures
>    - IMHO, deal breaker
> svk
>  - not a contender, it is subversion.
>    if someone wanted to use svk with the subversion tree they could;
>    it is transparent to any other.
> 
> -ryan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEUpTY/aM9DdBw91cRAvdFAKDUh9dNv025td6lm64YgKzZ6PwBbwCgvxL0
BIkORaLea2xiBzmbXpm6GSU=
=lD3P
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On Friday 28 April 2006 23:42, Ryan Phillips wrote:
> svn
>  + Atomic Commits
>  + Merging/tagging/brancing is a simple "copy" operation
>    http://svnbook.red-bean.com/en/1.1/ch04.html
>  + lots of benefits
>    http://svnbook.red-bean.com/nightly/en/svn.intro.features.html
>    there is more I'm sure people can come up with
>  - 2x Drive space

- No changeset/merge tracking

If we have a lot of active branches and a lot of merging between them, 
changeset tracking could be a major plus. I've never used git but I've heard 
that it, and other distributed development-style SCMs, have changeset/merge 
tracking features that are really helpful. Could someone who's used them 
comment on this?

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]

On Sat, Apr 29, 2006 at 03:02:46PM +0300, Dan Armak wrote:
> On Friday 28 April 2006 23:42, Ryan Phillips wrote:
> > svn
> >  + Atomic Commits
> >  + Merging/tagging/brancing is a simple "copy" operation
> >    http://svnbook.red-bean.com/en/1.1/ch04.html
> >  + lots of benefits
> >    http://svnbook.red-bean.com/nightly/en/svn.intro.features.html
> >    there is more I'm sure people can come up with
> >  - 2x Drive space
> 
> - No changeset/merge tracking
> 
> If we have a lot of active branches and a lot of merging between them, 
> changeset tracking could be a major plus. I've never used git but I've heard 
> that it, and other distributed development-style SCMs, have changeset/merge 
> tracking features that are really helpful. Could someone who's used them 
> comment on this?

Yes, Git tracks merges unless the merge is trivial (aka fast-forward).

When you merge branch 'a' into branch 'b' and 'b' is a strict subset of
'a' we call that a fast-forward, since there is no merge anywhere:

 o---o---o "b"
          \
           x---x---x "a"

If you merge 'a' into 'b' (git checkout b ; git pull . a) the result is:

 o---o---o---x---x---x "a" = "b"

However in the following case, a proper merge is required:

 o---o---o---#---# "b"
          \
           x---x---x "a"

'b' is not a strict subset of 'a' because the commits marked with # do
not exist in 'a', so the thing ends up being:

 o---o---o---#---#---@ "b"
          \         /
           x---x---x "a"

The commit marked with @ is a special comit called a 'merge'.

I hope that clarifies the merge tracking part.

However I don't know what do you mean with 'changeset tracking'.

Cheers,
Ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Saturday 29 April 2006 15:21, Fernando J. Pereda wrote:
> The commit marked with @ is a special comit called a 'merge'.
> I hope that clarifies the merge tracking part.
You just described what merging is. Svn can do that too with svn merge. But, 
if I merge changesets from branch A to B selectively, skipping some along the 
way, can I later ask git to:

- list the changesets remaining in A that I haven't merged to B yet? 
- list the branches, from a given list, which have/haven't merged a given 
changeset?

Those are things svn can't do.

>
> However I don't know what do you mean with 'changeset tracking'.

I didn't mean that 'changeset tracking' is different from 'merge tracking'.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On Sat, Apr 29, 2006 at 03:54:17PM +0300, Dan Armak wrote:
> On Saturday 29 April 2006 15:21, Fernando J. Pereda wrote:
> > The commit marked with @ is a special comit called a 'merge'.
> > I hope that clarifies the merge tracking part.
> You just described what merging is. Svn can do that too with svn merge. But, 
> if I merge changesets from branch A to B selectively, skipping some along the 
> way, can I later ask git to:
> 
> - list the changesets remaining in A that I haven't merged to B yet? 

Yes, unless you used cherry-pick. You have to do *real* merges to be
able to do that.

> - list the branches, from a given list, which have/haven't merged a given 
> changeset?

It depends on how you merged the changesets, if you did it sanely, yes,
should be easy. If you used cherry-pick here and there I don't think so.

> I didn't mean that 'changeset tracking' is different from 'merge tracking'.

Ok.

- ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[R Hill]

Dan Armak wrote:
> On Saturday 29 April 2006 15:21, Fernando J. Pereda wrote:
>> The commit marked with @ is a special comit called a 'merge'.
>> I hope that clarifies the merge tracking part.
> You just described what merging is. Svn can do that too with svn merge. But, 
> if I merge changesets from branch A to B selectively, skipping some along the 
> way, can I later ask git to:
> 
> - list the changesets remaining in A that I haven't merged to B yet? 
> - list the branches, from a given list, which have/haven't merged a given 
> changeset?
> 
> Those are things svn can't do.
> 
>> However I don't know what do you mean with 'changeset tracking'.
> 
> I didn't mean that 'changeset tracking' is different from 'merge tracking'.

Subversion dev Daniel Berlin was recently hired by Google, and according to his 
blog[i] one of his first duties is to implement merge tracking in svn.

--de.


[i] http://www.dberlin.org/blog/

-- 
gentoo-dev@gentoo.org mailing list

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

[Alexandre Buisse]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

On Sat, Apr 29, 2006 at 03:55:57 +0200, Donnie Berkholz wrote:

> Tim Yamin wrote:
> >Speaking of which, has anybody done any tests with svk? 
> >(http://svk.elixus.org)
> >And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare
> >checkout performance on it as well.
> 
> I've been planning to do a more detailed comparison of all the popular 
> SCM's out there for probably 6 months, but I just don't have the time 
> right now. If someone wants to pick this up, please let us know.

The opensolaris project has done a similar thing[1]. The three finalists
were bazaar[2], mercurial[3] and git[4], and the winner was eventually
mercurial. This is also the recommended choice from the EuroBSDcon
slides, so definitely something to consider.

Regards,
/Alexandre

[1] http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
[2] http://www.opensolaris.org/os/community/tools/scm/bzr-eval/
[3] http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial/
[4] http://www.opensolaris.org/os/community/tools/scm/git-eval.txt

-- 
Hi, I'm a .signature virus! Please copy me in your ~/.signature.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Donnie Berkholz]

Alexandre Buisse wrote:
> The opensolaris project has done a similar thing[1]. The three finalists
> were bazaar[2], mercurial[3] and git[4], and the winner was eventually
> mercurial. This is also the recommended choice from the EuroBSDcon
> slides, so definitely something to consider.

Indeed, although EuroBSDcon didn't even analyze git, just mentioned it 
in passing. It also seems that we have a fair lack of expertise relating 
to it, but there has been no shortage of contributions about subversion 
and git, at least.

The problem I had with the opensolaris testing is that they didn't seem 
to do any direct comparisons between the SCMs -- they were all isolated 
and based on a requirements doc. This makes it difficult to easily 
figure out how they balance out.

There have been a fair number of changes since the version of git 
analyzed in the opensolaris testing (1.2.2).

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Greg KH]

On Sat, Apr 29, 2006 at 05:00:10PM -0700, Donnie Berkholz wrote:
> Alexandre Buisse wrote:
> >The opensolaris project has done a similar thing[1]. The three finalists
> >were bazaar[2], mercurial[3] and git[4], and the winner was eventually
> >mercurial. This is also the recommended choice from the EuroBSDcon
> >slides, so definitely something to consider.
> 
> Indeed, although EuroBSDcon didn't even analyze git, just mentioned it 
> in passing. It also seems that we have a fair lack of expertise relating 
> to it, but there has been no shortage of contributions about subversion 
> and git, at least.

I think we have a pretty good bit of expertise with using git here :)

I use it from everything from storing config files, my mbox archive,
papers and articles, and yes, Linux kernel development.

And I've been playing around with the tools that Keith Packard used to
convert the X project, as well as having the advantage of talking at
length with him all about the issues that they had in converting over.

git is the most under-sold tool out there today.  It is by far, the most
powerful and flexible source code control tool ever made, and I've used
just about every one out there before.  It's not something that I say
lightly.

That being said, is it right for us?  Who knows, as no one has really
said what they want to do with a different SCM.

> The problem I had with the opensolaris testing is that they didn't seem 
> to do any direct comparisons between the SCMs -- they were all isolated 
> and based on a requirements doc. This makes it difficult to easily 
> figure out how they balance out.

I agree, but who really cares about opensolaris anyway :)

thanks,

greg k-h
-- 
gentoo-dev@gentoo.org mailing list

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

[Donnie Berkholz]

Alexandre Buisse wrote:
> The opensolaris project has done a similar thing[1].

While we're posting useful links, here's another one from the cairo 
project on switching from CVS to some distributed SCM:

http://lists.freedesktop.org/archives/cairo/2006-February/006255.html

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On Sun, Apr 30, 2006 at 12:50:45AM -0700, Donnie Berkholz wrote:
> While we're posting useful links, here's another one from the cairo 
> project on switching from CVS to some distributed SCM:

All this talk about switching to a more powerful SCM I can understand
- but what would the purpose of switching the portage tree to a
distributed SCM be?

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Chris Bainbridge]

On 30/04/06, Henrik Brix Andersen <brix@gentoo.org> wrote:
> On Sun, Apr 30, 2006 at 12:50:45AM -0700, Donnie Berkholz wrote:
> > While we're posting useful links, here's another one from the cairo
> > project on switching from CVS to some distributed SCM:
>
> All this talk about switching to a more powerful SCM I can understand
> - but what would the purpose of switching the portage tree to a
> distributed SCM be?

The main purpose that comes to mind is to help the groups working in
overlays (layman -L shows 28 current overlays; there may be more). It
should enable easier merging of trees, local tree management, sharing
experimental changes between devs without commiting to the main tree,
while still retaining the possibility of easily pushing changes back
to the main gentoo tree.

-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

On Mon, 2006-05-01 at 13:23 +0100, Chris Bainbridge wrote:
> The main purpose that comes to mind is to help the groups working in
> overlays (layman -L shows 28 current overlays; there may be more). It
> should enable easier merging of trees, local tree management, sharing
> experimental changes between devs without commiting to the main tree,
> while still retaining the possibility of easily pushing changes back
> to the main gentoo tree.

Hrm.  Don't we get that benefit only if the overlays switch over to
using the same distributed VCS that the main tree moves to?

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
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
--


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Donnie Berkholz]

Stuart Herbert wrote:
> Hrm.  Don't we get that benefit only if the overlays switch over to
> using the same distributed VCS that the main tree moves to?

The short answer is yes.

The long answer is that it's much easier to interconvert histories 
between most DVCS's than to convert back and forth between file-based 
history systems like CVS. One could plausibly and sanely export any 
commits from their mercurial overlay into e.g. git (or whatever ends up 
happening), suitable for merging into the official tree.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Luca Barbato]

Alexandre Buisse wrote:

> 
> [1] http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
> [2] http://www.opensolaris.org/os/community/tools/scm/bzr-eval/
> [3] http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial/
> [4] http://www.opensolaris.org/os/community/tools/scm/git-eval.txt
> 


Those figures are slightly old, some of the issues are probably
addressed both on mercurial and git.

I'd say that both are nice and are probably a good solution.

if there is space and cpu I'd like to have someone playing with them and
send benchmark results.

Mercurial should use a bit less disk and git should be a little faster
and with better merge/conflict resolution features.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

Luca Barbato wrote:
> Alexandre Buisse wrote:
> 
> 
>>[1] http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
>>[2] http://www.opensolaris.org/os/community/tools/scm/bzr-eval/
>>[3] http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial/
>>[4] http://www.opensolaris.org/os/community/tools/scm/git-eval.txt
>>
> 
> 
> 
> Those figures are slightly old, some of the issues are probably
> addressed both on mercurial and git.
> 
> I'd say that both are nice and are probably a good solution.
> 
> if there is space and cpu I'd like to have someone playing with them and
> send benchmark results.
> 

I am currently working on this, I have a page under
proj/en/infrastructure where I am describing my efforts but I need a bit
more time to make it pretty ;)  Currently cvs2svn is almost done, and
git cvsimport is chugging along.  Not really a fan of bzr for us but we
use it for pkgcore, so I'll fire that up as well.

I haven't looked at mercurial but it is on the list ;)

-Alec Warner

> Mercurial should use a bit less disk and git should be a little faster
> and with better merge/conflict resolution features.
> 
> lu
> 
-- 
gentoo-dev@gentoo.org mailing list

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 7384 bytes --]

Grant Goodyear <g2boojum@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Donnie Berkholz]

Ryan Phillips wrote:
> git - terrible with lots of tiny little files

Can you provide some evidence to support this?

I posted in more detail on SCMs elsewhere today.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Donnie Berkholz <spyderous@gentoo.org> said:
> Ryan Phillips wrote:
> >git - terrible with lots of tiny little files
> 
> Can you provide some evidence to support this?
> 
> I posted in more detail on SCMs elsewhere today.

Sure.

git only allows commits from the project parent.  Meaning that if
there was a project laid out like:

  portage-tree/
     some-package/
        some-package-1.0.0.ebuild
     xorg/
        xorg-1.ebuild
 
If I am in the portage-tree/xorg directory, I would be unable to do
a cg-commit.  Git only commits from the parent project directory, so I
would have to change back to the portage-tree and do a commit on the
entire tree.  We should not required that from an SCM.

Subversion versions each directory.  Tha is why one can change into
portage-tree/some-package and do svn svn commit.  This is different
that git, where the entire tree is versioned as one.  Make sense?

Second issue with git, is that with lots of tiny little files things
don't work so well.  I tried converting our portage tree into a git
tree, and it ran for around 2 days until I finally killed it.  If we
didn't want to preserve history, then maybe it would work out.  But
with the problem I outlined above I still don't see it as a contender.
There are lots of times when one would want to do a commit in one
directory.

-ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On Fri, Apr 28, 2006 at 02:06:36PM -0700, Ryan Phillips wrote:
> 
> Second issue with git, is that with lots of tiny little files things
> don't work so well.  I tried converting our portage tree into a git
> tree, and it ran for around 2 days until I finally killed it.  If we
> didn't want to preserve history, then maybe it would work out.  But
> with the problem I outlined above I still don't see it as a contender.
> There are lots of times when one would want to do a commit in one
> directory.
> 

Ryan,

What tool did you use for that? AFAIK parsecvs[1] has converted some
very big and broken CVS repositories successfully.

- ferdy

[1] git://git.freedesktop.org/~keithp/parsecvs

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

"Fernando J. Pereda" <ferdy@gentoo.org> said:
> On Fri, Apr 28, 2006 at 02:06:36PM -0700, Ryan Phillips wrote:
> > 
> > Second issue with git, is that with lots of tiny little files things
> > don't work so well.  I tried converting our portage tree into a git
> > tree, and it ran for around 2 days until I finally killed it.  If we
> > didn't want to preserve history, then maybe it would work out.  But
> > with the problem I outlined above I still don't see it as a contender.
> > There are lots of times when one would want to do a commit in one
> > directory.
> > 
> 
> Ryan,
> 
> What tool did you use for that? AFAIK parsecvs[1] has converted some
> very big and broken CVS repositories successfully.
> 
> - ferdy
> 
> [1] git://git.freedesktop.org/~keithp/parsecvs

I was using cvs2git.

I sorta like git in certain aspects. If git would  work better than
CVS or anything other SCM I'm for it.  Right now, _anything_ would be
better than CVS.

-ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Fri, Apr 28, 2006 at 02:56:26PM -0700, Ryan Phillips wrote:
> I sorta like git in certain aspects. If git would  work better than
> CVS or anything other SCM I'm for it.  Right now, _anything_ would be
> better than CVS.

I don't really know if Git is suitable for our workflow though... I was
just trying to clarify those issues you pointed out about Git.

I locally manage a couple of overlays with it, but nothing compared to
the portage tree.

- ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Donnie Berkholz]

Fernando J. Pereda wrote:
> On Fri, Apr 28, 2006 at 02:56:26PM -0700, Ryan Phillips wrote:
>> I sorta like git in certain aspects. If git would  work better than
>> CVS or anything other SCM I'm for it.  Right now, _anything_ would be
>> better than CVS.
> 
> I don't really know if Git is suitable for our workflow though... I was
> just trying to clarify those issues you pointed out about Git.
> 
> I locally manage a couple of overlays with it, but nothing compared to
> the portage tree.

Nobody's explicitly mentioned this yet, but X.Org is switching a lot of 
its stuff over to git. That's the reason for keithp's parsecvs tool. The 
biggest one is the xserver CVS module, which has years of history and 
much more complex branching than anything I'm aware of in our CVS.

They have a similar centralized development model to us, so it's a 
reasonable comparison. Although there are quite a few less files in 
their repo, arguments could be made for splitting up gentoo-x86 into one 
repo per subdirectory or similar.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

Ryan Phillips wrote: [Fri Apr 28 2006, 03:35:33PM CDT]
> 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.

Go for it! *Grin*

More seriously, the only thing standing in the way of migrating away
from CVS is actual evidence that something else will work better.  If
you want to do the testing, I don't think anybody is going to stand in
your way.  Indeed, I'm sure that if you wanted to solicit help with
testing from our users, I suspect that infra could make a tarball of the
repository available.

Some questions that need to be answered:

* Can the repo be converted while maintaining the history?
* How long does a full checkout take?  
* How much disk space does a full checkout require?
* Is there a viewcvs equivalent available?
* Others that I can't think of right now?  (Please feel free to add.)

(As an aside, it's perfectly possible to set up git so that anybody in
the appropriate group can make changes.)

You seem to have an obvious preference for svn; care to to the
benchmarking for that case?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Marius Mauch]

Grant Goodyear schrieb:
> Some questions that need to be answered:
> 
> * Can the repo be converted while maintaining the history?
> * How long does a full checkout take?  
> * How much disk space does a full checkout require?
> * Is there a viewcvs equivalent available?
> * Others that I can't think of right now?  (Please feel free to add.)

Right now portage and repoman have no support for using anything but cvs 
or rsync for the tree, e.g. repoman commit wouldn't work. Not hard to 
fix, but something to keep in mind.

Marius
-- 
gentoo-dev@gentoo.org mailing list

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

Marius Mauch <genone@gentoo.org> said:
> Grant Goodyear schrieb:
> >Some questions that need to be answered:
> >
> >* Can the repo be converted while maintaining the history?
> >* How long does a full checkout take?  
> >* How much disk space does a full checkout require?
> >* Is there a viewcvs equivalent available?
> >* Others that I can't think of right now?  (Please feel free to add.)
> 
> Right now portage and repoman have no support for using anything but cvs 
> or rsync for the tree, e.g. repoman commit wouldn't work. Not hard to 
> fix, but something to keep in mind.

Rsync could still be used to deliver up-to-date tree's to people.

Changing the process would of course require backend changes to our
utilities.

The quesion is what is best for the job, and then implement it.

-Ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Simon Stelling]

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

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

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 6670 bytes --]

Simon Stelling <blubb@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[Chris White]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Friday 28 April 2006 04:14 pm, Ryan Phillips wrote:
> 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.

cvs admin -or1.1
(delete revision 1.1)

cvs admin -or1.1::1.2
(delete revision 1.1 - 1.2)
-- 
Chris White
Gentoo Developer aka:
ChrisWhite
cpw
ChrisWhite|Work
WhiteChocolate
VanillaWhite
Whitey
WhiteLight
WhiteCheese
WhiteSugar
WhiteButter
WhiteWall
WhiteLemon
WhiteApple
WhiteBlanket
WhiteEnergy
WhiteWhite

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Donnie Berkholz]

Chris White wrote:
> On Friday 28 April 2006 04:14 pm, Ryan Phillips wrote:
>> 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.
> 
> cvs admin -or1.1
> (delete revision 1.1)
> 
> cvs admin -or1.1::1.2
> (delete revision 1.1 - 1.2)

If you have to use admin commands to fix a mistake, the system is 
broken. However in this particular case it is unnecessary, you just need 
to make use of the merging features.

cvs update -j 1.2 -j 1.1 oldfile

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

Ryan Phillips wrote:
> 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.

Umm, I'm not an ebuild dev, but how would users mix stable and unstable
packages in such a case?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

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

[Donnie Berkholz]

Jan Kundrát wrote:
> Ryan Phillips wrote:
>> 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.
> 
> Umm, I'm not an ebuild dev, but how would users mix stable and unstable
> packages in such a case?

They would probably have to check out two trees. But the two trees 
combined would likely be the same size as the single tree now, since a 
lot of packages have at least two ebuilds available, one ~arch and one 
stable.

The real showstopper in my mind is that having a single ~arch and a 
single stable tree means you can't selectively stable things on 
different architectures at different times.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

On Saturday 29 April 2006 19:52, Donnie Berkholz wrote:
> Jan Kundrát wrote:
> > Ryan Phillips wrote:
> >> 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.
> >
> > Umm, I'm not an ebuild dev, but how would users mix stable and
> > unstable packages in such a case?
>
> They would probably have to check out two trees. But the two trees
> combined would likely be the same size as the single tree now, since a
> lot of packages have at least two ebuilds available, one ~arch and one
> stable.
>
> The real showstopper in my mind is that having a single ~arch and a
> single stable tree means you can't selectively stable things on
> different architectures at different times.

Agreed, the main advantage of a proper vcs would be that the ancestry 
between different ebuild versions would be visible. This would make it 
even possible to merge back working changes from a testing version to a 
stable version without gambling that it will work.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

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

[Daniel Goller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simon Stelling wrote:
> 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.

how do you call it then if the entities in place make a decision, after
some long winded strange tribunal, and when they made a decision, people
ask "hey where is my vote?", i am not after devrel, what i am saying is,
noone appreciates their work it seems, so why couldn't they leave the
decision making to a developer vote, with the saved time, they could go
on and do something they enjoy/have fun with (those of you in devrel who
enjoy your devrel work (wrt to conflict resolution) i am glad you do, i
just don't think many at devrel enjoy hearing they are wrong no matter
how they decide)
the people affected by the vote could accept a developer vote much
easier than a devrel decision

> 
>> __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.
> 
and we also have lost developers that projects were eager to get on the
team, from what i recall over the developer questioning why an official
quiz must be answered by finding things in unofficial docs in dev spaces
no, that is not hard, but the question was valid, and with the whole
process allowing all of gentoo to make this possible or not, a developer
should be put in place by the leads of that project, at the project
leads discretion, they know the people they plan on hiring much better
than we know most people in our AT program, ATs have been turned into
devs after a very short time, the quiz is a silly hurdle if it gages
your ability to google, not your ability to write ebuilds

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

we are too possessive, if you give out access to a non-live tree, and
you see the commits were not fit for merging, and the person in question
does not learn from advise given, the person does not have to keep
commit access, but it would be nice to be more inviting than to keep our
high and mighty attitude, we are not so different from our users, many
of which are far better than we are, we just passed some strange test
you can pass by cut& paste or paraphrasing from the right docs, you can
do that w/o even knowing what you talk about

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

who stops you from fixing something here and there before you merge it,
you seem to think having a non live tree would unbind us from our
responsibility to help them become better

what a non live tree with commits by new people would allow is that
teams could check what there is to merge and say "great wrk, i merge
that" instead of just that one developer who works with that user, he
will be easier part of the family, a team member could approach him and
tell him, i merged it after quoting all your paths, please do so next
time, and peope still learn

if you think passing a test makes you a good driver, then think again,
it is constant learning and evolvement that makes you a good driver, and
we give out licenses quite easy, then if you are not suited, bye bye license

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

read what you wrote closely, you describe how well things work
currently...i think not, they are overworked due to how involved their
part of the process is, not because they have 300 new devs to process.
the hassle is not big, it just delays things, and prooves nothing
i can mentor someone and later on end up asking him for advise, because
i saw his abilities and know he is good...better than me when it comes
to technical issues, him passing the quiz did not tell me that, and
neither does it tell you anything, seeing his work tells me and you
something, so let their people's work speak for them, not the passing of
quizes

>> Perhaps its because of a live tree...
> 
> That's surely a big factor.

indeed it is, glad people do agree :)
> 
>> __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 don't know how perfection threatens our existence...so yeah it
requires many dedicated perfect gentoo users (that's what we are, gentoo
users with @gentoo.org email addresses and commit access to a live tree)
to make things go smooth, and it could go smoother if we had more
people, in more timezones, in more countries, in more states, you can
never have to many people, not many have full 56 hours/wk for gentoo, so
every 1hr per day can make a difference

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

you don't have to merge the whole tree at once, each project has
developers who work on packages of the herds they maintain, the
Changelog will tell you why there is a change, if it matters to you, you
verify and commit, but the nitty gritty of fixing it is long done

>> __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.
>
well, if cvs keeps us from going to a non-live tree, then it does
pertain to the discussion at hand, just if it should be svn or
[insertfavoritescmhere] is another point (that could quickly be solved
with a better voting structure, give the power back to the people,
simplify things, and then get this issue resolved with a vote)

>> __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.
> 
rather than having a QA policy that deals with punishment of devs, we
should focus on a system where an accidental commit has less impact, if
someone makes a commit in another branch, another set of eyes will have
a chance to catch it instead of things being in everyone's --sync in ~2
hours, a QA team could still scan the tree for things, but since they
find problems in the branches rather than the live tree will not have to
worry about what they do until the issue with the unruly dev is
resolved, and if the issues are indeed of magnitude, they can go and ask
 for a developer removal vote, if someone seconds that proposal, all
developers can vote, and if the devs who vote think the problem is big
and sizable enough, they can vote +1 for his removal, 0 to abstain or -1
if they disagree with the measure asked for by QA

>> 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 shouldn't have an underappreciated overworked entity (not intending
to upset the members of said entity, i know there are people behind the
alias) that makes the decisions we ask them to make to hear that they
did it wrong again (i am sure it gets tiring to hear us say that over
and over), instead the developers bring up the issue, if someone seconds
that, people vote and the issue gets resolved, one way or another
now if the technical issue is brought up by a project lead and does not
affect gentoo as a whole, then that project should vote, not all of us
who are not affected, if we like it or 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.
> 

in what world do you live in where 100% of members like decisions the
group makes? cause i wanna go move there.
be realistic. having a majority is enough, you could discuss if needing
a simple or super majority based on what is voted on

did anyone read the policies Ryan linked to (in particular the voting one?)

>> Gentoo should be a fun environment.  The previous paragraph should be
>> taken as
>> a last resort.
> 
> Gentoo is fun to me.
>
gentoo is too political, to too distanced from the developers (on a
decision making basis i mean) to have it be fun, our elitism drives
prospects away, when we should embrace them and use our good judgement
to decide if someone should have commit access, (for one of our projects
to lose a good guy over the rest of us, who have no say over their
project, bitching and moaning when our dev quiz gets criticized is
wrongi should be left to that project to decide if he will work well for
them or not), not some synthetic quiz, the quizes get harder and harder,
but does kloeri have less and less quick in and out devs to remove?

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

i talked about that further up, if the idea only affects your team,
bring it up to your team lead for a vote, if gets seconded, your team
votes, not us who have an opinion about your idea, although we do not
work on anything that is affected by your idea
voting is not limited to all of gentoo voting if it does not affect all
of gentoo

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

well i guess i put that one into so many other points i will not
reiterate but repost the link i would like to see people comment on,
since they happened to vote on this while Ryan wrote this email
i provided him with the link since it made us go "OMG! that's it!"

be fair, nothing i say is final, even if you think i sound like that,
those are my ideas, something i would like to see happen

the link:
http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html

mind you, i would like to discuss a voting policy like it, not smgl,
they do their thing, and we do ours, i just think their voting policy
kicks our behinds....

Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEUrvC/aM9DdBw91cRAh/PAKC2pAKFkM6Vp/y8E7LkhlAAkMCYYwCfSdSP
HRiQH90C3NwVf49PK9cHckU=
=DnLj
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Bryan Østergaard]

On Fri, Apr 28, 2006 at 08:05:06PM -0500, Daniel Goller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Simon Stelling wrote:
> > 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.
> 
> how do you call it then if the entities in place make a decision, after
> some long winded strange tribunal, and when they made a decision, people
> ask "hey where is my vote?", i am not after devrel, what i am saying is,
> noone appreciates their work it seems, so why couldn't they leave the
> decision making to a developer vote, with the saved time, they could go
> on and do something they enjoy/have fun with (those of you in devrel who
> enjoy your devrel work (wrt to conflict resolution) i am glad you do, i
> just don't think many at devrel enjoy hearing they are wrong no matter
> how they decide)
> the people affected by the vote could accept a developer vote much
> easier than a devrel decision
> 
> > 
> >> __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.
> > 
> and we also have lost developers that projects were eager to get on the
> team, from what i recall over the developer questioning why an official
> quiz must be answered by finding things in unofficial docs in dev spaces
> no, that is not hard, but the question was valid, and with the whole
> process allowing all of gentoo to make this possible or not, a developer
> should be put in place by the leads of that project, at the project
> leads discretion, they know the people they plan on hiring much better
> than we know most people in our AT program, ATs have been turned into
> devs after a very short time, the quiz is a silly hurdle if it gages
> your ability to google, not your ability to write ebuilds
You're probably able to answer the quiz questions correctly by googling
(that's on of the goals as we don't want every new developer reading
through all the portage code..) but you're not going to become a
developer that way. After having the quiz answers approved by your
mentor you'll have to talk to your recruiter who'll gauge whether or not
to add you as a new developer. As part of that we're asking additional
questions (usually both technical and organisational questions). I
sometimes think of this as a very condensed form of "super mentoring" as
it also very much helps prepare new developers getting their commit
access.

I often ask new people that I recruit if they think I'm being too hard
on them (after approving them as new devs). So far they've all said it
was very good and that they learned some important things that way. This
is of course a very informal survey but I think it shows that new
developers (in general) don't think the process is too hard.
> 
> > 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.
> 
> we are too possessive, if you give out access to a non-live tree, and
> you see the commits were not fit for merging, and the person in question
> does not learn from advise given, the person does not have to keep
> commit access, but it would be nice to be more inviting than to keep our
> high and mighty attitude, we are not so different from our users, many
> of which are far better than we are, we just passed some strange test
> you can pass by cut& paste or paraphrasing from the right docs, you can
> do that w/o even knowing what you talk about
> 
You're wrong, see above :)
> > 
> > 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.
> > 
> 
> who stops you from fixing something here and there before you merge it,
> you seem to think having a non live tree would unbind us from our
> responsibility to help them become better
> 
> what a non live tree with commits by new people would allow is that
> teams could check what there is to merge and say "great wrk, i merge
> that" instead of just that one developer who works with that user, he
> will be easier part of the family, a team member could approach him and
> tell him, i merged it after quoting all your paths, please do so next
> time, and peope still learn
> 
> if you think passing a test makes you a good driver, then think again,
> it is constant learning and evolvement that makes you a good driver, and
> we give out licenses quite easy, then if you are not suited, bye bye license
> 
> >> 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. ;)
> > 
> 
> read what you wrote closely, you describe how well things work
> currently...i think not, they are overworked due to how involved their
> part of the process is, not because they have 300 new devs to process.
> the hassle is not big, it just delays things, and prooves nothing
> i can mentor someone and later on end up asking him for advise, because
> i saw his abilities and know he is good...better than me when it comes
> to technical issues, him passing the quiz did not tell me that, and
> neither does it tell you anything, seeing his work tells me and you
> something, so let their people's work speak for them, not the passing of
> quizes
> 
> >> Perhaps its because of a live tree...
> > 
> > That's surely a big factor.
> 
> indeed it is, glad people do agree :)
> > 
> >> __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 don't know how perfection threatens our existence...so yeah it
> requires many dedicated perfect gentoo users (that's what we are, gentoo
> users with @gentoo.org email addresses and commit access to a live tree)
> to make things go smooth, and it could go smoother if we had more
> people, in more timezones, in more countries, in more states, you can
> never have to many people, not many have full 56 hours/wk for gentoo, so
> every 1hr per day can make a difference
> 
I'm going to contradict myself slightly here.. Yes, we need more
developers to keep up with all the bugs, package bumping etc. At the
same time I think more developers is the last thing we need.

Why? Simply because more developers means we need to spend a lot more
time communicating with each other, discussing directions of this and
that project etc. If we *really* want to improve we need fewer, more
active developers.

That's one of the goals of my little project cleaning up the developer
base. I'm not going to retire anybody putting "only" 1hr/wk into gentoo
but retiring inactive devs is one small part of raising overall
"quality" of gentoo developers imo.
> > 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?
> > 
> 
> you don't have to merge the whole tree at once, each project has
> developers who work on packages of the herds they maintain, the
> Changelog will tell you why there is a change, if it matters to you, you
> verify and commit, but the nitty gritty of fixing it is long done
> 
> >> __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.
> >
> well, if cvs keeps us from going to a non-live tree, then it does
> pertain to the discussion at hand, just if it should be svn or
> [insertfavoritescmhere] is another point (that could quickly be solved
> with a better voting structure, give the power back to the people,
> simplify things, and then get this issue resolved with a vote)
> 
> >> __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.
> > 
> rather than having a QA policy that deals with punishment of devs, we
> should focus on a system where an accidental commit has less impact, if
> someone makes a commit in another branch, another set of eyes will have
> a chance to catch it instead of things being in everyone's --sync in ~2
> hours, a QA team could still scan the tree for things, but since they
> find problems in the branches rather than the live tree will not have to
> worry about what they do until the issue with the unruly dev is
> resolved, and if the issues are indeed of magnitude, they can go and ask
>  for a developer removal vote, if someone seconds that proposal, all
> developers can vote, and if the devs who vote think the problem is big
> and sizable enough, they can vote +1 for his removal, 0 to abstain or -1
> if they disagree with the measure asked for by QA
> 
> >> 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 shouldn't have an underappreciated overworked entity (not intending
> to upset the members of said entity, i know there are people behind the
> alias) that makes the decisions we ask them to make to hear that they
> did it wrong again (i am sure it gets tiring to hear us say that over
> and over), instead the developers bring up the issue, if someone seconds
> that, people vote and the issue gets resolved, one way or another
> now if the technical issue is brought up by a project lead and does not
> affect gentoo as a whole, then that project should vote, not all of us
> who are not affected, if we like it or not
I strongly disagree with voting, be it by all developers or just the
affected project(s). In the first case the only thing we'll gain is
(relatively) quick, random decisions with no strong base in the
complaint(s). In the second case, we'll have quick decisions made by
obviously biased people - in effect a popularity contest set up to be
unfair in advance.

Now, as developer relations lead I'm obviously biased but I were of the
same opinion even before joining devrel. After devrel have handled a
few conflicts I think the current conflict resolution policy leaves a
lot to be desired. But moving conflict resolution from devrel to more
general voting is the wrong direction.

<snip rest of mail>

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

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

[Christel Dahlskjaer]

Hola Ryan, 

On Fri, 2006-04-28 at 10:14 -0700, Ryan Phillips wrote:
> This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and
> seemant's letter on herds, teams, and projects.
> 
> 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.

There certainly is scope for doing some things better, but this is of no
surprise to any of us. Gentoo has grown and matured quite a lot over the
past few years and what worked with 15 developers doesn't work all that
well with 300+, in the process of finding out what works best we have
(and will continue to) encounter difficulties and situations that
doesn't please everyone. However, I wouldn't say that it's all bad.

> Some of these problems are intermixed.  Please consider them starting points
> for discussion.
> 
> __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. 

Having just completed my ebuild and end quiz last week (having been a
'fake developer/staffer' for a little while longer) I must admit that I
didn't in any way find the quizzes to be at all difficult or hard, and
certainly not at all something that made it more difficult to become a
developer. If anything I found taking the quizzes to be educational,
now, I may be blessed by having Seemant as my mentor; he did ensure that
he took the time to review my quiz properly and that he also took the
time to expand on the questions already asked in the quiz (We played 20
questions and he made me answer a bunch of semi related stuff which in
turn helped me ellaborate on my answers as well as getting a better
understanding of the various bits mentioned in the quiz). And while I
have been around for a bit now, I certainly value the work my mentor did
in ensuring that I felt comfortable and confident before taking the
plunge and submitting.

As for the work involved from recruiters, they certainly didn't leave me
hanging around and when my quizzes were submitted it went pretty fast
ahead, they were marked, passed and my access was changed. 

I personally believe that the quizzes could be more difficult. And I
hope that the current revamp of the recruitment process will be one that
will benefit potential developers as well as current developers, Gentoo
as a whole and of course our user base.

> All these reasons leave the project stagnant and lacking developers.

On the contrary, now while I agree that some projects may be lacking in
man power I think overall there is more likely to be some deadweight. I
know Bryan (kloeri) has done quite a job out of clearing out and
retiring inactive devs, but I still believe that we may be overstaffed
in some areas. Maybe those areas that are lacking need to look at why
they are not attracting people? Or why people who showed interest didn't
stick around for the entire recruitment process? I believe that we need
to ensure that we have top notch, high quality devs rather than aiming
for quantity. 

And of course, we don't want a situation where it's too easy to become a
dev only to have people yo-yo in/out of the project as and when the
fancy takes them.

<snip>

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

Although we are all here to work on Gentoo and hopefully have a unision
goal, the motivation and the ideas for implementation and of course what
we find important differ. For the most part we are a group of pretty
decent people, but we don't always agree. Which is perfectly fine.

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

I am not entirely certain what your definition of conflict is, but in a
group as large as ours there will no doubt be a conflict of interests
and beliefs. People can't be expected to agree 100% all the time, and
lets be realistic, if we did we would be going absolutely nowhere and
this would be terribly boring. 

Now, I believe that having a votes only system in place could be quite
dangerous and could easily be abused. Say Developer X annoyed me, so I
decided to ensure that there was a vote, I could easily fabricate some
reason for why I thought he was bad for the project and I could
certainly win people over on my side to ensure that he was voted out. 

Now, admittedly the current policy for dealing with conflicts of the
sort of nature where action needs to be taken against a developer has
been proven to give more headache than what it's worth and therefor
Devrel are attempting to work on changing the way they deal with this.
Now, the discussion about this has been open on the gentoo-devrel@ ML
for a few days and it appears that no-one has any input on the proposed
new policy at all. 

Personally I would like to see a change, I would like us to be able to
avoid having to go through things such as a hearing process. I would
like for trolling/flaming and personal attacks to be discouraged and
stomped down on as and when they occur rather than when they have become
the sort of problem that affects the morale and motivation for all of
us. But that's a different discussion for a different time and a
different mailing list.


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

Quite. "It's supposed to be fun, too." Now, personally I find Gentoo to
be primarily fun. I am involved with some incredibly awesome teams and I
deal with people who just plain kick arse. And I know that for many they
find the same within their projects/teams/whatevers... It's just a shame
we can't make it global yet ;)

Cheers,
Christel Dahlskjaer





-- 
gentoo-dev@gentoo.org mailing list

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

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]

On Friday 28 April 2006 20:14, Ryan Phillips wrote:
> __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.
>
> 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.
>
> Projects (gentoo/bsd, embedded, hardened) could choose to keep their own
> branches of the portage tree and merge with trunk as needed.  Projects
> could stick to traditional solutions like profiles if they so wished.
>
> Some will probably ask who will merge between branches.  We can do that
> easily ourselves.  If I think a package is good to go, then svn merge
> -r1123:1124 to the branch.

I'm very much in favor of moving to a new SCM, and I see how it could solve 
many problems. But I don't understand how it could remove the need for a live 
tree. Could you explain the new usage pattern you're suggesting here?

If there's no live tree (or live branch), then every commit has to be merged 
from the 'incoming' branch or trunk where it is originally committed to 
the 'outgoing' branch which is directly used by users, even for ~arch chages. 
Is that really what you mean?

And this becomes a lot worse if you want to replace (at least some) KEYWORDS 
with branches, and have to merge each change many times.

Meanwhile, if no-one is using trunk (or the 'incoming' branch) directly 
(because it's not live), what is the benefit of leaving commits there for a 
few hours? It won't help you find most problems.


Apart from having no live tree, though, I understand and like the model of 
having:
- 'Incoming' (sandbox) branches where non-dev affiliates, and new devs, commit 
things which are then reviewed by a full dev/mentor and merged into trunk.
- Branches replacing today's various overlays for devs (or projects, etc) and 
anyone else we might welcome on g.o infrastructure (given per-branch commit 
permissions).
- Short-lived branches to replace things that are today package.masked.
- Branches to replace various non-arch keywords and projects, like hardened 
stuff, some server/ultrastable tree proposals, ...

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Daniel Goller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 
> 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.
> 
> Ryan
> Gentoo Developer
> 
> [1] http://article.gmane.org/gmane.linux.gentoo.devel/37599 
> [2] http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html

I would really like to hear more on [2], get something like it going,
then we could all vote on the scm of choice this thread has succumb to.
Although switching away from cvs is one of the many topics of this mail
(and if you want a foundation for some of the others), it is not the
only one. I would like to hear more on changing how we vote (unless you
all really like how voting is done now, be it problem resolution or
technical innovation), more on developer growth (we should be an open
inviting community) and why you think stricter test make for better
developers, why you think harder tests would cut down more on the quick
in and out people.
I don't just mean to hear the "hells no"s also the "hells yeah"s,
especially those that are just reading and then thinking it.


Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEU20L/aM9DdBw91cRAkPxAKCNB10kVHzVF+okuTc7Pc1Ysuza5QCcCdZ8
cYBVs1j9tBce2wTlCF7x7Tg=
=WWf3
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Jon Portnoy]

On Sat, Apr 29, 2006 at 08:41:31AM -0500, Daniel Goller wrote:
> inviting community) and why you think stricter test make for better
> developers, why you think harder tests would cut down more on the quick
> in and out people.

Empirical evidence agrees.

Our current quiz practices have done a good job keeping out a lot of the 
incompetence that used to slip through before we took that approach.

Stricter tests make for more knowledgable developers and folks with a 
lack of commitment to Gentoo are usually not willing to tackle the 
learning curve.

As for whether or not we're inviting or not, anybody can contribute. 
They don't need to be @gentoo.org to do so. What we really need is to 
focus more on those outside contributions.

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

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

[Daniel Goller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Portnoy wrote:
> On Sat, Apr 29, 2006 at 08:41:31AM -0500, Daniel Goller wrote:
>> inviting community) and why you think stricter test make for better
>> developers, why you think harder tests would cut down more on the quick
>> in and out people.
> 
> Empirical evidence agrees.
> 
> Our current quiz practices have done a good job keeping out a lot of the 
> incompetence that used to slip through before we took that approach.
> 
> Stricter tests make for more knowledgable developers and folks with a 
> lack of commitment to Gentoo are usually not willing to tackle the 
> learning curve.
> 
> As for whether or not we're inviting or not, anybody can contribute. 
> They don't need to be @gentoo.org to do so. What we really need is to 
> focus more on those outside contributions.
> 

so that is where this is all coming from, who said that we should hand
out @gentoo.org ? i never said that, they don't need it, and everyone
gets to feel all special about the @gentoo.org the way they are used to,
a committing contributor does not require a @gentoo.org


and unless you give them a general aptitude and attitude test, you do
not know a thing about the person who answered a few technical questions
(more)

Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEU3pZ/aM9DdBw91cRArKPAKCCr/9TYUc+VTqldUueqXN5RRCUWgCfbSH8
5QfB8r0xd2qAr018yFICd9o=
=aMhC
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Jon Portnoy]

On Sat, Apr 29, 2006 at 09:38:17AM -0500, Daniel Goller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jon Portnoy wrote:
> > On Sat, Apr 29, 2006 at 08:41:31AM -0500, Daniel Goller wrote:
> >> inviting community) and why you think stricter test make for better
> >> developers, why you think harder tests would cut down more on the quick
> >> in and out people.
> > 
> > Empirical evidence agrees.
> > 
> > Our current quiz practices have done a good job keeping out a lot of the 
> > incompetence that used to slip through before we took that approach.
> > 
> > Stricter tests make for more knowledgable developers and folks with a 
> > lack of commitment to Gentoo are usually not willing to tackle the 
> > learning curve.
> > 
> > As for whether or not we're inviting or not, anybody can contribute. 
> > They don't need to be @gentoo.org to do so. What we really need is to 
> > focus more on those outside contributions.
> > 
> 
> so that is where this is all coming from, who said that we should hand
> out @gentoo.org ? i never said that, they don't need it, and everyone
> gets to feel all special about the @gentoo.org the way they are used to,
> a committing contributor does not require a @gentoo.org
>
 
That's called a "figure of speech" -- I was not literally referring to 
the email address but rather Gentoo developer status. Sorry for being 
unclear.

My point was more that commit access is not a prerequisite to 
contribute.

> 
> and unless you give them a general aptitude and attitude test, you do
> not know a thing about the person who answered a few technical questions
> (more)
> 

Sure you do. You know whether they know what they're doing in the tree.

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

[-- Attachment #1: Type: text/plain, Size: 8611 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Tim Yamin]

On Sat, Apr 29, 2006 at 10:33:11PM +0100, Stuart Herbert 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.

That and the test is standardized: the range of questions it asks
people should know the answer to. That's why we have recruiters and
don't give out access to anybody...

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

+1

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

That's the beauty of community-based distros -- with a commercial distro
you can just wave cash and most of the time, things get done. We can't
do that but sooner or later somebody who has the necessary skills to fix
the problems starts shouting and problems do get fixed.

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

Yeah, and this is the problem we need to solve to get more corporate
adoption.

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

Yeah, I think Gentoo's only real PR to users is "Here you go, try it".
Those that do soon find out a lot of things "just work" which is exactly
what people want.

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

I don't think this will work. Your major problem is going to be merging
changes from users working on the arch trees to the dev trees and vice-
versa... users would (unknowingly) work on the arch trees (possibly on
some pretty serious changes) and then be told none of them apply any
longer. The advantage of one tree is that development is streamlined and
is always going in one direction - forward. With large branching this is
still doable. But it needs time and more importantly people and also the
motivation to do the job. And that usually means $$$.

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

I think that's the underlying idea -- if developers aren't up to scratch
the QA team would notice this pretty quickly and "teach the man how to
fish" the "proper way".

> 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 :)

+1

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

In one aspect that's what makes Gentoo work. Somebody comes along with
a product/idea and somebody else comes along with "can I make it flexible
enough to also do X, Y and Z?" [Look at catalyst, for example]
 
> Gentoo should be a fun environment.  I don't see how turning it into a
> popularity contest brings back the fun.

+1. Things generally do need a management structure. I think the one we
have now isn't perfect, but for the most part, it works. It's usually
clear what needs to be done and who you need to speak to get an issue
or proposal moving forward.

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

Sure, and take a whole month or two for a vote. And voting in one or two
days simply doesn't work -- people have a real life and things other than
Gentoo to get on with.

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

It's not working. But the ideas are there, and they're getting submitted
to a centralized place. Going to the email idea threads will just get
lost; at least with a GLEP people know and can very clearly see what
has and hasn't been acted on.
 
> 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.

And too often we've taked on people that commit one or two ebuilds and
then disappear. This only makes our problem worse -- they were supposed
to help (i.e. clean up somebody else's mess usually) and instead said
mess only increases.

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

Right, and thanks to the bug wranglers properly sorting things it's
pretty easy for the motivated person to work on maintainer-needed@
bugs...

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

And who's willing to pay the $$$ to help us get there? :)
-- 
gentoo-dev@gentoo.org mailing list

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

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]

Stuart Herbert wrote:

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

/me puts on his admin hat

Its going to be a bitch to switch to anything and it would be great to
have some quantitative (unbiased) proof that such a move will add enough
benefit for developers and Gentoo to be worth it. Truthfully, I don't
know much about the other VC's out there (git, subversion, etc). But
from what I do know, I would say that subversion has the best bet to be
our preferred replacement.

/me puts on his dev hat

From what I've heard, subversion offers the best features and
flexibility of the other VC's out there. Granted git has some nice
features too, but I'd have to evaluate what we really need.

/me puts on his neutral hat

Subversion would be the best bet now because of viewcvs (now viewvc)
support for it. Changing version control software is going to take a
*bunch* of work. Things I can think of off the top of my head that will
need work will be:

 * repoman support
 * portage regen tools on the master mirror
 * developer documentation
 * developer training (amazing concept!)
 * massive testing of all issues

Here's an idea I had tonight. Since we're going to be doing the Google
SoC this summer, perhaps a great project would be having someone work on
this migration (or at least do an unbiased test implementation). I'd be
willing to provide an infra server for testing/development. I don't see
much problem at least trying to work out all the details. I don't think
infra will go with any change unless there is a clear, detailed
migration plan with proper back-out plans also. The tree is the most
important part of our distribution and I'm not going to let such a
migration go by without proper planning and testing. After the test
implementation is done and has been fully tested, perhaps the council
could make the final decision if infra is happy with the
implementation/migration details.

I'm sure there are going to be unseen issues we won't know about until
we try a migration. It would be neat if I could provide a developer
restricted rsync module on the test box so that they can actually try
using their systems on there.

Anyways, I'd just thought I'd give my input since its going to need to
go through us eventually :). If people like the idea of having a SoC
project for this, let me know and I'll have user-rel add that to the list.

Cheers-

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

[Renat Lumpau]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

On Sat, Apr 29, 2006 at 08:55:52PM -0500, Lance Albertson wrote:
> Stuart Herbert wrote:
> 
> >> __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.
> 
> Here's an idea I had tonight. Since we're going to be doing the Google
> SoC this summer, perhaps a great project would be having someone work on
> this migration (or at least do an unbiased test implementation). I'd be
> willing to provide an infra server for testing/development. I don't see
> much problem at least trying to work out all the details. I don't think
> infra will go with any change unless there is a clear, detailed
> migration plan with proper back-out plans also. The tree is the most
> important part of our distribution and I'm not going to let such a
> migration go by without proper planning and testing. After the test
> implementation is done and has been fully tested, perhaps the council
> could make the final decision if infra is happy with the
> implementation/migration details.

It looks like if/when implemented, GLEP 44 (Manifest2) will significantly reduce
the number of small files in the tree. Whoever ends up doing the initial
benchmarking and testing should probably keep this in mind.

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

On Sunday 30 April 2006 03:55, Lance Albertson wrote:
>
> Here's an idea I had tonight. Since we're going to be doing the Google
> SoC this summer, perhaps a great project would be having someone work
> on this migration (or at least do an unbiased test implementation). I'd
> be willing to provide an infra server for testing/development. I don't
> see much problem at least trying to work out all the details. I don't
> think infra will go with any change unless there is a clear, detailed
> migration plan with proper back-out plans also. The tree is the most
> important part of our distribution and I'm not going to let such a
> migration go by without proper planning and testing. After the test
> implementation is done and has been fully tested, perhaps the council
> could make the final decision if infra is happy with the
> implementation/migration details.

I think that is a good idea. It's a perfect google SoC project as it has a 
clear boundary. Limited prerequisite knowledge is required, and it is 
something we would really benefit from.

Paul

ps. Perhaps the SoC project could include fixing up the migration tools 
(for example including the hypothesis that all ebuilds for a package 
descend from eachother) and other coding necessary to make things work 
perfectly.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

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

[Christel Dahlskjaer]

On Wed, 2006-05-03 at 11:43 +0200, Paul de Vrieze wrote:
> On Sunday 30 April 2006 03:55, Lance Albertson wrote:
> >
> > Here's an idea I had tonight. Since we're going to be doing the Google
> > SoC this summer, perhaps a great project would be having someone work
> > on this migration (or at least do an unbiased test implementation). I'd
> > be willing to provide an infra server for testing/development. I don't
> > see much problem at least trying to work out all the details. I don't
> > think infra will go with any change unless there is a clear, detailed
> > migration plan with proper back-out plans also. The tree is the most
> > important part of our distribution and I'm not going to let such a
> > migration go by without proper planning and testing. After the test
> > implementation is done and has been fully tested, perhaps the council
> > could make the final decision if infra is happy with the
> > implementation/migration details.
> 
> I think that is a good idea. It's a perfect google SoC project as it has a 
> clear boundary. Limited prerequisite knowledge is required, and it is 
> something we would really benefit from.
> 
> Paul
> 
> ps. Perhaps the SoC project could include fixing up the migration tools 
> (for example including the hypothesis that all ebuilds for a package 
> descend from eachother) and other coding necessary to make things work 
> perfectly.

Hiya, 

If one of you drop us a line of what you want included on the ideas
page, or pop into #gentoo-soc on irc.freenode.net we'll get it up
there. :)

Keep in mind, student applications close on the 8th of May, so the
sooner the better.

Christel


-- 
gentoo-dev@gentoo.org mailing list

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

[Ryan Phillips]

Stuart Herbert wrote:
>
> 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
>   

That sounds like a great idea.

-Ryan
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Gentoo: State of the Union

[Molle Bestefich]

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

Agreed.  That doesn't make sense.

Subversion has what is known as pre-commit hooks.
Using those it's very easy to:
 * prevent (most or some) committers from designating ebuilds as stable
 * allow committers to designate ebuilds as stable under a certain path only
 * strictly limit a commiters access to a part of the tree

Slightly harder, but could be done too:
 * deny commits if it breaks ebuild dependencies

If you want central control of what's happening in the repository,
Subversion seems like the way to go.

> SVN requires at least 2x the tree size for storage on the local machine,

This is a feature, not a bug.
It allows you to keep operations local, fx. do a diff without being
online with the repository.

> checkouts take something akin to an order of magnitude longer than CVS.

In the past Subversion performance was sub-par.  I haven't
systematically tested performance, but I would expect it to be much
better now.

Performance is gradually improved, see fx. r18867, r18944 and r19420:
http://svn.collab.net/viewvc/svn?view=rev&revision=18867
http://svn.collab.net/viewvc/svn?view=rev&revision=18944
http://svn.collab.net/viewvc/svn?view=rev&revision=19420

GIT might perform better, since Linus specifically emphasized
non-O(n^2) performance in the design.  But being a decentralized tool,
I'm not sure how well it fits the needs here.

> The former is annoying, but liveable, but
> the latter is a deal-breaker.

I don't think so.  You really rarely do a complete checkout.

> - No changeset/merge tracking

Solutions exist, including svnmerge and svk.
"Official" solution actively worked on at the moment, check out the
svn dev list.

A benefit of Subversion that I personally like is that FSFS
repositories are extremely easy to rsync.

-- 
gentoo-dev@gentoo.org mailing list

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

[Molle Bestefich]

> > If you want central control of what's happening in the repository,
> > Subversion seems like the way to go.
>
> Better to fix the design of the repository, so that it can't be
> broken in the first place, than to try putting band-aids in place
> to cover the gaps.

Wow, way out of scope.
Sure, a Portage that's inherently unbreakable would be nice.
And infinitely more difficult to carry out than what I was proposing.

Also, the two (QA inline in commit process vs. Perfect Portage) does
not preclude each other.  While one may be better long term you
can still do the other to improve quality short term.

(Not that you would need to - if you had a QA step in the commit
 process to make sure that ebuild dependencies were never broken,
 why would you want to create a whole new Portage?

I was trying to say that a QA tool in form of a SVN pre-commit hook
seems like a perfect fit.  The entire infrastructure to run an
external application to check a commit before carrying it out,
approve the commit, send appropriate error messages back to the SCM
client and display them to the user etc. is already in place (and
has been for years) in the Subversion server and any of the client
tools.

The amount of work involved between inventing a couple of rules that
committed ebuilds must obey to actually implementing an enforcement
of said rules is _very_ overcomeable with SVN.

I wasn't even proposing that Gentoo actually needs a QA tool inline
in the process, just saying that it can easily be done [with SVN] :-).


PS. I resent calling it a "band-aid".  It'd be a QA tool built on the
very well-thought-out foundation for quality assurance of commits that
SVN pre-commit hooks happens to be.

-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

Molle Bestefich wrote:
> I was trying to say that a QA tool in form of a SVN pre-commit hook
> seems like a perfect fit.  The entire infrastructure to run an
> external application to check a commit before carrying it out,
> approve the commit, send appropriate error messages back to the SCM
> client and display them to the user etc. is already in place (and
> has been for years) in the Subversion server and any of the client
> tools.

It's already possible with CVS (unless the gentoo/xml/htdocs/ uses some
uber-tweaked implementation :) ).

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]