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

[Charlie Shepherd]

On 10/04/07, Alexandre Buisse <nattfodd@g.o> 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@g.o mailing list