From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Andy Gospodarek <andy@greyhouse.net>
Cc: Jay Vosburgh <fubar@us.ibm.com>, netdev@vger.kernel.org
Subject: Re: bonding and ifenslave version.
Date: Wed, 03 Aug 2011 21:38:15 +0200 [thread overview]
Message-ID: <4E39A3A7.1080905@gmail.com> (raw)
In-Reply-To: <CAHashqCrRq3z_bwddy3Y3+t+hmA4oN3hndmsTKUDNc73U=c3Gg@mail.gmail.com>
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.
next prev parent reply other threads:[~2011-08-03 19:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-02 20:06 [PATCH] bonding: document two undocumented options Nicolas de Pesloüan
2011-08-03 6:43 ` bonding and ifenslave version Nicolas de Pesloüan
2011-08-03 19:03 ` Andy Gospodarek
2011-08-03 19:38 ` Nicolas de Pesloüan [this message]
2011-08-03 20:07 ` Jay Vosburgh
2011-08-03 20:38 ` Nicolas de Pesloüan
2011-08-03 21:33 ` Stephen Hemminger
2011-08-04 5:31 ` Nicolas de Pesloüan
2011-08-04 16:57 ` Stephen Hemminger
2011-08-04 21:20 ` Nicolas de Pesloüan
2011-08-03 10:44 ` [PATCH] bonding: document two undocumented options David Miller
2011-08-03 20:01 ` Nicolas de Pesloüan
2011-08-03 20:59 ` Jay Vosburgh
2011-08-04 5:41 ` Nicolas de Pesloüan
2011-08-06 17:06 ` [PATCH v3] " Nicolas de Pesloüan
2011-08-08 5:16 ` David Miller
2011-08-03 20:02 ` [PATCH] " Nicolas de Pesloüan
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=4E39A3A7.1080905@gmail.com \
--to=nicolas.2p.debian@gmail.com \
--cc=andy@greyhouse.net \
--cc=fubar@us.ibm.com \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).