Re: [gentoo-project] Metastructure: reorganization

[Ulrich Mueller <ulm@gentoo.org>]

>>>>> On Tue, 29 Oct 2013, Andreas K Huettel wrote:

> Actually for asking this question you've picked the best example...

> Imagine the poor KDE guys sorting out the language bindings for
> Ruby, Python, Java, and C#. Each comes with its own approach to
> solve the same problems, and with its own completely disjunct eclass
> syntax.

> Imagine updating your system after a while and then remembering that
> you need to run python-cleaner and perl-updater (and what was the
> syntax there again?).

> Maybe there isn't too much overlap right now, but people talking to
> each other would certainly help, and the problems are certainly
> related.

> This is the most important thing, and similar ideas also apply to
> the two other proposals. (PR, CoC enforcement and Ops are certainly
> related tasks?)

The key question is if it is reasonable to organise things as a common
project. This only makes sense if devs of the (to be) subprojects are
working together to some degree. For example, do they have a common
mailing list? (Turns out that in case of programming languages there
is gentoo-dev-lang, but it seems to be inactive.) It is perfectly fine
if people want to work together and organise themselves under an
umbrella TLP. However, I don't expect that creating such a structure
artificially would work, unless there is initiative from the projects
themselves.

Also the council has no power to decree a new project structure.
GLEP 39 says that projects organise themselves, so we cannot force any
project to convert itself from a TLP to a subproject. This would also
mean that some of the language projects (like Common Lisp and Scheme)
would be downgraded to third level.

> There's two additional motivations from my side. 

> One is my stereotypical German preference for cleanlyness and order.
> Or maybe it's just that part of leaving a professional impression is
> also that you don't just have a messy list of unordered projects.

That can be solved without introducing additional organisational
structures. For example, by arranging the project list by some
categories instead of alphabetical.

> The other one is that on the long run we might reconsider the role
> of umbrella project leads. I'm not so sure yet what we should do
> there though... Strengthen, give them tasks? some loose oversight
> that subprojects follow formalities? Abandon?

Just ask them what they see as their role, and if the umbrella project
is functional.

Ulrich