From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=4.0.0 Received: from chamber.cco.caltech.edu (chamber.cco.caltech.edu [131.215.48.55]) by chiba.3jane.net (Postfix) with ESMTP id 343B620EDA1E for ; Sat, 16 Mar 2002 13:45:52 -0600 (CST) Received: from there (PPP-36-5.caltech.edu [131.215.36.5]) by chamber.cco.caltech.edu (8.9.3/8.9.3) with SMTP id LAA07376 for ; Sat, 16 Mar 2002 11:42:14 -0800 (PST) Message-Id: <200203161942.LAA07376@chamber.cco.caltech.edu> Content-Type: text/plain; charset="koi8-r" From: George Shapovalov To: Gentoo Dev Date: Sat, 16 Mar 2002 11:46:07 -0800 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [gentoo-dev] Unstable branch proposal - second round Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 573a96aa-d088-4d9a-8f6c-696b4fedd976 X-Archives-Hash: 207c2ce556212b1b9d9acfb918330671 Hi All. I just looked again through the recent thread and here are some thoughts = I=20 would like to throw out. The thread did not see that much of activity and I thought that timing wa= s=20 not right - during the feature freeze right before 1.0 release. Then I ga= ve=20 it a second thought and here are a few things I would like to bring here.= I=20 will try to summarise the previous discussion and then propose some stuff= =20 which if accepted will require a minor addition to existing functionality= and=20 may even go in the tree before release (or to 1.x version). Now to the issue. Technically I would not call the proposed an "unstable branch". The core= =20 which is a portage system and supporting infrastructure is going to stay = the=20 same, there has been no call to fork that as far as I can tell (and I am = not=20 about to do that either). The call was for producing new ebuild submissio= n=20 system. At present gentoo definitely allows submission of new ebuilds - you just = have=20 to go to bugs.gentoo.org and submit an ebuild as described in manual, the= n it=20 gets reviewed by core developer and goes into /usr/portage/incoming/ and=20 later gets incorporated into the portage tree.=20 While a very sound submission protocol it is not very scalable if ebuild= =20 submissions are expected to grow significantly. In such case a decentrali= sed=20 submission/review schema is desired. One proposed way of doing this was to setup a self-managed "mirror", whic= h=20 should accept all packages from developers but keep them local. New=20 submissions will get reviewed by community and later manually incorporate= d=20 into the main tree by core developers.=20 While this allows better exposure of new submissions it does not prevent = the=20 bottleneck - core developers will be just as occupied. Than self-managed=20 sound like a way to start a big mess unless somebody is going to spend a = lot=20 of time actively maintaining thing, compiling lists of a "worthy", "confi= rmed=20 by majority", etc.. ebuilds. And actively pushing them to the core group.= =20 Also having to worry about separate system incarnation looks like a=20 possibility to start a fork where you might avoid doing so. After all the= se=20 systems will have different requirements. Another possibility is to use the same infrastructure, but add new=20 specificator to the package name, which will mark it as "unstable". Allow= =20 unstable ebuilds to appear in the main tree but these will be installed (= and=20 reported) only if you use special flag (for example --allow-unstable) wit= h=20 emerge (ebuild as a low-level utility I guess should just do whatever you= ask=20 it to). After all this is similar to what people do now with not yet=20 incorporated ebuilds. Users of unstable ebuilds can and are requested to report on=20 usability/stability of an ebuild by setting some flag in the package dir = or=20 somewhere in the database, which should be counted when user rsyncs again= =2E=20 Certain policy can be set, so that for example packages accumulating enou= gh=20 voices should automatically be granted for example "confirmed" status. Th= ere=20 might be additional layer of (even manual) check through which the packag= e=20 should go to get "approved" status (and the removal of specificator form=20 ebuild name). I am apparently thinking in favour of this one as it seems things can be=20 setup more cleanly this way (avoiding any reason for possible forking) wh= ile=20 allowing everybody to have easier access to all functionality. Users can = =20 choose to stick with "approved" packages if stability is of most concern,= =20 "confirmed" if some more functionality is desired or even "unstable" to=20 access all packages (and of course anybody anytime can force-install any=20 package). To provide this functionality emerge can check make.conf for=20 -allow-status flag for example. The tree can even be synchronised on user= =20 machine according to set stability level. The main benefit of setting up something along these lines is that newly=20 submitted ebuilds get much broader attention. Especially recalling numero= us=20 calls for setting up the list of new ebuild submissions so that newcomers= can=20 start to actively contribute to the system, while allowing "core" people = to=20 concentrate on essential stuff. George