| *** dangtrinhnt has joined #openstack-tc | 00:03 | |
| *** mriedem_away has quit IRC | 00:15 | |
| openstackgerrit | Merged openstack/governance master: New Repo: OpenStack-Helm Docs https://review.openstack.org/611896 | 01:37 |
|---|---|---|
| *** diablo_rojo has quit IRC | 01:56 | |
| *** scas has joined #openstack-tc | 01:57 | |
| *** diablo_rojo has joined #openstack-tc | 03:32 | |
| *** diablo_rojo has quit IRC | 04:21 | |
| *** diablo_rojo_ has joined #openstack-tc | 04:21 | |
| *** diablo_rojo_ has quit IRC | 04:42 | |
| *** diablo_rojo has joined #openstack-tc | 04:50 | |
| *** diablo_rojo has quit IRC | 05:00 | |
| *** jaosorior has quit IRC | 05:32 | |
| *** jaosorior has joined #openstack-tc | 05:32 | |
| *** wxy-xiyuan has quit IRC | 06:16 | |
| *** mnaser has quit IRC | 06:16 | |
| *** wxy-xiyuan has joined #openstack-tc | 06:16 | |
| *** mnaser has joined #openstack-tc | 06:17 | |
| tonyb | FWIW T release name poll is now open. | 06:24 |
| *** dangtrinhnt has quit IRC | 06:43 | |
| *** dangtrinhnt has joined #openstack-tc | 06:48 | |
| *** tonyb has quit IRC | 06:50 | |
| *** ricolin has joined #openstack-tc | 07:51 | |
| *** jpich has joined #openstack-tc | 08:26 | |
| *** e0ne has joined #openstack-tc | 08:41 | |
| * ttx slowly catching up after having chosen the wrong day to take a vacation. Or maybe that was the right day | 08:49 | |
| gmann | office hour time... | 09:04 |
| ttx | TC office hour is started, bring your questions | 09:04 |
| gmann | sent email too. | 09:04 |
| cmurphy | having just run into it, I'm concerned that the unique IP address requirement for the civs poll is a voting obstacle that might hinder some people from voting | 09:10 |
| ttx | yes, it is. We've been dancing around various solutions for that one. | 09:22 |
| gmann | yeah, few of my colleague faced the same issue. | 09:25 |
| gmann | and in poll, it is "M Release naming" | 09:26 |
| ttx | At one point we used surveymonkey to rank options, at another we used LP polls | 09:27 |
| ttx | then CIVS private and CIVS public | 09:28 |
| mnaser | I wonder what we can do to get non tc in here in office hours.. | 09:30 |
| cmurphy | mnaser: hi | 09:31 |
| mnaser | HI cmurphy | 09:31 |
| * mnaser has been seeing what the developer experience is like from EU | 09:32 | |
| cmurphy | it's nice and peaceful | 09:32 |
| smcginnis | Wow, might be my first time making it to this office hour. | 09:32 |
| gmann | mnaser: not sure, i started the email also but does not seems making any difference | 09:33 |
| gmann | ttx: i observed that we can do multiple voting from same link via opening from different IP | 09:34 |
| mnaser | smcginnis: isn’t it quite early.. or late? ;p | 09:34 |
| smcginnis | A bit early. One of those mornings for me. | 09:34 |
| mnaser | gmann: I guess actual topics proposed might make sense for those to come if they’re interested | 09:35 |
| gmann | may be. | 09:35 |
| smcginnis | The multiple voting issue came up before. It is a concern with not doing private polling. | 09:37 |
| cmurphy | I'm more concerned over people who don't vote because it's too hard to use another IP address than over people abusing the system | 09:38 |
| *** saneax has joined #openstack-tc | 09:39 | |
| *** cdent has joined #openstack-tc | 09:42 | |
| lbragstad | is it an issue with another piece of information being associated to voters? | 09:43 |
| * cdent waves | 09:43 | |
| smcginnis | cmurphy: I agree. | 09:44 |
| smcginnis | lbragstad: There's a problem that multiple people from the same IP have to jump through hoops to vote. | 09:44 |
| smcginnis | Or do you mean why we don't have private polling with per-person links? | 09:44 |
| cdent | didn't we had this problem last time and in the end just decided to deal? | 09:45 |
| smcginnis | Yeah | 09:45 |
| cdent | also, smcginnis, where are you? | 09:45 |
| smcginnis | My basement. :) | 09:45 |
| cdent | smh. | 09:45 |
| smcginnis | I suppose at least lbragstad has a very legitimate excuse. | 09:46 |
| lbragstad | i don't think i was around the first time per-person IPs came up | 09:49 |
| cmurphy | lbragstad: it's an issue if you work in an office behind a NAT, then one person in your office votes and no one else can vote without some proxy trickery | 09:50 |
| cmurphy | the alternative is individual ballot links for every foundation member which overloaded the civs service | 09:51 |
| cdent | Is there someway I can vote minus a billion on "Train"? | 09:51 |
| * lbragstad nods | 09:51 | |
| smcginnis | cdent: Depends how many unique IPs you can get access to. | 09:51 |
| cmurphy | lol | 09:51 |
| cdent | \o/ | 09:51 |
| cdent | now I know what to do with all that free time I have | 09:52 |
| ttx | I hear you can use TheCLoud[tm] | 09:52 |
| gmann | :) | 09:53 |
| smcginnis | If you can get ownership of an entire class A subnet and you rank it last choice every time, it could be done. | 09:53 |
| * smcginnis thinks some days "tincup" might be a better name for the next release | 10:05 | |
| smcginnis | https://media1.tenor.com/images/e8aafe4247ef10c5dfe48f4f6cd401d3/tenor.gif?itemid=12607194 | 10:05 |
| cdent | I'm rooting for teakettle | 10:06 |
| cdent | but tincup makes a lot of sense :( | 10:06 |
| smcginnis | Troublesome is also on the list. | 10:07 |
| cdent | Even I thought that was too negative. | 10:07 |
| smcginnis | Whoa | 10:07 |
| cdent | I know, right? | 10:07 |
| * cdent have a fever | 10:08 | |
| smcginnis | :) | 10:08 |
| * lbragstad goes to fire up the liquid energy machine | 10:10 | |
| * smcginnis accepts the fact that he's not going back to sleep and does the same | 10:11 | |
| *** fanzhang has left #openstack-tc | 10:24 | |
| *** e0ne has quit IRC | 10:32 | |
| lbragstad | resistance is futile | 10:32 |
| cdent | I've run out of beans... | 10:33 |
| cdent | Do any tc-members have forum sessions they'd like some assistance, additional input, whatever, on? I feel a bit off kilter for summit. | 10:37 |
| smcginnis | cdent: Maybe later/tomorrow I'll have an onboarding presentation I wouldn't mind some eyes on for flow and things. | 10:39 |
| cdent | smcginnis: shore, happy to help | 10:40 |
| * cdent goes to town for beans | 10:40 | |
| openstackgerrit | Lance Bragstad proposed openstack/project-team-guide master: Add section about collecting feedback to PTL guide https://review.openstack.org/613617 | 10:40 |
| *** cdent has quit IRC | 10:42 | |
| *** e0ne has joined #openstack-tc | 10:57 | |
| *** cdent has joined #openstack-tc | 11:13 | |
| *** dtantsur|afk is now known as dtantsur | 11:50 | |
| *** e0ne has quit IRC | 12:21 | |
| dhellmann | hmm, the candidate name "Tiny Town" seems to violate the rule about being a single word | 12:21 |
| openstackgerrit | Merged openstack/project-team-guide master: Add section about collecting feedback to PTL guide https://review.openstack.org/613617 | 12:34 |
| fungi | we'd need to concatenate it to tinytoons | 12:51 |
| dhellmann | too bad we're not on L. Although LooneyToons is probably out due to copyright. | 12:52 |
| dhellmann | or trademark | 12:52 |
| fungi | we missed out on merrymelodies too | 12:53 |
| smcginnis | Another short cycle and we can just call it Tiny. | 12:53 |
| fungi | maybe the next cycle can be underdog | 12:56 |
| fungi | *somehow* | 12:56 |
| *** cdent has quit IRC | 13:07 | |
| *** e0ne has joined #openstack-tc | 13:08 | |
| ttx | agreed Tiny town would have to be Tinytown to pass | 13:11 |
| TheJulia | hmmm cdent escaped | 13:12 |
| *** mriedem has joined #openstack-tc | 13:13 | |
| *** cdent has joined #openstack-tc | 13:27 | |
| *** dklyle has quit IRC | 13:37 | |
| *** dklyle has joined #openstack-tc | 13:37 | |
| *** dklyle has quit IRC | 14:02 | |
| *** david-lyle has joined #openstack-tc | 14:02 | |
| *** cdent has quit IRC | 14:21 | |
| *** e0ne has quit IRC | 14:33 | |
| *** e0ne has joined #openstack-tc | 14:37 | |
| *** dtantsur is now known as dtantsur|brb | 14:50 | |
| *** evrardjp has joined #openstack-tc | 14:54 | |
| *** jamesmcarthur has joined #openstack-tc | 15:05 | |
| *** evrardjp has quit IRC | 15:06 | |
| *** ianychoi_ is now known as ianychoi | 15:07 | |
| *** cdent has joined #openstack-tc | 15:08 | |
| *** evrardjp has joined #openstack-tc | 15:19 | |
| dhellmann | smcginnis , zaneb , fungi : what's the next step for resolving the python 3.5 and 3.7 question that came up in the last couple of weeks? | 15:24 |
| fungi | i think it's a question of whether we're deciding to continue testing stein on ubuntu xenial? | 15:25 |
| smcginnis | dhellmann: I need to look through and update my patch. | 15:25 |
| *** e0ne has quit IRC | 15:25 | |
| smcginnis | But I think although there were a lot of questions on it, I don't think it needs to change too much. | 15:26 |
| dhellmann | fungi : how do we answer that question? | 15:26 |
| fungi | i had been operating under the assumption that we would drop xenial just like we dropped trusty when we added xenial, and precise when we added trusty | 15:26 |
| smcginnis | One of the concerns was on "moving the goalposts" of getting rid of py3.5 testing, but I don't think that's as big of a deal. It's something we are going to have to get used to moving away from a py2.7 focus. | 15:27 |
| dhellmann | that makes sense to me. tbh, I haven't payed close attention to those changes in the past. | 15:27 |
| dhellmann | smcginnis : I would rather we just document this as a separate thing, to avoid confusion. esp. because as the goal champion I'm not prepared to answer questions about this additional work. | 15:27 |
| fungi | in the past the infra team just declared we were transitioning, so nobody raised the "but somebody think of the children!" arguments. this time since it's up to the tc we're going to get endless debates about it | 15:28 |
| smcginnis | dhellmann: Yeah, I don't even see that as part of the goal. It's more of a general "this is what we need to do" thing, IMO. | 15:28 |
| dhellmann | smcginnis : I like your patch to add the version info to a new document | 15:28 |
| fungi | the primary objection that keeps getting raised is that "the python3-first goal said we wouldn't get rid of python 3.5 testing" | 15:28 |
| dhellmann | yeah, that statement was about limiting scope of the goal work not blocking any other changes | 15:28 |
| smcginnis | dhellmann: Yeah, one way or another, I think whatever we land on should be documented in an easy to reference location. | 15:29 |
| dhellmann | smcginnis : ++ | 15:29 |
| fungi | i keep trying to make that assertion. it was that dropping 3.5 was out of scope for python3-first, not that another goal wouldn't have that as part of its scope | 15:29 |
| dhellmann | fungi : I think if we can get a clear statement written down, a la smcginnis' patch, about what versions are expected and why then we can get the tc to agree | 15:29 |
| smcginnis | In meeting now, but I can look at updating my patch afterwards. | 15:30 |
| dhellmann | I also think adding 3.7 is a separate conversation than dropping 3.5 | 15:30 |
| fungi | yeah, also on a conference call at the moment | 15:30 |
| dhellmann | related, but not dependent | 15:30 |
| dhellmann | ok | 15:30 |
| smcginnis | dhellmann: ++ | 15:30 |
| fungi | i concur, adding 3.7 is independent of dropping 3.5, but got confused by mass changes getting proposed which did both at the same time | 15:30 |
| fungi | so people ended up with the impression the two were related | 15:31 |
| *** e0ne has joined #openstack-tc | 15:35 | |
| *** saneax has quit IRC | 15:52 | |
| zaneb | yeah, the original change just added 3.7, then people on the mailing list said we had to drop 3.5 to add 3.7 (even though that's not true according to the figures we're getting), so the changes all got updated to do that | 15:53 |
| clarkb | zaneb: no the dropping 3.5 is related to dropping xenial | 15:54 |
| clarkb | still something we should do under the existing policy | 15:54 |
| zaneb | clarkb: I'd suggest to you that changes like https://review.openstack.org/#/c/610687/1/.zuul.yaml have nothing to do with dropping xenial, since they don't touch any integration jobs | 15:57 |
| zaneb | dhellmann: imho the best way forward is first to decide what process we want to apply in the future. then retroactively apply that process to Stein and make any one-off adjustments necessary because we are already well into the cycle. then do it | 15:57 |
| clarkb | zaneb: we usually not changed the distro testing in one go. I don't see that as abnormal | 15:57 |
| clarkb | zaneb: it is ok for this to take several steps | 15:58 |
| clarkb | and the last time we did it, that was the case | 15:58 |
| cdent | I acknowledge that I was one of the people who overcomplicated things by asking for some versions to be removed. In part that was the result of misunderstanding the usage numbers, but that was not the entire thing. I simply think we (upstream) should test less. But I recognize that I didn't make a sufficiently compelling case for that, so no worries, but I haven't got much to add to the existing discussion. | 15:59 |
| openstackgerrit | Sean McGinnis proposed openstack/project-team-guide master: Remove setup.py check from pep8 recommendations https://review.openstack.org/614283 | 16:02 |
| *** ricolin has quit IRC | 16:05 | |
| zaneb | cdent: Andreas suggested it in the mailing list thread long before you got involved, so I think you're off the hook this time ;) | 16:06 |
| cdent | this time | 16:11 |
| zaneb | dhellmann: I'm struggling to understand what the patch generated at branch time that you're suggesting in that mailing list thread would look like. Patch to master or stable branch? To change what? | 16:13 |
| cdent | I've put two new things on top of https://etherpad.openstack.org/p/tc-office-hour-conversation-starters . One of them is meta. | 16:16 |
| smcginnis | cdent: I've had the same thoughts re: constellations for awhile now. Good to talk about that. | 16:21 |
| clarkb | cdent: re testing less, I would probably put it as "testing more efficiently" but I agree. I think we do a ton of testing that is redundant and a lot of testing that doesn't provide worthwhile coverage of the software | 16:24 |
| clarkb | the legacy of using integration testing to enforce projects work together | 16:24 |
| smcginnis | Yeah, "more efficient" is probably a better way to phrase it. | 16:25 |
| cdent | clarkb: I agree with all that, but my reasoning has more to do about the distribution of responsibility to corporations | 16:25 |
| *** dtantsur|brb is now known as dtantsur | 16:26 | |
| *** e0ne has quit IRC | 16:30 | |
| dhellmann | zaneb : a patch to the master branch to update the zuul settings to use the new template instead of the old one. we already have a patch that adds the reno page for the new stable branch and that's generated at that point | 16:49 |
| zaneb | dhellmann: I guess that'd save some work for the goal champions | 16:52 |
| dhellmann | zaneb : any part of this that we can work into the regular flow of operation is going to make things easier all around | 16:59 |
| zaneb | yeah. as long as it gets tested and approved like any other patch (the reno one does) then I'm all for it | 17:00 |
| dhellmann | in fact, the fewer patches we have to apply to every repo, the better I think we'll be, so if there's a way to do this by flipping a single switch somewhere I'd be in favor of that | 17:00 |
| dhellmann | I'm personally not opposed to the big-hard-switch approach even if it means repos are broken for a week | 17:00 |
| dhellmann | that feels less risky, ultimately, than having teams fail to land the patches | 17:00 |
| clarkb | dhellmann: ya that was my take on it too. But there are/were some strong objections | 17:05 |
| clarkb | (my opinion largely formed by us letting projects migrate themselves to xenial last time at their own pace and many taking multiple cycles to do so) | 17:05 |
| zaneb | clarkb: I agree that that may be necessary for integration tests, but IMHO it would be completely unnecessary breakage to do that for unit tests | 17:07 |
| clarkb | I agree it will likely break things. But I don't think it is unnecessary. Its like ripping a bandaid off. In many cases that is preferable to the alternative | 17:07 |
| *** jpich has quit IRC | 17:08 | |
| dhellmann | if anything, I would say the reverse | 17:08 |
| clarkb | cdent: https://review.openstack.org/614305 changes like that are the super low hanging fruit of the test less problem | 17:08 |
| dhellmann | unit tests can be fixed with 1 patch in 1 repo. integration tests maybe not. | 17:08 |
| cdent | clarkb++ | 17:08 |
| zaneb | getting the unit tests working again just isn't that hard and can easily be done inside a cycle. there's just no reason to break the world to make it happen on an exact date | 17:09 |
| clarkb | fwiw from where I'm sitting the world has been broken since the PTG | 17:09 |
| clarkb | now is the perfect time for changes like this | 17:09 |
| clarkb | because we are already suffering anyway | 17:10 |
| dhellmann | what's broken today? | 17:10 |
| clarkb | dhellmann: our queue backlogs are regularly going into the ~8 hour range. The integrated gate has an incredibly high reset rate (driven by neutron tests currently I think). Tripleo is using ~53% of all available resources preventing anyone else from moving quickly. | 17:11 |
| clarkb | This is now a more than month long problem | 17:11 |
| dhellmann | ah, ok, yes, I thought you meant hard broken in some way | 17:11 |
| dhellmann | I do agree those problems have been doing on too long. I know the tripleo team is working on the new test architecture that will let them use shorter test jobs and fewer nodes, and I think they've made progress on the tools neededd | 17:12 |
| clarkb | we aren't getting much work done anyway. May as well rip the bandaid off on python3. In part because I think some of the stability issues are related to pytho3n so more eyes on it will help | 17:12 |
| clarkb | dhellmann: yes I think tripleo has responded to the problem more than most | 17:13 |
| clarkb | http://logs.openstack.org/50/610950/2/gate/openstack-tox-py35/ffbf1f3/job-output.txt.gz#_2018-10-30_16_38_34_738981 example of potential python3 related instability that just caused a gate reset | 17:14 |
| clarkb | http://status.openstack.org/elastic-recheck/data/integrated_gate.html has lsit of unknown failures in the integrated gate fwiw | 17:17 |
| cdent | I think much like the gate's queues being overwhelmed and full, people's are as well, making it hard to distinguish what's important | 17:19 |
| cdent | and also not be a bit stressed out by yet more important things coming into the pic | 17:19 |
| cdent | wish we had an easy way to say "pause" | 17:20 |
| clarkb | cdent: yes it feels like we are defaulting to just throwing code at the wall and trying again until things move because that is easier than digging in and fixing things. That digging in is high cost and we've lost most of the individuals that were willing to do it in the past | 17:21 |
| cdent | yes to all that. | 17:21 |
| cdent | and I think it is hard to become one of those individuals of yore in the current environment | 17:22 |
| clarkb | it is also low reward, which presents a lack of motivation | 17:22 |
| cdent | I think plenty of people are probably willing in the abstract (I am) but don't have the cycles given other commitments (something has to come off my list in order for me to anything) | 17:22 |
| cdent | which is why full on major breakage might be a good tool | 17:23 |
| clarkb | I do think that if we are going to tell the story of ongoing maintenance and focus on improvements over raw features (which I've heard thrown around here and there in the last yera or so) we'll need to address this | 17:25 |
| cdent | agree | 17:26 |
| cdent | a lot of the throwing that we do around here is hugely dependent on support from employers and there's a lot of chaos (or at least the feeling thereof) in that realm | 17:27 |
| cdent | I have an actual in person meeting with some management later this week, I'll try to stress the point. | 17:27 |
| cdent | clarkb are there ways to inform the queuing algorithms to downscore any project which causes a reset? | 17:28 |
| cdent | sort of like a 24 hour demerit? | 17:28 |
| clarkb | cdent: not currently. corvus proposal for priority changes http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-October/000575.html is similar and should mitigate some of that too I think | 17:29 |
| clarkb | (it deprioritizes based on the amount of work you've already been able to do, and gate resets are tied into that) | 17:29 |
| cdent | Yeah, I was aware of that change. I was thinking something a bit more drastic and directly tied to "flakiness that needs to be fixed" | 17:30 |
| clarkb | cdent: the mechanism we do have in place for that is a tcp like window that grows and shrinks based on your successes merging code | 17:30 |
| clarkb | cdent: that is queue wide (so integrated gate queue and tripleo queue have their own windows) | 17:31 |
| cdent | that seems a bit too wide | 17:31 |
| clarkb | but we have a window floor size of 20 to prevent us from not getting any work done (though the net effect maybe be the same when things are bad) | 17:31 |
| clarkb | cdent: ya, its mostly there to prevent the boader impact of a gate reset from entirely starving queues | 17:35 |
| clarkb | cdent: it has worked well for that (once upon a time we'd get 80 change deep queues and nothing would move) | 17:35 |
| dhellmann | the trick is figuring out which project has the bug that's causing the reset | 17:46 |
| dhellmann | and then of course if we make it harder to land patches in that project, we make it harder to land the fix, if someone's working on it | 17:46 |
| clarkb | dhellmann: ya thats the big concern with being aggressive on not running tests | 17:47 |
| clarkb | as for identifying resets that is why we have elastic-recheck. It would be excellent if we could get more people looking at it (ssbarnea had volunteered but unsure if that has been run by mriedem yet) | 17:47 |
| dhellmann | maybe a better approach is to make those reset stats more visible -- the web page is good, but depends on someone monitoring it | 17:48 |
| dhellmann | some sort of periodic report to the ML might improve the visibility | 17:48 |
| clarkb | dhellmann: I've been trying to send an email periodically since the PTG | 17:48 |
| *** jamesmcarthur has quit IRC | 17:48 | |
| dhellmann | ah, good | 17:48 |
| dhellmann | I've been away for a bit so must have missed those | 17:48 |
| clarkb | (it isn't on a regular schedule but while things are sad I've been trying to point people at constructive ways to help including the e-r information) | 17:49 |
| dhellmann | clarkb: I have read those emails, so maybe I didn't miss anything after all. | 17:54 |
| dhellmann | tc-members: I meant to get this out Monday so I apologize for the delay: http://lists.openstack.org/pipermail/openstack-dev/2018-October/136146.html | 17:55 |
| *** dtantsur is now known as dtantsur|afk | 17:57 | |
| lbragstad | dhellmann thanks for the update | 18:01 |
| *** e0ne has joined #openstack-tc | 18:10 | |
| *** jamesmcarthur has joined #openstack-tc | 18:19 | |
| *** jamesmcarthur has quit IRC | 18:22 | |
| *** diablo_rojo has joined #openstack-tc | 18:24 | |
| *** e0ne has quit IRC | 18:25 | |
| *** e0ne has joined #openstack-tc | 19:13 | |
| *** weshay is now known as weshay_doctor | 19:15 | |
| *** jamesmcarthur has joined #openstack-tc | 19:15 | |
| dhellmann | tc-members: I am looking for input about topics that you think we should include in the joint leadership meeting agenda. It looks like we're going to have about 30 minutes, so I think we should consider this much more a presentation than a discussion. | 19:34 |
| dhellmann | I've started a list in https://etherpad.openstack.org/p/tc-topics-jlm-stein-berlin | 19:35 |
| fungi | i'll assume the unidentified blue steel color there is cdent | 19:38 |
| cdent | no doubt | 19:38 |
| fungi | if you can expound on what needs fixing in/with ci that would be helpful | 19:38 |
| cdent | fungi: it's hard to say because we have hours-long conversations in here with many different conclusions. the most recent is "we're not fixing bugs that cause resets frequently enough" | 19:39 |
| smcginnis | I agree it's an issue, but is it a board level visibility issue? | 19:40 |
| fungi | ahh, so improving efficiency in openstack's use of ci resources? | 19:40 |
| cdent | better? | 19:40 |
| clarkb | smcginnis: if board is pushing devs to do feature work and not dedicate time to sutainability then yes? | 19:41 |
| cdent | smcginnis: my thinking was that as a very quick (30 minutes is no time) report, it is important that we (very quickly) hit on issues that are slowing us down | 19:41 |
| fungi | got it. so concerns about inability to prioritize the importance of identifying and fixing significant bugs which are impeding our ability to test openstack more effectively | 19:41 |
| cdent | fungi: yah | 19:41 |
| smcginnis | clarkb: I have yet to see the board pushing devs to do much of anything. | 19:41 |
| smcginnis | cdent: That makes sense. | 19:41 |
| cdent | smcginnis: I agree with your pessimism about the board pushing devs, but I feel sort of like "we need to tell the news" | 19:42 |
| cdent | I'm not sure why | 19:42 |
| smcginnis | Yeah, as long as it is a quick update to let them know and not presented as something that we need BoD action to do something about it. | 19:44 |
| clarkb | smcginnis: ya I'm not necessarily saying it will directly chagne things, but if we can't talk to business representatives on our board about these things who do we talk to? | 19:47 |
| *** saneax has joined #openstack-tc | 19:52 | |
| * cdent waves | 19:56 | |
| *** cdent has quit IRC | 19:56 | |
| TheJulia | clarkb: I suspect that the board is disconnected largely from the devs. The board is responsible for reporting back to their various businesses, and ultimately it is a pure money business decision that it has to be able to be made at | 19:56 |
| TheJulia | So if we want to focus on sustainability we need to approach it from both directions at the same time and help people understand the actual cost in time. If we have "time in queue" results, that would be awesome because there is no way every scenario can be adequately tested locally by a developer using any automated test suite. Now if we had a good way to express and pipeline the jobs so we're just editing config | 19:58 |
| TheJulia | files and or something between runs, maybe that is different. | 19:58 |
| clarkb | I dont think we want every developer to test everything. But we do want some sense of ownership for "we know the software doesnt work properly, this effects our ability to merge code and end users, we should fix it" | 20:01 |
| dhellmann | given the brief nature of this presentation, I don't think we're going to have time to go into the level of detail needed to explain that particular issue. Let's focus on success stories to start out. | 20:01 |
| fungi | yeah, alan cautioned us to stick to positives as much as possible | 20:01 |
| smcginnis | Maybe if we have a small "These are the things we are concerned about / working on, it would be a good bullet item for the list. | 20:02 |
| fungi | give the board members ammunition to relate to their respective organizations about how great openstack is, and how we're chugging right along | 20:02 |
| fungi | can we spin them as things we made progress on solving? | 20:02 |
| fungi | even if they're not fully solved yet | 20:02 |
| dhellmann | concrete discussions of WIP items may be ok, but I'll bet we can fill 30 minutes without them, too | 20:03 |
| clarkb | basically it seems there is a void in maintaining the software. same reason python3 is so contentious I think | 20:05 |
| zaneb | I don't understand what we'd be trying to achieve by dropping the CI stuff on the board's plate. If we don't know how to fix it then they certainly don't | 20:11 |
| zaneb | smcginnis++ | 20:12 |
| TheJulia | zaneb: ++, I think the first reaction would be "what do you want us to do with this?!?" Followed shortly by "Why is this our problem?!?" | 20:14 |
| zaneb | TheJulia: followed by (internally) "OpenStack is in chaos, let's back another horse" | 20:15 |
| TheJulia | ++ | 20:15 |
| TheJulia | From my point of view, it is not. But I say that with a particular context, so that context or point of view would need to be conveyed, and then there is still the need to get people to buy in to the same vision to have the same context | 20:17 |
| zaneb | not that we should hide stuff from the board or anything, but this seems like exactly the kind of thing Alan has recommended we not bring to the BoD, if I'm interpreting what I heard (second-hand) correctly | 20:17 |
| smcginnis | zaneb: That's last part is my concern, and I think the thing Alan was warning us against. | 20:17 |
| smcginnis | Hah, jinx. | 20:17 |
| TheJulia | positive outcome of team checkins were improved communication | 20:17 |
| clarkb | if not the board, is there a suggestion for an appropriate venue? or do I keep sending emails to the list in the hopes that peoplr will take it seriously? | 20:20 |
| dhellmann | did we identify any specific issues and then fix them as a result of the health checks? we talked about a few items in denver... | 20:20 |
| * dhellmann has to run to the dry cleaners | 20:20 | |
| *** saneax has quit IRC | 20:24 | |
| *** weshay_doctor is now known as weshay | 20:51 | |
| TheJulia | dhellmann: I felt like we spotted a number of small administrative items that were quick to fix or that allowed us the chance to express/set context. I feel like a common ask was "make people come work on my project" and while we can't do that, we can help encourage different ways of raising visibility. (Of course, that being done by projects requires sufficient spoons to be available...) | 20:59 |
| fungi | clarkb: ideally, bringing such issues to the tc should be sufficient. we're in a position to be able to tell $team "your only task this cycle is to fix $x before you're no longer a part of openstack" and ensure that one of those two outcomes is reached | 21:00 |
| fungi | also opendev may choose to throttle specific zuul tenants in the future to maintain sanity so that openstack (or whoever) can't starve all resources for everyone else | 21:01 |
| fungi | which provides the tc and all openstack projects a bit of an incentive to act as more polite consumers of those donated resources | 21:01 |
| clarkb | fungi: fwiw I think some of the problem is that team specific mindset. We need people to think about "openstack" and not "tripleo" or "neutron" | 21:17 |
| clarkb | yes the neutron team is well positioned to fix the neutron functional tests, but the rest of the iaas integrated gate openstack system relies on neutron too | 21:17 |
| *** e0ne has quit IRC | 21:18 | |
| smcginnis | Well... | 21:21 |
| smcginnis | I feel like I'm being negative, but I would bet if you polled the community, most contributors to other projects don't really care about tripleo. | 21:21 |
| clarkb | smcginnis: sure, but the TC (our elected body) has asserted they are one of the rest of us | 21:22 |
| clarkb | smcginnis: and that gives them access to the large amount of resources they are using. It is in openstack's best interest to make tripleo succeed as long as that holds true | 21:22 |
| *** mriedem has quit IRC | 21:30 | |
| *** jamesmcarthur has quit IRC | 21:46 | |
| *** david-lyle has quit IRC | 22:08 | |
| *** dklyle has joined #openstack-tc | 22:28 | |
| *** e0ne has joined #openstack-tc | 22:49 | |
| *** fanzhang has joined #openstack-tc | 22:54 | |
| *** tonyb has joined #openstack-tc | 23:03 | |
| TheJulia | smcginnis: I think the fair follow-on question would be one to help classify why, if that is indeed the case. TripleO is part of OpenStack, but it is also an opinionated deployment project that has had to move in particular directions because of $reasons. Maintenance of those $reasons also creates friction... | 23:08 |
| TheJulia | a resistance to change... a desire to keep the same. | 23:09 |
| *** e0ne has quit IRC | 23:13 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
