From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id EECF51385B0 for ; Wed, 30 Oct 2013 06:46:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E6C17E0A45; Wed, 30 Oct 2013 06:46:09 +0000 (UTC) Received: from a1www.kph.uni-mainz.de (a1www.kph.uni-mainz.de [134.93.134.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 39AE3E09EC for ; Wed, 30 Oct 2013 06:46:08 +0000 (UTC) Received: from a1i15.kph.uni-mainz.de (a1i15.kph.uni-mainz.de [134.93.134.92]) by a1www.kph.uni-mainz.de (8.14.7/8.13.4) with ESMTP id r9U6k6T2011018 for ; Wed, 30 Oct 2013 07:46:06 +0100 Received: from a1i15.kph.uni-mainz.de (localhost [127.0.0.1]) by a1i15.kph.uni-mainz.de (8.14.7/8.14.2) with ESMTP id r9U6k3A9031692; Wed, 30 Oct 2013 07:46:03 +0100 Received: (from ulm@localhost) by a1i15.kph.uni-mainz.de (8.14.7/8.14.7/Submit) id r9U6k3xi031524; Wed, 30 Oct 2013 07:46:03 +0100 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21104.43819.507319.106956@a1i15.kph.uni-mainz.de> Date: Wed, 30 Oct 2013 07:46:03 +0100 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Metastructure: reorganization In-Reply-To: <201310292348.43755.dilfridge@gentoo.org> References: <1701685.NthhqudeZE@kailua> <201310292255.04913.dilfridge@gentoo.org> <21104.13201.654027.432888@a1i15.kph.uni-mainz.de> <201310292348.43755.dilfridge@gentoo.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) From: Ulrich Mueller X-Archives-Salt: 69d46546-7053-41eb-b5fa-61eb5be37de2 X-Archives-Hash: 65e419273f8d0381f284585e116e5c57 >>>>> 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