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=-1.2 required=5.0 tests=DKIM_ADSP_NXDOMAIN, DMARC_MISSING,MAILING_LIST_MULTI,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=4.0.0 Received: from relay02.cablecom.net (relay02.cablecom.net [62.2.33.102]) by chiba.3jane.net (Postfix) with ESMTP id 26F0FAC58E for ; Mon, 26 Aug 2002 20:37:23 -0500 (CDT) Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay02.cablecom.net (8.12.5/8.12.5/SOL/AWF/MXRELAY/20020820) with ESMTP id g7R1X9Wu088493 for ; Tue, 27 Aug 2002 03:36:54 +0200 (CEST) (envelope-from mettlerd@icu.unizh.ch) Received: from machine.nowhere.com (dclient217-162-252-124.hispeed.ch [217.162.252.124]) by mail.swissonline.ch (8.11.6/8.11.4/MSOL-2.30/21-Dec-2000) with ESMTP id g7R1Du804273 for ; Tue, 27 Aug 2002 03:15:17 +0200 (MET DST) Content-Type: text/plain; charset="koi8-r" From: Daniel Mettler To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] State of Developement Date: Tue, 27 Aug 2002 02:56:27 +0200 User-Agent: KMail/1.4.3 References: <20020826064346.GX5078@squish.home.loc> <20020826192857.GA15770@orange-pc.ces.clemson.edu> <200208261524.41211.george@gentoo.org> In-Reply-To: <200208261524.41211.george@gentoo.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208270256.32629.mettlerd@icu.unizh.ch> 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 List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 5ee83162-bce4-4766-a024-77baee3d92bb X-Archives-Hash: 33c6f93243c39e409f4a9f2bb26402ae -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 george (et al.), On Tuesday 27 August 2002 00:24, George Shapovalov wrote: > original authors of the packages. It would be a life in heaven > if everything installed via "./configure && make && make > install". All packages would compile on any arch and glibc/gcc > version and no weir dependencies were lost in docs and nothing > would conflict... ack. > Well, you get the idea. Unfortunately this > is our imperfect word where everything tends to break and ack. nevertheless i'd like to add that gentoo is particularly and implicitly vulnerable to such issues as some troubles are "home-made by concept". 1) gentoo uses performance optimizations by default (which sometimes lead to non-deterministic, non-reproducible results which are particularly hard to track down and solve, e.g. parallel make) 2) gentoo users usually further tweak their systems (aggressive gcc flags, ...) 3) while better performance is desirable one must be aware (i think most gentooers are) that things tend to be less stable, less predictable the more aggressive and uncommon the performance optimizations are. gentoo also uses the latest app releases which are less thouroughly tested by nature and consequences not entirely clear from the beginning (introduction of non-backwards-compatible changes, e.g. libvorbis). now i do not say that this is bad practice or a conceptually wrong, i just say that this implicitly means that gentoo is a "bleeding edge" distro and that this is gentoo's (and its community's) own decision (thus no self-pity, please ;) the same goes for greater flexibility which is fine but makes *any* testing approach pretty tough to unmanageable (see combinatorics ;). in real world, there will always be a trade-off between performance optimizations, flexibility and stability. > changes were implemented in this new revision? Things will get > better when we release 1.4, however I am afraid not by much. well, it's some bad luck currently with these horrible gcc 2.95.3 - -> gcc 3.1 -> gcc 3.2 changes. as the gcc devs have declared to take better care of backwards compatibility in the future, i hope things will stabilize. > The point I am getting at here is that we should and can allow > our users to take care of a large portion of non-crytical > packages. What we need is: 1. Multiple stability levels or > KEYWORDS ack. > 2. Streamlined ebuild processing - that automates submission > of new ebuilds/versions and assigns them some kind of "new" or > "user-test" keyword/level ack. > 3.Feedback system that collects user voices and moves ebuilds > to corresponding categories increasing or decreasing their > stability rating. ack. the barrier for giving feedback should be as low as possible and feedback should be given instantly. i.e. emerge should give the user an option to send a standardized bug-report by more or less just hitting enter when an ebuild fails (i think this has been discussed several times on this list already). rule: you can always trash submitted, bad (useless) bug-reports but you can't get bug-reports that were not submitted. standardizing bug-reports should also help in improving their quality. > 4. Core group oversees and takes care of the > core/crytical stuff and has *much* more time to work > onportage/sysinit/other_more_distro_specifc_stuff Well, that > would be one possible point of view on this :). addendum regarding qa: perhaps a more process-oriented organization would help improving qa and take some pressure from core-devs? has this ever been evaluated? how is qa organized atm? disclaimer: i do not know how gentoo-core is really organized (i do not think anybody outside of gentoo-core does). i think some more information about gentoo's internal organization, tasks, release schedules and targets for non-gentoo-core people would be very much appreciated and would enhance confidence, predictability and thus the coordination of own activities. gentoo-core still looks like some kind of a blackbox to me as what regards these points. is this really intended? > Please take a look at bug#1523 for much more details (though > bear in mind that some of that stuff is outdated by now). i've only skimed your proposal but it looks fine to me. is there any reason why gentoo-core has not approved it yet? summa summarum: 1.) gentoo as a distro has its own strengths and weaknesses 2.) organization is a very important thing when managing software projects 3.) information flow from gentoo-core to gentoo-dev/-user and vice-versa is important regards dan - -- ...::: Daniel Mettler | http://www.numlock.ch :::.... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9as5ASLYjgrGjnWQRAsroAJ40C3TJCCZmVKy0zaYFD37jrA1kHACeJu1l A9+Z8QG4R/T2Ywg1nPguzis= =eC5U -----END PGP SIGNATURE-----