netdev - Re: bonding and ifenslave version.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E39A3A7.1080905@gmail.com>
Date:	Wed, 03 Aug 2011 21:38:15 +0200
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Andy Gospodarek <andy@...yhouse.net>
CC:	Jay Vosburgh <fubar@...ibm.com>, netdev@...r.kernel.org
Subject: Re: bonding and ifenslave version.

Le 03/08/2011 21:03, Andy Gospodarek a écrit :

>> I thought introducing a new option should cause the driver version to
>> change. Am I right?
>
> When a significant change happens, we try to change the version
> number.  The version number probably should have been changed when
> those were added.  Inspecting the module options or sysfs parameters
> indicate whether or not these patches were added, so it is less of a
> priority than when some internal infrastructure (like moving to use
> rx_handler) changes.
>
> I consider it more critical to change the bonding module version when
> something changes that cannot be detected by inspecting the module or
> sysfs parameters.  This is more helpful to users reporting problems.
>

Ok, 'sounds perfectly sensible to me, thanks.

>> On a different but related topic, the version in
>> Documentation/networking/ifenslave.c (1.1.0) didn't change since the git
>> origin and probably since 2003.
>>
>> Arguably, none of the commit regarding this file introduced a significant
>> change (with the possible exception of commit
>> e6d184e33109010412ad1d59719af74755a935f4, [NET]: Fix ifenslave to not fail
>> on lack of IP information). But if we never change a 3-level version number,
>> whatever the level of change, this version number might be useless. Any
>> comment?
>>
>>         Nicolas.
>>
>
> Distributions benefit from version numbers on userspace utils.  It
> would probably be better to keep ifenslave's version number as it is
> to help those maintaining those distro packages.

As one of the maintainers for the ifenslave package on Debian, I perfectly understand the need for 
an upstream version, but as such, I expected the upstream version number to change when the file 
change... Version numbers in Debian use upstream version numbers when available and add a subversion 
number for Debian specific changes. I would expect to change the version number and not only the 
Debian subversion when the only change is a new upstream version.

Anyway, it is not that important and I can leave with 1.1.0 for long :-D

Thanks again.

	Nicolas.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html