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 73C60ABB50 for ; Mon, 26 Aug 2002 17:24:46 -0500 (CDT) Received: from groug.home.net (PPP-36-99.caltech.edu [131.215.36.99]) by vestibule.its.caltech.edu (8.12.3/8.12.3) with ESMTP id g7QMOedK014154 for ; Mon, 26 Aug 2002 15:24:41 -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 15:24:40 -0700 User-Agent: KMail/1.4.3 References: <20020826064346.GX5078@squish.home.loc> <20020826180102.GA7111@jackpot.localdomain> <20020826192857.GA15770@orange-pc.ces.clemson.edu> In-Reply-To: <20020826192857.GA15770@orange-pc.ces.clemson.edu> Organization: Gentoo Inc. MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200208261524.41211.george@gentoo.org> 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: f49a3a5d-417f-47c8-8760-476c18a56887 X-Archives-Hash: 0f25d02bc1e91daf9ddb925f66fe8035 Hi Grant, Jeremiah On Monday 26 August 2002 12:28, Grant Goodyear wrote: > > And they have to go through a specific set of privileged people. > > True, although to the best of my knowledge all distributions have > a similar system. I don't think it will ever make sense to > provide CVS write access to all users; it's simply too easy to > mess things up. Goodness knows that our developers regularly > manage to render Gentoo uninstallable, and they're trying very > hard not to do that. Our system isn't perfect, but I'm not sure > what would be better. Jeremiah: yup, above is quite to the point. I'd second all that Grant has= =20 said. However there is some hope for more general user involvment. Please= =20 read below... > > Q: Can I help, can I help > > A: Sure, you can take out the trash and scrub the toilets. > > Well, right now that's pretty much what the developers are doing, > too. Our biggest need for help right now is good bug reports and > help with existing bugs. The only major "development" that is > ocurring right now is portage and some people starting to work on > a sensible installer. Everything else is really bug fixing of > one sort or another. This is quite true, core developers spend large portion of their time "ta= king=20 out the trash". However I am afraid that we are pretty stuck in this mode= the=20 way things are now. The problem is: these bugs are mostly not ours, but=20 rahter due to ignorance/weirdness/etc of upstream stuff, I mean here orig= inal=20 authors of the packages. It would be a life in heaven if everything insta= lled=20 via "./configure && make && make install". All packages would compile on = any=20 arch and glibc/gcc version and no weir dependencies were lost in docs and= =20 nothing would conflict... Well, you get the idea. Unfortunately this is o= ur=20 imperfect word where everything tends to break and noticeable portion of = bugs=20 require getting in touch with package authors or figuring out just what=20 build/configuration changes were implemented in this new revision? Things will get better when we release 1.4, however I am afraid not by= =20 much. The point I am getting at here is that we should and can allow our users = to=20 take care of a large portion of non-crytical packages. What we need is: 1. Multiple stability levels or KEYWORDS 2. Streamlined ebuild processing - that automates submission of new=20 ebuilds/versions and assigns them some kind of "new" or "user-test"=20 keyword/level 3.Feedback system that collects user voices and moves ebuilds to correspo= nding=20 categories increasing or decreasing their stability rating. 4. Core group oversees and takes care of the core/crytical stuff and has=20 *much* more time to work onportage/sysinit/other_more_distro_specifc_stuf= f Well, that would be one possible point of view on this :). Please take a look at bug#1523 for much more details (though bear in mind= that=20 some of that stuff is outdated by now). > > Among all the distributions I am familiar with, Gentoo is, > > in my opinion, the best as far as placing trust in it's users. > > But Gentoo is also, in my opinion, far from what I imagine as ideal. > > Fair enough. If you have additional ideas on how we can trust our > users better, please do post on bugzilla. That's what I did over half a year ago. Since then I got involved in gent= oo=20 more than I imagined :). So, the situation can (and I think should) be changed to give even more=20 freedom to our users (and take some stress off core group simultaneously = ;)).=20 However as any change this takes time, especially with a large evolving=20 system which gentoo became. At present we are near completion of step 1 i= n=20 that partial list above (I mean here the KEYWORDS that we were so busy=20 adding. As things settle down we will switch to this new masking mechanis= m=20 and get even some more functionality into. At least this was the plan=20 according to discussions/announcements over past few month). Eventually I= =20 hope we will get some more issues resolved and will be offering: 1. multitude of profiles (not just arch/gcc specific but tailored to cert= ain=20 tasks: such as server vs desktop, etc.) 2. partial [portage tree] database checkout (according to profile or stab= ility=20 setting) 3. streamlined/user_managed ebuild submissions (for non-crytical stuff) 4. anything else? And it all takes quite some work, so any help is appreciated; but then an= y=20 exciting project has a lot of routine associated with it. George