https://bugzilla.redhat.com/show_bug.cgi?id=1324590 --- Comment #38 from paul.j.reger@xxxxxxxxx --- (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? The 10.1 code that I pushed to github, was not released. It represents essentially the tip of our master branch. The 10.1 branch has NOT been made yet. The purpose of putting the bits on git hub was purely to support this review to get PSM accepted into Fedora. The 10.1 release is still probably 8 weeks away from being released. > > 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. I understand what you are saying. FWIW, we have a different definition of released. I hope you understand? > 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. The quality of code is not the issue here. We _believe_ it is production level quality. The issue here is that the code has not been formally tested by our internal validation department, and as such it can not be released yet. > > I will push the new version of the spec file for your review. > > > > Can you please re-review my spec file, and make further comments? > > I will. > > > 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. > > > and just review a tar ball. > > Did you create this tarball specially for the purpose of this review? That's > not what Doug was asking for. Neither was to upload tarballs to Bugzilla. > Just make sure the tarballs you publish on github use a sane naming and > versioning scheme. > > This tarball can be acceptable as a base for a Fedora package: > https://github.com/01org/opa-psm2/releases/download/10_1/hfi1-psm-10.1-0.tar. > gz > If I were the packager, I'd infer from the file name the version of the > software is "10.1" and "-0" is some superfluous string to ignore. Please disregard the tarball that I posted, as it appears we can move forward on the spec file. I will take down the tarball to prevent confusion. -- 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