Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757868AbZJFP1W (ORCPT ); Tue, 6 Oct 2009 11:27:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757853AbZJFP1V (ORCPT ); Tue, 6 Oct 2009 11:27:21 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:41726 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757848AbZJFP1V (ORCPT ); Tue, 6 Oct 2009 11:27:21 -0400 Date: Tue, 6 Oct 2009 08:24:52 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Ingo Molnar cc: Dirk Hohndel , Len Brown , Linux Kernel Mailing List Subject: Re: Linux 2.6.32-rc3 In-Reply-To: <20091006144449.GA23078@elte.hu> Message-ID: References: <1254797502.14122.146.camel@dhohndel-mobl.amr.corp.intel.com> <20091006144449.GA23078@elte.hu> User-Agent: Alpine 2.01 (LFD 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2673 Lines: 64 On Tue, 6 Oct 2009, Ingo Molnar wrote: > > We can ignore that and say "hehe, you dont understand non-linear trees > and ran git remote update blindly, too bad for you", or we might do > something to make things more transparent and reduce the confusion. You are missing the point. The only thing we can do is to teach people that the Makefile version isn't too important, and that it really doesn't tell very much. Trying to tweak it to make it somehow "more meaningful" is a BAD THING, because it continues to spoon-feed people a lie. The cake is a lie. In between kernel versions, you can't rely on the Makefile. You should teach yourself (and others) THAT, rather than trying to teach people to believe the lie even more. Once you start believing the lie, suddenly all the subtrees will start thinking that now _their_ kernel versions are bad, so now they'll start to want to make the same idiotic changes to their Makefiles, or maybe they'll decide that they don't want to pull tagged releases, but the "one after the tag so that they'll get the updated Makefile". And even if they don't do that idiocy, the whole "the version number is meaningful outside of releases" thing leads to brain damage. > One option would be to make LOCALVERSION_AUTO compulsory. Yes, I could live with that. If you're compiling from a git tree, we migth as well show the real version. It's the "let's make that meaningful and misleading number be even _more_ misleading by making people think it has meaning" magical thinking that I hate. It's wrong, and it leads people to believe in things that aren't true. I refuse to cater to that kind of wrongheaded thinking. I'd much rather screw up the version number entirely and add a _random_ number to it (so that the Makefile would say "2.6.18" after I have released 2.6.32) just so that people would be forced to _understand_ that the version number isn't as meaningful as you seem to think it is. For example, let's take Arjan's request, that kerneloops should get -rc0. Think about that for a few minutes. Really THINK about it. What happens? [ Spend some time really thinking here. ] What about people like all the networking guys who are running their development kernels that haven't been merged yet? Their kernels won't say -rc0. Are you going to ask them to do it too? Or would you be better off teaching kerneloops about local versions? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/