Hi Lance, I'd like to shoot for the week after Thanksgiving. We should be able to the two patches below merged to master in the next couple of days. There are a few other fixes tagged for 18.10.1 already. Anyone who knows a fix that has been merged to master and that you think should be included in 18.10.1, please add a "18.10.1" hashtag to it in GerritHub. I added a +2 to 429963. For 424973, it's still not clear to me what this should look like on master. I propose we handle it like we do include/spdk/version.h around a release: 1) when we check it in now, set Version to "master" and point Source to the github master.zip 2) when this gets cherry-picked to v18.10 branch, change Version to "18.10" and point Source to the github v18.10.zip 3) when we make the commit for the 18.10.1 tag, which updates include/spdk/version.h, we change Version on the spec file to "18.10.1" and point Source to the github v18.10.1.zip 4) in January when we do the 19.01 release, when we make the commit for the 19.01 tag, we change Version on the spec file to "19.01" and point Source to the github v19.01.zip 5) immediately after the 19.01 release, when we update include/spdk/version.h to 19.04-pre, we change Version on the spec file back to "master" and point Source to the github master.zip Thoughts? -Jim On 11/13/18, 8:39 AM, "SPDK on behalf of Lance Hartmann ORACLE" <spdk-bounces(a)lists.01.org on behalf of lance.hartmann(a)oracle.com&gt; wrote: Where are we with respect to releasing 18.10.1? Are we only awaiting +2 reviews on the packaging-related changes: https://review.gerrithub.io/#/c/spdk/spdk/+/424973/ https://review.gerrithub.io/#/c/spdk/spdk/+/429963/ Pawel pointed out during the community meeting today (2018-Nov-13) with respect to 424973, the importance of the proper version string (18.10.1) inside the spec file as that is used during the macro expansion for the source tarball name. -- Lance Hartmann _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk

On 11/14/18, 12:48 PM, "SPDK on behalf of Lance Hartmann ORACLE" <spdk-bounces(a)lists.01.org on behalf of lance.hartmann(a)oracle.com&gt; wrote: Just to confirm: we'll never populate github with an actual master.zip in case someone tries to do a "rpmbuild --undefine=_disable_source_fetch" or uses "spectool -g -R"? Hi Lance, master.zip is always populated - it always results in a zip file containing the current master. But that should be fine. If you want to build an 18.10.1 package, then you must have the pkg.spec file for 18.10.1 in hand (step #3 below). And that version of the spec file won't point to master.zip, it will point to v18.10.1.zip. -Jim -- Lance Hartmann _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk

On 11/14/18, 1:31 PM, "SPDK on behalf of Lance Hartmann ORACLE" <spdk-bounces(a)lists.01.org on behalf of lance.hartmann(a)oracle.com&gt; wrote: <snip> Really? So upon every merge into master, there's some script/hook that produces the master.zip on github? I'm not sure how GitHub implements it (maybe it creates the zip file when the http request is received), but yes - if you pull master.zip at any point, it will contain the current contents of the master branch. Now, I'm curious what would happen if one had a "properly" version'd SPDK pkg installed (e.g. 18.10.1) and then attempted to install a "spdk-master" in terms of checking version numbers... Nothing good I'm sure. If we're going to decouple the Version parameter from the Source parameter, we could make the Version = 19.01-pre. That's probably a better idea. -Jim