From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 399141381F3 for ; Wed, 24 Jul 2013 22:18:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5206BE095D; Wed, 24 Jul 2013 22:18:19 +0000 (UTC) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 68697E0954 for ; Wed, 24 Jul 2013 22:18:18 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hi5so1407056wib.13 for ; Wed, 24 Jul 2013 15:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=WpY5P8Napq1Yd64NVvC7XWA+Q1qJ77DF6caunapvnBw=; b=ltDJ5ckSRlMFCK4+TAJS2hrYYjn7gmfDc2F8BPejXdS6lFozjvjH++9eXWD+vof1i1 p3byEfQHvrc8EBPKGeu39M0L9cknekF9eLHVgnSlLR4+Q/EAtWnXLEkQ2OdCXZwcNcs7 UPU2wV4yokEA03Rrsi16lP/bnxxv7XI4qXAUEMqw3WM9QtIhCsmUs+KVo4DfWkvDdtxp PREVA9mU8w9SIjdUvovqRyuiKpQTvMjW1lYfi2QG2bz+2Th/hHSfiaf8mzZy9vPNHTUX BKJDETs2vBHsMNwROpaOTQ5pwxEKpv+wGQXraQX/Cai1VJjhkRubpPSyn6/TCqQbwn8t 7KTA== X-Received: by 10.180.108.129 with SMTP id hk1mr4186197wib.42.1374704296896; Wed, 24 Jul 2013 15:18:16 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Sender: markos.chandras@gmail.com Received: by 10.194.163.138 with HTTP; Wed, 24 Jul 2013 15:17:36 -0700 (PDT) In-Reply-To: <20130724225940.3bce3c88@TOMWIJ-GENTOO> References: <1462872.zkzQFHQRNq@comanche> <20130724173751.8848.qmail@stuge.se> <51F0125D.2090500@yahoo.ca> <20130724174924.9909.qmail@stuge.se> <51F015A8.7010904@yahoo.ca> <20130724181659.12207.qmail@stuge.se> <20130724225940.3bce3c88@TOMWIJ-GENTOO> From: Markos Chandras Date: Wed, 24 Jul 2013 23:17:36 +0100 X-Google-Sender-Auth: 4N50Al_hRHtd5a8H12QGzy-8Dno Message-ID: Subject: Re: [gentoo-dev] Vanilla sources stabilization policy change To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 4044799d-a98e-4777-950a-d67c092b3fa4 X-Archives-Hash: 5fce59315d2a40e574b80ec04e7dc44e On 24 July 2013 21:59, Tom Wijsman wrote: > On Wed, 24 Jul 2013 20:16:59 +0200 > Peter Stuge wrote: > >> Alex Xu wrote: >> > >>> Maybe it would make sense to automatically stabilize every v-s >> > >>> kernel right away? >> > >> >> > >> As has been stated, this implies that Gentoo QA has tested the >> > >> packages and found them to be reasonably safe for use. >> > > .. >> > >> Although stable kernels *have* been tested by many people before >> > >> use, Gentoo QA has *not* (officially) tested them, at least not >> > >> on every architecture. >> > > >> > > I don't think that matters. >> > >> > If you don't care too much for Gentoo QA >> >> The point is that when arch teams find that they can not keep up with >> the pace of upstream and choose never to attempt stabilize v-s then >> clearly Gentoo QA will also not be able to keep up with that pace and >> thus Gentoo QA becomes irrelevant for the particular package. > > No, stabilization of vanilla-sources would be an addition in work > required; one can not assume that if gentoo-sources is stable than > vanilla-sources is or vice versa. Also, the premise here is that > vanilla-sources would need to be stabilized every version; and not just > once per branch (we would like two or three though) as gentoo-sources. > >> The original post also mentioned that generally v-s has more fixes >> than anything coming from stabilization efforts. > > More fixes; but also more regressions, new features, more 0-days, ... > >> It seems that for this package Gentoo QA can not realistically add >> any value to this package, hence my suggestion not to pretend that >> they can, and just remove the distinction between ~arch and arch for >> v-s, and make the latest version available to users by default. > > That's a contradiction; their added value is it being deemed stable, > they can't just pretend it is stable, that overrides the distinction. > > For as far that I know there is nowhere in the tree we provide matters > that walk past Gentoo; so, why should they make an exception here? > >> > >> On a technical level, it's not that hard to put >> > >> "sys-kernel/vanilla-sources" in your package.accept_keywords. >> > > >> > > But why should Gentoo users have to do that in order to use v-s? >> > >> > So they acknowledge that vanilla-sources has not been officially >> > tested by Gentoo QA. >> >> Since v-s is a special case that Gentoo QA is known not to handle, >> this overhead seems completely unneccessary to me. And the usability >> is of course poor. > > If Gentoo QA can't handle it, why could our users; if they are to make > a poor sense of stability, that suffices to make it an explicit choice. > >> > > If it is intentional to push g-s onto users then it makes good >> > > sense >> .. >> > I can't comment on that. >> >> I guess this is really the pivotal point. If Gentoo prefers to push >> g-s rather than v-s then adding overhead for v-s kernels is fine. I'd >> prefer Gentoo to push v-s instead. > > If this weren't intentional, we wouldn't be doing this; the kernel team > exists to add value and not just to blindly follow upstream. > > Let me quote the project description: > > "With an ever increasing userbase demanding a higher quality of stable, > production-ready kernel sources and featureful desktop support the > professionalism and staffing of the kernel project is very important. > > Because we as users want the best from Gentoo Linux we supply a > selection of both generic and specialised sources capable of handling > the day-to-day grind to make life a little easier. > > In order to provide a rich choice of high quality kernel trees Gentoo > Linux must apply, write and test several kernel patches to the official > upstream releases before they can offer finished ebuilds to the users. > This is where the Gentoo Kernel project comes into play." > > -- > With kind regards, > > Tom Wijsman (TomWij) > Gentoo Developer > > E-mail address : TomWij@gentoo.org > GPG Public Key : 6D34E57D > GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D This thread derailed as usual. The kernel team made a decision. We can simply accept it and move on. Stable keywords imply at least a minimal build and runtime testing by arch teams. Since we have no manpower to do it, then stabilizing them blindly is not appropriate. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang