From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1J3Qk0-0002Ev-0b for garchives@archives.gentoo.org; Sat, 15 Dec 2007 06:43:16 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBF6gv90026394; Sat, 15 Dec 2007 06:42:57 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lBF6guYH026386 for ; Sat, 15 Dec 2007 06:42:56 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 50CED64A16 for ; Sat, 15 Dec 2007 06:42:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 1.121 X-Spam-Level: * X-Spam-Status: No, score=1.121 required=5.5 tests=[AWL=-0.947, BAYES_50=0.001, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK0QxqNR+w7G for ; Sat, 15 Dec 2007 06:42:50 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id CC0FD65778 for ; Sat, 15 Dec 2007 06:42:48 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J3Qj3-0005lJ-I9 for gentoo-project@gentoo.org; Sat, 15 Dec 2007 06:42:17 +0000 Received: from 91.84.87.26 ([91.84.87.26]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 06:42:17 +0000 Received: from slong by 91.84.87.26 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 06:42:17 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-project@lists.gentoo.org From: Steve Long Subject: [gentoo-project] PMS Date: Sat, 15 Dec 2007 06:46:32 +0000 Message-ID: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.84.87.26 User-Agent: KNode/0.10.4 Sender: news X-Archives-Salt: f7e8748a-a087-4474-bedc-59d5cfddaec6 X-Archives-Hash: 1f3796a0f6d4bdd6edbfd81f4bd2e9ff Just a quick post re something that was raised in the council meeting. My understanding is that portage is the official package manager for Gentoo, and will stay that way for the conceivable future. Other package managers are supported as much as any other externally-hosted project is supported, although they can in a sense be considered downstream of Gentoo. In a meeting of the last council: http://www.gentoo.org/proj/en/council/meeting-logs/20070816.txt the consensus seemed to be that it is important as: if the document is incorrect and a package manager is released following the incorrect spec, you *will* break boxes It was brought in-house as there had been no development on the spec for a substantial period of time, and it was holding up portage releases. Additionally: if the route we're going is that we dont add crazy things to EAPI/PMS unless we cover it in gentoo-dev, then having it be with the current package manager would lessen that maintenance The question which came up was: if we fork it to inhouse, will the inhouse fork still have enough momentum? As there had been no movement on the document for a year, it didn't seem important, but it is the situation now occurring: * Philantrop considers the place where the actual *work* takes place as authoritative until something significant happens in our repo. The concern I have with this is that PMS as developed by an external team is now being seen as authoritative for the whole of Gentoo. EAPI bumps should be based on input from the general ebuild developer community I think, since the the purpose of EAPI bumps is to give them features that they want. I accept that occasional threads are posted to dev m-l about proposals in PMS, but that is not the same as moving back to a situation where perhaps the fundamental Gentoo spec is developed by an upstream software provider. It has technical implications for the interoperability of all package managers, and if one of those teams is to be responsible for its development, I feel it should be the portage ones who have the final word on what is, and is not, "authoritative" for all Gentoo devs writing ebuilds. If that's about to change, I for one think it's a bad idea. Interesting article wrt the cat herd ;) s/guild/team/; s/alliance/project http://www.escapistmagazine.com/articles/view/issues/issue_124/ 2645-Riding-the-Failure-Cascade "An effective protection for any guild is to simply have fun." -- gentoo-project@gentoo.org mailing list