Tuesday, 2017-07-11

*** sdague has quit IRC01:17
*** emagana has joined #openstack-tc03:41
*** emagana has quit IRC04:23
*** emagana has joined #openstack-tc04:24
*** emagana_ has joined #openstack-tc04:26
*** emagana has quit IRC04:28
*** emagana_ has quit IRC04:31
*** emagana has joined #openstack-tc04:32
*** emagana has quit IRC04:36
*** zaneb has quit IRC05:29
*** zaneb has joined #openstack-tc05:29
*** emagana has joined #openstack-tc06:44
*** emagana has quit IRC06:48
*** zaneb has quit IRC07:36
*** jpich has joined #openstack-tc07:47
*** zaneb has joined #openstack-tc07:48
*** cdent has joined #openstack-tc08:58
ttxOffice hours time!09:00
ttxflaper87: around?09:00
ttxcdent: hi!09:01
* cdent coffees09:05
ttxLooking up our current initiatives, we'll hopefully unblock the vision and goals at the meeting today09:06
ttxSWG is still waiting for a new champion to rise to drive it09:07
ttxStackube/Gluon applications are frozen09:07
ttxGlare application, we can discuss here09:07
ttxLooks like the PostgreSQL statement is nearing agreement09:08
ttxflaper87 still needs to work on the meeting drop statement09:08
ttxI made good progress on the SIG stuff with mrhillsman, hopefully will ahve some announcement about it soon09:08
ttxflaper87: what's the next step on "Allow teams to use their channel for meetings" ?09:09
ttxI think the cost of switching is now accepted, so we could relax irc-meetings change validation rules ?09:09
ttxre: Glare, /me looks up what Artifactory is09:11
johnthetubaguyttx: afraid I can't be around for the meeting later, I had already arranged a quintet rehearsal09:13
ttxew, open core09:13
ttxjohnthetubaguy: you're fine with the goals ? Any input on the next step for vision ?09:13
johnthetubaguyttx: I added my votes/comments on the vision patches09:15
johnthetubaguyttx: at a high level the goals seems sound, particularly as folks stepped up to lead them both09:16
johnthetubaguyvision wise, I like cdent's tweaks to the wording so its easier to consume09:16
johnthetubaguyI think we should probably merge what we have, even though things have changed some since we agreed the priorities in there09:17
johnthetubaguythere is nothing in the vision I think we should remove, its just I wonder if there are now higher priority issues to consider, but having the vision merged is probably a good starting point for that discussion09:18
ttxcdent: regarding your comment on the Glare review... I think storage of versioned artifacts has a breadth of use, and Glance avoids that territory. What I'd prefer is complementarity (Glare as a Glance backend) rather than replacement/competition (Glare accessed directly from Nova)09:19
ttxMy other concern is that it's likely to split the limited resources willing to work on that project space09:20
ttxBut otherwise it's definitely in scope and following our principles, so we should probably accept it09:20
ttxOne positive way to look at it is that we may be able to influence the direction of it toward more complementarity once it's "in"09:21
ttxWould love to hear flaper87's take on it, since he is way more involved in that discussion than I ever was09:22
cdentI think it is pretty clear from the discussion surrounding it that the desired end game by the people working on glare is to replace glance09:22
cdentwhich is perhaps fine, but should be considered as we are evaluating it09:23
cdentwe may want it to be complementary, but what we want doesn't have _that_ much to do with it09:23
cdentI think it is also important to consider if maybe glance's functionality (and artifact handling) can be handled by a very small shim over something that is more globally available09:25
cdentartifactory seems to _not_ be it09:25
johnthetubaguywithout answering the can you implement glance v2 on top question, it seems a bit like a framework that doesn't share any users with OpenStack09:27
johnthetubaguyhaving a better image "life cycle" in glance seems really important for interop, and artifacts maybe helps, but not in the short term09:28
johnthetubaguyI guess that is a +1 to ttx's splitting limited resources worry09:28
ttxcdent: if we have a precise vision for it, we could reject the application (on grounds of duplication of effort) until it's fixed. With the risk that they just drop the idea of joining of course09:30
ttxI mean "gratuitous duplication of effort"09:30
ttxBut it's not really gratuitous, so it's a bit of a stretch09:30
johnthetubaguyseems odd for the mission to include images for Nova and templates for Heat, that does overlap with glance09:31
ttxcdent: overll I feel like versioning and multi-object-per-artifact could be implemented more cheaply, yes09:31
ttxNo need to duplicate Nova-Glance code paths or Glance store functionality09:32
cdentI have no objection to the application, instead I think we have an opportunity to either cut some fat, or provide more direct guidance on being more simple09:32
ttxcdent: right. I'm there too09:32
ttxAt this point I think we'll have more leverage with it in09:32
ttxit's not as if it doesn't exist09:33
ttxAlso we don't really have that unified vision of how that should work. Maybe flaper87 has09:33
ttxWe are just annoyed that there seems to be a duplication of effort in a limited-resource area09:33
johnthetubaguyyeah, I am curious how this looks to the API user09:33
ttxFrom an interoperability perspective, ideally users of a Glare-backed cloud would not see a difference09:34
ttxif they do, this would be a step back09:34
johnthetubaguyyeah, just trying to say that in the comment I am writing09:35
ttxApparently they addressed it in the thread during the night, reading now09:39
cdentit was a case of "yes, the same, except for one critical bit" from my read09:40
ttxfeels like it could be 100% compatible with some minimal effort09:43
* cdent nods09:44
*** sdague has joined #openstack-tc10:05
flaper87ttx: here now11:22
flaper87ttx: re channels, I'll work on a resolution for that and a patch to remove the validation check on the meetings repo11:23
flaper87ttx: re the TC meetings, I was actually planning to update that patch today. I think we've made good progress on figuring out a good way to work11:23
flaper87there are still things to polish out but we're making progress11:24
* flaper87 goes and reads cdent's comment on the Glare patch11:24
cdenti'm not sure I said anything all that interesting flaper87...11:34
flaper87cdent: I can still make fun of you for not being interesting enough, right? :P11:35
cdentbut of course11:36
cdentalso: happy belated birthday; twitter made it look like a great time11:36
* dims reading OpenStack-Gender-Diversity-Report_Apr2017.pdf12:08
dims:( female representation lags among Project Team Lead (PTL) positions at 5%, and within the Technical Committee at 0%.12:09
cdentyeah, we're not doing great on that front12:30
* cdent walks12:30
sdaguedims: reference link?12:31
fungididn't glare start out under the glance team and then split into an independent effort? i wonder if any of that plays into the "designed to be glance-ng++" thinking12:35
fungithough my opinion is we shouldn't be encouraging a new effort to replace one currently covered by refstack and trademark programs without some very clearly-thought-out transition planning12:40
sdaguefungi: yeh, this was part of a push right before getting rid of the integrated release of a lot of function trying to build into glance instead of going through the governance process from scratch12:41
sdagueboth searchlight and glare were products of that. The first to make finding snapshots by names viable in large systems, the second to change glance from image store to artifact store where an image could be an artifact12:42
fungimakes sense, and jives with my memory of the situation back when12:43
dimssdague : http://superuser.openstack.org/wp-content/uploads/2017/07/OpenStack-Gender-Diversity-Report_Apr2017.pdf13:16
dimssdague : superuser article - http://superuser.openstack.org/articles/bitergia-intel-report/13:17
*** emagana has joined #openstack-tc13:19
*** emagana has quit IRC13:24
sdaguedims: thanks13:25
sdaguedims: it would have been nice to do some of those as graphs instead of just tables of numbers13:45
sdagueI guess there is a jupyter notebook behind some of it - https://github.com/dicortazar/ipython-notebooks/blob/master/projects/openstack-diversity/OpenStack%20Diversity%20Metrics.ipynb13:48
dimsnice find sdague13:49
sdagueit's in the footnotes at the end13:50
sdagueI honestly wish the whole thing was just published as a jupyter notebook13:50
*** hongbin has joined #openstack-tc14:03
*** marst has joined #openstack-tc14:31
*** emagana has joined #openstack-tc14:49
dhellmannisn't the packaging-deb project basically a set of repos that copy everything else? seems like those should have been left out of the stats.15:10
cdentdhellmann: yeah, I think you're correct15:13
dhellmannI wonder how that skews the results.15:14
dhellmannI guess if everything is counted twice, it's not skewing, but if packaging-deb includes things that wouldn't otherwise be counted it might15:16
ttxdhellmann: it does count a number of commits twice yes15:24
ttxBitergia always had trouble weeding out problematic data, due to not knowing the specifics15:24
dhellmannthey also have official repos for projects that aren't otherwise official (deb-kazoo was the first one I found, then I stopped looking)15:24
dhellmannI don't know how to accurately count that project, but given that it doesn't currently have an active ptl it seems odd to be highlighting it as a top project in this regard15:25
ttxso yeah, I wouldn't read too much into their project data. The leadership diversity issues still hold though15:25
dhellmannoh, definitely15:25
*** cdent has quit IRC15:56
*** cdent has joined #openstack-tc15:58
sdaguethere is actually quite a bit of the data that seems slightly inconsistent, like projects with percent female authors that aren't possible given the number of authors that exist15:58
sdagueor more than slightly inconsistent15:58
sdagueI tried to pull and replicate the jupyter notebook, but it requires a private ES server with credentials to get the data it seems15:59
dhellmannyeah, this is sort of disappointing15:59
sdaguettx: it would be really great if the foundation is paying for stuff like this if the required output includes a jupyter notebook with the raw data set so it can be replicated as well as visualized better by others16:00
cdentit’s sadly common that numeric corporate research is completely bogus16:00
fungianyone doing raw git digestion for our repos is going to end up with some significant skew in results. if they instead query the gerrit api and analyze distinct changes instead of git commits the duplication goes away16:01
sdaguecdent: sure, it's just when easy to identify problems like i18n with 1.0 authors but 7.14% ratio authors doesn't make you feel very good about the rest of the analysis16:02
dhellmannfungi : well, part of the problem is also that they're counting repos they shouldn't (packaging-deb owns deb-kazoo, but kazoo isn't an official project, for example)16:02
sdagueunless that is female authors?16:02
sdagueI don't know, those final tables are a little wonky to understand16:02
cdentsdague: I think we’re agreeing?16:02
sdagueand 5 decimal places isn't helping :)16:02
sdaguecdent: yes16:02
fungidhellmann: if they were analyzing gerrit changes, the only hits for deb-kazoo would be the packaging-related work and not any of the actual kazoo contributions16:03
fungithat's what i mean by "duplication"16:03
sdagueI was trying to provide specific supporting statements of things that seem wrong or unclear16:03
dhellmannfungi : ah16:03
fungiinfra has the same situation with its fork of the gerrit repo... if you look at changes in our gerrit for our gerrit repo fork you'll only find patches we initiate, and won't count any of the upstream gerrit commits16:04
dhellmannI would have also thought the differences in patches submitted vs. accepted by gender would be a key piece of information, but I don't see that broken out16:04
ttxsdague: I think our support for it was only in promotion, but yes, that sounds like a good requirement to add :)16:05
fungiso in the deb-kazoo example, these are ideally the only hits they would count as openstack contribution: https://review.openstack.org/#/q/project:openstack/deb-kazoo16:05
dhellmannI would not expect to see packaging-deb as the project with the most patches, counted like that16:06
sdaguettx: about half their stuff is there, but they need to provide a way to get the raw data that's not locked in their elastic search16:06
fungier, more accurately https://review.openstack.org/#/q/is:merged+project:openstack/deb-kazoo16:07
dhellmannsdague : I like the extra precision of showing 1 digit after the decimal place when counting authors.16:08
* fungi only counts as 0.7 authors16:08
dhellmannfungi : you're 0.7 of a 10x developer, though, so still a 716:09
dhellmannso the leadership section of this is useful, but I don't know how much we can count on the bulk of the contributor stats16:10
fungi7 out of 10. it has a beat i can dance to, but i find the melody lacking16:10
sdaguedhellmann: yeh16:10
sdaguethe leadership side isn't any data processing though, that's just manual counting16:11
sdagueit's good to have all in one place16:11
*** jpich has quit IRC16:25
cdentmeeting at 8 utc?18:13
dhellmanncdent : yes18:37
cdentthanks dhellmann and smcginnis18:38
*** dtroyer has quit IRC18:47
*** dtroyer has joined #openstack-tc18:49
*** sdague has quit IRC19:00
*** cdent has quit IRC19:02
*** rockyg has joined #openstack-tc19:03
*** cdent has joined #openstack-tc19:06
*** rocky_g has joined #openstack-tc19:22
*** rockyg has quit IRC19:23
*** rockyg has joined #openstack-tc19:31
*** rocky_g has quit IRC19:32
*** emagana has quit IRC19:59
*** emagana_ has joined #openstack-tc20:00
*** marst has quit IRC20:08
rockyg quickie -- InteropWG has 2 full days scheduled at PTG -- Monday and Tuesday.  In case I don't get the info to the rest of the TC in office hours21:06
rockygInteropWG PTG prelim schedule:  https://docs.google.com/spreadsheets/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/edit#gid=39724131221:07
cdenthey rockyg, what are you saying?21:08
rockygInteropWG==Defcore.  InteropWG will have two full days at PTG, Monday and Tuesday.  Their preliminary schedule is in the posted doc.  I've added a comment about glare to the InteropWG meeting agenda for tomorrow21:11
cdentrockyg: ah, that’s my confusion, that link is the overall ptg schedule. did you also have a link for a specific interopwg schedule?21:14
rockygOh!  I'm sorry.  Misread the minutes.21:15
rockygYeah.  It doesn't look like we've started building the schedule yet.21:16
cdentI guess I need to start a similar thing for api-wg21:16
cdentProbably won’t have the audience we did last time because microversions not currently on the agenda21:17
cdentguess need to do put them there and then everyone will show up21:17
rockygThat's a thought!21:19
rockygAnother possibility is to offer to review and comment on new projects' APIs and what they should do to meet the guidelines.21:20
cdentthat actually a good idea (where my silliness was not)21:21
rockygSort of APIWG Office hours for new projects.21:22
rockygOr API guideline tutorials.21:23
rockygLet folks know early so the devs turn up for the first couple of days.21:24
cdenti’ll add a link to this for the next agenda21:25
rockygThat could really turn into something useful for PTGs.  Get New projects integrated better and maybe have problem solving sessions for devs who have tough questions.21:25
*** rockyg has quit IRC21:34
*** cdent has quit IRC22:56
*** hongbin has quit IRC23:29

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!