[02:01:43] *** Quits: jstern (~jstern@192.55.54.44) (Ping timeout: 240 seconds) [02:01:43] *** Quits: cunyinch (~cunyinch@192.55.54.44) (Ping timeout: 240 seconds) [02:02:13] *** Quits: jimharris (~jimharris@192.55.54.44) (Ping timeout: 240 seconds) [02:03:07] *** Joins: jstern (~jstern@192.55.54.44) [02:04:58] *** Joins: cunyinch (~cunyinch@192.55.54.44) [02:05:28] *** Joins: jimharris (~jimharris@192.55.54.44) [06:26:49] *** Joins: mszwed (~mszwed@192.55.55.41) [06:30:40] *** Quits: tomzawadzki (~tzawadzk@192.55.54.42) (Ping timeout: 276 seconds) [06:39:27] *** Quits: mszwed (~mszwed@192.55.55.41) (Quit: Leaving) [06:40:35] *** Joins: mszwed (~mszwed@192.55.55.41) [06:45:41] *** Quits: mszwed (~mszwed@192.55.55.41) (Quit: Leaving) [07:45:30] *** Joins: nKumar (uid239884@gateway/web/irccloud.com/x-eyxvkzlosbwbnedj) [07:53:22] *** ChanServ sets mode: +o jimharris [07:58:44] OK, my UT patches are so screwed up wrt dependencies that I can't keep a consistent set posted - some keep updating others losing previous changes, etc. I'm going to abandon all of them and resubmit independently [08:08:52] new ones will have commit msg starting with "UNIT TEST:" [08:10:34] how about just "UT:" to keep it short? [08:40:07] Hi all, please check out the CI trello page https://trello.com/b/3DvD85zi/continuous-integration. I have added a list for Intermittent Failures to that page. If you see one, please add it to the list so we can look into it properly. [08:51:42] sethhowe: thanks! [08:51:58] drv: do you have the nightly test run patch in gerrithub starred by chance? [08:52:27] i'm putting together a query where the maintainers can star "significant" patches [08:53:55] Important=projects:spdk+starredby:jimharris+OR+starredby:benlwalker+OR+starredby:dverkamp-intel+status:open [09:05:42] great! [09:06:00] sethhowe, awesome idea! [09:08:14] jimharris I just starred it. [09:12:01] peluse, wish I could say it was mine. This one was all drv. [09:12:50] just read the rest of your comments jimharris. Here is the link to the nightly build so you can star it for the list. https://review.gerrithub.io/#/c/365924/ [09:15:43] why is that one starred? [09:23:15] jimharris: I unstarred it now [09:23:30] cool [09:47:34] jimharris, FYI I am indeed submitting the new UT chain as a series of patches but just one dependency chain so there are no conflicts at the end where the test add logic is at. Will let you know when they're done.... [10:47:20] here's the end of the chain https://review.gerrithub.io/#/c/372554/ but I don't understand some of the stuff gerrithub is saying in the 'conflicts with' section as all these were built one on top of another... blah [11:09:22] *** Joins: guest577 (~username@109241096052.gdansk.vectranet.pl) [11:14:44] *** Quits: guest577 (~username@109241096052.gdansk.vectranet.pl) (Remote host closed the connection) [11:20:45] *** Joins: pzedlews1 (~pzedlews@109241096052.gdansk.vectranet.pl) [11:21:17] *** Quits: pzedlews1 (~pzedlews@109241096052.gdansk.vectranet.pl) (Remote host closed the connection) [11:21:34] *** Joins: pzedlews1 (~pzedlews@109241096052.gdansk.vectranet.pl) [11:22:14] *** Quits: pzedlews1 (~pzedlews@109241096052.gdansk.vectranet.pl) (Remote host closed the connection) [11:25:56] *** Joins: guest577 (~username@109241096052.gdansk.vectranet.pl) [11:27:43] *** Joins: pzedlews_ (6df16034@gateway/web/freenode/ip.109.241.96.52) [11:32:53] to help a bit with the feedback from this morning: https://review.gerrithub.io/#/c/372560/ [11:33:09] *** Quits: guest577 (~username@109241096052.gdansk.vectranet.pl) (Remote host closed the connection) [11:37:05] *** Quits: pzedlews_ (6df16034@gateway/web/freenode/ip.109.241.96.52) (Ping timeout: 260 seconds) [11:52:05] that patch, combined with this query: https://review.gerrithub.io/#/q/project:spdk/spdk+AND+file:CHANGELOG.md [11:52:16] should let people monitor any API breaking change pretty easily [13:16:38] peluse: are we proposing "UNIT TEST:" as the model for patches that include unit test code? [13:17:08] i feel like you're shouting at me :) [13:18:13] maybe something like "ut/nvme: add tests for xyz" so we get the component in there? (jimharris suggested something like this when we were talking earlier) [13:18:38] yeah - i was just trying to understand why all caps [13:55:22] jimharris: can you look at this patch to SpdkEnv? https://review.gerrithub.io/#/c/370585/ [13:55:37] it is failing, but only because it requires some merge coordination between the SPDK repo and the RocksDB repo [14:00:26] lgtm [14:00:36] ok - I'll work on the RocksDB side [14:00:39] and figure out a good time to do that [14:00:52] I also have a patch to port our stuff to the latest RocksDB [14:00:59] i added changpeng as a reviewer just to make sure that one ENOENT-related change looks OK [14:01:02] should we do that, or hold things constant? [14:01:12] no - I think we should go to the latest RocksDB [14:01:24] the one we're still on still has that XFS issue w/ latest kernel right? [14:01:30] yes [14:01:34] and it's fixed on the newer one [14:01:53] https://review.gerrithub.io/#/c/367732/ [14:02:05] I can merge that without breaking anything because the test machines don't update automatically [14:02:11] as long as you're cool with it [14:03:37] +2 [14:14:36] *** Joins: shiyer (~shiyer@143.166.116.70) [14:40:49] jimharris, LOL, they were all caps so you could see the new ones (with corrected dependencies) from the old ones which were cross dependent all over the place :) [16:25:30] bwalker, I thought you mentioned once that a MD sync in blobstore was a sync call but the API has a callback, did I just hear you wrong? [16:37:33] void spdk_bs_md_sync_blob(struct spdk_blob *blob, spdk_blob_op_complete cb_fn, void *cb_arg); [16:37:41] the 'sync' in that name is short for "synchronize" [16:37:44] not "synchronous" [16:37:55] so that call is asynchronous [16:38:06] it does writes to disk (to synchronous memory with disk) [16:38:11] synchronize* [16:38:12] oh boy [16:39:25] :) It was when I heard it verbally that I didn't connect the dots. thanks for confirming, already updated hello_blob. Need to send my slides to SNIA soon if you can get a chance to look through that patch, would be great [16:42:13] I think you missed my comments from patchset 11 [16:42:28] particularly the one about alignment [16:42:41] that's the only actually important one [16:44:18] OK, I'll fix that. If you don't have for full thorough review, just comments like that here in IRC will help make sure I don't have anything huge missing in the slides [16:45:55] OK bear with me folks. I have 10 UT patches that are all built one on top of another sequentially. I don't see in GH how I can tell which was first and which was last w/o looking at each and every one to find the one with "submitted together" showing just one entry (for first) or 10 for last. Is there any easier way anyone knows of either in GH or git? [16:47:00] they all look related to me in gerrithub [16:47:53] https://review.gerrithub.io/#/c/372548/ [16:47:54] they're in a nice change on gerrithub [16:47:57] nice chain [16:48:00] but you do see that "submitted together" column right? That has a different number for each one so I do think the one with only 1 is the first and the one with 10 is the last. Would be nice to see the freaking order somewhere [16:48:17] submitted together means just that - did you submit them in one push? [16:48:24] Related Changes shows the list for me [16:48:25] related changes shows how patches are related to each other [16:48:42] no, I did one with commit -s -a the pushed. Then did the next the same way, then the next, etc [16:48:52] makign change in between of course [16:48:52] so you'll see one at a time in "submitted together" [16:49:02] but they'll all be in "related changes" [16:49:08] you see that locally in git using "git log" [16:49:44] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.83) [16:54:27] OK, yeah git log --oneline is nice to see the order provided, of course, you've checkout the last in the series once you've found it [16:54:28] thanks [16:58:08] yeah, the main Gerrit dashboard isn't very good for multi-patch sets - there's no way to see the order from there [16:58:56] but once you've opened one of the patches in the series, the "Related Changes" list is in order [17:03:36] drv, cool yeah I wasn't sure if that order was correct or not but it does jive with git log, thanks [17:04:16] BTW, all the UT patch updates now were just commit msg changes... assuming they all pass they're once again ready for review [17:05:13] drv, and yeah your last comment about the dummy/match thing is something I had addressed before it just got lost because I had the dependencies all over the place so another update trashed them. It's all good now (famous last words) [17:06:05] ok, I'll check it out tomorrow - sounds good [17:06:10] FYI, AZ cards are playing now - first preseason game. I'm outta here! [17:55:01] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.83) (Remote host closed the connection) [17:57:56] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.83) [18:34:48] It seems that our gerrit pool is down, it does not test new submitted patches [18:42:55] hi ziyeyang, it looks like our lab network is having some kind of problem [18:43:55] OK, got it [18:44:32] I am able to access the server, but the connection is very slow, and it looks like the build pool is timing out when trying to connect to GerritHub [19:16:17] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.83) (Remote host closed the connection) [19:18:44] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.83) [20:08:17] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.83) (Ping timeout: 248 seconds) [20:22:02] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.83) [20:42:10] *** Quits: shiyer (~shiyer@143.166.116.70) (Ping timeout: 276 seconds) [20:42:14] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.83) (Remote host closed the connection) [20:42:33] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.83) [20:45:56] *** Joins: shiyer (~shiyer@143.166.116.70) [21:06:12] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.83) (Ping timeout: 240 seconds) [22:01:28] *** Joins: ziyeyang_ (~ziyeyang@192.55.55.41) [22:04:33] *** Quits: nKumar (uid239884@gateway/web/irccloud.com/x-eyxvkzlosbwbnedj) (Quit: Connection closed for inactivity) [22:22:42] *** Quits: ziyeyang_ (~ziyeyang@192.55.55.41) (Ping timeout: 240 seconds) [22:34:15] *** Joins: ziyeyang_ (~ziyeyang@192.55.55.41) [23:05:08] *** Joins: tomzawadzki (~tzawadzk@134.134.139.77) [23:23:49] *** Joins: Piotr (~pzedlews@109241096052.gdansk.vectranet.pl) [23:25:54] *** Quits: Piotr (~pzedlews@109241096052.gdansk.vectranet.pl) (Client Quit) [23:27:26] *** Joins: Piotr (~pzedlews@109241096052.gdansk.vectranet.pl) [23:28:14] *** Quits: Piotr (~pzedlews@109241096052.gdansk.vectranet.pl) (Client Quit)