Hello!
I'm trying to keep some external drivers up to date with the kernel, and

the first two weeks after the release is the worst time for me.  There

is no way to distinguish the current git kernel from the latest release.

It's only after rc1 is released that I can use preprocessor to check

LINUX_VERSION_CODE.
Before that, I have to rely on tricks or change the kernel version

myself in a separate patch and tell other team members to do the same.
Basically, I only care about kernel releases, but I also want to

increase the probability that the next standalone release of my drivers

will work with the next release on the kernel.  That's why I check

compatibility with the tip of the linux-2.6 repository.
Calling git version of Linux "2.6.23" one day before 2.6.24-rc1 is

preposterous, as it's likely to be compatible with 2.6.24, not 2.6.23.

Calling git version of Linux "2.6.24-pre" or something next day after

2.6.23 release is OK in comparison, since nobody developing external

drivers cares about old revisions of the kernel.  And the developers of

the kernel itself shouldn't care about versions at all.
It would be nice to establish a rule to increment the version number

immediately after the kernel release and have a suffix to indicate that

it's a pre-rc version.  "rc0" is my personal favorite.
It would also be helpful for other repositories, as it would indicate

whether any post-release changes have been merged in.
--

Regards,

Pavel Roskin
-

Note that you can see if there have been commits since a release (the last git tag) by using the command 'git describe'.
$ git checkout -b temp v2.6.23

Switched to a new branch "temp"

$ git describe

v2.6.23

$ git checkout master

$ git describe

v2.6.23-4223-g65a6ec0
Format is: last tag - # commits since last tag - id of HEAD commit
Hope this helps,

Frans Pop

-

I don't see how I can use it in preprocessor conditions.
--

Regards,

Pavel Roskin

-

On Tue, 16 Oct 2007 22:22:43 -0400
Consider this an incentive to submit your code for inclusion

in the upstream kernel.  Having all the common drivers integrated

in the mainline kernel makes it much easier for users to use all

their hardware, external drivers are not just a pain for the developers.
--

"Debugging is twice as hard as writing the code in the first place.

Therefore, if you write the code as cleverly as possible, you are,

by definition, not smart enough to debug it." - Brian W. Kernighan

-

The incentive has already worked for MadWifi, which has landed in the

wireless-2.6 repository under the name "ath5k".  Still, there is a lot

of work to do, and some features won't appear in the kernel driver soon,

partly because they rely on the chipset features that still need to be

reverse engineered.
In the meantime, somebody has to maintain the old madwifi and release

fixed for security and kernel compatibility.
Also, there are drivers that are just to unwieldy to be shaped into

something resembling a typical Linux driver.  linux-wlan-ng is such

project.  No matter what the incentive, it won't go to the kernel.

Maybe somebody will write a clean driver for Prism USB devices one day,

but it didn't happen so far.
Finally, there is a little at76_usb driver, which supports quite old

802.11b devices.  It's in wireless-2.6 as well, but I simply cannot

expect users to test it from there.  And if I make a standalone release,

I'd rather not make another one when 2.6.24 comes out.
--

Regards,

Pavel Roskin
-

On Tue, Oct 16, 2007 at 10:22:43PM -0400, Pavel Roskin wrote:
 > It would be nice to establish a rule to increment the version number

 > immediately after the kernel release and have a suffix to indicate that

 > it's a pre-rc version.  "rc0" is my personal favorite.
fwiw, rc0 is also what the Fedora kernel uses for versioning when we're

shipping pre-rc1 kernels.
	Dave
--

http://www.codemonkey.org.uk

-

Thanks!  I didn't think of the possibility of anyone distributing

precompiled kernels from the "pre-rc" window, but if Fedora does it

(hopefully for beta-testers only), it should be absolutely clear that

it's not just a release with some minor fixes.
Anyone adjusting any software for that kernel would be adjusting for the

next kernel release.
--

Regards,

Pavel Roskin
-

On Tue, Oct 16, 2007 at 10:45:17PM -0400, Pavel Roskin wrote:

 >

 > On Tue, 2007-10-16 at 22:34 -0400, Dave Jones wrote:

 > > On Tue, Oct 16, 2007 at 10:22:43PM -0400, Pavel Roskin wrote:

 > >

 > >  > It would be nice to establish a rule to increment the version number

 > >  > immediately after the kernel release and have a suffix to indicate that

 > >  > it's a pre-rc version.  "rc0" is my personal favorite.

 > >

 > > fwiw, rc0 is also what the Fedora kernel uses for versioning when we're

 > > shipping pre-rc1 kernels.

 >

 > Thanks!  I didn't think of the possibility of anyone distributing

 > precompiled kernels from the "pre-rc" window, but if Fedora does it

 > (hopefully for beta-testers only), it should be absolutely clear that

 > it's not just a release with some minor fixes.
yeah, this is just in our 'development' pool (also known as 'rawhide')

Proper releases only ever get full point releases + -stable as updates.
	Dave
--

http://www.codemonkey.org.uk

-