All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.