[gentoo-dev] [RFC] New metastructure proposal

[gentoo-dev] [RFC] New metastructure proposal

[Alexandre Buisse]

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

Hi everyone,

as everyone probably noticed, there is a current atmosphere of sinking ship,
with quite a lot of people leaving and many agreeing that gentoo is no fun
working on anymore. Before it's too late, I'd like to propose a big reformation
that would help solve some of the issues we are currently having and,
hopefully, bring back some of the fun we all had developing and using this
distribution.


The basic idea is to make gentoo a lot more meta than it already is. Something
that is said quite often is that gentoo lacks a direction. Some people want it
to be a business-oriented distribution, some want it to be bleeding-edge, some
a multimedia, development platform, you name it. Obviously, arbitrarily
choosing one of those directions would mean losing a lot of developers, and
this is something we can't afford to do. The solution, of course, is to go
meta: provide a set of tools that allow people to build the distribution of
their dreams.
This is something that we are already trying to do, but my opinion is that we
are not going far enough. For one thing, we target users as the one who should
build and customize their distribution, while it would be pretty interesting
to also target ourselves as the ones who should be doing this "instantiation"
work. Stage 4's were going in this direction, but they were too isolated and, as
far as I know, they are dead now.



The idea is pretty simple: modularization. There is a core part, with a couple
hundred packages that are absolutely necessary to a system. Then we have a
hierarchy of overlays with additional ebuilds for people's need. Top-level
projects could look like: desktop, dev, business, embedded, misc. Then we
would have subprojects, e.g. multimedia, DE, games for desktop, multimedia
being itself subdivided in audio and video, and so on. This would get us a
tree of arbitrary depth, with development happening mostly in leaves. The
hierarchy would mostly serve as a classification tool, and projects would not
necessarily share resources, including devs, with their subprojects, neither
should they have decision power over them.

This structure has many advantages, one of those being that since projects are
autonomous, they handle their own recruitment, which helps the dev/user
distinction fade away. It concentrates development in small areas where people
will know each other well and be able to interact efficiently.  By
decentralizing, we remove the need for a big authority and give everyone the
freedom they want. The current devrel authority is reduced to only the core
project, though people could still ask its wisdom whenever conflicts pop up.
Basically, the only job involving red tape and a central authority is deciding
who gets the nice "gentoo official project" stamp, and the resources infra can
then provide. Of course, QA would be the main, if not only, criterion in this
choice.

By having everything as modular as possible, we also allow an easy fork of a
single project, for whatever reason. So if enough people think that mozilla is
being badly maintained by the current project and that people in it don't want
or can't apply their fixes, they can easily provide their own overlay with
better ebuilds.  And if their version is indeed better, over time it will get
the official status and have superseeded smoothly the first project. Think of
paludis and pkgcore vs portage.



So far, I've come up with two main disadvantages to this reformation. The first
is that dependencies between different projects could become a problem if not
handled carefully. For one thing, they would require a change to ebuild
syntax, along the lines of DEPEND="dev.perl.libs:libfoo", and of course
support from package managers. Pulling single ebuilds when required instead of
a full overlay would be a nice thing to have as well. Another idea to simplify
this would be to have a central DB with every known ebuild in it (including
non-official, bad QA ones) and the names of repositories/projects providing
it. This would give enough information to package managers for them to make
intelligent choices about how they should behave.

The other big problem is that a migration to this structure would require a
lot of effort from everyone. The good news is that we could use the
opportunity to migrate to a nicer scm (and given what gentoo would look like,
a distributed one like mercurial or git would be a natural choice) and also
that we would get a good idea of what is maintained and what isn't. Leaving
out stuff that no-one wants would then be very easy. Also, I believe that by
having a clear goal, everyone should get a huge motivation boost and I believe
that things could go quite smoothly, and even quickly.



Of course, many details have been left out that should be discussed and solved
before any decision is taken. Among those is the status of arch teams, which
is a bit unclear. An idea would be to have the main three or four most-used
arches (x86, amd64, ppc would be my guess) in KEYWORDS, as usual, along with a
list of repositories that given person is allowed to keyword in, keeping arch
teams organized as they currently are. Other arches would be projects of their
own, with some kind of meta-overlay that specifies which ebuild from which
overlay has been tested, etc. Or we could make no distinction between popular
and less popular arches, I don't really have any opinion on the matter. 
Also, what to do about stuff that isn't specific to any project, even
though it wouldn't happen so often? For instance, deciding whether we
should participate in SoC, or this kind of things. We could use a
council as currently, or ask for representatives of all official
projects to punctually decide, or organize a general vote, or maybe even
something else.



To end this proposal, let me say that without a doubt, there are many holes
and hidden problems in it. I don't claim it's perfect, nor that it will
magically solve our problems. But I think it is a better structure than the
one we currently have, and that switching would reduce, perhaps even stop, the
dev bleeding, bring back freedom as well as fun, and help ease the tensions.

Please criticize this with everything constructive you can think of.


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

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Petteri Räty]

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

Alexandre Buisse kirjoitti:
> Hi everyone,
> 
> as everyone probably noticed, there is a current atmosphere of sinking ship,
> with quite a lot of people leaving and many agreeing that gentoo is no fun
> working on anymore. Before it's too late, I'd like to propose a big reformation
> that would help solve some of the issues we are currently having and,
> hopefully, bring back some of the fun we all had developing and using this
> distribution.
>

I can say that inside all the teams I work with things are just fine and
fun as ever. :)
IMHO it's just this mailing list that is perceived rotten in some
people's eyes. Only time time will if the ongoing changes will help.

> 
> The idea is pretty simple: modularization. There is a core part, with a couple
> hundred packages that are absolutely necessary to a system. Then we have a
> hierarchy of overlays with additional ebuilds for people's need. Top-level
> projects could look like: desktop, dev, business, embedded, misc. Then we
> would have subprojects, e.g. multimedia, DE, games for desktop, multimedia
> being itself subdivided in audio and video, and so on. This would get us a
> tree of arbitrary depth, with development happening mostly in leaves. The
> hierarchy would mostly serve as a classification tool, and projects would not
> necessarily share resources, including devs, with their subprojects, neither
> should they have decision power over them.
>

Splitting the tree is a nice idea but first we would need to solve the
problems that have come up in previous threads about this some of which
you outline later.

> 
> By having everything as modular as possible, we also allow an easy fork of a
> single project, for whatever reason. So if enough people think that mozilla is
> being badly maintained by the current project and that people in it don't want
> or can't apply their fixes, they can easily provide their own overlay with
> better ebuilds.  And if their version is indeed better, over time it will get
> the official status and have superseeded smoothly the first project. Think of
> paludis and pkgcore vs portage.
>

Hmm. Should I emerge mozilla-firefox from module A or module B. Both
have web sites claiming theirs is better. Flame on. Maybe we should just
focus on QA being able to kick out people who do a lousy job.

Regards,
Petteri


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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote:
> work. Stage 4's were going in this direction, but they were too isolated and, as
> far as I know, they are dead now.

Wow.  I'm glad to see that yet another thing I spend so much time
working on is marginalized or otherwise discounted because someone
couldn't take 3 seconds to check their facts before making a post.  The
stage4 concept is alive and kicking.  It is one of the targets made by
catalyst, and likely something we will be utilizing much more in later
releases.

If anyone has further questions about the stage4 target or how it's
utilized in catalyst, feel free to drop onto the gentoo-catalyst mailing
list and ask.

Now, just to stay on topic with this posting, I have some simple (yeah
right) questions.

Will this actually resolve any of the recent problems?

Will this stop flame wars?

Will this cause people be nicer to each other?

Will this give us more qualified developers?

Will this increase the quality of the tree?

Restructuring the project isn't going to solve these problems.  At best,
it will mask them during the time that we've wasted restructuring only
to find that we are back with the same set of problems, though now
without any form of centralized management to have even the glimmer of
hope of being able to resolve them.  It will take us to a complete mess
of incompatible overlays and trees.  It also places the projects in a
hierarchy that doesn't match the actual power structure.

If the parent project doesn't govern the sub-project, then why is it a
sub-project, at all?

What exactly are all of us supposed to actually *do* while we're waiting
for the SCM conversion and for the package managers to get the support
necessary and all of the changes are made to the tree?  Do we simply
stop developing the distribution for days?  Weeks?  Months?

I think that the clique-like nature of many projects is part of the
problem.  We already have too much of a "us versus them" mentality.

How will moving to having lots of independent projects with no central
authority make Gentoo better?

Will it make the distribution better for our users?

Reading back over your proposal with my questions in mind leaves me with
exactly one last question.

What, exactly, is your proposal supposed to actually accomplish?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[paul]

Chris Gianelloni schrieb:
> On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote:
>> work. Stage 4's were going in this direction, but they were too isolated and, as
>> far as I know, they are dead now.
> 
> Wow.  I'm glad to see that yet another thing I spend so much time
> working on is marginalized or otherwise discounted because someone
> couldn't take 3 seconds to check their facts before making a post.  The
> stage4 concept is alive and kicking.  It is one of the targets made by
> catalyst, and likely something we will be utilizing much more in later
> releases.
Nice to hear ;)
As already noted, splitting the tree at arbitrary boundaries will not
work. However, I think I understand the motivation that drives the
proposal in the first place. My feeling is: things getting more complex
(ebuild wise, deps, more packages),  it's just so easy to step on other
ppls feet these days ;)

maybe its time to kill the life tree?

/me runs away ;)

cheers
 Paul
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal

[Alon Bar-Lev]

On 4/10/07, Alexandre Buisse <nattfodd@gentoo.org> wrote:
> Hi everyone,
>
> as everyone probably noticed, there is a current atmosphere of sinking ship,
> with quite a lot of people leaving and many agreeing that gentoo is no fun
> working on anymore. Before it's too late, I'd like to propose a big reformation
> that would help solve some of the issues we are currently having and,
> hopefully, bring back some of the fun we all had developing and using this
> distribution.

Thank you for bringing this up. I think the discussion is very important.

It is first time I response to a "political" issue here... So forgive
me if I am totally wrong.

I don't think this is the reason people are leaving.
I think people are leaving because a lack of direction.
I am not aware of any goal Gentoo distribution wish to acquire. For
example: Do we wish to use a mainstream distribution? Do we aim to a
specific user community? Or Do we develop distribution for our use?

If you wish to be (And I think we should be) mainstream distribution,
we should derive targets, such as QA level, response times and
content.

Being more modular is one technical feature to achieve better
stability. But we should discuss the basics first.

I hear a lot that open source project with unpaid developers cannot be
committed to deadlines or requirements from its developers, but I
disagree. There can be an open source project with high quality
products and dead lines, if these properly defined.

I am quite new here, but it seems like there are few groups here, from
a group that interested in anarchy to a group that interested in
formal hierarchy.

I must disclose that in my view whenever a large group of people are
doing something together, some kind of hierarchy must be in place. And
I am not talking about current council, it seems that current council
does not LEAD Gentoo anywhere.

I read that sometime in history there was an effort to impose
structural format on the community, but then Daniel Robbins left?

If we wish to be a major distribution, we must grow. If we to grow we
must organize our-self better, and work toward a common goal. Common
goal forces decision making. Decision making forces leadership.
Leadership forces vision.

Is there any vision?

Now, for your idea.
When I written something similar in the past, someone told me that it
was already suggested... I don't know why it wasn't accepted.

I think too that ebuilds should exists in several overlays. At least:
Stage3 (current)
Base (baselayout, networking, boot loaders etc)
<herd>-tear-<N>

Each tear should have commitments for:
1. Time from upstream release package until it in overlay.
2. Time from security issue until it in stable.
3. Time from stable request until make stable per each platform.
4. Time for addressing bug, time for solving bug.
5. Keep last N stable version (major, minor).
I guess you got the idea.

For example, for crypto there can be several overlays, tear-1 overlay
with core packages, tear-2 with misc packages, tear-3 with supported
at free-time bases.
Each tear has its own measures.

tear-1 desktop cannot be dependent on tear-2 crypto, the desktop herd
need to ask crypto herd to move the package into tear-1 before
dependency is added.

I totally agree that each user may ask for package of specific
overlay, but I think that this should not be specified in the build,
but by the user at /etc/portage.

For example, I decide that dev-libs/gtk+ should be from overlay X the
portage should take it from there.

But I believe we should first discuss the community goals, then derive
a technical solution.

Best Regards,
Alon Bar-Lev.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] New metastructure proposal

[Alexandre Buisse]

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

On Tue, Apr 10, 2007 at 22:32:20 +0200, Chris Gianelloni wrote:

> On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote:
> > work. Stage 4's were going in this direction, but they were too isolated and, as
> > far as I know, they are dead now.
> 
> Wow.  I'm glad to see that yet another thing I spend so much time
> working on is marginalized or otherwise discounted because someone
> couldn't take 3 seconds to check their facts before making a post.  The
> stage4 concept is alive and kicking.  It is one of the targets made by
> catalyst, and likely something we will be utilizing much more in later
> releases.

Sorry about that, I should have taken the time to look it up. Since I
didn't hear about it after Stuart leaved, I assumed no one was working
on it anymore.

 
> If anyone has further questions about the stage4 target or how it's
> utilized in catalyst, feel free to drop onto the gentoo-catalyst mailing
> list and ask.
> 
> Now, just to stay on topic with this posting, I have some simple (yeah
> right) questions.
> 
> Will this actually resolve any of the recent problems?

Yes, as I tried to explain in the proposal.

 
> Will this stop flame wars?

Probably not, but it can help reduce the volume, hopefully. Indirectly,
of course, but I believe it would help a lot to reduce the tensions.

 
> Will this cause people be nicer to each other?

Definitely, yes. Because everyone will work on a smaller scale.

 
> Will this give us more qualified developers?

Will depend on how each team will do its recruitment. And of course, to
get official status, some kind of council would ensure some minimal
qualifications (along the current guidelines would be my guess).

 
> Will this increase the quality of the tree?

Hard to tell. Having people leave the project out of disgust certainly
doesn't improve it.

 
> Restructuring the project isn't going to solve these problems.  

Not all of them, of course. And I never pretended it would. But I
believe that it would definitely help.


> At best,
> it will mask them during the time that we've wasted restructuring only
> to find that we are back with the same set of problems, though now
> without any form of centralized management to have even the glimmer of
> hope of being able to resolve them.

I don't see how not having a centralized management would make it
impossible to solve problems. Or are people really that stupid that they
can't manage to get together and reach a decision, in some way or
another (I gave some ideas in the last part of the email as well). Just
giving all your power of decision to a big boss is a very crude and
unefficient way of solving problems.


> It will take us to a complete mess
> of incompatible overlays and trees.  

If we do it carelessly, certainly. But free software has solved much more
complex problems in the past.


> It also places the projects in a
> hierarchy that doesn't match the actual power structure.

Power structure? I'm afraid I don't understand what you mean here.

 
> If the parent project doesn't govern the sub-project, then why is it a
> sub-project, at all?

To ease coordination and make obvious relationships clearer, I guess.
Can also help overlay management with hints like "you've pulled the
audio overlay, you probably also want the multimedia one" and stuff like
that. But it isn't really important, and the name "subproject" is
probably misleading.

 
> What exactly are all of us supposed to actually *do* while we're waiting
> for the SCM conversion and for the package managers to get the support
> necessary and all of the changes are made to the tree?  

Keep working on the current version? I don't know, I would classify that
as an implementation detail to be sorted if we actually decide to go
forward.


> Do we simply
> stop developing the distribution for days?  Weeks?  Months?

I'm sure we can find a better solution than that. But do we want to
discuss such tiny details before the big plan itself?

 
> I think that the clique-like nature of many projects is part of the
> problem.  We already have too much of a "us versus them" mentality.

I'm not sure what you mean. Which projects are you speaking about? It
sounds like a silly accusation to me, but perhaps I'm unaware of some
other case.

 
> How will moving to having lots of independent projects with no central
> authority make Gentoo better?

I have said this in the proposal. If you don't agree on specific points,
please provide arguments to back up your position.

 
> Will it make the distribution better for our users?

Because gentoo won't be dead in a couple months? Because people will
think again that it's a fun project and want to be part of it?

 
> Reading back over your proposal with my questions in mind leaves me with
> exactly one last question.
> 
> What, exactly, is your proposal supposed to actually accomplish?

What I *want* to do is to make gentoo fun again. And I believe that
decentralising and giving more autonomy to people will achieve exactly
that, for reasons explained in the proposal.

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

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Tue, 2007-04-10 at 22:50 +0200, paul@subsignal.org wrote:
> it's just so easy to step on other
> ppls feet these days ;)

I tend to agree that this is a problem, but only insofar as we've become
too territorial.  Many times I see bugs filed with seemingly minor
changes being asked for.  A good example is bug #173884 which is a
completely valid request.  The change is simple, removing
"insinto /etc/env.d ; doins $somefile" and replacing it with "doenvd
$somefile" instead.  Now, this is something that *anyone* with commit
access should feel comfortable doing to *anyone's* packages without fear
of being attacked for touching someone else's packages.  Unfortunately,
we're all a bit too territorial over what we keep in the tree sometimes.
If we had more explicit freedom to touch other people's packages for
minor things, we would go a lot further towards the goal of being a
community of mutually respectful people working towards a common goal.
Our rule of thumb here is pretty simple... "If you touch it, don't break
it.  If you break it, fix it."  Some people have become too frightened
to touch packages for even typo fixes due to the territoriality of some
of our developers.  We need to fix this and have a more open and
welcoming feeling for new developers and old developers alike.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Petteri Räty]

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

Alexandre Buisse kirjoitti:
> 
> What I *want* to do is to make gentoo fun again. And I believe that
> decentralising and giving more autonomy to people will achieve exactly
> that, for reasons explained in the proposal.
> 

I am a project lead for two projects and have no idea what kind of more
autonomy I would need for my two projects.

Regards,
Petteri
--
Gentoo/Java project lead
Gentoo/Recruiters project lead


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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Joshua Jackson]

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

Petteri Räty wrote:
> Alexandre Buisse kirjoitti:
>   
>> What I *want* to do is to make gentoo fun again. And I believe that
>> decentralising and giving more autonomy to people will achieve exactly
>> that, for reasons explained in the proposal.
>>
>>     
>
> I am a project lead for two projects and have no idea what kind of more
> autonomy I would need for my two projects.
>
> Regards,
> Petteri
> --
> Gentoo/Java project lead
> Gentoo/Recruiters project lead
>
>   
I agree as a Project lead of another...I don't think more autonomy is
needed..Basically I'm allowed to do what Is best with the team (and that
amounts to mostly just patting people on the back. Good job x86 team
members btw <---see there's a pat on the back). So really, I think most
project leads are there to a, give a direction to the team, and once its
there twiddle our thumbs and go yay I got good people under me who work
hard. its management at its finest ;)


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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Petteri Räty]

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

Chris Gianelloni kirjoitti:
> On Tue, 2007-04-10 at 22:50 +0200, paul@subsignal.org wrote:
>> it's just so easy to step on other
>> ppls feet these days ;)
> 
> I tend to agree that this is a problem, but only insofar as we've become
> too territorial.  Many times I see bugs filed with seemingly minor
> changes being asked for.  A good example is bug #173884 which is a
> completely valid request.  The change is simple, removing
> "insinto /etc/env.d ; doins $somefile" and replacing it with "doenvd
> $somefile" instead.  

Or it's plain boring to fix that stuff and if you make people fix their
own packages first, the boring part is distributed. I for example would
fix the ChangeLog syntax problem for all ChangeLogs in the tree but I
know that it's damn boring so I just prefer to get the check into
repoman and let time deal with it. If I ever get to writing an automatic
fixer, I still you need to check the changes or otherwise I could be
committing broken fixes because of false positives.

Regards,
Petteri


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

[gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal

[Rémi Cardona]

Alexandre Buisse a écrit :
[snip]

My experience is limited to the gnome packages and just based on those, 
your proposal is already not doable.

Gnome deps on :
- core glib/gtk packages, used by many other packages, including 
"server" packages, but "owned" by the gnome herd
- dbus/hal, handled by gentopia
- fd.o packages, some handled by us, some by the x11 herd, some by 
individual devs
- mozilla, ...

I could go on for a while ...

While some change in Gentoo could bring some fresh air, your proposal 
would be impossible for us, and possibly worse for other teams/herds.

The current status quo for the gnome team is to work with all the other 
herds on an as-needed basis, with some devs being proxies for the rest 
of the team based on who gets along with whoever.

So far it seems to be working fine.

Hope my 0.02€ worth of explanations weren't too braindead :)

Rémi
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] New metastructure proposal

[Marius Mauch]

On Tue, 10 Apr 2007 21:32:49 +0200
Alexandre Buisse <nattfodd@gentoo.org> wrote:

[snip]
> Please criticize this with everything constructive you > can think of.

This idea of putting almost everything into its own repo/overlay will IMO end up in the same mess that several other distros have with tons of 3rd party repos that don't play nice with each other. In case you don't know, the "one stop" philosophy with one central repo is what attracts a lot of people to Gentoo.
And no, inter-repo deps won't solve that problem.

Also you said you're trying to solve the "lack of goals" problem (which I don't think is a real problem in the first place) which wouldn't really solved by this proposal either, not without duplicating a lot of work at least.

I like the part about projects being self-organizing, but splitting up the tree is a no go from my POV.

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Charlie Shepherd]

On 10/04/07, Alexandre Buisse <nattfodd@gentoo.org> wrote:
> Hi everyone,
>
> as everyone probably noticed, there is a current atmosphere of sinking ship,
> with quite a lot of people leaving and many agreeing that gentoo is no fun
> working on anymore. Before it's too late, I'd like to propose a big reformation
> that would help solve some of the issues we are currently having and,
> hopefully, bring back some of the fun we all had developing and using this
> distribution.

I can't see any great advantage of this new structure, and indeed I
think it will lead to more chaos and anarchy than there is already.

> The basic idea is to make gentoo a lot more meta than it already is. Something
> that is said quite often is that gentoo lacks a direction. Some people want it
> to be a business-oriented distribution,

I think the idea with this was of "freezing" the tree, and then only
adding bugfixes to the frozen tree to provide enterprise level QA.

> some want it to be bleeding-edge

I think you'd struggle to get Gentoo to stop being on the bleeding edge :)

> , some
> a multimedia, development platform, you name it.

Don't these relate more to the packages we provide than our structure?

> Obviously, arbitrarily
> choosing one of those directions would mean losing a lot of developers, and
> this is something we can't afford to do.

We could of course move in several directions at once...

> The solution, of course, is to go
> meta: provide a set of tools that allow people to build the distribution of
> their dreams.

Don't we already provide most of these tools?

> This is something that we are already trying to do, but my opinion is that we
> are not going far enough.

How does this proposal help to bring us forward in this respect?

> This structure has many advantages, one of those being that since projects are
> autonomous, they handle their own recruitment,

Will this decrease QA?

> which helps the dev/user
> distinction fade away.

I'm not convinced of this distinction. While many people cite the
interactions on the forums, mailing lists or bugzilla as evidence of
it, if you look at IRC I think you see a quite different picture. I
know several users who I get on well with, and who participate

> It concentrates development in small areas where people
> will know each other well and be able to interact efficiently.  By
> decentralizing, we remove the need for a big authority and give everyone the
> freedom they want.

Just because people want freedom doesn't mean they won't abuse it.

> The current devrel authority is reduced to only the core
> project

I don't think this is a good idea. Most projects are short on people
already, without having to have their members wasting time policing
themselves.

> By having everything as modular as possible, we also allow an easy fork of a
> single project, for whatever reason. So if enough people think that mozilla is
> being badly maintained by the current project and that people in it don't want
> or can't apply their fixes, they can easily provide their own overlay with
> better ebuilds.

People can already do this anyway, they just need to put up a tarball
and pop into #gentoo-overlays and ask it be added to the overlay list
for layman.

> And if their version is indeed better, over time it will get
> the official status and have superseeded smoothly the first project. Think of
> paludis and pkgcore vs portage.

This is hardly a good example. Pkgcore and paludis both have totally
different codebases to portage, heck, paludis is written in a
different language. What you talk about above is different _ebuilds_,
and I have yet to see a serious dispute over ebuilds that has not been
settled in tree. The only existing ones I can think of are new
unstable or live ebuilds for packages that the maintainer will not
accept.

> So far, I've come up with two main disadvantages to this reformation. The first
> is that dependencies between different projects could become a problem if not
> handled carefully.

I think this is the least of your worries.

> For one thing, they would require a change to ebuild
> syntax, along the lines of DEPEND="dev.perl.libs:libfoo", and of course
> support from package managers. Pulling single ebuilds when required instead of
> a full overlay would be a nice thing to have as well.

The extended atom syntax allows a repo-id to be included in the atom,
in the form category/package::repo (versions, slots etc can be
included too). You could have kde-base/kde::kde for the kde package
from the kde repo for example. This would at least make this proposal
slightly less chaotic were it actually to take place.

> Another idea to simplify
> this would be to have a central DB with every known ebuild in it
> (including
> non-official, bad QA ones)

Who would put in this information? Wouldn't it be easier to fix the QA
problems rather than listing them? Unless the ebuilds are in a
different overlay, oh wait they are(!). This is a problem with the
whole "lets split the tree up into overlays" idea. People act as
though devs being allowed to commit to the whole tree is a bad idea. I
have seen several mails expressing this, and talked to several people
on IRC who were shocked when they realised this. Why? The whole point
of being given commit access is that Gentoo is trusting that person to
commit to the tree, and if they are not trusted enough to commit to
the whole tree they should not have been given access in the first
place.

> and the names of repositories/projects providing
> it. This would give enough information to package managers for them to make
> intelligent choices about how they should behave.

Another format?

> The other big problem is that a migration to this structure would require a
> lot of effort from everyone.

> The good news is that we could use the
> opportunity to migrate to a nicer scm

This hardly seems to offset the negative effects.

> (and given what gentoo would look like,
> a distributed one like mercurial or git would be a natural choice)

Not at all. Just because projects would be tiered does not mean they
would naturally lend themselves to a distributed scm, they would in
effect just be overlays. See the scm topic for more discussion on
this.

> and also
> that we would get a good idea of what is maintained and what isn't. Leaving
> out stuff that no-one wants would then be very easy. Also, I believe that by
> having a clear goal, everyone should get a huge motivation boost and I believe
> that things could go quite smoothly, and even quickly.

Just because stuff isn't maintained doesn't mean that it's not being
used, and if it's not broken I fail to see why it should be removed.

> Of course, many details have been left out that should be discussed and solved
> before any decision is taken. Among those is the status of arch teams, which
> is a bit unclear. An idea would be to have the main three or four most-used
> arches (x86, amd64, ppc would be my guess) in KEYWORDS, as usual, along with a
> list of repositories that given person is allowed to keyword in, keeping arch
> teams organized as they currently are. Other arches would be projects of their
> own, with some kind of meta-overlay that specifies which ebuild from which
> overlay has been tested, etc.

This demonstrates how badly the idea of splitting the tree into
multiple overlays scales imo. Unless you give arch teams access to all
repos. But what about the recent kde vs. mips incident? What if the
kde team decided to disallow the mips team access to their repo? Who
looses out in the end? Users.

>  But I think it is a better structure than the
> one we currently have, and that switching would reduce, perhaps even stop, the
> dev bleeding, bring back freedom as well as fun, and help ease the tensions.

/me would strongly disagree

> Please criticize this with everything constructive you can think of.

While I like and respect you, I can say with my hand on my heart, I
hope this proposal is never implemented.


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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Denis Dupeyron]

(Quoting Chris below, but actually replying to Alexandre)

On 4/10/07, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> Will this actually resolve any of the recent problems?

That's a good point, let's list them.

> Will this stop flame wars?

This a mailing-list issue, no amount of restructuring will fix that.
We now have the CoC and a splitting of -dev is planned to be discussed
at next council meeting. So it surely doesn't look like nothing is
being done about this.

> Will this cause people be nicer to each other?

See above. In the end niceness needs fun, and fun needs niceness. All
we need is to prime the pump. This requires an effort from everybody,
but I'm confident we'll make it in the end.

> Will this give us more qualified developers?

Recruiters are working hard to get new, better people in. Again,
structure has nothing to do with this. We may need more recruiters and
a polishing of the recruiting procedures, but this is already being
addressed. A new recuiters lead and the equizapp project are good
examples of what is being done.

> Will this increase the quality of the tree?

QA issue, here, and again they may need more people, better
procedures, and maybe more power but it isn't a structure issue.
Splitting projects (and thus people) even more than what they are
today will only result in a QA nightmare, as it will be very difficult
to maintain (or worse, to enforce) a suitable level of quality and
consistency.

> I think that the clique-like nature of many projects is part of the
> problem.  We already have too much of a "us versus them" mentality.

Right on. What we need is unity and coherence. We need to be facing
issues together, not creating new needless ones. With Gentoo growing
everyday it's certainly more and more difficult, but this is our
challenge for today and tomorrow. Recent history shows we are a lot
better with technical issues than with human relations so I suspect
we'll struggle quite a bit along the way. Btw, this being a social
issue, a structure change won't do anything to it. But I'm sure we'll
make it simply because we have too.

> What, exactly, is your proposal supposed to actually accomplish?

With all the respect due to you and the effort you put into writing
this proposal, I'd be tempted to answer: "apply a cataplasm on a
wooden leg" (you surely know this old french saying). I've seen this
"let's restructure, it'll solve it all" thing too many times in real
life, and the only effect was always to delay the actual resolution of
the problems, and lose valuable energy and people on the way.

The bottom line is that we already have solutions for most of the
problems we are facing, and some are already being implemented. All we
need is to continue working on what's left to do, wait for the first
results, and apply corrections if necessary. We shouldn't expect our
actions to have immediate effect and problems be solved overnight.

However, if we have a structure problem I'm all for trying to address
it. But first I'll need to hear what it is exactly.

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Nguyễn Thái Ngọc Duy]

On 4/11/07, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> On Tue, 2007-04-10 at 22:50 +0200, paul@subsignal.org wrote:
> > it's just so easy to step on other
> > ppls feet these days ;)
>
> I tend to agree that this is a problem, but only insofar as we've become
> too territorial.  Many times I see bugs filed with seemingly minor
> changes being asked for.  A good example is bug #173884 which is a
> completely valid request.  The change is simple, removing
> "insinto /etc/env.d ; doins $somefile" and replacing it with "doenvd
> $somefile" instead.  Now, this is something that *anyone* with commit
> access should feel comfortable doing to *anyone's* packages without fear
> of being attacked for touching someone else's packages.

I wish we could have a list stating which package you have to contact
its maintainer first (and the reason why if possible), or add
<restricted> tag in metadata.xml to warn people. The rest of the tree
will be free land (unless you break the tree of course)

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 00:41 +0300, Petteri Räty wrote:
> Chris Gianelloni kirjoitti:
> > On Tue, 2007-04-10 at 22:50 +0200, paul@subsignal.org wrote:
> >> it's just so easy to step on other
> >> ppls feet these days ;)
> > 
> > I tend to agree that this is a problem, but only insofar as we've become
> > too territorial.  Many times I see bugs filed with seemingly minor
> > changes being asked for.  A good example is bug #173884 which is a
> > completely valid request.  The change is simple, removing
> > "insinto /etc/env.d ; doins $somefile" and replacing it with "doenvd
> > $somefile" instead.  
> 
> Or it's plain boring to fix that stuff and if you make people fix their
> own packages first, the boring part is distributed. I for example would
> fix the ChangeLog syntax problem for all ChangeLogs in the tree but I
> know that it's damn boring so I just prefer to get the check into
> repoman and let time deal with it. If I ever get to writing an automatic
> fixer, I still you need to check the changes or otherwise I could be
> committing broken fixes because of false positives.

You missed my point entirely.  My point was that there's no reason that
someone should *have* to file a bug.  Everyone should be welcome to make
changes like this on their own, without the maintainer being involved.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Tue, 2007-04-10 at 23:11 +0200, Alexandre Buisse wrote: 
> Sorry about that, I should have taken the time to look it up. Since I
> didn't hear about it after Stuart leaved, I assumed no one was working
> on it anymore.

Stuart's work had nothing to do with the implementation of stage4.  His
work was *utilizing* the stage4 target, not implementing it.  I don't
know about the status of the Seeds project itself, but Release
Engineering has been working towards producing similarly-designed stage4
tarballs for some time.  It is actually one of the motivators to moving
to the desktop/server sub-profiles on the release profiles.

> > Will this actually resolve any of the recent problems?
> 
> Yes, as I tried to explain in the proposal.

OK.  I missed the solutions, then.

> > Will this stop flame wars?
> 
> Probably not, but it can help reduce the volume, hopefully. Indirectly,
> of course, but I believe it would help a lot to reduce the tensions.

Why bother restructuring, then?  Why not just dump the gentoo-dev
mailing list entirely and have everyone use the individual project lists
that already exist for intra-project communications and have no official
facility for inter-project or global issues.  This sounds like what
you're proposing to me, but I may be mistaken.

> > Will this cause people be nicer to each other?
> 
> Definitely, yes. Because everyone will work on a smaller scale.

This is entirely speculation.  The projects will still have to interact
to be able to produce a cohesive product (the tree) so I don't see how
artificially sectioning people off into their own little worlds will do
anything to change the current situation other than possibly make some
groups even more closed and xenophobic than they already are today.

> > Will this give us more qualified developers?
> 
> Will depend on how each team will do its recruitment. And of course, to
> get official status, some kind of council would ensure some minimal
> qualifications (along the current guidelines would be my guess).

If these projects are still required to follow the same guidelines and
still have a centralized Council to guide them, what is changing?

> > Will this increase the quality of the tree?
> 
> Hard to tell. Having people leave the project out of disgust certainly
> doesn't improve it.

Neither does avoiding a direct question.

> > Restructuring the project isn't going to solve these problems.  
> 
> Not all of them, of course. And I never pretended it would. But I
> believe that it would definitely help.

How?

Please be very verbose in your responses.  Vague speculation and
guessing isn't necessary.  If you're unable to qualify your statements,
please don't make them.  If we're talking about restructuring the entire
project yet again in an attempt to rectify the current social problems
Gentoo is facing, I want to know *exactly* why I should consider it and
*exactly* what changes you think will occur, including reasoning for
thinking such things.

> > At best,
> > it will mask them during the time that we've wasted restructuring only
> > to find that we are back with the same set of problems, though now
> > without any form of centralized management to have even the glimmer of
> > hope of being able to resolve them.
> 
> I don't see how not having a centralized management would make it
> impossible to solve problems. Or are people really that stupid that they
> can't manage to get together and reach a decision, in some way or
> another (I gave some ideas in the last part of the email as well). Just
> giving all your power of decision to a big boss is a very crude and
> unefficient way of solving problems.

I had a feeling this was going to move in this direction.  We have
shown, quite well, actually, that there needs to be some form of
leadership that is active in the global issues of the distribution.
Nobody has ever said *anything* about giving over all decision-making
ability to some "boss" group.  Your description doesn't match the
current state of things and is only used as a way of trying to convince
people on an emotional level to agree with you where your statements
aren't based on fact.

> > It will take us to a complete mess
> > of incompatible overlays and trees.  
> 
> If we do it carelessly, certainly. But free software has solved much more
> complex problems in the past.

No offense, but what does that have to do with my statement?

Remember that as much as we like to tout Gentoo as a meta-distribution
it is *also* a distribution of its own.  It needs some kind of cohesion
to keep it functioning.  One of the things that keeps Gentoo cohesive,
even with the current overlays, is that in almost all cases, the
overlays for some project, such as Java, are run by the Java team.  This
means they won't have conflicting things around, since they manage both
sides.  If suddenly I were to go around creating a ton of Java ebuilds
in an overlay, the Java team's overlay would still be the "official"
overlay for the team, unless the team decided to adopt mine.  How is
your proposal any different?  Why does *Gentoo* need to encourage
competition within its own ranks when we've already shown that the
competition can come from outside just as easily, if not more easily?
Why not simply keep the "one project per area" that we have currently?
Yes, I am aware that we *could* have competing projects doing the same
work currently, but what real gain do we have from multiple people doing
the same thing?  Realize that I'm not talking about competing
*alternatives* to each other, like portage/pkgcore/paludis, I'm talking
competing teams doing essentially the same work, like having two Java
teams.

> > It also places the projects in a
> > hierarchy that doesn't match the actual power structure.
> 
> Power structure? I'm afraid I don't understand what you mean here.

What I meant to say is what is the point in projects being a "sub" or in
any way associated with another project if they're not under the same
management tree of any kind.  This is something that applies currently,
too.  Why is, for example, games a sub-project of desktop, when the
desktop guys don't have any say in what games does?  I think a flat
project space for these independent projects is best, even with our
current structure.  At the same time, there *are* some projects that are
directly related.  A good example of this is Release Engineering and the
Installer projects.  While the Installer *is* a sub-project of Release
Engineering, it is run by the project itself.  However, the project
*does* get some direction from Release Engineering.  The top-level
project requests features and other such things, and the sub-project
provides them.  Now, the project provides them under their own
management, in a way entirely of their own choosing, but they still
"answer" to Release Engineering in a vague sense.

> > If the parent project doesn't govern the sub-project, then why is it a
> > sub-project, at all?
> 
> To ease coordination and make obvious relationships clearer, I guess.

I'm not sure I see the point.  Where do you draw the lines?

> Can also help overlay management with hints like "you've pulled the
> audio overlay, you probably also want the multimedia one" and stuff like
> that. But it isn't really important, and the name "subproject" is
> probably misleading.

Agreed.  I just don't see any need to associate the individual projects
if they're not under the same management structure.  Sure, people might
want to associate projects due to their similarity, but I don't see how
associating them politically has anything to do with them being
associated technically.  A good example here is GNOME/KDE.  While both
of them are very similar, they really have no need to have any
association with each other to get their job done.  Just because they're
both desktop environments doesn't mean they need political ties.

> > What exactly are all of us supposed to actually *do* while we're waiting
> > for the SCM conversion and for the package managers to get the support
> > necessary and all of the changes are made to the tree?  
> 
> Keep working on the current version? I don't know, I would classify that
> as an implementation detail to be sorted if we actually decide to go
> forward.

That seems like an awfully big "detail" to completely gloss over.
You're talking about completely changing the way that technical
contribution, political structure, and social structure are all done
within Gentoo.  I think something so disruptive is quite a bit more than
an "implementation detail" especially considering it is the subject of
your proposal.

> > Do we simply
> > stop developing the distribution for days?  Weeks?  Months?
> 
> I'm sure we can find a better solution than that. But do we want to
> discuss such tiny details before the big plan itself?

We'll just have to disagree that it is a tiny detail, since I see it as
probably the most important aspect of your proposal.  It's all fine and
dandy to speculate on how we could be different, but if there's no way
to *get* there, the whole discussion is moot.

> > I think that the clique-like nature of many projects is part of the
> > problem.  We already have too much of a "us versus them" mentality.
> 
> I'm not sure what you mean. Which projects are you speaking about? It
> sounds like a silly accusation to me, but perhaps I'm unaware of some
> other case.

There have been numerous instances of this happening.  For quite some
time, there was a "Release Engineering versus Hardened" battle.  It
started before my time, and I have no clue why it existed, but it did.
Luckily, both teams have long since worked through such problems and now
happily cooperate, but it wasn't always that way.

> > How will moving to having lots of independent projects with no central
> > authority make Gentoo better?
> 
> I have said this in the proposal. If you don't agree on specific points,
> please provide arguments to back up your position.

The specific point I'm arguing, then, is your assumption that making
these changes will make anything better.  I don't think you've shown
enough proof that anything will improve by making the changes you've
suggested.  Because of this, I cannot point out specific instances where
I do not agree, since I don't think there's anything to argue against.
 
> > Will it make the distribution better for our users?
> 
> Because gentoo won't be dead in a couple months? Because people will
> think again that it's a fun project and want to be part of it?

Are you really using rhetoric as an argument?  What evidence do you have
that Gentoo will be dead in a few months?  If you don't have any, you
can't exactly use that as a pro-change argument, now can you?  Now, had
you said something like "We won't be losing developers at a net rate of
$x per month" or something else based in fact, I could at least attempt
to argue for/against it.  However, by arguing solely using conjecture
without any facts to back it up, I cannot possibly argue the point.

> > Reading back over your proposal with my questions in mind leaves me with
> > exactly one last question.
> > 
> > What, exactly, is your proposal supposed to actually accomplish?
> 
> What I *want* to do is to make gentoo fun again. And I believe that
> decentralising and giving more autonomy to people will achieve exactly
> that, for reasons explained in the proposal.

So what you're saying is that your proposal will make things "fun" again
by taking what should be global problems, and forcing lots of individual
groups to reinvent the wheel and tackle the same problems individually?

Where are all of the unofficial projects going to get infrastructure
from?  Mirror space?

Who is going to what is considered "Gentoo" and what isn't?

How is this going to improve our image as a cohesive and competitive
community-based distribution to our current and potential users?

How are we going to ensure that we can even provide a single working
product?

You haven't answered any of my questions, as far as I can tell.  You've
simply deflected them or avoided them entirely.  Rather than continue
with this and turn it into a yet another long thread, that should, by
the way, belong somewhere other than a development-related list since
this is purely a political change in an attempt to resolve social
problems, I'll wait until you've got something much more complete before
rendering any further comments or questions.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 00:05 +0300, Alon Bar-Lev wrote:
> I don't think this is the reason people are leaving.

Agreed.

> I think people are leaving because a lack of direction.

I also agree here, but only to an extent.

> I am not aware of any goal Gentoo distribution wish to acquire. For
> example: Do we wish to use a mainstream distribution? Do we aim to a
> specific user community? Or Do we develop distribution for our use?

Currently, we do not have any real global goals set out.

> If you wish to be (And I think we should be) mainstream distribution,
> we should derive targets, such as QA level, response times and
> content.

I agree that we should definitely have some measurable goals.

> Being more modular is one technical feature to achieve better
> stability. But we should discuss the basics first.

Being modular in the sense of being able to easily replace code, sure.
Being modular in the sense stated by Alexandre, I'm not sure.  I just
don't see how making everybody entirely independent will help us work
together.  It just seems so counter-productive to the idea of
cooperation to artificially separate people off into smaller
territories.

> I hear a lot that open source project with unpaid developers cannot be
> committed to deadlines or requirements from its developers, but I
> disagree. There can be an open source project with high quality
> products and dead lines, if these properly defined.

Agreed.  It works quite well within our own ranks, even, with Release
Engineering.  The only time we really miss deadlines are due to
technical reasons (security, things being broken, etc) that are
unforeseen.

> I must disclose that in my view whenever a large group of people are
> doing something together, some kind of hierarchy must be in place. And
> I am not talking about current council, it seems that current council
> does not LEAD Gentoo anywhere.

I agree that we need a formal hierarchy, but must protest that the
current Council doesn't lead.  The problem is that every time we *try*
to lead, we get a ton of developer backlash, which leads to things like
this proposal to try to reduce the Council's ability to lead.  So which
is it?  Do people want the Council to lead or not?  If the answer is no,
then why do we even *have* a Council?

> I read that sometime in history there was an effort to impose
> structural format on the community, but then Daniel Robbins left?

It was the structure that we had between Daniel leaving and the current
Council, and it was pretty much a disaster.  The ineffectual nature of
that structure is what led us to the current structure.

> If we wish to be a major distribution, we must grow. If we to grow we
> must organize our-self better, and work toward a common goal. Common
> goal forces decision making. Decision making forces leadership.
> Leadership forces vision.

I tend to think that a "common goal" isn't necessarily something that we
need.  We do need direction, but I don't think that everyone needs to be
working towards the same goals, especially when we have projects that
are "at odds" with each other.  If we focus on being the best desktop
distribution, what happens to embedded?  Instead, we need several
directions, based on functional differences.

Via this sort of breakdown I could see the following:

Core system
Desktop
Server/Hardened
Embedded
Documentation
Release Engineering

Even these are not static.  They could be changed fairly easily.  These
groupings are done entirely by function.  If we were to think of this as
a client/provider relationship, there would be certain functional
dependencies.  Everybody would depend on the Core system group.
Everybody would depend on documentation.  Release Engineering would
depend on everyone else.  Each of these different groups would easily be
able to have their own goals and visions, just like divisional units
within a company can have different goals.  Core system would be
interested in solidifying and stabilizing the core of Gentoo.  Desktop
would be working towards making Gentoo more friendly to desktop users.
While the goals aren't necessarily mutually exclusive, they're
different.  The same could be said for any of the other groups.

> Is there any vision?

Of course there is some vision.  The Council has plenty of ideas and
lots of ways where we can lead Gentoo.  Why don't we?  Because, quite
frankly, we're sick of the miles of bullshit attached to every single
minor decision made.  I'm speaking not for every member of the Council,
but from my own perceptions and from the grumblings I've heard from many
other Council members during conversations.

> Now, for your idea.
> When I written something similar in the past, someone told me that it
> was already suggested... I don't know why it wasn't accepted.

I still think it's a fairly good idea for how Gentoo should be
organized.  I just don't see how changing our organization will solve
our most pressing current issues.  I'd rather clean the house up a bit
before we decide to try to remodel it.

<snip>

The ideas of having differing metrics for different packages is really a
good one.  It doesn't require overlays to accomplish, either.  The only
real problem I see with it is determining how to rate the packages.

> But I believe we should first discuss the community goals, then derive
> a technical solution.

Agreed.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 00:59 +0200, Marius Mauch wrote:
> I like the part about projects being self-organizing, but splitting up the tree is a no go from my POV.

Are they not already?

Aside from the global requirements on what it takes to be a developer,
projects are able to recruit anyone that they want.  If they have an
overlay, the person needs not even meet the requirements for being a
developer.  Does the Council interfere in the recruitment of new
developers into projects?  If the answer is no, then what change would
actually be made and what problems would it solve?  It looks like to me
there would be no change in how we operate currently.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 00:11 +0100, Charlie Shepherd wrote:
> > some want it to be bleeding-edge
> 
> I think you'd struggle to get Gentoo to stop being on the bleeding edge :)

I'm pretty sure we're more cutting edge and less bleeding edge these
days.  We've slowed down quite a bit simply due to sheer size of the
tree and the added complexities involved with it.

> > Obviously, arbitrarily
> > choosing one of those directions would mean losing a lot of developers, and
> > this is something we can't afford to do.
> 
> We could of course move in several directions at once...

Exactly.

We don't have to have global goals.  We just want *some* goals.  Each of
the major functional groups can define their own goals, and they would
be Gentoo's goals.  We just don't all have to work on the same thing.
After all, how many companies only work on exactly one thing, putting
all of their employees on the one task?  I'd venture to guess that only
the very small would do that.  Most companies branch out into multiple
directions at once.  Gentoo fits in more with this style of thinking,
since we cater to very different user groups with different projects
within our ranks.

> > The current devrel authority is reduced to only the core
> > project
> 
> I don't think this is a good idea. Most projects are short on people
> already, without having to have their members wasting time policing
> themselves.

This is exactly what I mean by all of the groups having to reinvent the
wheel.  We already have a recruitment staff.  Why do we now need $x
recruitment methodologies for $x projects?

> Just because stuff isn't maintained doesn't mean that it's not being
> used, and if it's not broken I fail to see why it should be removed.

I've seen many times people say "well, this hasn't been touched
since..." when a package has no bugs.  Of *course* it hasn't been
touched.  It just works.  I wouldn't be surprised if there were quite a
few packages that fall into this category.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal

[Alec Warner]

Chris Gianelloni wrote:
>> I think people are leaving because a lack of direction.
> 
> I also agree here, but only to an extent.
> 

To quantify my earlier statement.  There is no ability to say 'this is 
something Gentoo should dedicate resources to' vs. 'this is something 
that is outside the scope of what Gentoo is trying to do'.  I feel this 
way because I have no idea 'what Gentoo is trying to do'.  Gentoo has no 
scope and thus any idea is basically good to go.  Someone can launch 
Seeds and work on it (which they are free to do regardless of whether 
it's a Gentoo Project) and there is really nothing you can do about it 
except point out the technical merits and pitfalls.  But does something 
like seeds fit into the scope of Gentoo?

Does SCIRE, another project I love, fit into the scope of Gentoo?

Does having a tree with many unmaintained packages fit into the scope of 
Gentoo?

Does having a tree with every package in existence fit into the scope of 
Gentoo?

These are the things that I see argued about often; do you try to add 
tons of packages?  Do you try to remove packages? Do you try to keep a 
balance.  Why does the tree contain unmaintained and broken packages? 
Why does no (developer) care?  Do you cater to users?  Do you cater to 
ourselves?  Do you target the desktop? Do you target embedded users?  Do 
you target servers?  Do you target 'release early, release often' or do 
you target stability and QA?

Some of these goals are opposites of each other.  Many developers only 
care about one or the other or none.  This is where I'd love for the 
council to lead.  If we care about QA then I'd expect to see some 
developers leave, because they don't care about QA at all.  If we go for 
a tree that contains maintained and 'good/well-known' packages I'd 
expect people to leave and create something bigger than sun-rise with 
every package known to man in it.

I think when people talk about splitting up Gentoo, this is a piece of 
what they are referring to.

> I agree that we need a formal hierarchy, but must protest that the
> current Council doesn't lead.  The problem is that every time we *try*
> to lead, we get a ton of developer backlash, which leads to things like
> this proposal to try to reduce the Council's ability to lead.  So which
> is it?  Do people want the Council to lead or not?  If the answer is no,
> then why do we even *have* a Council?
>> Is there any vision?
> 
> Of course there is some vision.  The Council has plenty of ideas and
> lots of ways where we can lead Gentoo.  Why don't we?  Because, quite
> frankly, we're sick of the miles of bullshit attached to every single
> minor decision made.  I'm speaking not for every member of the Council,
> but from my own perceptions and from the grumblings I've heard from many
> other Council members during conversations.

I don't recall hearing about lots of anything.  I don't claim to having 
read every meeting log however.

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Jan Kundrát]

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

Chris Gianelloni wrote:
> Wow.  I'm glad to see that yet another thing I spend so much time
> working on is marginalized or otherwise discounted because someone
> couldn't take 3 seconds to check their facts before making a post.  The
> stage4 concept is alive and kicking.  It is one of the targets made by
> catalyst, and likely something we will be utilizing much more in later
> releases.

I think that announcing such good news in -dev would be a great idea and
nobody will complain.

Cheers,
-jkt

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


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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Ciaran McCreesh]

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

On Wed, 11 Apr 2007 12:04:15 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > Just because stuff isn't maintained doesn't mean that it's not being
> > used, and if it's not broken I fail to see why it should be removed.
> 
> I've seen many times people say "well, this hasn't been touched
> since..." when a package has no bugs.  Of *course* it hasn't been
> touched.  It just works.  I wouldn't be surprised if there were quite
> a few packages that fall into this category.

Except that the tree is a moving target. The obvious example being a
package with X dependencies that hasn't been touched for four years...

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 20:02 +0700, Nguyễn Thái Ngọc Duy wrote:
> > I tend to agree that this is a problem, but only insofar as we've become
> > too territorial.  Many times I see bugs filed with seemingly minor
> > changes being asked for.  A good example is bug #173884 which is a
> > completely valid request.  The change is simple, removing
> > "insinto /etc/env.d ; doins $somefile" and replacing it with "doenvd
> > $somefile" instead.  Now, this is something that *anyone* with commit
> > access should feel comfortable doing to *anyone's* packages without fear
> > of being attacked for touching someone else's packages.
> 
> I wish we could have a list stating which package you have to contact
> its maintainer first (and the reason why if possible), or add
> <restricted> tag in metadata.xml to warn people. The rest of the tree
> will be free land (unless you break the tree of course)

That's really the point here.  You should *never* have to contact the
maintainer first for minor QA issues like changing something as simple
as "insinto /etc/env.d ; doins $somefile" into "doenvd $somefile" or
fixing a typo.  The maintainer only needs to be contacted on changes
that modify the end result.  If you're completely rearranging the ebuild
or trying to add a patch, you should definitely contact the maintainer.
If you're just cleaning up minor QA issues, it isn't necessary.  This
has always been the case, but perhaps it would be better to state it
more plainly so people understand that they are allowed to touch
*anything* in the tree.

The main thing to take into consideration is the scope of who is
affected.  Take a package rename as an example.  If your package foo is
being renamed bar, then I would fully expect you to change all instances
of foo in dependencies in the tree to bar, as it really only "affects"
you since it was your package that changed.  If you're adding a new
default local USE that only affects your package, there's no need to ask
anyone.  If you're adding a new default USE that's used in a bunch of
packages, it should be asked here.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Ciaran McCreesh]

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

On Wed, 11 Apr 2007 12:31:01 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> That's really the point here.  You should *never* have to contact the
> maintainer first for minor QA issues like changing something as simple
> as "insinto /etc/env.d ; doins $somefile" into "doenvd $somefile" or
> fixing a typo.

Except if you don't, the maintainer won't learn from their mistake or
learn about the change in policy.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 09:06 -0700, Alec Warner wrote:
> These are the things that I see argued about often; do you try to add 
> tons of packages?  Do you try to remove packages? Do you try to keep a 
> balance.  Why does the tree contain unmaintained and broken packages? 
> Why does no (developer) care?  Do you cater to users?  Do you cater to 
> ourselves?  Do you target the desktop? Do you target embedded users?  Do 
> you target servers?  Do you target 'release early, release often' or do 
> you target stability and QA?

You're looking at everything too narrow-minded.  Do we cater to users?
Developers?  The answer is yes to both.  Do we cater to desktop?
Embedded?  Again, the answer is both.  Trying to push Gentoo into some
single-minded narrowly-focused vision is ignoring many of the facets of
Gentoo that make it unique.  We must play to our strengths.  We are
quite diversified and I think that is one of our strengths.  Trying to
force everyone into some cookie-cutter mold is not in our best long-term
or even short-term interest.

> I don't recall hearing about lots of anything.  I don't claim to having 
> read every meeting log however.

I hope you also don't claim to have read every conversation any Council
member has ever had with another.  Not all ideas are fleshed out at the
meetings.  Some are simply not mature enough to be brought up to anyone.
Some, we decide, are simply crap, or unusable.  I know I've come up with
plenty of things that once discussed with someone else, turn out to be
complete crap.  ;]

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 18:13 +0200, Jan Kundrát wrote:
> Chris Gianelloni wrote:
> > Wow.  I'm glad to see that yet another thing I spend so much time
> > working on is marginalized or otherwise discounted because someone
> > couldn't take 3 seconds to check their facts before making a post.  The
> > stage4 concept is alive and kicking.  It is one of the targets made by
> > catalyst, and likely something we will be utilizing much more in later
> > releases.
> 
> I think that announcing such good news in -dev would be a great idea and
> nobody will complain.

What "news" exactly?  That catalyst still supports a code branch it's
had for some time now?  *grin*  There's nothing "new" to report.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Marius Mauch]

On Wed, 11 Apr 2007 11:21:05 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> On Wed, 2007-04-11 at 00:59 +0200, Marius Mauch wrote:
> > I like the part about projects being self-organizing, but splitting up the tree is a no go from my POV.
> 
> Are they not already?

Mostly yes.

> Aside from the global requirements on what it takes to be a developer,
> projects are able to recruit anyone that they want.

Still needs coordination with recruiters/infra to get all the right permissions and stuff setup. For example, ideally there shouldn't be a need for a project lead to bug someone from recruiters/infra to givea dev access to his projects resources (if they are restricted). Note that it's just a _very minor_ annoyance, the current system is generally good enough. Another idea would be to change the staffing needs page from push to pull (similar to the projects index.xml page) so projects could publish their needs without having to redirect it by recruiters (again, minor issue).

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 17:15 +0100, Ciaran McCreesh wrote:
> On Wed, 11 Apr 2007 12:04:15 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > > Just because stuff isn't maintained doesn't mean that it's not being
> > > used, and if it's not broken I fail to see why it should be removed.
> > 
> > I've seen many times people say "well, this hasn't been touched
> > since..." when a package has no bugs.  Of *course* it hasn't been
> > touched.  It just works.  I wouldn't be surprised if there were quite
> > a few packages that fall into this category.
> 
> Except that the tree is a moving target. The obvious example being a
> package with X dependencies that hasn't been touched for four years...

Except that package would have bugs.  It would have broken dependencies.
Again, I said packages that work.  Being untouched and broken is wholly
different from being untouched and working.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 17:45 +0100, Ciaran McCreesh wrote:
> On Wed, 11 Apr 2007 12:31:01 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > That's really the point here.  You should *never* have to contact the
> > maintainer first for minor QA issues like changing something as simple
> > as "insinto /etc/env.d ; doins $somefile" into "doenvd $somefile" or
> > fixing a typo.
> 
> Except if you don't, the maintainer won't learn from their mistake or
> learn about the change in policy.

You're right.  There's no way at all to inform someone of a change in
policy besides filing a bug and letting things sit in the tree for days,
months, or even years before they get fixed.

Personally, I'd prefer we fix the stuff and simply inform the
maintainers, rather than force them to have to do the work as some form
of punishment for not following policy close enough.  ;]

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Mike Frysinger]

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

On Wednesday 11 April 2007, Chris Gianelloni wrote:
> Personally, I'd prefer we fix the stuff and simply inform the
> maintainers, rather than force them to have to do the work as some form
> of punishment for not following policy close enough.  ;]

i drop notes to gentoo-dev when doing mass changes like the doenvd stuff ... i 
used to e-mail individual maintainers, but writing so many e-mails sucked up 
time real fast
-mike

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Donnie Berkholz]

Chris Gianelloni wrote:
> Why bother restructuring, then?  Why not just dump the gentoo-dev
> mailing list entirely and have everyone use the individual project lists
> that already exist for intra-project communications and have no official
> facility for inter-project or global issues.  This sounds like what
> you're proposing to me, but I may be mistaken.

Actually, that sounds like a great idea. Not dumping the -dev list 
entirely, but moving most development stuff that's restricted to a 
certain area to a list specific to it. For example, we already have 
-portage-dev, -releng, -desktop et al., although many are underused. We 
could add a list for each project to have its development on.

This is not artificial, it's based upon the size of groups people can 
effectively work in. George has posted on this a number of times. I 
suspect this is a major contributor to the ineffectiveness of -dev recently.

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Jan Kundrát]

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

Chris Gianelloni wrote:
> What "news" exactly?  That catalyst still supports a code branch it's
> had for some time now?  *grin*  There's nothing "new" to report.

I've been around for two years and have never heard anything about
stage4. If it's been discussed on this list before that time, I
apologize. Please don't take this as an admonition, but rather a hint
about what I'd like to see.

Cheers,
-jkt

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


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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 20:37 +0200, Jan Kundrát wrote:
> Chris Gianelloni wrote:
> > What "news" exactly?  That catalyst still supports a code branch it's
> > had for some time now?  *grin*  There's nothing "new" to report.
> 
> I've been around for two years and have never heard anything about
> stage4. If it's been discussed on this list before that time, I
> apologize. Please don't take this as an admonition, but rather a hint
> about what I'd like to see.

Well, anything about catalyst is usually kept on the gentoo-catalyst
mailing list.  I don't bother sending to gentoo-dev every time we add
new features or make changes simply because I would suspect most of the
people on this list could care less.  All of the people on the
gentoo-catalyst list, on the other hand, are interested in catalyst
development and usage.  The original stage4 code was imported into
catalyst CVS on 4 April 2005, though it was worked on for some time
before then.  The concept of the "stage4" tarball was created long
before that and several other implementations and ideas have been thrown
about on the forums even before it was introduced in catalyst.  Stuart's
Seeds project was the first official usage of the stage4 target in
catalyst.  Currently, it is used by the PPC64 team for the PS3 builds.
I am unaware of anyone else actually using them in an official manner at
this time.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Chris Gianelloni]

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

On Wed, 2007-04-11 at 11:25 -0700, Donnie Berkholz wrote:
> This is not artificial, it's based upon the size of groups people can 
> effectively work in. George has posted on this a number of times. I 
> suspect this is a major contributor to the ineffectiveness of -dev recently.

I tend to agree.  I also think that not having a place for any potential
political discussions, though I think they likely belong on the
gentoo-council mailing list, lends towards people posting those threads
on this list.  Nothing stirs people up like politics, religion, and sex.

Luckily, we haven't had much sex on this list, or we'd all have left
long ago.  :P

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Brandon Edens]

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

On Wed, Apr 11, 2007 at 12:59:35AM +0200, Marius Mauch wrote:

> On Tue, 10 Apr 2007 21:32:49 +0200
> Alexandre Buisse <nattfodd@gentoo.org> wrote:
> 
> [snip]
> > Please criticize this with everything constructive you > can think of.
> 
> This idea of putting almost everything into its own repo/overlay will IMO end up in the same mess that several other distros have with tons of 3rd party repos that don't play nice with each other. In case you don't know, the "one stop" philosophy with one central repo is what attracts a lot of people to Gentoo.

I think a lot of the problems with those other distributions and their 3rd party
repositories is related to the fact that they are binary-based distributions and
we are not.

Having an ebuild that
DEPENDS on such and such >= than a certain version and having ebuilds named after
the projects they represent. well...

Brandon

-- 
Brandon Edens                                   brandon@cs.uri.edu
http://www.brandonedens.org
key 0x55438F48

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Mike Frysinger]

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

On Wednesday 11 April 2007, Brandon Edens wrote:
> On Wed, Apr 11, 2007 at 12:59:35AM +0200, Marius Mauch wrote:
> > On Tue, 10 Apr 2007 21:32:49 +0200
> > Alexandre Buisse <nattfodd@gentoo.org> wrote:
> >
> > [snip]
> >
> > > Please criticize this with everything constructive you > can think of.
> >
> > This idea of putting almost everything into its own repo/overlay will IMO
> > end up in the same mess that several other distros have with tons of 3rd
> > party repos that don't play nice with each other. In case you don't know,
> > the "one stop" philosophy with one central repo is what attracts a lot of
> > people to Gentoo.
>
> I think a lot of the problems with those other distributions and their 3rd
> party repositories is related to the fact that they are binary-based
> distributions and we are not.

ever put that to the test and build things up from the .spec files ?  it's 
still hell on wheels
-mike

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Roy Marples]

On Wed, 11 Apr 2007 20:11:33 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> > I think a lot of the problems with those other distributions and
> > their 3rd party repositories is related to the fact that they are
> > binary-based distributions and we are not.
> 
> ever put that to the test and build things up from the .spec files ?
> it's still hell on wheels

/me nods

I monitor the dovecot mailing list and the rpm packing guys constantly
(well, nearly every other release) moan that new files were added,
breaking their precious .spec files.

Long live the ebuild!

Thanks

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Andrew Cowie]

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

On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote:
> as everyone probably noticed, there is a current atmosphere of sinking ship,
> with quite a lot of people leaving and many agreeing that gentoo is no fun
> working on anymore. Before it's too late, I'd like to propose a big reformation

A well considered and thoughtful message. Reinvigorating communities is
hard, and I hope the rest of the Gentoo developer community will find
inspiration from the gentle encouragement to be positive, even if it
turns out the specific ideas aren't the direction you want to go.

For all that the original poster got hammered about the stage4 thing, as
a long time Gentoo advocate I must admit that the constant stream of
negativity connected with so many developers getting upset and leaving
in a relatively short period of time is vaguely unsettling. It's good to
see other developers noting that they are happy - it balances things.

One of the hallmarks of Gentoo has been whole tree co-ordination and the
fact that developers are able to cover for each other is really rather
cool. Regardless of any structural changes you might make, this
characteristic co-ordination and co-operation is what has made Gentoo an
impressive distribution and so I hope you manage to maintain this spirit
in the years to come.

AfC
Bangalore

-- 
Andrew Frederick Cowie

Technology strategy, managing change, establishing procedures,
and executing successful upgrades to mission critical business
infrastructure.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

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

Re: [gentoo-dev] [RFC] New metastructure proposal

[Ferris McCormick]

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

On Fri, 2007-04-13 at 19:26 +0530, Andrew Cowie wrote:
> On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote:
> > as everyone probably noticed, there is a current atmosphere of sinking ship,
> > with quite a lot of people leaving and many agreeing that gentoo is no fun
> > working on anymore. Before it's too late, I'd like to propose a big reformation
> 
> A well considered and thoughtful message. Reinvigorating communities is
> hard, and I hope the rest of the Gentoo developer community will find
> inspiration from the gentle encouragement to be positive, even if it
> turns out the specific ideas aren't the direction you want to go.
> 
> For all that the original poster got hammered about the stage4 thing, as
> a long time Gentoo advocate I must admit that the constant stream of
> negativity connected with so many developers getting upset and leaving
> in a relatively short period of time is vaguely unsettling. It's good to
> see other developers noting that they are happy - it balances things.
> 

OK, I'm a happy developer. 

> One of the hallmarks of Gentoo has been whole tree co-ordination and the
> fact that developers are able to cover for each other is really rather
> cool. Regardless of any structural changes you might make, this
> characteristic co-ordination and co-operation is what has made Gentoo an
> impressive distribution and so I hope you manage to maintain this spirit
> in the years to come.
> 
> AfC
> Bangalore
> 

Thanks for the kind words; positive posts are always welcome. :) I
believe it is very much our intent to "maintain this spirit [of
co-operation]".

Regards,
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc)


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