[Open-FCoE] fcoe-utils tagging

Joe Eykholt jeykholt at cisco.com
Thu Dec 17 02:39:39 UTC 2009

Love, Robert W wrote:
> A few things are occurring right now that have made me think about the
> fcoe-utils tagging. These things are that Lucy and Eric are making
> changes to multiple user space tools and that I'd like to have a 2.6.32
> tarball for the "Downloads" page that has up-to-date code.
> Eric and Lucy's changes just made me think about whether each tool
> should have its own version or if there should be a common version.
> Looking at Open-iSCSI as a model it seems to make sense to have one
> version that's shared by all of the tools. Chris has just published
> a patch to accomplish this during our build process. With this patch
> we can increment the fcoe-utils version in configure.ac and it will
> be imported as each tool's version string. I think that every time
> this is incremented we should add a tag to the repository reflecting
> that new version (we've been doing that already).
> As I said, I'd also like the 2.6.32 tarball to have current code. The
> problem is that a few applications have been added that require
> exported kernel header files (for passthrough) and these exported 
> header files will not be available until 2.6.33. This means that I
> can't simply grab the tip and create a tarball.
> What I intend to do is to commit Chris' patch quickly (i.e. tomorrow).
> I don't think Chris' patch will be controversial, but if it is,
> please speak up now. I'm then going to generate a patch that modifies
> the Makefile to not build any tools dependent on the kernel header
> files. I'll tag that patch v2.6.32 and generate the tarball. Then
> I'll revert that patch so that the fcoe-utils tip builds the
> passthrough applications against a >2.6.32 kernel.
> The bottom line is that I'll be committing Chris' patch quickly and
> that I'll be reverting some Makefile changes and then reverting that
> patch immediately. I'll also add a few new tags to the repo. I
> expect the resultant fcoe-utils repo to look like this-
> v2.6.33 - 1.0.10 - <some change>       <--- in the future
>                  - <some change>
>                  - <some change>
>                  - revert last patch   <--- tomorrow
> v2.6.32 - 1.0.9  - Remove kernel header dependent apps from build
>           1.0.8  - Chris' versioning patch
>                  - Current tip (Eric's version patch)
> Thanks, //Rob

Maybe we can have versions on the individual tools and a version for the package.

One minor issue is the fcc script.  Editing the version in the script seems
wrong if the script hasn't changed.   I suppose the package version could be
put inside the fcc script as part of the build, but it's unnecessary as
it stands alone and doesn't need support from the rest of the package.

It's also nice to be able to know that if the versions are different, then
something really changed in the tool itself, not just in the packaging or
in some unrelated tool.

That's my 2 cents.  I can live with it either way.


More information about the devel mailing list