> -----Original Message----- > From: fcoe-devel [mailto:[email protected]] On Behalf Of > Dev, Vasu > Sent: Friday, January 30, 2015 9:14 AM > To: Chris Leech > Cc: [email protected] > Subject: Re: [Open-FCoE] [PATCH] fcoe-utils: automake fixes for > dist/distcheck > > > -----Original Message----- > > From: Chris Leech [mailto:[email protected]] > > Sent: Thursday, January 29, 2015 9:35 PM > > To: Dev, Vasu > > Cc: [email protected] > > Subject: Re: [Open-FCoE] [PATCH] fcoe-utils: automake fixes for > > dist/distcheck > > > > On Fri, Jan 30, 2015 at 01:54:42AM +0000, Dev, Vasu wrote: > > > > > > > > I thought I'd give make distcheck a try on fcoe-utils and see if > > > > it produced a working release. It didn't, so here are some fixes for > > > > that. > > > > > > > > Missing header files added to git are included in the release archive. > > > > > > > > The systemd unit files are marked dist_DATA so they get included, > > > > otherwise data files are assumed to be generated at build time and > > > > left out of the release. > > > > > > > > A few other missing doc files are added to dist_noinst_DATA. > > > > > > > > The manual rules for handling bash completion files are replaced > > > > with dist_DATA definitions letting automake handle generating rules. > > > > > > > > Any change of applying build system fixes, and getting a new tag > > > > and release tarball anytime in the near future? > > > > > > > > > > I announced last year of doing away with upstream tar ball release > > > and in fact when we had it, then also it was simply tar of three > > > open-fcoe user tools git trees instead of using distcheck, so I > > > won't be surprised if this doesn't work for other two user tools git > > > trees but any > > case good to fix all three git repos. > > > > Ah, I knew the kernel code wasn't using a separate tree anymore but I > > guess I missed the bit about not doing user-space releases. > > > > libhbaapi/libhbalinux look to have some minor autotools issues, I can > > send a patch if you want. > > > > Always, that would be good. > > > > I'm not sure if we need tags but sure user tools version bump make > > > sense and I'm thinking of using same for tag instead of we used to > > > have tag every kernel cycle even when no change to user tools. > > > > Yeah, the kernel version tags aren't all that useful - I keep deleting > > them locally so they don't mess with git-describe. I get that Rob was > > trying to keep the same cadence as the kernel releases when there were > > active changes going on. > > > > fcoe-utils is now 33 patches ahead of the last tag, with the bulk of > > those being in git for over a year. I just thought it would be nice > > to bump the version to 1.0.30 and tag it, maybe put out a tarball. I > > don't expect this to be a frequent thing. > > > > Yes looks like won't be frequent. All good suggestions, I agree with all and > doing tarball release along any major version bump makes sense given that it > should be infrequent. > I mean any version bump not major version, I was considering later but will defer that for now.
//Vasu _______________________________________________ fcoe-devel mailing list [email protected] http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
