| *** lbragstad has joined #openstack-tc | 00:29 | |
| *** zhurong has joined #openstack-tc | 00:54 | |
| *** lbragstad has quit IRC | 01:50 | |
| *** masayukig has joined #openstack-tc | 01:57 | |
| *** masayukig has quit IRC | 02:10 | |
| *** masayukig has joined #openstack-tc | 02:10 | |
| *** lbragstad has joined #openstack-tc | 02:12 | |
| *** jamesmcarthur has joined #openstack-tc | 02:19 | |
| *** jamesmcarthur has quit IRC | 02:26 | |
| *** jamesmcarthur has joined #openstack-tc | 02:26 | |
| *** jamesmcarthur has quit IRC | 02:32 | |
| *** jamesmcarthur has joined #openstack-tc | 02:46 | |
| *** jamesmcarthur has quit IRC | 02:49 | |
| *** jamesmcarthur has joined #openstack-tc | 02:50 | |
| *** jamesmcarthur has quit IRC | 02:54 | |
| *** jamesmcarthur has joined #openstack-tc | 03:31 | |
| *** jamesmcarthur has quit IRC | 03:32 | |
| *** tonyb[m] has joined #openstack-tc | 03:40 | |
| *** whoami-rajat has joined #openstack-tc | 04:37 | |
| *** jaosorior has joined #openstack-tc | 04:48 | |
| *** Luzi has joined #openstack-tc | 05:59 | |
| *** e0ne has joined #openstack-tc | 06:48 | |
| *** e0ne has quit IRC | 06:49 | |
| *** e0ne has joined #openstack-tc | 06:52 | |
| *** lbragstad has quit IRC | 06:52 | |
| *** e0ne has quit IRC | 07:12 | |
| *** tosky has joined #openstack-tc | 07:20 | |
| *** spotz has joined #openstack-tc | 07:22 | |
| *** e0ne has joined #openstack-tc | 07:31 | |
| *** e0ne has quit IRC | 07:52 | |
| *** jpich has joined #openstack-tc | 07:55 | |
| *** e0ne has joined #openstack-tc | 07:57 | |
| *** dtantsur|afk is now known as dtantsur | 08:30 | |
| asettle | Morning o/ | 08:45 |
|---|---|---|
| *** sapd1 has quit IRC | 08:59 | |
| *** e0ne has quit IRC | 09:09 | |
| *** e0ne has joined #openstack-tc | 09:18 | |
| *** jpich has quit IRC | 09:21 | |
| *** jpich has joined #openstack-tc | 09:22 | |
| *** jpich has quit IRC | 09:23 | |
| *** jpich has joined #openstack-tc | 09:24 | |
| ttx | morning! | 09:35 |
| *** e0ne has quit IRC | 09:55 | |
| *** e0ne has joined #openstack-tc | 10:06 | |
| *** e0ne has quit IRC | 10:26 | |
| *** e0ne has joined #openstack-tc | 10:35 | |
| *** jpich has quit IRC | 11:02 | |
| *** jpich has joined #openstack-tc | 11:07 | |
| *** jpich has quit IRC | 11:07 | |
| *** jpich has joined #openstack-tc | 11:08 | |
| *** e0ne has quit IRC | 11:10 | |
| *** weshay_pto has quit IRC | 11:12 | |
| *** weshay_pto has joined #openstack-tc | 11:13 | |
| *** sapd1 has joined #openstack-tc | 11:44 | |
| *** e0ne has joined #openstack-tc | 12:16 | |
| *** jamesmcarthur has joined #openstack-tc | 12:24 | |
| *** jamesmcarthur has quit IRC | 12:35 | |
| *** tosky has quit IRC | 12:36 | |
| *** e0ne has quit IRC | 12:40 | |
| *** e0ne has joined #openstack-tc | 12:41 | |
| *** jamesmcarthur has joined #openstack-tc | 12:46 | |
| *** e0ne has quit IRC | 12:58 | |
| *** jamesmcarthur has quit IRC | 13:12 | |
| *** lbragstad has joined #openstack-tc | 13:14 | |
| *** e0ne has joined #openstack-tc | 13:17 | |
| *** ijolliffe has joined #openstack-tc | 13:20 | |
| *** mriedem has joined #openstack-tc | 13:24 | |
| *** jroll has quit IRC | 13:25 | |
| *** jroll has joined #openstack-tc | 13:26 | |
| *** e0ne has quit IRC | 13:28 | |
| *** e0ne has joined #openstack-tc | 13:34 | |
| *** jamesmcarthur has joined #openstack-tc | 13:35 | |
| *** jamesmcarthur_ has joined #openstack-tc | 13:46 | |
| *** jamesmcarthur has quit IRC | 13:49 | |
| *** e0ne has quit IRC | 14:06 | |
| *** Luzi has quit IRC | 14:07 | |
| *** e0ne has joined #openstack-tc | 14:21 | |
| mugsie | morning o/ | 14:46 |
| *** tosky has joined #openstack-tc | 15:08 | |
| *** e0ne has quit IRC | 15:14 | |
| asettle | Slow day, huh | 15:22 |
| *** e0ne has joined #openstack-tc | 15:23 | |
| *** e0ne has quit IRC | 15:34 | |
| mnaser | so | 15:39 |
| mnaser | thanks to the awesome work for Horace (OSF's employee in China) | 15:40 |
| mnaser | he has reached out to the tricircle team and we've managed to get some explanations | 15:40 |
| mnaser | a big part of it was that big spam attack | 15:40 |
| mnaser | they seemed to have moved to WeChat because a) there was a ton of spam and b) they couldn't get in the channel (assuming registration and what not) and just figured "this is easier" | 15:41 |
| mnaser | there's an *awesome* diverse team of people working on it from different orgs. I started talking to them and asking them to come to IRC, so they're going to try and do that | 15:41 |
| mnaser | I also realized https://docs.openstack.org/contributors/common/irc.html is not translated to chinese | 15:42 |
| mnaser | so I've asked in a WhatsApp group within the Chinese community if someone would like to volunteer to translate that, it's late there now, but I'm hoping that we get a volunteer | 15:42 |
| gmann | +1. | 15:47 |
| gmann | tc-members: to update Train testing runtime, I am thinking we update 'openstack-python-jobs' template to add the py3.6/7 jobs. and same we use for any future change. - 'https://github.com/openstack-infra/openstack-zuul-jobs/blob/fc72f5ab5de8753d0254a3f3293fb0aff7f3805c/zuul.d/project-templates.yaml#L282' | 15:50 |
| smcginnis | gmann: That would affect stable branches too though. | 15:50 |
| gmann | This template is used in all projects to run and by updating this template for each cycle runtime we can avoid project side update. and running each targeted py version testing consistently. | 15:50 |
| gmann | smcginnis: that can be handled with branch variant. | 15:51 |
| gmann | we used to handle the same in integrated-gate template also for tempest-full | 15:51 |
| clarkb | mnaser: horace may be able to help wtih that document if we don't get community volunteers | 15:51 |
| mnaser | clarkb: yup, indeed! | 15:51 |
| jroll | gmann: I proposed doing this recently and was told the TC agreed that it was best to do it per branch: https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html | 15:52 |
| fungi | asettle: or busy day for everyone who would otherwise be talking in here maybe? | 15:53 |
| gmann | yeah, i think we still need to update project side for tox env and setup.cfg but i still feel keeping all supported version in single template is much easy to maintain | 15:56 |
| fungi | jroll: gmann: more specifically, it's that the resolution where we agreed on how to specify supported runtimes per release got deep into implementation details, and now we're compelled to have a new resolution or stick to what we agreed on in that one (to me it was unclear we were actually encoding job design choices in that resolution, i had voted in favor on the assumption folks more familiar with the | 15:56 |
| fungi | available options would be consulted when it came time to design the actual implementation, but apparently others disagree) | 15:56 |
| jroll | sure | 15:57 |
| jroll | maybe gmann has more motivation than I do to change it :) | 15:57 |
| smcginnis | I'm still partial to this approach: https://review.openstack.org/#/c/637866/ | 15:58 |
| gmann | yeah, it is more practical (implementation wise) now when we are dropping one version and adding other. | 16:04 |
| asettle | fungi, definitely a busy day for me :( | 16:04 |
| *** jpich has quit IRC | 16:23 | |
| *** dtantsur is now known as dtantsur|afk | 16:44 | |
| *** e0ne has joined #openstack-tc | 16:51 | |
| zaneb | smcginnis: that approach is *almost* identical to the one we agreed on (https://review.openstack.org/641878) and the exact opposite of the thing jroll/fungi/dhellmann/gmann/everybody keeps proposing | 17:28 |
| dhellmann | ? | 17:29 |
| dhellmann | I think I want the series name in the template name. Is that not what we agreed to do? | 17:29 |
| zaneb | yes, it is | 17:30 |
| zaneb | but we're having another go-around of the bikeshedding, apparently | 17:30 |
| * dhellmann sighs | 17:30 | |
| gmann | zaneb: may be we can move the implementation detail from resolution to "when defining the goal". and when we add the goal artifact there we add how to implement the runtime which depends on current cycle template, zull design etc | 17:31 |
| * jroll did his best to engage by only pointing out the history | 17:31 | |
| jroll | er, not engage | 17:31 |
| zaneb | jroll: appreciated :) | 17:32 |
| dhellmann | gmann : can you help me understand why you want to make a new plan now instead of just implementing https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html ? | 17:32 |
| zaneb | gmann: if you want to write up the cycle goal that would be great. but if we're not going to implement the plan we agreed on the resolution then I am -1 unless you also update the resolution | 17:33 |
| gmann | dhellmann: i am not saying not implementing this, just a thought of implementing it via 'openstack-python-jobs' template which give us 1. single template to hold all the py version jobs . 2. one template on project side instead of two (openstack-python-jobs and openstack-python3-<releasename>-jobs) | 17:35 |
| zaneb | because it is NOT much to ask the the TC implement a simple thing like this as agreed and almost unanimously voted on the very first time it comes up. if we can't manage that then the community should never listen to anything we ever say again | 17:35 |
| gmann | to make clear, i am proposing to use the template 'openstack-python-jobs' for our resolution implementation | 17:36 |
| dhellmann | but the whole point of that resolution was to describe how we would use series-specific names for the templates | 17:36 |
| zaneb | gmann: one template to hold all the jobs means (1) branch specifier hell in the template, and (2) projects that don't support py27 yet will get broken immediately when we could easily have waited as long as the end of the cycle to add py37 support | 17:36 |
| zaneb | both of which issues we have been over many times | 17:37 |
| zaneb | s/py27/py37/ | 17:37 |
| dhellmann | yeah, as much as I would like to just flip a switch and say we support a new python version, in practice it's not that easy | 17:37 |
| gmann | that can be avoided for projects to make py37 job n-v if they failing on that. | 17:38 |
| gmann | anyways i wanted to avoid project side patches for each version update but that is not the case when i realized of updating tox.ini and setup.cfg on project side in both cases. | 17:39 |
| dhellmann | the ultimate plan was to have the release automation generate the patches, we just didn't get to it this cycle | 17:39 |
| gmann | if we can have that automation, it will be great. | 17:40 |
| zaneb | ++ automation would be excellent | 17:41 |
| gmann | and it is little more update we need for this cycle. remove the currently used openstack-tox-py37 job on project zuul.yaml explicitly when adding the template | 17:41 |
| zaneb | I think dhellmann has already built quite a lot of stuff around the py3-first transition that should be a good starting point | 17:42 |
| dhellmann | yeah, there are some scripts in goal-tools that could be used to build something to add the missing template to a repo | 17:43 |
| zaneb | I think setup.cfg will be the hardest thing to automate because so many of them are wrong already | 17:43 |
| dhellmann | and there's already a script as part of the release branching job that creates several patches to set up the new branch that can be extended to do this new step | 17:43 |
| gmann | yeah, many use 3.4, 2.7 only and so on | 17:43 |
| fungi | somehow i didn't get that being the entire point of the resolution. i thought the point of the resolution was to declare that we would be picking etsted runtimes per cycle and how they would be chosen, and took the zuul implementation details as an example, but i respect that others saw that as what they were voting on | 17:44 |
| *** diablo_rojo has joined #openstack-tc | 17:45 | |
| fungi | and if we already have to update every single project to adjust their setup.cfg and tox.ini anyway, then i guess also altering their zuul pipeline configuration in the same change is a reasonable approach | 17:45 |
| dhellmann | fungi : I thought we were trying to describe how we were going to make it easy for teams to understand which jobs we expect to have run for each cycle, so we don't keep having the "when should we add 3.7 tests and drop 3.5 tests?" type conversations | 17:45 |
| fungi | i worry more about having to get the tc to agree on yet another resolution every time there are different features in the ci system we might want to take advantage of to achieve a similar end result | 17:46 |
| fungi | and feel like a literal interpretation there is painting us into a corner of "well we can't consider this option because we designed *the solution* into our project governance" | 17:47 |
| dhellmann | maybe. or maybe it's fine to say "this solution is not perfect but it works and we have lots of things without any solutions at all" | 17:48 |
| zaneb | ok, but we haven't even tried it *once* to see how well it worked since we agreed on it, and there's nothing stopping us from changing the resolution apart from the fact that nobody wants to do that work | 17:49 |
| gmann | "The TC will set an OpenStack-wide goal for the cycle that project teams update each repo to:" this is place i think we should involve the implementation way which can be same each cycle or different depends on source code of that cycle | 17:50 |
| zaneb | (oops, that was ambiguous - I was replying to fungi, not dhellmann there.) | 17:50 |
| fungi | sure, i don't object to giving it a try, as i've said, i even think rolling it up into the same change which updates the python versions for the pypi package and default tox testenvs makes some sense | 17:51 |
| fungi | i was just saying that the choice of technical implementation seemed like an example to me, because we don't usually make project governance decisions which involve that level of implementation detail | 17:52 |
| zaneb | gmann: I agree, and in fact the resolution leaves large parts of the implementation up to the goal champions, but I also think that if we decided to change parts that are encoded in the resolution then we should update the resolution (even if we just change it to say the goal champions will decide case-by-case what to do each cycle) | 17:52 |
| fungi | i think in that case we need a new resolution? resolutions are a dated record of decisions the tc has made | 17:53 |
| *** Sundar has joined #openstack-tc | 17:53 | |
| fungi | so we wouldn't change an old decision, we would just make a new decision which supercedes it | 17:54 |
| dhellmann | that's the process we have used in the past, yes | 17:55 |
| *** ijolliffe has quit IRC | 17:55 | |
| zaneb | sure, whatever | 17:56 |
| *** ijolliffe has joined #openstack-tc | 17:57 | |
| *** e0ne has quit IRC | 18:00 | |
| *** jamesmcarthur_ has quit IRC | 18:04 | |
| *** Sundar has quit IRC | 18:37 | |
| *** ijolliffe has quit IRC | 18:42 | |
| *** ijolliffe has joined #openstack-tc | 18:46 | |
| *** jamesmcarthur has joined #openstack-tc | 19:01 | |
| *** e0ne has joined #openstack-tc | 19:02 | |
| *** e0ne has quit IRC | 19:06 | |
| *** Sundar has joined #openstack-tc | 19:29 | |
| openstackgerrit | Sean McGinnis proposed openstack/governance master: Drop references to git.openstack.org https://review.openstack.org/652762 | 19:30 |
| *** penick has quit IRC | 19:46 | |
| mnaser | did we get to any closure on that topic ^ ? | 19:48 |
| *** Sundar has quit IRC | 20:00 | |
| *** jamesmcarthur has quit IRC | 20:37 | |
| *** jamesmcarthur has joined #openstack-tc | 20:39 | |
| *** jamesmcarthur has quit IRC | 20:56 | |
| *** jamesmcarthur has joined #openstack-tc | 21:27 | |
| *** ijolliffe has quit IRC | 21:28 | |
| *** jamesmcarthur has quit IRC | 21:52 | |
| *** whoami-rajat has quit IRC | 21:54 | |
| *** jamesmcarthur has joined #openstack-tc | 21:55 | |
| *** jamesmcarthur has quit IRC | 21:55 | |
| *** jamesmcarthur has joined #openstack-tc | 22:00 | |
| *** diablo_rojo_phon has joined #openstack-tc | 22:12 | |
| *** mriedem has quit IRC | 22:14 | |
| *** jamesmcarthur has quit IRC | 22:25 | |
| fungi | closure on the git.openstack.org topic? | 22:37 |
| *** lbragstad has quit IRC | 23:13 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!