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 ED44A1381F3 for ; Sat, 22 Jun 2013 03:42:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 462B0E0A91; Sat, 22 Jun 2013 03:42:04 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9E423E0A8A for ; Sat, 22 Jun 2013 03:42:03 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id 027972106A for ; Fri, 21 Jun 2013 23:42:03 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 21 Jun 2013 23:42:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=4KQDPJBZTJVSu5Y+iMGbpcDNi/s=; b=HK+N1pUgdCuTYQ5dwuRu2pnl+mSg BVYFzJK91UP0JXQu5S91+yI4DwqGkYBmNKJSSIdpT1HqN8xU8Oldp0Iew+qvdIAg eFAVmHs3hlIUb3unvdNQP6bApKkD/eLOW3ppOara5V+vg+tcuSHMePuOeI/cKP5d Vo6hg9oscYSYHQQ= X-Sasl-enc: dJynwFVi0H58SecV82BrZ/z6/nU+wJCmwZc0uyPelhH6 1371872522 Received: from localhost (unknown [76.28.172.123]) by mail.messagingengine.com (Postfix) with ESMTPA id 71BB9680277; Fri, 21 Jun 2013 23:42:02 -0400 (EDT) Date: Fri, 21 Jun 2013 20:42:44 -0700 From: Greg KH To: gentoo-kernel@lists.gentoo.org Subject: Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions Message-ID: <20130622034243.GA2058@kroah.com> References: <20130621145801.GA5202@kroah.com> <20130622020259.7a411a7a@TOMWIJ-GENTOO> <20130622001303.GA2278@kroah.com> <20130622024516.3a51911e@TOMWIJ-GENTOO> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-kernel@lists.gentoo.org Reply-to: gentoo-kernel@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130622024516.3a51911e@TOMWIJ-GENTOO> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 233ca0c3-0f33-4cdd-9215-08c499a0debc X-Archives-Hash: 5f4c275accdd2abfa37fb50c1c9d4cce On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote: > On Fri, 21 Jun 2013 17:13:03 -0700 > Greg KH wrote: > > > Great! But as only the latest version released is "stable", that's > > all that should stick around, right? > > Tricky decision to make. Do we really want to force people's kernel > sources to unmerge every single time you push a new version? Which on > its own turn, forces them to build and install the new kernel. If they are following the vanilla kernels, isn't that what people expect? The latest stable-kernel-of-the-week, as that's what I'm releasing. They don't have to do an update if they don't want to :) > > > If possible we could script it to keep the package unstable the > > > first X days it is in Portage to keep the stabilization effect in > > > place; that way Gentoo users are unaffected if something goes wrong > > > the day after you push a patch, I assume not, but you never know. > > > > If something goes "wrong" the day after I push a update, I push a new > > one fixing the problem, so this shouldn't be an issue, right? > > It's not so much about fixing the problem, but rather about the > severity of the issue. If this involves a corruption that corrupts a > large amount of data on well known hardware which the patches were not > tested on, users with such hardware would be affected; if we however > delay our Gentoo users, they wouldn't become affected due to an > upstream problem, unless they intentionally use the ~ keyword And how would you find out about these types of issues, unless they get tested on those systems? It's a chicken-and-egg issue. People who want more "stable" releases, follow the gentoo kernels. If you want to track upstream directly, use the vanilla kernels, that's what they are there for. > > And as these are coming out about 1-2 a week, the timeout before the > > arch teams could get around to marking things stable seems like a lot > > of work, for something that isn't really needed at all. > > What I meant was to not involve arch teams at all, as per the original > proposal but just have a cron job running somewhere to stabilize the > new versions, as well as to drop older versions. A cron job doesn't mean anything (how to stop it?), so you might as well just always either mark them stable or not, as no one is testing them for "stability". > The delayed stabilization and delayed dropping from the tree are merely > ideas that I think are in favor of the users; I may be wrong about this > but would like to at least see this discussed, unless everyone agrees > we should completely reflect the current state as listed on kernel.org. > > As you probably know, there are different groups of users where some > run personal laptops or desktops whereas other run a (professional) > server. I think an approach that what would make sense for people > running a secure and stable server might not necessarily make sense for > people running their own laptop or desktop. Not all exploits target > both servers and desktops (eg. they can't get behind router). I agree, that's why we have so many different kernel packages. > On the other hand, the vanilla-sources ebuilds set > K_SECURITY_UNSUPPORTED="1"; so perhaps we're not even aiming for the > (professional) server people at all and therefore perhaps only the > laptop and desktop users. Or at least, that's how Gentoo Security and > that variable would make it look like; I agree though that it is > inconsistent with how upstream would look at these versions, I > therofore think it should be a good idea to reevaluate said variable if > we are going to change the way we stabilize and drop vanilla-sources. I'll leave that alone, as I don't know what that flag means or does, sorry. greg k-h