Thursday, 2017-08-24

*** gcb has quit IRC01:33
*** gcb has joined #openstack-tc01:34
*** jpich has joined #openstack-tc06:59
*** dtantsur|afk is now known as dtantsur07:46
*** cdent has joined #openstack-tc08:48
*** cdent has quit IRC09:04
*** cdent has joined #openstack-tc09:05
*** cdent has quit IRC09:26
*** cdent has joined #openstack-tc10:02
*** dtantsur is now known as dtantsur|brb10:14
*** cdent has quit IRC11:08
*** cdent has joined #openstack-tc12:28
*** dtantsur|brb is now known as dtantsur13:00
*** hongbin has joined #openstack-tc14:08
*** marst has joined #openstack-tc14:22
* smcginnis flips on the light and puts out the sign15:00
* cdent passes a glass of ice cold lemonade smcginnis 15:00
cdentthere’s more here for anyone else around15:01
* johnthetubaguy raises his hand15:01
* cdent lemonades johnthetubaguy 15:04
cdentif there’s nothing else, I’ll (re-)point people at
cdentand ask: how do we make that go?15:05
mugsieI would have concerns about it being something that is rewarded15:08
cdent“it” == cleaning things up?15:08
mugsiethe last thing I want to see is a ton of reviews breaking up long files, just so that a company say the worked on a top 515:09
mugsieit depends on the level of cleaning up - people tend to take what nova / keystone etc do, and just try to apply it blindly to other projects15:10
cdentthat’s why I’m trying to be circumspect about metrics because I think they point to gaming15:10
mugsieyeah, and sources of endless bikesheding15:10
cdentOn the other hand, if we have fewer really long files, I’d be pretty happy.15:11
dhellmanncdent : I'm finally getting around to reading -- good stuff, thanks for sharing that link15:11
cdentdhellmann: ah, good, glad you like it. I think it’s at least a useful perspective, and at best, has some good framework for thinking about stuff15:11
mugsiesure. we have one really long one, and it annoys me. but, to break that up well, takes effort, and planning, and someone who knows the project15:12
dhellmanncdent, mugsie : on the simplifying thing, I wonder if the right approach here is to ask teams to provide a list of changes they have been trying to get to for a while but haven't quite made it, and measure the burndown against that list15:13
dhellmannlike gcb is doing in oslo, for example15:13
smcginnisI think there are a lot of folks that do think "we need to simplify things" without a clear idea of what or how.15:13
dhellmannyes, and we've seen how easily we can end up with a flood of mechanically generated patches15:14
smcginnisBut maybe if we provided a common wiki page or etherpad that various projects could list some efforts they'd like worked on, it could be a good way for folks looking for something to tackle to get directed to something useful.15:14
smcginnisOther than fixing spelling and changing http to https everywhere.15:14
dhellmannor removing utf-8 headers15:15
mugsiedhellmann: ++15:15
mugsieI did like the oslo cleanup stuff15:15
cdentNot to put too fine a point on it, but I think part of the issue here is that projects aren’t concerned about some of this stuff, and it makes the project less open to new people. So relying on the projects to declare where the work should happen might be a non-starter15:15
smcginnisYeah, for some projects, I do think that would be the case.15:16
dhellmannmaybe. otoh, if the projects don't buy in to the idea of doing this, they'll be less likely to review patches with a positive approach15:16
mugsiecdent: sure. but project that have small review teams see a lot of pointless patches that we still have to review, so they get jaded15:16
dhellmannso maybe we don't want to say all projects, but just have some way for projects to indicate interest in signing up15:16
dhellmannmugsie : even some of the larger teams have that reaction15:17
cdentmugsie: yeah, I totally get that it is a mixed bag and there are many conflicting factors15:17
dhellmannso we need a way to channel contributor energy in a direction that each team finds useful15:17
dhellmannlike I suspect the rosmaita and the glance team wouldn't want a lot of code churn for "simplification", unless the contributor was also actively working on some of the other priorities or interested in becoming a core reviewer15:18
smcginnisI was thinking of the glance/glare case.15:18
smcginnisIf part of the motivation for glare is that the glance code base is overly complicated, I wonder if it would be faster migrating to a new service vs actually spending the time to simplify the architecture and code of glance.15:19
johnthetubaguysmcginnis: for me the problem is APIs and our user base15:20
smcginnisjohnthetubaguy: Definitely. So I'm thinking of that effort of migrating users and projects to potentially a new API, and how long that transition would take, compared to just making glance better.15:21
smcginnisGranted, there are other things in glare, but I don't really want to get into that discussion right now. :)15:22
johnthetubaguysmcginnis: yeah, its a different discussion, I know in Nova we landed on infinity (in the sense of some time after most of the current contributors would have stopped working on the project)15:23
cdentIt may be that coming up with a systemized way of doing cleanups is the wrong approach. The real problem is that we don’t have a culture of rigorous maintainability (using generally accepted rules of thumb) nor of refactoring15:23
johnthetubaguyas in infinity is the time needed to migrate15:23
smcginnisjohnthetubaguy: I think that may be accurate.15:23
cdentto reach back to the article dhellmann linked, we have become unbalance by urgency15:23
dhellmanncdent : there is some of that. there's also a real impact on existing contributors when the code base undergoes large changes with some frequency15:25
dhellmannwhether that applies depends on the nature of the simplification, of course15:25
dhellmannand I guess it's not even "existing" contributors if changes cause a lot of rebases for other ongoing work15:26
smcginnisdhellmann: That's an issue I've seen. Reorganzing things usally conflicts with other in-flight work.15:27
dhellmanncdent : I saw that article applying more to the "unmet requirements" discussions than to simplification, but I think you're right that there's some overlap15:27
cdentthat’s perhaps why a cultural shift (so it is more piecemeal) is more important than a set of goals15:27
dhellmannsmcginnis : right15:27
cdentbut at least for me, I’d gladly pay a bunch of rebases and code shift to eventually be able to spend less time disentangling a method that is 100s of lines long and has huge numbers of collaborators15:28
cdentI’m _exhausted_15:28
dhellmannhow many cases like that do you think we have? I honestly couldn't say, myself.15:29
johnthetubaguythe problem I have had is confidence against regression when reviewing the refactoring, I have been on both ends of that really15:29
dhellmannis it a small enough number to make a list?15:29
smcginnisThe difficulty I've seen is I know of a lot of people that want to simplify things, but either don't have the time themselves, don't know where to begin, or can't get past that hurdle of causing conflicts.15:30
johnthetubaguythe problem I had is finding folks with time to review the changes before the conflicted into needing to be thrown away15:31
cdentthat’s an issue for changes in general15:31
cdentand one which needs to be generally resolved15:32
dhellmannsmcginnis : that's another thing we need to start doing: having our more experienced contributors spend more time teaching new folks than they do now (and maybe more time than writing code themselves)15:32
johnthetubaguyI like the idea of having some regular way to highlight these things, making the list is probably the best way to find out if that would work15:32
smcginnisI'm generally against metrics driven development, but maybe as a start we try to use something like radon. There could be a lot of gaming, but I think eventually if those numbers get better, it could result in easier to maintain code.15:32
smcginnisdhellmann: ++15:32
johnthetubaguycdent: true, its a more general problem15:32
smcginnisRadon just being one tool that came up in a quick search.15:32
cdentsmcginnis: yeah, radon is the one I named simply because it is the top of the search results and one I’ve used before15:33
smcginnisMight be worth just adding not voting jobs with that output so those interested can take a look and see if numbers are getting better or worse.15:33
dhellmannsmcginnis : I agree we need to be careful with metrics, that's why I proposed a specific list rather than measurements15:33
cdentI actually don’t have a lot of faith in its results. They are useful to find some stuff, but humans are better.15:33
dhellmannyeah, this feels like the sort of thing where we *know* where the problem points are, or are likely to be15:33
smcginnisI think there probably isn't one good answer to this problem.15:33
mugsieyeah, we ran sonar against designate (and I think octavia did as well for a while) and it did not really add anything useful15:34
smcginnisAs far as a top-5 item, I would like to see a specific list.15:34
smcginnisAs far as ongoing and building this into our development culture, I think we need something like the radon output to give us feedback.15:34
johnthetubaguyhmm, do we want to restrict things in that way? highlighting the issue could help us find a solution15:35
dhellmanndo we have a tool that produces good feedback then? radon is better than sonar?15:35
* smcginnis smells a PTG discussion15:35
dhellmanncan someone give me a link to radon? I'm just finding stuff about ventilating basements.15:36
dhellmannoh, it has a flake8 plugin, so we may not need a new job15:37
smcginnisJust noticed they point to xenon for CI jobs:
cdentthe radon plugin against nova is somewhat slow, but is nicely informative15:42
smcginnisJust ran against Cinder. Think this will take a little while to grep through.15:42
dhellmannok, Radon says this function is too complex
dhellmannit has 1 loop, and 1 conditional15:43
dhellmannunless I'm misreading the output?15:43
smcginnisTwo conditionals. That's way too complex. :D15:44
dhellmannah, 2, yes, I can't count15:44
cdentno, dhellmann, you got an A for that method15:44
cdentmain got a C15:44
dhellmannoh, what is the F in the left column?15:45
dhellmannI thought that was the score15:45
dhellmannok, well that makes me feel a bit better :-)15:45
cdentyeah, it is disorienting15:45
cdentif you use the flake8 plugin, it only shows you poor output15:45
smcginnisThe output is definitely not immediately intuitove.15:45
cdentso can be a bit less alarming15:45
* dhellmann avoids pointing out the irony of a complexity measuring tool having complex output15:46
smcginnisYou can also use -nc to only show a C ranking or worse.15:46
smcginnisHaha, true.15:46
smcginnisSimplicity is complex.15:46
dhellmannso main() got a C. What would you change?15:46
cdentmake it do less, extract some stuff`/15:48
smcginnisMaybe move out the reading of rulesets and tests into separate calls? This is where it would get tricky. What's really an improvement vs making something harder to read for the sake of better number.15:48
smcginnisMaybe just D or worse to start?15:48
dhellmannI guess the stuff after the file reading could be split out, but it's just printing results15:49
cdenthandle_mismatches(), handle_untested(), etc15:49
cdentI know I’m a blind grape in the path of progress, but I tend to think if I can’t see the entire method in my 80x24 vt220 it’s too big15:51
cdent277 “errors” in nova (using 10 as the score)15:53
dhellmannI guess I tend to use whitespace between stanzas as a replacement for splitting up medium length methods into smaller ones when there is no real thematic difference or reusability15:55
cdentI also love vertical whitespace. that ends up meaning either a lot of methods that violate my vt220 or a lot of private methods15:56
* cdent doesn’t really use a vt200, just to be clear15:56
smcginnisI like the mi (maintainability index) but less specific feedback.15:58
dimsis this "we need this, come help us do it" to folks who are not currently engaged/active?16:00
cdentdims: probably not, which is part of why it’s not super workable as a top-5, but it seems a way to get the ball rolling16:01
dimsif they do show up, how do we help them help us? (given our review bandwidth)16:01
smcginnisIdeally it would be good to have the already active folks doing some of the bigger refactoring, but I could see some of it bing "low hanging fruit".16:01
* cdent has to go to api-sig meeting16:02
cdentthanks for thinking about this stuff16:02
*** openstackgerrit has quit IRC16:04
smcginnisradon raw output is a lot of data, but interesting. Could just target the ones there where "Comments: 0"16:08
* cdent is pleased that he has helped give smcginnis a new way to see parts of the world16:09
dimssmcginnis : paste me what you are looking at please? :)16:28
*** jpich has quit IRC16:29
*** dtantsur is now known as dtantsur|afk16:47
*** cdent has quit IRC17:04
smcginnisdims: Sorry for the delay. This is what I was looking at:
dimsah thanks smcginnis17:56
smcginnisThinking the percentage numbers comparing comments to code might be an interesting metric. At least to start identifying areas where maybe there wasn't enough done.17:56
*** openstackgerrit has joined #openstack-tc19:15
openstackgerritBrian Rosmaita proposed openstack/project-team-guide master: Add "How to Preview Release Notes at RC-time"
*** marst has quit IRC23:05
*** hongbin has quit IRC23:23

Generated by 2.15.3 by Marius Gedminas - find it at!