Wednesday, 2019-06-26

*** ianychoi has quit IRC00:12
*** ianychoi has joined #openstack-tc00:14
*** ianychoi has quit IRC00:20
*** ianychoi has joined #openstack-tc00:21
*** lbragstad has quit IRC00:23
*** ianychoi has quit IRC00:30
*** ianychoi has joined #openstack-tc00:31
*** ianychoi has quit IRC01:03
*** ianychoi has joined #openstack-tc01:04
fungioh, and we're 25 minutes into office hour already01:25
persiaBut this is the unpopular office hour, so having missed the beginning is less noticeable than it might otherwise be.01:27
fungiyeah, i got distracted by a cooking show01:28
mnasero/01:28
mnaseri reached out to people over wechat in china to ask for reviews01:30
fungithanks mnaser!01:30
mnaserprobably won't hear back until starting now-ish cause it was really early :)01:31
fungisure01:32
*** diablo_rojo has quit IRC01:57
*** ianychoi has quit IRC02:14
*** ianychoi has joined #openstack-tc02:16
*** ianychoi has quit IRC02:38
*** ianychoi has joined #openstack-tc02:40
*** ricolin has joined #openstack-tc03:01
*** whoami-rajat has joined #openstack-tc03:04
*** e0ne has joined #openstack-tc05:19
*** e0ne has quit IRC05:23
*** lpetrut has joined #openstack-tc05:56
*** lpetrut has quit IRC05:57
*** lpetrut has joined #openstack-tc05:57
*** ianychoi has quit IRC06:34
*** ianychoi has joined #openstack-tc06:41
*** tosky has joined #openstack-tc07:16
*** e0ne has joined #openstack-tc07:47
*** ianychoi has quit IRC07:59
*** ianychoi has joined #openstack-tc08:01
*** jpich has joined #openstack-tc08:03
*** Luzi has joined #openstack-tc08:31
*** dtantsur|afk is now known as dtantsur|mtg08:37
*** ianychoi has quit IRC09:07
*** ianychoi has joined #openstack-tc09:10
asettleo/09:11
*** jaosorior has quit IRC09:22
*** jaosorior has joined #openstack-tc09:24
*** tdasilva_ has joined #openstack-tc10:02
*** tdasilva has quit IRC10:03
*** tdasilva_ has quit IRC10:22
*** iurygregory has joined #openstack-tc11:00
*** tosky has quit IRC11:15
*** tosky has joined #openstack-tc11:16
*** ianychoi has quit IRC11:40
*** ianychoi has joined #openstack-tc11:45
*** tdasilva has joined #openstack-tc12:11
*** ianychoi has quit IRC12:14
*** lbragstad has joined #openstack-tc12:17
*** ianychoi has joined #openstack-tc12:22
*** mriedem has joined #openstack-tc12:25
mnaserbonjour12:32
*** Luzi has quit IRC12:35
ricolino/12:52
mnasertc-members: https://review.opendev.org/#/c/655984/ has been sitting around for a while and has the minimum favorable votes at this point to merge13:29
mnaserthere's only a few nits, i'd like to merge it unless someone really feels strongly otherwise.13:29
dhellmannevrardjp seemed to have the most recent objections13:31
mnaseri noticed he dropped the -1 but didn't replace it with a +113:46
dhellmannmnaser : looks like there were lots of merge failures due to the docs job failing13:58
zanebI think I'm in the same boat as evrardjp on that review. I think the process we're documenting there is bad.14:08
zanebbut IIUC gmann's point is that it is our current de facto process, and that process is currently undocumented, so we should document it now and worry about fixing it separately14:09
zanebwhich is a fair point and makes me ambivalent about voting against it14:10
evrardjpzaneb: this is exactly why I didn't vote positively14:11
evrardjp-1 means for me that we shouldn't clarify things, which is wrong to me. But +1 means endorsing this. I thought there could be a discussion to just have a different text, and not allow this.14:12
fungiyes, my +1 was an endorsement of documenting the previously undocumented process which has been followed so far. having it written down makes it easier to then discuss what can/should be changed14:13
fungiand also provides a better record of what changed about it when14:14
zanebthere's always the old CR-1/RV+1 available ;)14:14
gmannyeah. otherwise we will face issue on 'what is the process' of re-obtaining the tag if there will be any in future.14:14
gmannchanging the process as per user interest is always good but i feel that need broader discussion because that will change stable policy team working structure.14:16
*** iurygregory has quit IRC14:19
dhellmannif you're going to abstain, at least say so explicitly on the review so the rest of us know what you're thinking14:24
evrardjpI said it on this channel in the past, my bad I forgot to say it in the review. I thought I did.14:25
*** lpetrut has quit IRC14:52
*** asettle is now known as asettle-PTO15:03
*** whoami-rajat has quit IRC15:22
*** diablo_rojo has joined #openstack-tc15:31
*** tosky has quit IRC15:37
*** whoami-rajat has joined #openstack-tc15:38
*** openstackgerrit has joined #openstack-tc15:59
openstackgerritSean McGinnis proposed openstack/governance master: Only get git timestamp for generated files  https://review.opendev.org/66766415:59
*** tdasilva has quit IRC15:59
dhellmannevrardjp : I'm not sure I understand what you're objecting to in that patch. Writing down a bad policy? Or having a policy about this at all?15:59
zanebdhellmann: I think it's writing down a bad policy (which both commits us to following it should the situation come up again, and advertises that its a situation that teams could consider bringing up again)16:10
evrardjpdhellmann: It was a concern about a bad policy. I think I wrote it down in one of my earlier reviews. It's not really about code itself, but about people (stable maintenance team burden), message (please don't change decisions about something that big + encouraging ppl to drop projects) and practicity (why the burden if we can make another project, if it's effectively that)16:10
zanebAIUI nobody thinks that the policy should be just left undefined16:10
dhellmannit is, nonetheless, the policy we have today, isn't it? and so shouldn't we at least write that down so we're not inventing new policy every time the subject comes up?16:11
dhellmannevrardjp: how would you change the policy to make it less of a burden?16:11
fungiwould be good to have the extended maintenance sig members chime in on whether they feel documenting this puts any additional burden on them16:11
evrardjpdhellmann: correct. I thought we could have a conversation about what would be better. If consensus is there, then I can write an alternative new policy before encouraging a bad policy :)16:11
zanebI believe it's the de facto policy, yes16:11
dhellmannevrardjp : ok, it sounds like you should just record a -1 vote on this patch then16:12
dhellmannbecause abstaining isn't "I don't care" it's "I should not vote on this, I have a conflict of interest"16:12
dhellmannand you pretty clearly disagree with this change16:12
evrardjpIt seems I didn't communicate correctly16:13
dhellmannyou disagree with this change and want something different, right?16:13
evrardjpI disagree with the change, but unless I have something else to propose I cannot -1. It's not bringing any progress :)16:13
dhellmannneither is abstaining, really16:13
dhellmannyou either support the change (which is not the same as liking it) or you don't16:13
dhellmannif you can live by this change, then you should vote in favor. If you cannot, you should vote -1.16:14
evrardjpmmm I thought abstaining woulnd't block16:14
fungi-1 doesn't block either16:14
dhellmannit won't, but neither will it trigger any real discussion16:14
dhellmanntrue16:14
evrardjpI see your reasonings. I leave a lot of 0 votes with comments to trigger discussions in general, maybe I should be more -1ing :p16:15
fungiwe just need a majority in favor with quorum, technically?16:15
dhellmannit is perfectly fine to say "this is good enough for now, but we need to address this further" and vote +116:15
evrardjpfungi: that's my understanding :)16:15
dhellmannthere's a difference between asking questions and abstaining (which is why I asked you to state explicitly that you were abstaining)16:15
dhellmannmnaser "called the vote" on this question, so we need everyone to go on record with what their current opinion is16:16
dhellmanncasting a real vote is the only way for us to really know if we have consensus or not16:16
dhellmanns/real vote/up or down vote/16:16
evrardjpIn that case, if I want another convo, it's easier to -1 this.16:17
evrardjpThat will be pretty explicit16:17
evrardjpIt's so not black and white that I have trouble voting.16:18
dhellmannzaneb : this policy basically amounts to "you have to start over to get the tag", which is a bit harsh on the project team, but we don't want to encourage teams to toggle this tag frequently and it seemed less work for the stable team because they don't have to track the tag per-branch (which tonyb has said was too much work). I haven't been able to come up with a better compromise, but would be happy to have one.16:18
dhellmannevrardjp : yeah, think of it in terms of whether you could implement the policy if it was approved, not whether you actually like it16:19
evrardjpcorrect that's why I am also leaning towards +1 .... Darnit!16:19
dhellmannyeah, I'm asking you to think about it and make up your mind. :-)16:20
* dhellmann toddles off to lunch16:20
*** tdasilva has joined #openstack-tc16:29
zanebdhellmann: I have real difficulty imagining a scenario where removing the tag makes more sense than removing the project from OpenStack. if we're going to allow that then the reapplication part seems fine16:30
dhellmannwe did allow that, with trove, didn't we?16:30
dhellmannor is that still up for discussion?16:31
gmanni feel documenting the re-obtaining tag policy which make it very clear to team that re-obtaining is not going to be easy so  think twice before you request  to remove the tag.16:33
gmannwith no doc of that policy does not give clear side effect or difficulties to re-obtain tag for their project. so may be more team will think remove tag is ok and we can get it back any time.16:34
fungiwe allow projects in openstack which don't follow stable branch policy, right?16:37
gmannyeah16:38
fungiso i don't see failing to be able to follow stable branch policy as necessarily indicating that the project should also be removed from openstack16:38
fungi(though it certainly could be a sign that the project is effectively unmaintainable/unusable)16:39
*** jpich has quit IRC16:39
fungii do agree somewhat with zaneb that if a project wants to *temporarily* drop stable branch policy with ideas about re-adding it later, then that's probably an indication that they should not be part of openstack until whatever transition which caused them to not be able to support their users in that way has passed16:40
gmanni think zaneb concern is about remove the tag which is more dangerous than not having tag from starting from usage perspective (user using old stable which had tag need to re-checking whether project following the tag or not)16:41
gmannyeah you typed it fast.16:41
zanebdhellmann: we allowed it and I'm not at all convinced we should have16:42
gmannshould we think of some notification mechanism to users if stable tag status is changed ?16:42
zanebI don't understand their reasoning for wanting to drop it (they never said AFAIK), but it can only have been bad as far as I can imagine16:43
fungii would support a proposal (after this one merges) to adjust the de-facto policy to say that any projects which add the tag in the future (or which choose not to remove it by some predetermined cut-off date) can't remove that tag without removing the project from openstack and having to reapply as a project again some time later16:43
dhellmanniirc, as the 3rd (?) new team to take over the project, they didn't want to have to support the designs of previous teams. Perhaps we should have asked them to start a new project.16:44
fungizaneb: i don't recall where the discussion took place, but the argument i heard was that they wanted to do a major rewrite and keeping backward compatibility would be too much work for the limited set of maintainers they have16:44
dhellmannso we can have projects that never bring the tag in, but existing projects that do have the tag must keep it?16:44
gmannwill not start the new project will be just renaming the project with same code base ?16:44
zanebdhellmann: great, don't support it. don't backport anything. how does backporting *features* help?16:44
gmannbecause no one will rewrite the code again16:44
zanebfungi: keeping backward compatibility on stable branches? or master?16:45
dhellmannit wasn't about backporting features,  it was about not having to fix bugs at all. and maybe that would have been acceptable without dropping the tag16:45
zanebdhellmann: the stable branch tag means you don't backport features. if you don't want to backport anything, close the stable branch, problem solved16:46
fungiahh, i had gotten the impression they wanted to make non-backward-compatible changes on stable because the companies employing the new maintainers weren't interested in upgrading16:46
dhellmannoh, maybe that was it?16:46
dhellmannfor some reason this did make sense at the time, but I would have to go dig through logs to find the discussion16:47
zanebyou only need to remove the tag if you want to backport patches that are not allowed under the policy, i.e. features since everything else is now allowed. it's really not an onerous policy16:47
gmannyeah that can be case.16:47
fungibut really, at this point i suppose it's academic unless the folks involved in that decision clue us in16:47
zanebfungi: "i had gotten the impression they wanted to make non-backward-compatible changes on stable because the companies employing the new maintainers weren't interested in upgrading" <- that means the project doesn't belong in openstack any more IMHO16:48
zaneb(assuming that was the case, which I don't know)16:48
dhellmannit looks like the work over the last few months has been on master16:48
dhellmannhttps://review.opendev.org/#/q/project:openstack/trove16:48
fungihttps://review.openstack.org/519685 removed it from kolla deliverables, fwiw16:50
fungistill digging through history for clues on trove16:50
zanebbtw if they were making breaking API changes on master (which has nothing whatsoever to do with the stable tag) then we should absolutely remove the project and require them to reapply with a new name. we already stated that in the past when it came up on the mailing list16:50
fungihttps://review.openstack.org/507924 removed it from tripleo deliverables16:50
zanebmaybe stuff like https://review.opendev.org/#/c/651672/ was the motivation for dropping the tag?16:51
fungioh... http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004991.html16:55
fungiand yeah, it was that patch16:56
fungiwhich started the ml discussion16:56
zanebso one possibility (that we would need to discuss with the release team and the stable maint team) is that we require different names for branches that don't follow the policy16:56
zaneblike, ok you can drop the tag but we're closing stable/stein and you can backport all the patches you like to unstable/stein16:57
*** e0ne has quit IRC16:58
fungiso yes it was the desire to not follow stable policy when reviewing/approving changes to stable branches16:58
*** ricolin has quit IRC17:02
dhellmannafter zuul v3, how much of our CI/infra has to change to support branches with names other than "stable/" and "feature/"?17:18
fungithe reference from apevec in that change suggests that was the impetus for tripleo dropping it from their deliverables as well17:18
fungidhellmann: none i'm aware of unless you want some magic which makes changes to unstable/foo to be tested as if they were changes to stable/foo when determining which branches of other projects to integrate with17:19
dhellmannyeah, that's what I was thinking of17:19
fungiby default (and this was true before zuul v3 as well) we assume that if your change is on trove's unstable/foo branch and you're including nova in your job, then if nova doesn't also have an unstable/foo branch it will checkout nova master instead17:20
fungithough you can write your job so that the definition of it on your unstable/foo branch indicates specific required projects should have their stable/foo branches checked out automatically instead17:21
fungior the job could explicitly do a git checkout stable/foo in each of them17:21
zanebfungi: ah, I wasn't aware that TripleO had dropped the tag also. fwiw I agree with ttx's comment on that review: "One could argue that this tag was never really a good fit for deployment/lifecycle management projects"17:22
fungi(zuul will still prepare the dependent refs for every branch it's aware of in those clones anyway)17:22
fungizaneb: yeah, that's also the argument used when kolla dropped stable:follows-policy from their deliverables17:22
openstackgerritSean McGinnis proposed openstack/governance master: Only get git timestamp for generated files  https://review.opendev.org/66766417:25
gmannkolla should not be consider as deployment tool, its lib. kolla-ansible tag removal was with deployment tool reason17:29
fungigmann: well, https://review.opendev.org/519685 removed it from both17:34
*** e0ne has joined #openstack-tc17:52
*** dtantsur has joined #openstack-tc17:52
*** dtantsur|mtg has quit IRC17:53
*** altlogbot_3 has quit IRC17:55
*** altlogbot_3 has joined #openstack-tc18:00
*** altlogbot_3 has quit IRC18:01
*** altlogbot_0 has joined #openstack-tc18:03
*** e0ne has quit IRC18:29
openstackgerritSean McGinnis proposed openstack/governance master: Only get git timestamp for generated files  https://review.opendev.org/66766418:35
*** e0ne has joined #openstack-tc18:44
openstackgerritKendall Nelson proposed openstack/project-team-guide master: Add Project Update info to Events Section  https://review.opendev.org/66770919:02
openstackgerritKendall Nelson proposed openstack/project-team-guide master: Add Project Update info to Events Section  https://review.opendev.org/66770919:04
*** e0ne has quit IRC19:08
*** dklyle has quit IRC19:09
*** dims has quit IRC19:20
*** whoami-rajat has quit IRC19:22
*** dims has joined #openstack-tc19:28
*** dims has quit IRC19:32
*** dims has joined #openstack-tc19:33
openstackgerritKendall Nelson proposed openstack/governance-sigs master: Add Matt Oliver to FC SIG Chair List  https://review.opendev.org/66771519:34
*** dklyle has joined #openstack-tc19:36
*** altlogbot_0 has quit IRC19:46
*** dims has quit IRC19:46
*** altlogbot_0 has joined #openstack-tc19:47
*** dims has joined #openstack-tc19:52
*** dims has quit IRC19:57
*** dims has joined #openstack-tc19:57
*** mriedem has quit IRC20:04
*** mriedem has joined #openstack-tc20:07
*** dims has quit IRC20:08
*** diablo_rojo has quit IRC20:09
*** dims has joined #openstack-tc20:14
*** altlogbot_0 has quit IRC20:15
*** altlogbot_0 has joined #openstack-tc20:19
*** altlogbot_0 has quit IRC20:43
*** altlogbot_2 has joined #openstack-tc20:45
*** altlogbot_2 has quit IRC21:00
*** tosky has joined #openstack-tc21:02
*** altlogbot_2 has joined #openstack-tc21:05
*** ianychoi has quit IRC21:23
*** ianychoi has joined #openstack-tc21:28
*** diablo_rojo has joined #openstack-tc21:40
*** tdasilva_ has joined #openstack-tc21:52
*** tdasilva has quit IRC21:54
openstackgerritMohammed Naser proposed openstack/governance master: Defining popup teams  https://review.opendev.org/66135621:54
openstackgerritMohammed Naser proposed openstack/governance master: Drop requirement to list all affected teams  https://review.opendev.org/66422221:55
openstackgerritMohammed Naser proposed openstack/governance master: Adding Image Encryption as a popup team  https://review.opendev.org/66198321:55
openstackgerritMohammed Naser proposed openstack/governance master: Update the 'stable:follows-policy' tag doc for re-obtaining process  https://review.opendev.org/65598422:02
mnasertc-members: anyone around to code review https://review.opendev.org/#/c/667664/3 to help push the other changes we got goin on?22:05
fungiyeah, was just looking at that, seems to be working22:06
mnaserthanks fungi :)22:07
fungitc-members: the osf staff heard our feedback at the denver leadership meeting and are planning to do a spotlight piece on one of our help wanted entries in next week's foundation newsletter... now we just need to pick which one!22:24
lbragstadsweet22:24
lbragstaddo we want to start a ML thread to help pick the one we want to talk about?22:25
lbragstadrather, the one we want them to promote?22:25
fungican't hurt. i'm happy to toss something out there22:25
fungiwe'll have more opportunities, just need to decide which one goes first22:25
lbragstadif the newsletter is going out next week, we won't be able to use the meeting to discuss it since that'll be the 11th22:26
lbragstadthe ML probably has more visibility than discussing it in office hours tomorrow, too22:26
fungii doubt it needs much discussion, we ought to be able to cycle through them all over the coming months22:26
fungibut yeah, ml is a good idea22:27
dhellmannI would also be happy to have a few interested TC members just pick one22:32
fungiyeah, given we expect to get around to all of them in short order regardless22:33
fungiit's less a question of which one get promoted, more of which get promoted sooner than others22:34
*** diablo_rojo has quit IRC22:44
dhellmannright, and for things like that I think we should just let a couple of people do the work and the rest of us get out of the way22:45
fungii'm happy to let the folks who have led the charge on the recent revamp of the help wanted list pick22:58
fungii'm mostly just the messenger here, passing along info from the newsletter editors22:59
*** diablo_rojo has joined #openstack-tc23:07
*** tosky has quit IRC23:12
*** mriedem has quit IRC23:42

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