https://bugzilla.redhat.com/show_bug.cgi?id=1324590 --- Comment #37 from Doug Ledford <dledford@xxxxxxxxxx> --- (In reply to Michal Schmidt from comment #34) > (In reply to paul.j.reger from comment #31) > > As such, I have changed that version to 10.1.0. But, that version is subject > > to change > > I'm confused. Do you mean that this is just a pre-release of 10.1.0 and a > final 10.1.0 is yet to be released? > Or you're not yet sure what version number the real release will have? > > > as the code is not quite ready to be released. > > I think we have different ideas what it means to release something. > It is tagged in the public git repo, a tarball was made from it and > published for anyone to download => it is released. > Do you mean this release does not have production-level quality? Consider > using common terms like "alpha", "beta", "rc" in the version string of such > releases, or have a well-defined numeric versioning scheme (for example: > X.Y.Z where Y is an odd number are pre-releases). > Consider writing release announcements to a mailing list (I see > intel-opa@xxxxxxxxxxxx is mentioned on > https://github.com/01org/opa-psm2/wiki, > but so far there were only test messages) and/or post them on a webpage. > Whatever versioning scheme you adopt, make it understandable for your > downstream consumers and distributors. I'd like to second this. Once a tarball is live on a download site, that's a release. And releases are permanent. If you need a structure or organization that allows you to have production code and test code, you could do something like openmpi. For them, their version breaks down like so: 1.8.0 | | | | | Version that's incremeneted on each subsequent release | Minor point, where all odd minor point versions are non-production | code bases for people to test with, and all even minor point releases | are production branches Major release version So, they will release any number of point releases starting at, say, 1.3.0. They may make it all the way up to 1.3.35 if need be. When they decide that this development branch is ready for a production release, it basically becomes 1.4.0. They then open 1.5.0 as the new development branch. They can then do parallel work on 1.4.0 and 1.5.0, where any fixes needed for production environments go on the 1.4.0 (and 1.5.0) branches, and when they have enough fixes to warrant it, they release 1.4.1. Likewise, they keep working on 1.5.0, taking in not just fixes that were needed for production but their ongoing new development, and they make releases here as needed. Something like that might work for you guys. > > Or, if you want, we can abandon this review, as Doug suggests, > > I did not read that as a suggestion to abandon this review. > We all still would like to get hfi1-psm accepted into Fedora, so the package > needs to pass through the review. Indeed. What I was meaning with my statement is that you are trying to fulfill the requirement of this review while wearing your Intel PSM developer hat and spit out all of the things this review needs from your upstream source repo. My suggestion was to instead split your work into two halves. One being the upstream PSM developer, and that role should spit out a tarball and nothing but a tarball. Then, with your Fedora packager hat on, you should take that tarball and write a Fedora specific spec file that will pass review. Once this review completes and we take the package into Fedora, the spec file will never be imported from the tarball again, so there's not really much sense in trying to get the tarball release to provide an ongoing spec file for use in Fedora. The Fedora spec file will be a part of the Fedora package repo, separate from the tarball. So, my "We only want and can only accept a tarball" is what I expect you to do with your PSM developer hat on. I expect you to switch to a Fedora package hat when working on the spec file and src rpm. The two efforts should be separate and distinct. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx