From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0439725173622264240==" MIME-Version: 1.0 From: Sasha Kotchubievsky Subject: [SPDK] Re: Preparation for SPDK 19.10 release Date: Wed, 16 Oct 2019 19:10:30 +0300 Message-ID: <050b01d5843c$3be930e0$b3bb92a0$@dev.mellanox.co.il> In-Reply-To: 761A88C7-7FAB-4982-9224-64BE01372A80@intel.com List-ID: To: spdk@lists.01.org --===============0439725173622264240== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Paul, PSB[SK] -----Original Message----- From: Luse, Paul E = Sent: Wednesday, October 16, 2019 5:47 PM To: 'Storage Performance Development Kit' Subject: [SPDK] Re: Preparation for SPDK 19.10 release Hi Sasha, I'm sure you'll get some other opinions as well but as the changelog now pr= etty much only contains interface and parameter changes sorted by module, a= re you just suggesting re-organizing it to make it clearer per module where= interface changes have occurred vs parameter changes? [SK] = I agree, changes in interfaces, mostly, are documented in changelog. I just= suggest to add compact table/list with per module changes in "public" inte= rfaces. Changes parameters are less documented. It would be nice to see the same information with focus on changes in inter= faces in addition to list of feature descriptions. Wrt testing, I love that you guys are testing this so thoroughly! I have to= ask though, what additional testing are you proposing that isn't already i= n either the main CI or your own CI? [SK] Our own CI Is there a possibility to get these tests unstreamed? We really want to co= ntinue with a model of continuous integration and test without any addition= al testing nearing a release. [SK] Unfortunately, it's quite complicated. We focus on network part of SPD= K and we test on real HW. I don't see how we can upstream such kind of test= ing. We're working on continuous testing for upstream SPDK, but at this sta= ge it's not ready. On the other hand, our test suite complements existing S= PDK in-house testing and we can provide valuable feedback at least for rele= ase version. More frequent testing will come later. The freeze window is to provide time to prepare the release, make sure we'v= e got everything in it that was intended, go through some Intel security ch= ecklist stuff, etc. Ben said it best once at a summit, our releases are re= ally just a bookkeeping activity. You can most definitely use that freeze window to do testing on your own an= d submit a bug that could potentially halt the release, but I'd wouldn't su= pport making that part of the process. Thx Paul =EF=BB=BFOn 10/16/19, 4:55 AM, "Sasha Kotchubievsky" wrote: Hi Tomek, = That's great news. = = I have couple questions: = - Some of latest SPDK releases (18.10, 19.04, 19.07) were released with serious bugs in NVME-OF RDMA. Especially latest 19.07. Is it possible to wait with formal release till our group in Mellanox will verify release candidate in internal verification system? I think, couple of days will= be enough for us provide a feedback to the community. - Can we add couple special sections to SPDK release notes (https://github.com/spdk/spdk/releases/tag/v19.07) ? = - Changes in interfaces - Changes in configuration parameters (including defaults) - Known bugs/issues For customers building solution on SPDK and considering upgrade, it's important to see changes in interfaces (including configuration paramet= ers). = = Example of changes in an interface in coming 19.10 is = https://github.com/spdk/spdk/commit/9522ed36f8474c9314b76b2618e8d2d9de5= 6afee #diff-2c205ae4170cbd2bbf219969f03c9c8d This commit adds a new event to bdev interface. = One of commits changed defaults was https://github.com/spdk/spdk/commit/b6b0a0ba59a21faf1a320dd3ea7079b282f= 9fc31 It changes default IOUnit size from 4K to 8K and affected existing configurations. = From my experience, having a table/list in release notes with such chan= ges (interfaces, parameters) can help to users to understand side-effects o= f the upgrade. I would suggest to maintain the table in Changelog and ask for contribu= tors to update it is a part of patch. At release, this table can be just cop= ied to release notes. = = Best regards Sasha = -----Original Message----- From: Zawadzki, Tomasz = Sent: Wednesday, October 9, 2019 5:41 PM To: Storage Performance Development Kit Subject: [SPDK] Preparation for SPDK 19.10 release = Hello all, = The merge window for SPDK 19.10 release will close by October 24th. Please ensure all patches you believe should be included in the release= are merged to master branch by this date. You can do it by adding a hashtag '19.10' in GerritHub on those patches. = The current set of patches that are tagged and need to be reviewed can = be seen here: https://review.gerrithub.io/q/hashtag:%252219.10%2522+(status:open) = Starting with this release, process used so far for Maintenance releases (ex. 19.04.1) will be applied to main releases. On October 24th new bra= nch 'v19.10.x' will be created, and a patch on it will be tagged as release candidate. Then, on October 31th, a formal release will take place tagging the last patch on the branch as SPDK 19.10. = Between release candidate and formal release, only critical fixes shall= be backported to the 'v19.10.x' branch. = Development can continue without disruptions on 'master' branch. = Thanks, Tomek _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org = _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org --===============0439725173622264240==--