| *** dhellmann has joined #openstack-tc | 00:07 | |
| *** dangtrinhnt_x has joined #openstack-tc | 01:12 | |
| *** dangtrinhnt_x has quit IRC | 01:46 | |
| *** mriedem has quit IRC | 01:50 | |
| *** diablo_rojo has quit IRC | 01:53 | |
| *** ricolin has joined #openstack-tc | 02:20 | |
| *** fungi has quit IRC | 03:06 | |
| *** fungi has joined #openstack-tc | 03:09 | |
| *** fungi has quit IRC | 03:10 | |
| *** mrhillsman has joined #openstack-tc | 03:19 | |
| *** fungi has joined #openstack-tc | 03:40 | |
| *** fungi has quit IRC | 03:41 | |
| *** fungi has joined #openstack-tc | 03:45 | |
| *** diablo_rojo has joined #openstack-tc | 06:20 | |
| *** chenyb4 has joined #openstack-tc | 07:10 | |
| *** alexchadin has joined #openstack-tc | 07:39 | |
| *** diablo_rojo has quit IRC | 08:08 | |
| *** shrasool has joined #openstack-tc | 08:30 | |
| *** shrasool has quit IRC | 09:11 | |
| *** jpich has joined #openstack-tc | 09:14 | |
| *** e0ne has joined #openstack-tc | 09:50 | |
| *** dtantsur|afk is now known as dtantsur | 09:55 | |
| *** chenyb4 has quit IRC | 11:00 | |
| evrardjp | o/ | 12:27 |
|---|---|---|
| *** dtantsur is now known as dtantsur|brb | 12:32 | |
| *** weshay is now known as weshay_ruck | 12:59 | |
| jroll | choo choo! | 13:01 |
| *** e0ne has quit IRC | 13:03 | |
| evrardjp | jroll: :) | 13:09 |
| evrardjp | it's official! | 13:09 |
| evrardjp | almost | 13:09 |
| evrardjp | we're gonna eat trains for x years more (counting extended maintenance) | 13:09 |
| dhellmann | tc-members: I think all of the slides for our presentation monday are done. feedback welcome: https://docs.google.com/presentation/d/1wcG7InY2A5y67dt5lC14CI1gQHGZ3db8-yshOu-STk8/edit#slide=id.g46a6072f4a_4_229 | 13:24 |
| gmann | dhellmann: on slide#8, i see kolla-ansible is highest commit, is it considered in kolla? | 13:32 |
| gmann | dhellmann: on slide#9 should we include tempest plugins release also ? | 13:36 |
| *** e0ne has joined #openstack-tc | 13:37 | |
| dims | dhellmann : nice work! slides look great | 13:39 |
| dhellmann | dims : zaneb, TheJulia, and smcginnis did the work on their sections | 13:39 |
| dhellmann | gmann : good questions. I think ttx and smcginnis worked together on those slides | 13:40 |
| dims | zaneb, TheJulia, smcginnis : awesome! | 13:40 |
| ttx | gmann: I used the Kolla " | 13:41 |
| ttx | group" in stackalytics | 13:41 |
| ttx | so it should | 13:42 |
| ttx | The others spread their work across a /lot/ of repos | 13:42 |
| TheJulia | we have many many many repos | 13:43 |
| ttx | dhellmann: slide 10 is obviously incomplete. Not sure if smcginnis planned to fill it | 13:44 |
| dhellmann | hmm, yeah | 13:44 |
| gmann | ttx: yeah, got it. thanks | 13:45 |
| gmann | dhellmann zaneb, TheJulia, smcginnis, ttx nice work. good slides and stats. | 13:48 |
| TheJulia | I'm tempted to write a script that goes through all the git histories and does the math, excludes procedural/translation patches and calculates the numbers for the slide, I did mine with the whole data so naturally a bit watered down | 13:50 |
| evrardjp | TheJulia: I kinda like that, I feel like raw data should go into a dashboard. Those dashboards can be used by anyone later. I think this can be extended to show hotspots of risks, etc. | 13:52 |
| evrardjp | but I am getting ahead there. | 13:53 |
| evrardjp | anyway, nice slides! | 13:53 |
| dhellmann | TheJulia : there's some stuff in goal-tools that may help with that. I used it for the presentation in Vancouver, and then imported CSV data into google docs to make charts | 14:01 |
| dhellmann | it's all very hacky, so don't judge | 14:01 |
| *** jpich has quit IRC | 14:02 | |
| *** irclogbot_3 has quit IRC | 14:02 | |
| *** tdasilva has quit IRC | 14:02 | |
| *** fanzhang has quit IRC | 14:02 | |
| *** jaosorior has quit IRC | 14:02 | |
| *** tonyb has quit IRC | 14:02 | |
| *** scas has quit IRC | 14:02 | |
| *** eandersson has quit IRC | 14:02 | |
| TheJulia | never :) | 14:02 |
| *** fanzhang has joined #openstack-tc | 14:03 | |
| TheJulia | evrardjp: I kind of like that idea... but it is also all very situational, the issue I kind of felt with the existing data was the only way to reveal the 50-60 revision patches would be to evaluate each item per repo | 14:04 |
| *** jpich has joined #openstack-tc | 14:04 | |
| *** tonyb has joined #openstack-tc | 14:07 | |
| *** jaosorior has joined #openstack-tc | 14:08 | |
| evrardjp | TheJulia: I don't think there is 'one solution fits all' for this kind of things, but at least if we could share all those hacks into one location, it would prevent people from rewriting their own | 14:13 |
| *** mriedem has joined #openstack-tc | 14:13 | |
| evrardjp | I can already see 4 ppl having their own tooling for getting stats, pretty sure we can work on that all together | 14:14 |
| dhellmann | evrardjp : yeah, that was part of the point of starting to dump a bunch of code into the goal-tools repo | 14:17 |
| evrardjp | cool | 14:17 |
| *** alexchadin has quit IRC | 14:39 | |
| lbragstad | dhellmann those slides look nice | 14:44 |
| dhellmann | lbragstad : thanks! | 14:46 |
| evrardjp | office hours time? | 15:00 |
| zaneb | o/ | 15:00 |
| fungi | looks that way | 15:00 |
| evrardjp | gmann: are you there for the email? :D | 15:00 |
| ttx | ohai | 15:01 |
| gmann | done | 15:01 |
| gmann | o/ | 15:01 |
| * ttx is packing up | 15:01 | |
| fungi | yeah, same | 15:01 |
| evrardjp | gmann: thanks! | 15:01 |
| evrardjp | ttx: already? | 15:01 |
| ttx | evrardjp: I'll be in Berlin starting Friday | 15:02 |
| *** dtantsur|brb is now known as dtantsur | 15:02 | |
| evrardjp | ttx: oh that sounds fair then :p | 15:02 |
| * lbragstad pops in for office hours | 15:04 | |
| dhellmann | o/ | 15:05 |
| *** tdasilva has joined #openstack-tc | 15:11 | |
| dhellmann | TheJulia : do you want to +1 this patch to add tenks? https://review.openstack.org/#/c/600411/1 | 15:11 |
| TheJulia | done | 15:13 |
| dhellmann | tc-members: we could use another review on https://review.openstack.org/616189 too | 15:13 |
| dhellmann | TheJulia : thanks | 15:13 |
| dhellmann | tc-members: it looks like we're close to ready with zaneb's technical vision proposal; it would be good to have that lined up for approval for next week's discussion: https://review.openstack.org/#/c/592205/ | 15:15 |
| ttx | dhellmann: added my review on the 616189 | 15:16 |
| dhellmann | ttx: thanks | 15:17 |
| openstackgerrit | Merged openstack/governance master: Add tenks under Ironic governance https://review.openstack.org/600411 | 15:22 |
| openstackgerrit | Merged openstack/governance master: update home page for openstackclient https://review.openstack.org/616189 | 15:23 |
| zaneb | tc-members: we need to discuss what changes we want to make to https://review.openstack.org/#/c/613145/ | 15:25 |
| dhellmann | which comments do you want to start with? | 15:29 |
| zaneb | dhellmann: so you're saying we should test the exact versions that LTS distros are going to ship, and not worry about newer versions... | 15:30 |
| dhellmann | we should focus on those; I consider anything else a bonus | 15:31 |
| zaneb | cdent is saying we should only test newer versions... | 15:31 |
| dhellmann | yeah, I think that's severely misguided | 15:31 |
| dhellmann | and would be a disservice to our users | 15:31 |
| zaneb | me too fwiw | 15:31 |
| dhellmann | I don't mind including those, but I definitely don't think we should limit ourselves to those | 15:31 |
| dhellmann | and I don't place a high priority on it | 15:31 |
| zaneb | but distro folks like coreycb and zigo want both current and newer versions | 15:31 |
| zaneb | oh, and folks on the ML wanted to avoid testing too many versions at once | 15:32 |
| dhellmann | I'm ok with that. My position isn't a strong no. It's just about where I place the emphasis. | 15:32 |
| dhellmann | and if someone wants us to include a version, they should be prepared to help set up the images needed | 15:32 |
| zaneb | +1 | 15:33 |
| dhellmann | the concern about testing too many versions is based on a lack of understanding of where our CI resources are actually being spent | 15:33 |
| dhellmann | unit test jobs take a tiny amount of resources compared to some of our much longer running jobs | 15:34 |
| dhellmann | so it's something to be aware of, but it's not a reason to aggressively drop jobs | 15:34 |
| ttx | On the Python version testing question I'll admit that I had trouble making sense of the overlapping proposals and which one(s) should actually be reviewed | 15:34 |
| dhellmann | yeah, we have 3-4 patches changing different aspects of things and I think we want to either merge those or get them into a series so the progression is clear | 15:35 |
| fungi | i feel like as long as we're not also stuck catering to outdated python versions for prior distro lts releases (what is the benefit to keeping stein compatible with the python3.5 shipped on ubuntu 16.04 lts, especially when we still test python2.7 anyway?), it's fine to test the current ubuntu lts and some future interpreter as well | 15:35 |
| zaneb | so I guess the main question is if we want to stick with min-max testing (fewer CI resources; slightly higher risk) or also unit test versions from specific distros that fall in the middle of the range (more CI, but slightly lower risk) | 15:35 |
| gmann | +1, unit test jobs does not add much time on overall time/resource | 15:35 |
| ttx | is 613145 our best shot as a consensus ? | 15:35 |
| dhellmann | fungi : it's not yet clear to me which version of python 3 RHEL 8 will have, so I don't want us to drop 3.5, yet | 15:35 |
| fungi | dhellmann: it's not clear there will be a future ibm rhel | 15:36 |
| fungi | (at least not to me at any rate) | 15:36 |
| dhellmann | if I could get anyone to give me a version number I would be more definitive about dropping, so for now it's just conservative stance | 15:36 |
| dhellmann | I don't know if the dates for RHEL 8 release are public, but I would personally expect that to happen before the acquisition goes through | 15:36 |
| dhellmann | and I haven't heard anything internally that makes me believe RHEL will be going anywhere | 15:36 |
| zaneb | fungi: nobody knows the future, but IBM have announced that they intend to run RH as a standalone unit. it's very unlikely that they'd discontinue RHEL | 15:37 |
| fungi | well, at any rate, i would not be especially happy if we declare that we're keeping stable/stein compatible with ubunt 16.04 lts because it means that much longer before we'll eventually be able to stop worrying about that particular platform | 15:37 |
| dhellmann | can we run 3.5 on bionic? | 15:37 |
| zaneb | dhellmann: I believe not | 15:38 |
| dhellmann | or 18.04 or whatever the right designation is | 15:38 |
| dhellmann | ok | 15:38 |
| fungi | it wouldn't be a python version that users are deploying | 15:38 |
| zaneb | bionic has 3.6 & 3.7 IIUC | 15:38 |
| zaneb | fungi: for unit tests that's less crucial | 15:38 |
| fungi | we could build python from source for whatever distro we want in that case | 15:39 |
| dhellmann | fwiw, I am perfectly OK with us saying that when we reach this stage for future transitions, we would expect someone from RH to set up a CentOS image for running those tests | 15:39 |
| dhellmann | it's a bit short notice to do that now, so I'm hoping we can have a more gradual transition | 15:39 |
| dhellmann | I will see what I can learn about python versions in RHEL 8 | 15:39 |
| fungi | i'm more concerned that we won't be able to stop relying on ubuntu-xenial images once we cease testing stable/rocky | 15:39 |
| fungi | because we'll be stuck testing stable/stein on it too | 15:40 |
| dhellmann | sure, I understand | 15:40 |
| dhellmann | I will try to determine if it's safe to drop them for stein now | 15:40 |
| dhellmann | or at least before the release | 15:40 |
| fungi | i'm more than a little miffed that we're catering to a closed development process and making wild guesses as to what python version their open-core release model is going to suddenly pop out with no warning | 15:41 |
| fungi | if red hat can start letting us (the public) see their actual package choices for the next release it would make sense to track and plan to support them | 15:42 |
| dhellmann | hmm. I don't like it either. I'm not sure I would call it "open core" | 15:42 |
| fungi | er, well, not openly-developed at any rate | 15:42 |
| dhellmann | I think "not publicly announced" is reasonable. They seem particularly concerned about making public announcements for some reason. | 15:43 |
| fungi | not making a public announcement and not letting people see what you're working on (and potentially participate in it) are different things altogether | 15:43 |
| dhellmann | true | 15:44 |
| evrardjp | I think we are losing track of conversation there | 15:44 |
| dhellmann | ok, I have confirmed that it is safe to drop 3.5 support. | 15:44 |
| fungi | evrardjp: not really. ubuntu lets us know what python versions they're considering. red hat doesn't. i'm fine planning ahead on not-entirely-certain ubuntu python3 plans but not so much mums-the-word rhel python3 plans | 15:45 |
| evrardjp | I also believe that _even if our employers (except for a few select ones) should adapt to the produced community codes, not the other way around_ like it's done for other software | 15:45 |
| evrardjp | even if these are our employers we are talking about, the distros should adapt* | 15:45 |
| evrardjp | or should I say vendors | 15:46 |
| evrardjp | fungi: but does that matter? | 15:46 |
| dhellmann | zaneb : so I think that leaves us with saying 3.6 for sure, and 3.7 as a future version? | 15:46 |
| fungi | dhellmann: thanks for confirming. that makes this somewhat easier | 15:46 |
| dhellmann | I agree this is frustrating. Frankly it's frustrating for a lot of us internally too. | 15:47 |
| dhellmann | I would support wording to the effect of "python versions known to be available in the next LTS" or whatever and then if RH won't say then we have explained why we're not going to worry about it. | 15:47 |
| fungi | i can only begin to imagine how frustrating it is for you :/ | 15:47 |
| fungi | and yes, that seems like a reasonable statement | 15:48 |
| dhellmann | let's get the basics settled and we can add that as a follow-up | 15:48 |
| fungi | we can't make plans to support a distro release if the distro won't give us some inkling of what target we need to try hitting | 15:48 |
| dhellmann | then I can point my management team at the patch | 15:48 |
| evrardjp | yay | 15:49 |
| dhellmann | that won't be a fun thread :-/ | 15:49 |
| evrardjp | I guess... | 15:49 |
| evrardjp | good luck in advance :p | 15:50 |
| fungi | i mean, it's not just about python versions | 15:50 |
| dhellmann | of course | 15:50 |
| fungi | when nova needs to decide what versions of libvirt to drop support for, same problem | 15:50 |
| dhellmann | I'd be happy with an idea of a base version number for those things | 15:50 |
| evrardjp | yeah but nova goes for a review, ask for companies to step in, and is more a community discussion of 'how far can we go together' | 15:51 |
| evrardjp | dhellmann: could you clarify what you mean there? | 15:52 |
| evrardjp | I have the impression we are talking about the same thing, but with different vocabulary | 15:52 |
| dhellmann | cdent, jroll: could one of you add me to the cross-project-spec-liaisons group, please: https://review.openstack.org/#/admin/groups/1372,members | 15:52 |
| dhellmann | evrardjp : by "base version" I mean a guess at a minimum. So I don't know what version of python will be in rhel 8, but I know it will be higher than 3.5 (so at least 3.6) | 15:53 |
| dhellmann | basically give me the >= version for the dependency | 15:53 |
| dhellmann | usually that's enough | 15:53 |
| jroll | dhellmann: I'm not able to add people there | 15:53 |
| dhellmann | hmm, I guess it's not self-editing | 15:53 |
| evrardjp | that was my understanding. but you plan for the future, not the present | 15:54 |
| dhellmann | jroll : thanks, I'll move that discussion to -infra | 15:54 |
| jroll | :) | 15:54 |
| fungi | that group is managed by cross-project-spec-liaisons-chair | 15:55 |
| fungi | which seems to have dhellmann in it | 15:55 |
| fungi | so he should be able to alter it | 15:55 |
| fungi | https://review.openstack.org/#/admin/groups/1371,members | 15:55 |
| dhellmann | oh, frickler just added me to that group | 15:55 |
| dhellmann | see #openstack-infra for details | 15:56 |
| fungi | cool, you should be all set then | 15:56 |
| dhellmann | zaneb : did you get enough of an answer from that discussion? | 15:59 |
| zaneb | dhellmann: I think so... let's make the change we discussed to test every version that appears in a supported distro + the newest version we can find if that's different | 16:00 |
| dhellmann | the newest version available in a system package somewhere? | 16:01 |
| dhellmann | system/distro whatever | 16:01 |
| dhellmann | I don't want us to write a policy that implies we're committing to building our own | 16:01 |
| zaneb | yes | 16:01 |
| zaneb | "the latest released version that is available in any distribution we can feasibly use for testing" | 16:02 |
| dhellmann | wfm | 16:03 |
| zaneb | plenty of outs there if we need them ;) | 16:03 |
| dhellmann | projects must support the other versions, and may support the latest version, if the image is available | 16:03 |
| dhellmann | gmann : is the qa team prepared to coordinate the image update work? ("coordinate" not always "do") | 16:04 |
| dhellmann | ideally it would be done by distro staff working with/on the qa team | 16:05 |
| gmann | dhellmann: i doubt. having less people in OpenStack QA having image update experience/knowledge | 16:05 |
| dhellmann | yeah | 16:05 |
| dhellmann | that will be the next challenge | 16:06 |
| gmann | if i am not wrong, is it infra doing till now ? | 16:07 |
| dhellmann | infra has, yes. I'm sure they would help someone else learn to do it. | 16:07 |
| gmann | agree but main issue in QA is very few resources and their bandwidth. | 16:09 |
| dhellmann | sure, maybe I wasn't clear in what I was asking | 16:09 |
| dhellmann | if there was a document to explain how to do it, and there was someone willing to do the work, would the QA team *coordinate* that work by helping to work out the schedule when the change should happen, helping to communicate the change to the community, etc. | 16:10 |
| fungi | odds are we won't have problems finding volunteers to get images building for ubuntu 20.04 lts and centos-next | 16:10 |
| dhellmann | I certainly hope not | 16:11 |
| fungi | most of the coordination we're going to need is confirming that we have those images in advance of when openstack will need them, and keeping tabs on jobs switching from old to new images | 16:11 |
| dhellmann | I think it would be good to have a team responsible for the activity, rather than treating it as a special one-off thing every time | 16:11 |
| fungi | sure | 16:11 |
| dhellmann | right | 16:11 |
| fungi | just saying it doesn't have to be qa team members doing the work to make those images available | 16:12 |
| dhellmann | that feels like a fit in terms of mission for the qa team, so if the promise is that no work is expected without volunteers to build the images, I'm hoping gmann will say yes to the coordination part | 16:12 |
| dhellmann | right, I think we're saying the same thing | 16:12 |
| dhellmann | I think the folks doing the image work *become* qa team members for the duration | 16:12 |
| fungi | a fine way to look at it | 16:13 |
| dhellmann | even if that's their only contribution, they would do the work within that team | 16:13 |
| persia | Is there a structural reason for it not to be "the QA team", or just something about the current size of the QA team? My thought is that if the QA team is willing to accept more folk to also do that, it might make sense to have one larger team rather than two small ones. | 16:13 |
| dhellmann | persia : it's a resource issue for the current members | 16:13 |
| dhellmann | that's why I'm trying to position it as just a coordination task | 16:13 |
| persia | dhellmann: Then I think I'm arguing with you, that new folk should become QA members to build images. | 16:13 |
| fungi | mostly trying to assuage gmann's concerns of "less people in OpenStack QA having image update experience/knowledge" | 16:14 |
| dhellmann | persia : yeah, that's what I'm saying | 16:14 |
| persia | (or maybe "arguing alongside .." is clearer in writing) | 16:14 |
| dhellmann | they just might not stick around and do other work, which is fine | 16:14 |
| dhellmann | and the existing qa members who have no vested interest in this task aren't expected to pick up the slack if volunteers from the distros don't show up | 16:14 |
| dhellmann | yes, I think we agree :-) | 16:14 |
| fungi | those images are used system-wide. opendev will want to be able to run jobs on them, as will zuul, starlingx too, and airship, maybe eventually even kata | 16:15 |
| dhellmann | fungi : I agree that's a concern. We're going to have to do some training, which means we need to assemble the volunteers to receive (and give) it, which means we need to start making noise about this policy change ASAP | 16:15 |
| fungi | so it's more about collaborating to make sure someone has done the work to make them available | 16:15 |
| persia | fungi: Do you feel there is a need for the images to be provided by the (semi-) external CI vendor, rather than describe those other projects as using components from OpenStack and maybe contributing back? | 16:15 |
| dhellmann | ok, maybe I misunderstood what clarkb had said about this in the past, which I thought was that the infra/opendev team was no longer going to do the work | 16:16 |
| persia | I also remember reading something like that (which may have no relation to any text in archives) | 16:16 |
| fungi | dhellmann: the infra/opendev team is no longer going to force openstack to stick to its testing policies | 16:16 |
| dhellmann | ah | 16:16 |
| fungi | that's the biggest change | 16:17 |
| dhellmann | I interpreted that as also meaning creating the images, but I can see how it wouldn't have to include that change, too | 16:17 |
| fungi | in the past _we_ drove the changing of jobs over from running on older to newer images, pre-testing to make sure they wouldn't break openstack projects, et cetera | 16:17 |
| *** dklyle has quit IRC | 16:17 | |
| persia | The side effect of this is that in the event that the opendev policies diverge from openstack, someone in openstack needs to pick up the slack | 16:17 |
| fungi | s/_we_/infra/ | 16:17 |
| dhellmann | yeah, I'm fine with us just doing a hard change of platform at the start of each cycle, and fixing the fallout | 16:18 |
| dhellmann | someone else might want a more nuanced plan, though :-) | 16:18 |
| dhellmann | I think gmann did say the QA team would deal with that for the devstack jobs | 16:18 |
| fungi | so we would of course want the qa team to collaborate with the opendev infra team and distro volunteers to make sure images it wants to run jobs on are made available in the system, but those popular enterprise distro images are going to be valuable beyond openstack so i think it's fair for openstack not to bear all of the burden on making those images viable | 16:19 |
| dhellmann | that seems completely reasonable | 16:20 |
| dhellmann | I'm not sure where we write down those expectations | 16:20 |
| fungi | we had people really excited to make ubuntu-bionic images usable well before bionic even officially released | 16:20 |
| openstackgerrit | Zane Bitter proposed openstack/governance master: Resolution on keeping up with Python 3 releases https://review.openstack.org/613145 | 16:21 |
| zaneb | dhellmann: let's try that ^ | 16:21 |
| fungi | dhellmann: worst case it's up to the distros who want us to test on them to work with the opendev infra team to make sure they're available in a reasonable amount of time, else openstack can certainly choose to stop testing on those particular platforms | 16:21 |
| fungi | it's how we've managed the images for fedora, opensuse, gentoo and so on | 16:22 |
| dhellmann | fungi : right, that's exactly the dynamic I'm trying to get us to set up | 16:22 |
| fungi | volunteers invested in those distros worked to make sure the images were buildable and could run jobs | 16:22 |
| fungi | debian too | 16:23 |
| *** dklyle has joined #openstack-tc | 16:23 | |
| zaneb | fungi: ++ | 16:23 |
| fungi | even the centos images to a great extent | 16:23 |
| fungi | ubuntu has sort of gotten a free ride, but if push comes to shove i expect we would look to them to help us make those happen too | 16:23 |
| fungi | since the bulk of the opendev services run on ubuntu, the opendev infra team has had a vested interest in being able to run its own ci jobs on that particular platform anyway | 16:25 |
| gmann | sorry got disconnected. reading ... | 16:25 |
| dhellmann | zaneb : 2 questions about wording clarity, but otherwise I think that looks pretty good | 16:26 |
| dhellmann | I have to step out for a bit, so I'll catch up and read it more closely when I return | 16:26 |
| gmann | dhellmann: fungi got it now. I am ok with QA team to coordinate image work/availability between infra/opendev/distro -> openstack community. | 16:27 |
| gmann | and it mostly fit for devstack scope. | 16:28 |
| fungi | awesome, thanks gmann! | 16:28 |
| gmann | if we have some doc/guide for that i can put that link on QA doc side. | 16:29 |
| fungi | since it's something that's tended to only happen once every couple of years and the circumstances in openstack change more rapidly than that, we've done it different ways every time | 16:31 |
| clarkb | fungi: dhellmann: right I think the issue is that the last two times infra did this for openstack there was lots of complaining. We are happy to provide the platform but the actual transition is really openstack's thing and if openstack doesn't like how we've done it in the past I'd prefer openstack figure it out itself | 16:31 |
| fungi | i'm not sure detailed documentation of the process is a super effective use of anyone's time | 16:32 |
| fungi | it would have to be updated more frequently than it was used, and would inevitably fall out of date and have to be figured out again when the time came anyway | 16:32 |
| clarkb | the upside to when infra was doing it is I felt like we spent far less time on this in the past :) | 16:35 |
| smcginnis | ttx: I thought you added that Rocky highlight slide. I seem to remember talking very briefly about it and wondering if we needed to recap the cycle highlight compilation that Anne had done. | 16:41 |
| smcginnis | I think we can probably drop the slide unless there are key points to call out with those. | 16:42 |
| *** fanzhang has quit IRC | 16:46 | |
| *** e0ne has quit IRC | 16:48 | |
| ttx | smcginnis: I'm fine with dropping it. But then the retrospective feels a bit short, for two people... If you feel comfortable presenting the contributors data I compiled, I'm fine not presenting | 16:48 |
| *** fanzhang has joined #openstack-tc | 16:49 | |
| ttx | The key on those graphs is to convey that one developer can make a significant impact. Because with large numbers there is always the temptation to think that there is no point is contributing since there are so many contributors already and one more would not make a difference | 16:52 |
| ttx | So Doug presented data to reinforce that point last time, and the slides for this meeting are a way to make that point again | 16:53 |
| ttx | from a different angle | 16:53 |
| ttx | So if you feel ok presenting that data, it's probably better for you to present the whole segment and drop my name from it | 16:54 |
| persia | The number "17" is really exciting. That means that if someone can only generate a single patch per fortnight, they still end up in the "more active" category. | 17:01 |
| ttx | yes! | 17:30 |
| ttx | A lot of people say "it's hard for us, and there is little point in contributing a drop in the ocean" -- but that's really a false perception. A couple of hours per week will make a significant difference already | 17:31 |
| persia | I'd probably say "a day a fortnight", being as it's easy to burn through a couple hours a week, especially if not concentrated. | 17:32 |
| persia | But I recognise that not everyone likes the word, so maybe "a day every couple weeks"? | 17:32 |
| *** jpich has quit IRC | 17:34 | |
| persia | Alternately put: "If your organisation can only donate 10% of an FTE to openstack development, this is enough to make a significant impact, and will likely cause your organisation to appear on lists of the more active contributors" or so. | 17:34 |
| *** diablo_rojo has joined #openstack-tc | 17:48 | |
| *** irclogbot_3 has joined #openstack-tc | 17:59 | |
| *** zaneb has quit IRC | 18:23 | |
| *** ricolin has quit IRC | 18:24 | |
| * TheJulia reads the interesting discussion | 19:04 | |
| TheJulia | fungi: I really really really like that idea | 19:04 |
| * TheJulia goes to the airport | 19:06 | |
| *** diablo_rojo has quit IRC | 19:12 | |
| *** diablo_rojo has joined #openstack-tc | 19:15 | |
| *** mriedem has quit IRC | 19:32 | |
| *** mriedem has joined #openstack-tc | 19:59 | |
| *** e0ne has joined #openstack-tc | 20:19 | |
| *** e0ne has quit IRC | 20:22 | |
| *** mriedem has quit IRC | 20:41 | |
| *** dklyle has quit IRC | 20:45 | |
| *** dklyle has joined #openstack-tc | 20:45 | |
| *** mriedem has joined #openstack-tc | 20:45 | |
| *** dklyle has quit IRC | 20:46 | |
| *** mriedem has left #openstack-tc | 21:18 | |
| *** diablo_rojo has quit IRC | 21:50 | |
| *** zaneb has joined #openstack-tc | 21:52 | |
| *** diablo_rojo has joined #openstack-tc | 22:03 | |
| *** mriedem has joined #openstack-tc | 22:36 | |
| *** mriedem has quit IRC | 22:46 | |
| *** dklyle has joined #openstack-tc | 23:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!