netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.




  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).