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

[Chris Gianelloni]

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