All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benny Halevy <bhalevy@panasas.com>
To: Mark Hills <mark@pogo.org.uk>
Cc: linux-kernel@vger.kernel.org,
	David Rientjes <rientjes@google.com>,
	Michal Marek <mmarek@suse.cz>
Subject: Re: Appending '+' to version, since 2.6.35-rc2
Date: Tue, 15 Jun 2010 09:48:08 -0400	[thread overview]
Message-ID: <4C178498.3000702@panasas.com> (raw)
In-Reply-To: <alpine.NEB.2.01.1006131729430.2991@jrf.vwaro.pbz>

On Jun. 13, 2010, 15:01 -0400, Mark Hills <mark@pogo.org.uk> wrote:
> Commit 85a256d adds a new feature:
> 
>   [...] When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
>   to the kernel version to represent that the kernel has been revised
>   since the last release unless "make LOCALVERSION=" was used to uniquely
>   identify the build.
> 
> I'm finding this inconvenient for 'casual' kernel development.
> 
> For example, my usual workflow goes something like:
> 

FWIW, I agree with this.
If I wanted a version suffix of this sort I'd just use CONFIG_LOCALVERSION_AUTO.

Benny

> 1) find something I suspect is a bug
> 2) upgrade to the latest stable or -rc kernel, to confirm
> 3) experiment with patch to fix it
> 
> Since 2.6.35-rc2, going from step 2 to 3 causes the version of the kernel 
> to change: forcing time-consuming rebuilds, installing modules, and manual 
> changes associated with a new version number; eg. updating the lilo/grub 
> config, or the distribution's initrd.
> 
> Whilst I can understand the motivation for the '+' being mandatory, the 
> added stages above unnecessarily raise the bar for casual developers, or 
> other people who need to 'dip' into the kernel and test patches. These 
> people are least likely to be aware of using LOCALVERSION to override it 
> too.
> 
> May I suggest that this particular part of the commit be reverted (example 
> below)? In favour of a user, if they wish, explicitly setting LOCALVERSION 
> or using CONFIG_LOCALVERSION_AUTO.
> 


      parent reply	other threads:[~2010-06-15 13:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-13 19:01 Appending '+' to version, since 2.6.35-rc2 Mark Hills
2010-06-14  6:52 ` Alexey Dobriyan
2010-06-14  7:38   ` Mark Hills
2010-06-15 13:48 ` Benny Halevy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C178498.3000702@panasas.com \
    --to=bhalevy@panasas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@pogo.org.uk \
    --cc=mmarek@suse.cz \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.