On Sun, 1 Apr 2007, Mike Isely wrote:
> On Sun, 1 Apr 2007, Marr wrote:
>
>> On Saturday 31 March 2007 2:14pm, Neil Whelchel wrote:
>>
>>> BTW I agree with Bill, any time ANYTHING is changed in the module, the
>>> version number should be bumped. If you change the spelling of colour to
>>> color, this should bump the revision. Changing anything that changes the
>>> flow of the module such as adding the cypress_set_dead() function should
>>> have bumped the minor.
>>
>> I'm kind of surprised that it seems the norm (per Greg KH's message) that
>> this
>> is done the way it is (i.e. no change to revision). Either way, I intend to
>> bump the revision number to "1.10" if my VID/PID-check patch (which includes
>> some other trivial indentation/whitespace fixes) makes it into mainline.
>>
>> Thanks again for your input, Neil!
>
> Neil:
>
> IMHO It doesn't make a lot of sense to be tracking version info for
> every little thing in the Linux kernel. Version information is of
> course important, but that's where the kernel version comes in. One can
> also suggest that versioning of modules is important for traceability
> but really it's the signed-off changesets that provide the traceability.
> Also consider this: If every kernel janitor / submitter / random person
> were required to bump up that version number as part of his / her patch,
> now that 1 line change becomes a guaranteed merge conflict for EVERY
> single patch that touches that driver.
I agree with this completely. I was simply stating my frustration/opinion
about the way that drivers are versioned which seems to be complete chaos.
Maybe the thing to do here is to modify git to assign version numbers to
groups of files (drivers) as an atom (and possibly modify a tag in the
file with the version). IE @@GIT_VERSION@@ would be replaced accordingly
if it is found in a file/s within the group.
IMHO A simple serial number or date would be quite useful.
>
> The pvrusb2 driver I maintain has an out-of-tree variant, and that one
> _is_ versioned - it has to be otherwise there's no way to identify a
> random out-of-tree driver build out in the wild. But that reasoning
> falters when the driver is in the kernel. In those cases it's the
> kernel version I follow not the driver version. I've worked it this way
> for some time now and it simply hasn't been a problem.
>
> Nevertheless with all that said it's not my driver we're talking about
> here. If the official cypress_m8 maintainer wants to require that
> version number to be bumped up (Neil: Why aren't you listed as a
> maintainer?) then it's not my place to debate it. I may have my opinion
> but it's not my driver. Greg KH, as a shepherd for all this might feel
> differently however...
>
> -Mike
>
> --
> | Mike Isely | PGP fingerprint
> Spammers Die!! | | 03 54 43 4D 75 E5 CC 92
> | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
> | |
>
-Neil Whelchel-
First Light Internet Services
760 366-0145 Ext 601
- I don't do Window$, that's what the janitor is for -
Nobody shot me.
-- Frank Gusenberg, his last words, when asked by police
who had shot him 14 times with a machine gun in the Saint
Valentine's Day Massacre.
Only Capone kills like that.
-- George "Bugs" Moran, on the Saint Valentine's Day Massacre
The only man who kills like that is Bugs Moran.
-- Al Capone, on the Saint Valentine's Day Massacre
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
