From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Lans Carstensen <Lans.Carstensen@dreamworks.com>,
NFS list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 2/4] nfs-utils: nfs-iostat.py autofs cleanup and option to sort by ops/s
Date: Thu, 27 Aug 2009 10:17:38 -0400 [thread overview]
Message-ID: <4A969582.50702@RedHat.com> (raw)
In-Reply-To: <9AB6A612-3CAA-4215-8247-25B1F8111896@oracle.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 <Lans.Carstensen@dreamworks.com>
>>>>>>>> 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.
next prev parent reply other threads:[~2009-08-27 14:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-26 4:59 [PATCH 2/4] nfs-utils: nfs-iostat.py autofs cleanup and option to sort by ops/s Lans Carstensen
2009-08-26 14:28 ` Chuck Lever
2009-08-26 15:13 ` Steve Dickson
2009-08-26 15:35 ` Chuck Lever
2009-08-26 18:03 ` Steve Dickson
2009-08-26 20:28 ` Chuck Lever
2009-08-26 23:56 ` Lans Carstensen
2009-08-27 14:04 ` Chuck Lever
2009-08-27 14:17 ` Steve Dickson [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-09-15 4:57 Lans Carstensen
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=4A969582.50702@RedHat.com \
--to=steved@redhat.com \
--cc=Lans.Carstensen@dreamworks.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@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.