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.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI, NICE_REPLY_A autolearn=unavailable autolearn_force=no version=4.0.0 Received: from vestibule.its.caltech.edu (vestibule.its.caltech.edu [131.215.48.17]) by chiba.3jane.net (Postfix) with ESMTP id EDE92AC4EA for ; Mon, 26 Aug 2002 22:45:57 -0500 (CDT) Received: from groug.home.net (PPP-36-187.caltech.edu [131.215.36.187]) by vestibule.its.caltech.edu (8.12.3/8.12.3) with ESMTP id g7R3jUdK023545 for ; Mon, 26 Aug 2002 20:45:31 -0700 (PDT) Content-Type: text/plain; charset="koi8-r" From: George Shapovalov To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] State of Developement Date: Mon, 26 Aug 2002 20:45:20 -0700 User-Agent: KMail/1.4.3 References: <20020826064346.GX5078@squish.home.loc> <200208261524.41211.george@gentoo.org> <200208270256.32629.mettlerd@icu.unizh.ch> In-Reply-To: <200208270256.32629.mettlerd@icu.unizh.ch> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200208262045.20820.georges@its.caltech.edu> 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: 749e0ff9-4ac7-4b5c-a461-0709471d7360 X-Archives-Hash: 799cf23cd7c05a73c06cc839af7ce0a7 Hi guys. I'll answer this message, as I think this will cover some questions by Ev= an as=20 well. > > 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 > 1) gentoo uses performance optimizations by default (which > 2) gentoo users usually further tweak their systems (aggressive > 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. Well, this is what freedom is about. We cannot do much about this short o= f=20 locking users to certain precompiled binaries, as debian does. You should= =20 think of gentoo more in terms of a meta-distribution with the ability to = set=20 or screw things next to only Linux From Scratch. Some breakage by the mor= e=20 advantrous types is inevitable, while on the other hand I saw reports by=20 people running gentoo on servers without any problems (and of course they= do=20 not run the daily cron job of "emerge rsync &&emerge -u world" :) ). > 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). Good point. Eventually this will be remedied by the stable profile which = will=20 lock packages to the approved stable versions for the most part. Please d= o=20 not confuse with branches: there is no point in branching gentoo. It is f= ar=20 better to have a big general database and subset it (via profiles or KEYW= ORDS=20 of what we have at present) on order to get the system tailored for the=20 certain task.=20 However bear in mind, that gentoo is a young distribution (guess why we a= re=20 1.4 now and not say 7.5?). We are in early stages of implementing all the= se=20 features. > 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. This is why we really depend on you - our users. We perform significant a= mount=20 of testing before new packages or versions are incorporated into the tree= =20 (and this is a part of the reason new submissions take long time to be=20 processed). However it is not possible to cover all possible combinations= of=20 architectures, package and compiler versions and combinations. More impor= tant=20 packages get tested more, less important..., well, this is what this=20 multistability user-driven ebuild processing concept is about: to let=20 interested users help us and themselves simultaneously. > > 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). If you have some tight concept or a good idea, please contribute it. Answ= ering=20 to this thread or posting a comment to that bug I mentioned (and there ar= e=20 some more) are the ways to get your word to developers. (This is a general remark, I see you do just that below. Thanks for that!= ) > 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. True. Also it should be kept in mind that the feedback system should be=20 largely automatic and well balanced (so that popularity of the package do= es=20 not influence its stability ratings too much for example). > 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? Good point.=20 The intent is to have some place for "wild" discussions, which might=20 potentially and unnecessarily upset users: "gentoo devs want to do this e= vil=20 thing!" while it was merely a trial suggestion that was shot down quickly= =20 afterwards. Core devs are encouraged to take questions that require user=20 feedback or general discussion to the gentoo-dev. > > 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? Well, its not that it has not been approved, its more the issue of differ= ence=20 between accepting some idea and implementing it :). It does take quite some work and time to do things, especially that touch= the=20 core of the system and require updates to majority or all the ebuilds. We= =20 just recently had a large session of KEYWORD additions. This required all= =20 developers to retest and modify their ebuilds (or all the ebuilds they=20 oversee). This is not over yet, but nearing completion, thus taking care = of=20 the larger part of step 1 (as in my previous message). Other parts of tha= t=20 proposal will have to be settled and implemented as well. Particularly a = good=20 discussion on the feedback/voting system may help to settle at least the=20 design. And thanks for the thoughts! George