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

[Paul de Vrieze]

On Thursday 04 May 2006 14:17, Stuart Herbert wrote:
> Talking about an SVN perspective ... provided the trees live in a
> single repository (which would make a lot of sense), it would be very
> straightforward to provide a tool to copy a particular ebuild & its
> files from an unstable tree simultaneously to the other trees.  The
> difficulties with such a tool would be taking over the right files/
> contents (something which is solveable), and what to do about signing
> (where a distribtued system like Git probably makes much more sense
> anyway).

The files content problem should be solved anyway. That way one could even 
make selfcontained ebuild packages including source. A way of 
distributing that would be more appropriate for external ebuilds.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpImatmLNLKQ.pgp
Description: PGP signature

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

[Thomas Cort]

On Thu, 04 May 2006 11:44:18 +0100
Stuart Herbert <[EMAIL PROTECTED]> wrote:
> However, if you have a separate tree per-arch, that tree can be tested  
> and approved for release as a single unit.

How big would this tree be? Would it be every package? How will this make the 
arch teams' life easier and/or the users' experience better? I still fail to 
see how this will work any differently than what we have today. Today we have 
~arch, someone tests the package for stability on an arch system, and marks it 
stable. The tester is effectively integrating the package into a stable system. 
Maybe you could explain how the procedure might go with branches for getting a 
package from just put into the tree to ~arch to arch and what happens with 
version bumps.

~tcort


pgp4rW3LFoaWO.pgp
Description: PGP signature

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

[Stuart Herbert]

On 5/4/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:

On Thu, 2006-05-04 at 11:44 +0100, Stuart Herbert wrote:
>  From a SCM point of view, arches are a subset of the full Gentoo
> tree.  They would fit very well into a branching model - and
> Subversion's support for branching would make it a breeze for us to
> support without overloading the arch teams.

Are you kidding me?  What about people that commit for multiple arches?
They're now going to have to do the same commit over $x number of trees?
How exactly will that not overload the arch teams?


Talking about an SVN perspective ... provided the trees live in a
single repository (which would make a lot of sense), it would be very
straightforward to provide a tool to copy a particular ebuild & its
files from an unstable tree simultaneously to the other trees.  The
difficulties with such a tool would be taking over the right files/
contents (something which is solveable), and what to do about signing
(where a distribtued system like Git probably makes much more sense
anyway).

Given such a tool, you could promote a version of a package to any
number of per-arch trees at the same time.


The more I hear about all of these great features of qall of these
alternative SCM's, the more I think that somebody just has a hard-on for
getting rid of CVS and plans on doing it, no matter the cost to
efficiency and other developers.


What we're talking about here is a step in the development cycle
commonly called 'integration', where something's taken from the
development bucket, put into the 'release' bucket, and tested to
ensure that it plays nice with everything else already in the
'release' bucket.  It should be listed in RUP, CMM, or whatever
development methodology you use locally in your day job.

Adopting this approach would be far more painful with CVS than with
(say) subversion.  Branch management in subversion is infinitely
easier than with CVS.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

On Thu, 2006-05-04 at 11:44 +0100, Stuart Herbert wrote:
>  From a SCM point of view, arches are a subset of the full Gentoo  
> tree.  They would fit very well into a branching model - and  
> Subversion's support for branching would make it a breeze for us to  
> support without overloading the arch teams.

Are you kidding me?  What about people that commit for multiple arches?
They're now going to have to do the same commit over $x number of trees?
How exactly will that not overload the arch teams?

The more I hear about all of these great features of qall of these
alternative SCM's, the more I think that somebody just has a hard-on for
getting rid of CVS and plans on doing it, no matter the cost to
efficiency and other developers.  No, I'm pointing to anyone in
particular.  It just seems that everyone wants to blame CVS for our
problems, when our problems are almost entirely cultural.

Seriously, if I were forced to commit to multiple trees, or branches, or
whatever, I'd simply leave the project since it would be such an
enormous waste of time.  I'm sure lots of others feel the same.  Our
version control system is supposed to be a tool to help us get our work
done, not a hindrance.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

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

[Stuart Herbert]

Quoting Molle Bestefich <[EMAIL PROTECTED]>:


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


Agreed.  That doesn't make sense.


It does if you have a separate stable tree per-arch.  With the current  
tree design, it's too easy to break an arch that you've no intention  
of affecting.


However, if you have a separate tree per-arch, that tree can be tested  
and approved for release as a single unit.


From a SCM point of view, arches are a subset of the full Gentoo  
tree.  They would fit very well into a branching model - and  
Subversion's support for branching would make it a breeze for us to  
support without overloading the arch teams.



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.



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


I'd be interested to see some stats from our CVS logs to back that up.

Best regards,
Stu
--
Stuart Herbert [EMAIL PROTECTED]
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
--



This message was sent using IMP, the Internet Messaging Program.


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

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)

[Paul de Vrieze]

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: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpWMiUJy2oP0.pgp
Description: PGP signature

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

[Paul de Vrieze]

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: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgp4tFTO5NwuU.pgp
Description: PGP signature

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

[Paul de Vrieze]

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: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgppBZT3o6Cal.pgp
Description: PGP signature

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

[Stuart Herbert]

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 [EMAIL PROTECTED]
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
--



signature.asc
Description: This is a digitally signed message part

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

[Chris Bainbridge]

On 30/04/06, Henrik Brix Andersen <[EMAIL PROTECTED]> 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

[Henrik Brix Andersen]

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 <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpa08H1Uq7kt.pgp
Description: PGP signature

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

[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

[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 + 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

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 + suggestion for global dev conference (at bottom, if you want to skip)

[Renat Lumpau]

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.


pgpEJg1nREPxX.pgp
Description: PGP signature

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

[Lance Albertson]

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 <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

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 + 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 fu

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

[Alexandre Buisse]

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.


pgpllA9qF2teS.pgp
Description: PGP signature

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

[Stuart Herbert]

Hi Ryan,

I hope you find these comments useful.

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

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

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

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

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

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

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

> __Problem: Live Tree__
> 
> Having a live tree requires people to be perfect.  People are not perfect and
> requiring it is ridiculous.  I love having commits in my local tree within the
> hour, but having a stable and unstable branch makes a lot of sense.  

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

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

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

Hear, hear.

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

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

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

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

> Conflict resolution should not be a subproject.  It should *not* exist at all.
> Rules need to be in place to avoid conflict.  Having some sort of voting
> structure for all the developers (this doesn't mean requiring everyone to 
> vote)
> and not just the council or devrel makes a lot of sense for most things.  If I
> don't like how someone is acting within the project there should be a vote and
> then see if that person is kicked out.  No trial, no anything besides a vote.
> And if I lose I have to deal with it.  Either stay with the project, or find
> something else.  This solution just works.

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

In any organisation, you have to have key people who understand what the
organisation is about, and who police it to get rid of those people who
from the inside are subverting and attacking the organisation's culture.
An organisation's 

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

[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

[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 t

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

[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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] as well as [EMAIL 
> > PROTECTED] 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 [EMAIL PROTECTED] and [EMAIL PROTECTED] 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

[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

[Fernando J. Pereda]

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


pgp5JAHZLyaXe.pgp
Description: PGP signature

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

[Dan Armak]

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


pgprs6FwXYu3W.pgp
Description: PGP signature

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

[Fernando J. Pereda]

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


pgpeQGlULeJE4.pgp
Description: PGP signature

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

[Dan Armak]

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


pgpKK0WsRkHbd.pgp
Description: PGP signature

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

[Dan Armak]

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


pgp7hV8KLhwgg.pgp
Description: PGP signature

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

[Jan Kundrát]

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


signature.asc
Description: OpenPGP digital signature

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 

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.



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

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

[Chris White]

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


pgphj3s2uEZ85.pgp
Description: PGP signature

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

[Ryan Phillips]

Simon Stelling <[EMAIL PROTECTED]> 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 mos

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

[Ryan Phillips]

Marius Mauch <[EMAIL PROTECTED]> 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


pgpBLVqQi2OKZ.pgp
Description: PGP signature

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 dev

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

[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

[Daniel Goller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ryan Phillips wrote:
> Donnie Berkholz <[EMAIL PROTECTED]> 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/
768Mtotal
localhost64 ffmpeg-0.4.9-p20060302-shared # du -csh /cvs/gentoo-x86/
- --apparent-size
224M/cvs/gentoo-x86/
224Mtotal

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

[Ryan Phillips]

"Fernando J. Pereda" <[EMAIL PROTECTED]> 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


pgpUxk2oFOLaj.pgp
Description: PGP signature

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

[Fernando J. Pereda]

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


pgpBDy9Dpn3Ta.pgp
Description: PGP signature

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

[Fernando J. Pereda]

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


pgpgWkOwhe4QL.pgp
Description: PGP signature

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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] as well as [EMAIL PROTECTED] 
> 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

[Ryan Phillips]

"Fernando J. Pereda" <[EMAIL PROTECTED]> 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


pgpDqAkxf42aD.pgp
Description: PGP signature

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

[Thomas Cort]

On Fri, 28 Apr 2006 21:42:57 +0200
Bryan Østergaard <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] as well as [EMAIL PROTECTED] 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


pgptBnvwxt1RL.pgp
Description: PGP signature

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

[Ryan Phillips]

"Fernando J. Pereda" <[EMAIL PROTECTED]> 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


pgpYAOsjE8CQ3.pgp
Description: PGP signature

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

[Fernando J. Pereda]

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


pgpEnrmtBVaXl.pgp
Description: PGP signature

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

[Fernando J. Pereda]

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


pgpZfPqD2Ec9B.pgp
Description: PGP signature

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

[Ryan Phillips]

"Fernando J. Pereda" <[EMAIL PROTECTED]> 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


pgpFFG53shvAt.pgp
Description: PGP signature

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

[Ryan Phillips]

Donnie Berkholz <[EMAIL PROTECTED]> 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


pgpMfm2NTwBbL.pgp
Description: PGP signature

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

[Fernando J. Pereda]

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


pgpuShtf3rkjZ.pgp
Description: PGP signature

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

[Grant Goodyear]

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


pgpG8lLk2QGJl.pgp
Description: PGP signature

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

[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]

Donnie Berkholz <[EMAIL PROTECTED]> 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


pgpTsXgV9yu6w.pgp
Description: PGP signature

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]

Grant Goodyear <[EMAIL PROTECTED]> 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, 

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

[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

[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 <[EMAIL PROTECTED]> 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

[Bryan Østergaard]

On Fri, Apr 28, 2006 at 11:22:05AM -0700, Ryan Phillips wrote:
> Jon Portnoy <[EMAIL PROTECTED]> 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.
> 
> > > Conflic

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

[Alin Nastac]

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?


signature.asc
Description: OpenPGP digital signature

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

[Stephen Bennett]

On Fri, 28 Apr 2006 12:03:29 -0700
Chris White <[EMAIL PROTECTED]> 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

[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

[Grant Goodyear]

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


pgpjHkscJlgrf.pgp
Description: PGP signature

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

[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

[Grant Goodyear]

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


pgpDLnBJpwh7K.pgp
Description: PGP signature

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

[Chris White]

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


pgpsEo0jFFxVO.pgp
Description: PGP signature

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

[Ryan Phillips]

Alin Nastac <[EMAIL PROTECTED]> 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


pgplEy9kSx55S.pgp
Description: PGP signature

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

[Grant Goodyear]

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

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

> __Problem: Live Tree__
> 
> Having a live tree requires people to be perfect.  People are not
> perfect and requiring it is ridiculous.  I love having commits in my
> local tree within the hour, but having a stable and unstable branch
> makes a lot of sense.  

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

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

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

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

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

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

> Conflict resolution should not be a subproject.  It should *not* exist
> at all.  Rules need to be in place to avoid conflict.  Having some
> sort of voting structure for all the developers (this doesn't mean
> requiring everyone to vote) and not just the council or devrel makes a
> lot of sense for most things.  If I don't like how someone is acting
> within the project there should be a vote and then see if that person
> is kicked out.  No trial, no anything besides a vote.  And if I lose I
> have to deal with it.  Either stay with the project, or find something
> else.  This solution just works.

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

> __Problem: GLEPs__
> 
> I dislike GLEPs.  Usually they sit on the website for a long long time
> not doing anything.  My vote (+1) is get rid of gleps and do
> everything by email and a vote by the developers.  AFAIK, the board
> votes on the GLEPs.  Bad Idea.  It stifles things from getting done,
> and there is no ownership of who is going to implement the idea.

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

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

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

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

[Ryan Phillips]

Chris White <[EMAIL PROTECTED]> 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


pgpR35ZcUmZet.pgp
Description: PGP signature

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

[Alin Nastac]

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


signature.asc
Description: OpenPGP digital signature

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

[Ryan Phillips]

Alec Warner <[EMAIL PROTECTED]> 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 

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

[Chris White]

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


pgpbeCyYZYYeh.pgp
Description: PGP signature

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

[Ryan Phillips]

Jon Portnoy <[EMAIL PROTECTED]> 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.  

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

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

[gentoo-dev] Gentoo: State of the Union

[Ryan Phillips]

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 e