commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e
Author: Lans Carstensen <[email protected]>
Date: Tue Aug 25 21:52:03 2009 -0700
Bump nfs-iostat.py version up to 0.3 to reflect new features.
diff --git a/tools/nfs-iostat/nfs-iostat.py b/tools/nfs-iostat/nfs-iostat.py
index ea02db4..6ce31fc 100644
--- a/tools/nfs-iostat/nfs-iostat.py
+++ b/tools/nfs-iostat/nfs-iostat.py
@@ -22,7 +22,7 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
import sys, os, time
-Iostats_version = '0.2'
+Iostats_version = '0.3'
def difference(x, y):
"""Used for a map() function
On 08/26/2009 11:35 AM, Chuck Lever wrote:
> On Aug 26, 2009, at 11:13 AM, Steve Dickson wrote:
>> On 08/26/2009 10:28 AM, Chuck Lever wrote:
>>>
>>> On Aug 26, 2009, at 12:59 AM, Lans Carstensen wrote:
>>>
>>>> commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e
>>>> Author: Lans Carstensen <[email protected]>
>>>> Date: Tue Aug 25 21:52:03 2009 -0700
>>>>
>>>> Bump nfs-iostat.py version up to 0.3 to reflect new features.
>>>
>>> Now that nfs-iostat.py has been integrated into nfs-utils, I'm not sure
>>> we want to maintain an individual version number for it. Maybe it
>>> should use the nfs-utils package's versioning instead... Steve, your
>>> thoughts?
>> Hmm... I don't think we tie any of other commands versions to
>> the package version....
>
> Actually many of the C commands do grab a macro defined during
> autoconfiguration: PACKAGE_VERSION.
>
Interesting.. I do see PACKAGE_VERSION being defined in support/include/config.h
I guess I didn't know that was there and it does not seem to be used
by anybody... which is probably a problem but I don't think its a problem
with this script...
steved.
On Aug 26, 2009, at 7:56 PM, Lans Carstensen wrote:
> Chuck Lever wrote:
>> On Aug 26, 2009, at 2:03 PM, Steve Dickson wrote:
>>> On 08/26/2009 11:35 AM, Chuck Lever wrote:
>>>> On Aug 26, 2009, at 11:13 AM, Steve Dickson wrote:
>>>>> On 08/26/2009 10:28 AM, Chuck Lever wrote:
>>>>>>
>>>>>> On Aug 26, 2009, at 12:59 AM, Lans Carstensen wrote:
>>>>>>
>>>>>>> commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e
>>>>>>> Author: Lans Carstensen <[email protected]>
>>>>>>> Date: Tue Aug 25 21:52:03 2009 -0700
>>>>>>>
>>>>>>> Bump nfs-iostat.py version up to 0.3 to reflect new features.
>>>>>>
>>>>>> Now that nfs-iostat.py has been integrated into nfs-utils, I'm
>>>>>> not sure
>>>>>> we want to maintain an individual version number for it. Maybe
>>>>>> it
>>>>>> should use the nfs-utils package's versioning instead... Steve,
>>>>>> your
>>>>>> thoughts?
>>>>> Hmm... I don't think we tie any of other commands versions to
>>>>> the package version....
>>>>
>>>> Actually many of the C commands do grab a macro defined during
>>>> autoconfiguration: PACKAGE_VERSION.
>>>>
>>> Interesting.. I do see PACKAGE_VERSION being defined in support/
>>> include/config.h
>>> I guess I didn't know that was there and it does not seem to be used
>>> by anybody... which is probably a problem but I don't think its a
>>> problem
>>> with this script...
>> Right, I'm suggesting now would be a good time to switch these
>> scripts over to the package-wide versioning scheme.
>> But take a look at mount, statd, showmount, and nfsstat, at least:
>> these, for example, use the VERSION macro in their -V and usage
>> messages.
>
> I agree with that concept but I'll kindly defer on the
> implementation as I'm not exactly sure what would be required.
That's quite alright. Probably Steve should cook something up for
this one.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Chuck Lever wrote:
> On Aug 26, 2009, at 2:03 PM, Steve Dickson wrote:
>> On 08/26/2009 11:35 AM, Chuck Lever wrote:
>>> On Aug 26, 2009, at 11:13 AM, Steve Dickson wrote:
>>>> On 08/26/2009 10:28 AM, Chuck Lever wrote:
>>>>>
>>>>> On Aug 26, 2009, at 12:59 AM, Lans Carstensen wrote:
>>>>>
>>>>>> commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e
>>>>>> Author: Lans Carstensen <[email protected]>
>>>>>> Date: Tue Aug 25 21:52:03 2009 -0700
>>>>>>
>>>>>> Bump nfs-iostat.py version up to 0.3 to reflect new features.
>>>>>
>>>>> Now that nfs-iostat.py has been integrated into nfs-utils, I'm not
>>>>> sure
>>>>> we want to maintain an individual version number for it. Maybe it
>>>>> should use the nfs-utils package's versioning instead... Steve, your
>>>>> thoughts?
>>>> Hmm... I don't think we tie any of other commands versions to
>>>> the package version....
>>>
>>> Actually many of the C commands do grab a macro defined during
>>> autoconfiguration: PACKAGE_VERSION.
>>>
>> Interesting.. I do see PACKAGE_VERSION being defined in
>> support/include/config.h
>> I guess I didn't know that was there and it does not seem to be used
>> by anybody... which is probably a problem but I don't think its a problem
>> with this script...
>
> Right, I'm suggesting now would be a good time to switch these scripts
> over to the package-wide versioning scheme.
>
> But take a look at mount, statd, showmount, and nfsstat, at least:
> these, for example, use the VERSION macro in their -V and usage messages.
I agree with that concept but I'll kindly defer on the implementation as
I'm not exactly sure what would be required. I guess maybe generation
of a Makefile.am that uses sed or somesuch to patch the script?
-- Lans Carstensen, Systems Engineering, Dreamworks Animation
Because they consistently observe and listen, the humble improve.
-- Wynton Marsalis
On Aug 26, 2009, at 11:13 AM, Steve Dickson wrote:
> On 08/26/2009 10:28 AM, Chuck Lever wrote:
>>
>> On Aug 26, 2009, at 12:59 AM, Lans Carstensen wrote:
>>
>>> commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e
>>> Author: Lans Carstensen <[email protected]>
>>> Date: Tue Aug 25 21:52:03 2009 -0700
>>>
>>> Bump nfs-iostat.py version up to 0.3 to reflect new features.
>>
>> Now that nfs-iostat.py has been integrated into nfs-utils, I'm not
>> sure
>> we want to maintain an individual version number for it. Maybe it
>> should use the nfs-utils package's versioning instead... Steve, your
>> thoughts?
> Hmm... I don't think we tie any of other commands versions to
> the package version....
Actually many of the C commands do grab a macro defined during
autoconfiguration: PACKAGE_VERSION.
> Although it might be a good idea to do so,
> but for this instance, since these commands are still incognito (there
> are not man pages, which is on my plate), I think just bumping the
> version is fine..
>
> steved.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On 08/27/2009 10:04 AM, Chuck Lever wrote:
> On Aug 26, 2009, at 7:56 PM, Lans Carstensen wrote:
>> Chuck Lever wrote:
>>> On Aug 26, 2009, at 2:03 PM, Steve Dickson wrote:
>>>> On 08/26/2009 11:35 AM, Chuck Lever wrote:
>>>>> On Aug 26, 2009, at 11:13 AM, Steve Dickson wrote:
>>>>>> On 08/26/2009 10:28 AM, Chuck Lever wrote:
>>>>>>>
>>>>>>> On Aug 26, 2009, at 12:59 AM, Lans Carstensen wrote:
>>>>>>>
>>>>>>>> commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e
>>>>>>>> Author: Lans Carstensen <[email protected]>
>>>>>>>> Date: Tue Aug 25 21:52:03 2009 -0700
>>>>>>>>
>>>>>>>> Bump nfs-iostat.py version up to 0.3 to reflect new features.
>>>>>>>
>>>>>>> Now that nfs-iostat.py has been integrated into nfs-utils, I'm
>>>>>>> not sure
>>>>>>> we want to maintain an individual version number for it. Maybe it
>>>>>>> should use the nfs-utils package's versioning instead... Steve, your
>>>>>>> thoughts?
>>>>>> Hmm... I don't think we tie any of other commands versions to
>>>>>> the package version....
>>>>>
>>>>> Actually many of the C commands do grab a macro defined during
>>>>> autoconfiguration: PACKAGE_VERSION.
>>>>>
>>>> Interesting.. I do see PACKAGE_VERSION being defined in
>>>> support/include/config.h
>>>> I guess I didn't know that was there and it does not seem to be used
>>>> by anybody... which is probably a problem but I don't think its a
>>>> problem
>>>> with this script...
>>> Right, I'm suggesting now would be a good time to switch these
>>> scripts over to the package-wide versioning scheme.
>>> But take a look at mount, statd, showmount, and nfsstat, at least:
>>> these, for example, use the VERSION macro in their -V and usage
>>> messages.
>>
>> I agree with that concept but I'll kindly defer on the implementation
>> as I'm not exactly sure what would be required.
>
> That's quite alright. Probably Steve should cook something up for this
> one.
Yeah... don't get get hung up on this one... I'll deal with it...
steved.
On Aug 26, 2009, at 12:59 AM, Lans Carstensen wrote:
> commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e
> Author: Lans Carstensen <[email protected]>
> Date: Tue Aug 25 21:52:03 2009 -0700
>
> Bump nfs-iostat.py version up to 0.3 to reflect new features.
Now that nfs-iostat.py has been integrated into nfs-utils, I'm not
sure we want to maintain an individual version number for it. Maybe
it should use the nfs-utils package's versioning instead... Steve,
your thoughts?
> diff --git a/tools/nfs-iostat/nfs-iostat.py b/tools/nfs-iostat/nfs-
> iostat.py
> index ea02db4..6ce31fc 100644
> --- a/tools/nfs-iostat/nfs-iostat.py
> +++ b/tools/nfs-iostat/nfs-iostat.py
> @@ -22,7 +22,7 @@ Foundation, Inc., 59 Temple Place, Suite 330,
> Boston, MA 02111-1307 USA
>
> import sys, os, time
>
> -Iostats_version = '0.2'
> +Iostats_version = '0.3'
>
> def difference(x, y):
> """Used for a map() function
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Aug 26, 2009, at 2:03 PM, Steve Dickson wrote:
> On 08/26/2009 11:35 AM, Chuck Lever wrote:
>> On Aug 26, 2009, at 11:13 AM, Steve Dickson wrote:
>>> On 08/26/2009 10:28 AM, Chuck Lever wrote:
>>>>
>>>> On Aug 26, 2009, at 12:59 AM, Lans Carstensen wrote:
>>>>
>>>>> commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e
>>>>> Author: Lans Carstensen <[email protected]>
>>>>> Date: Tue Aug 25 21:52:03 2009 -0700
>>>>>
>>>>> Bump nfs-iostat.py version up to 0.3 to reflect new features.
>>>>
>>>> Now that nfs-iostat.py has been integrated into nfs-utils, I'm
>>>> not sure
>>>> we want to maintain an individual version number for it. Maybe it
>>>> should use the nfs-utils package's versioning instead... Steve,
>>>> your
>>>> thoughts?
>>> Hmm... I don't think we tie any of other commands versions to
>>> the package version....
>>
>> Actually many of the C commands do grab a macro defined during
>> autoconfiguration: PACKAGE_VERSION.
>>
> Interesting.. I do see PACKAGE_VERSION being defined in support/
> include/config.h
> I guess I didn't know that was there and it does not seem to be used
> by anybody... which is probably a problem but I don't think its a
> problem
> with this script...
Right, I'm suggesting now would be a good time to switch these scripts
over to the package-wide versioning scheme.
But take a look at mount, statd, showmount, and nfsstat, at least:
these, for example, use the VERSION macro in their -V and usage
messages.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On 08/26/2009 10:28 AM, Chuck Lever wrote:
>
> On Aug 26, 2009, at 12:59 AM, Lans Carstensen wrote:
>
>> commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e
>> Author: Lans Carstensen <[email protected]>
>> Date: Tue Aug 25 21:52:03 2009 -0700
>>
>> Bump nfs-iostat.py version up to 0.3 to reflect new features.
>
> Now that nfs-iostat.py has been integrated into nfs-utils, I'm not sure
> we want to maintain an individual version number for it. Maybe it
> should use the nfs-utils package's versioning instead... Steve, your
> thoughts?
Hmm... I don't think we tie any of other commands versions to
the package version.... Although it might be a good idea to do so,
but for this instance, since these commands are still incognito (there
are not man pages, which is on my plate), I think just bumping the
version is fine..
steved.