Thursday, 2018-03-08

*** mriedem has quit IRC00:05
*** annabelleB has joined #openstack-tc00:15
*** lbragstad has quit IRC00:39
*** david-lyle has quit IRC00:53
*** david-lyle has joined #openstack-tc00:56
*** notmyname has quit IRC01:02
*** notmyname has joined #openstack-tc01:03
*** annabelleB has quit IRC01:55
*** david-lyle has quit IRC01:57
*** annabelleB has joined #openstack-tc02:00
*** diablo_rojo has quit IRC02:25
*** harlowja has quit IRC02:49
*** diablo_rojo has joined #openstack-tc02:50
*** annabelleB has quit IRC03:02
*** annabelleB has joined #openstack-tc03:07
*** annabelleB has quit IRC03:47
*** annabelleB has joined #openstack-tc03:50
*** harlowja has joined #openstack-tc04:37
*** kumarmn has quit IRC04:57
*** pabelanger has quit IRC04:58
*** gcb has joined #openstack-tc05:02
*** kumarmn has joined #openstack-tc05:03
*** harlowja has quit IRC06:05
*** david-lyle has joined #openstack-tc06:09
*** dims has quit IRC06:24
*** dims has joined #openstack-tc06:30
*** annabelleB has quit IRC06:33
*** annabelleB has joined #openstack-tc06:46
*** ykarel has joined #openstack-tc06:51
*** ykarel has quit IRC07:40
*** annabelleB has quit IRC08:14
ttxwow wall of text08:40
ttxTwo remarks: yes one of the hidden goals of the original resolution was hoping that it would infuse more resources  to the QA team by making some its work directly usable downstream08:41
ttxwhich obviously did not happen08:41
ttxAnd on clouds now behaving generally better interop-wise: I think they finally realized that their success depends on being interoperable rather than being different.08:42
*** dtantsur|afk has quit IRC08:43
*** annabelleB has joined #openstack-tc08:43
ttxwhich means the interop program is less necessary as an interoperability-driving tool (its trademark usage gatekeeper usefullness remains)08:44
*** dtantsur has joined #openstack-tc08:50
*** jpich has joined #openstack-tc08:54
*** annabelleB has quit IRC08:56
*** dtantsur has quit IRC09:01
*** dtantsur has joined #openstack-tc09:06
*** dtantsur has quit IRC09:31
*** dtantsur has joined #openstack-tc09:38
*** pabelanger has joined #openstack-tc09:41
*** cdent has joined #openstack-tc09:47
*** cdent has quit IRC10:03
*** gcb has quit IRC10:46
*** gcb has joined #openstack-tc10:49
*** cdent has joined #openstack-tc11:27
*** pabelanger_ has joined #openstack-tc12:27
*** pabelanger has quit IRC12:29
*** zhipeng has joined #openstack-tc12:55
*** annabelleB has joined #openstack-tc13:09
*** pabelanger_ is now known as pabelanger13:10
*** jpich has quit IRC13:21
*** jpich has joined #openstack-tc13:22
*** kumarmn has quit IRC13:32
*** kumarmn has joined #openstack-tc13:33
*** kumarmn has quit IRC13:37
*** mriedem has joined #openstack-tc13:45
*** rosmaita has joined #openstack-tc13:47
*** kumarmn has joined #openstack-tc13:54
*** kumarmn has quit IRC13:54
*** kumarmn has joined #openstack-tc13:54
*** lbragstad has joined #openstack-tc13:54
*** annabelleB has quit IRC14:03
*** dtantsur is now known as dtantsur|brb14:05
*** dtk has quit IRC14:36
*** dtk has joined #openstack-tc14:37
*** dtk has quit IRC14:45
fungiwell, trademark programs are also the signal we use as a community to communicate the importance we place on interoperability14:46
fungi"not interoperable (per our standards)? then you can't call it openstack!"14:47
cdentthat was an awesome long distance context switch14:47
persiaIndeed, thinking about trademark-program-as-tool is easier than thinking about social-model-to-support-abstract-program.14:49
persiaThe Mozilla Foundation trademark program related to "Firefox" is a lovely example of using trademarks in that way.14:49
*** melwitt has quit IRC14:59
cdenttc-members and others assemble15:00
EmilienMo/ (with my 10 fingers)15:01
cdentI was going to suggest we talk about the trademark tests but:
* fungi shakes off the morning and grabs more caffeine15:01
* cdent shakes huge thumb at EmilienM 15:01
cdentso I'm gonna focus on listening15:01
* ttx was lost updating himself on Riot/Matrix status15:02
pabelangerI also wanted to confirm no members had issues with proposed names and prepare for the formal vote next week15:02
ttxI'll post a summary of the TC Friday PTG room in the weekly status tomorrow15:03
ttxor at least that's the plan15:03
persiaGood day.  I would like to change some wording on , but suspect normal code review isn't the right solution.  Specifically, I feel the ATC mechanisms we have in place are not well described by that document, and would like to either bring the document in line with practice, or be formally nofitied that current practice is insufficient.15:03
mriedempersia: i think we're talking past each other on
persiaDoes anyone have specific suggestions on whose authorisation is required for such a change, or the best practice for doing so?15:04
ttxpersia: charter change process is described... in the charter15:04
persiamriedem: My apologies if my last comment did not read "please ignore this subthread" loudly enough.15:04
mriedemmaybe i should just update this resolution proposal today with new fangled stuff and then we can rathole on the new thing15:04
mriedempersia: i'm a simple man with simple tastes, you need to dumb it down for me :)15:05
persiattx: So use code review, and it needs 9 roll-call votes?15:05
ttxwhich means code review approved by 2/3 of the members15:05
persiattx: Thanks for the clarification.15:05
ttxOne thing we discussed is to use some form of tracking for issues the TC wants to tackle. Something standing between the vision and the reviews/motions15:06
ttxA task tracker could be used15:06
*** melwitt has joined #openstack-tc15:06
cdentgranular goals, something like that?15:07
*** melwitt is now known as Guest7007515:07
ttxyeah, basically tracking the various headlines on that etherpad more often than once every 3 months at Forums and PTGs15:07
mriedemtask tracker? like...storyboard?15:08
mriedemoh the irony15:08
ttxmriedem: Oh! Excellent suggestion!15:08
* ttx whistles innocently15:08
persia!/story/list?status=active&project_id=923 might be a reasonable place to put things15:09
ttxHappy to go ahead and create things there if we collectively think it's a good idea15:10
pabelangerpersia: neat, didn't know that was a thing yet15:11
ttxpabelanger: that's what we use for tracking goals now15:11
openstackgerritGraham Hayes proposed openstack/governance master: Update Trademark test locations
fungiyeah, we did that so goals tracking had a place to land15:11
persiapabelanger: There's a deployment bug, or it could say "project=governance" instead of us needing to remember "923", so it will be better in the next while.15:11
* dhellmann wonders why that query is returning things that don't appear related to the governance repo15:12
dhellmannand not the goals15:12
pabelangerttx: ++15:12
dhellmannoh, 1565 results15:12
persiadhellmann: There's a race condition bug (which fix is stalled for the previously mentioned deployment bug).  Reloading a few times should reduce the count from 1500+ to 2.15:12
cdentso besides putting tc micro goals in storyboard because it is a good idea, we can use it as a way to encourage fixing storyboard...15:15
persiaFor those interested, is the project-name issue, and is the race condition issue, and neither is a priority to merge because of the publication issue (which was actively being hacked at by the infra team as recently as yesterday).15:17
TheJuliaPart of the reason I'm hoping to get ironic over is that as well15:17
* ttx reads latest developments on the EM proposal and the Interop proposal15:19
mugsiethere are now 3 options for InterOp - the one I wrote based on jroll's comments in Dublin, cdent's simplified version, and a new 3rd option, which we talked about over the last few days, which is to let InterOp WG decide where they want tests to come from15:20
ttxNot sure that brings us closer to a solution though... Gerrit is notoriously bad to discuss choosing one of 3 proposals15:21
cdentthanks for doing that mugsie. have dropped my -1 on that third one for the reasons we discussed15:22
mugsiecdent: yup, I agree with you, but I wanted people to have the option15:22
cdentyup, which is what I said in my review15:23
TheJuliaI'm going to need to find time to read through those things. I agree that 3 options don't help, but maybe we can reach consensus quickly if we make a point of trying to discuss it next week at a particular office hour?15:23
fungispecific choice of tool aside... what mathematical model _would_ be good for reaching consensus on n-of-m sets where the set members are interrelated and can't merely use a straight ranking?15:24
fungivoting within an n-dimensional matrix seems... hard15:25
dhellmanncdent : I'm curious about your characterization of that 3rd option as "abdication". We "delegate" other similar decisions to other similar working groups. How do you see this one as different?15:25
TheJuliaor each tc member gets one vote on the topic to pair it down?15:25
cdentfungi: That problem is probably easier to solve simply by humans trying a bit harder despite limits of tools15:26
mugsieI think cdent's simplified version is just a better, shorter version of my long winded one15:26
fungicdent: so answer is "try harder next time"15:26
fungigot it ;)15:26
cdentdhellmann: that's based on conversations with various people yesterday, but: we're the technical leadership and the governance for the community. It's our job to fix real problems.15:27
cdentpunting to interop will not fix the real problems15:27
cdentnor provide any reduction in complexity for projects (one, but only one, of the problems)15:27
dhellmannisn't the problem that we tried to over-specify the answer to this in the first place?15:27
cdentthat may be one of the problems15:28
cdentbut there are others15:28
cdentunder-resourced groups15:28
cdentunder-trained people15:28
mugsiedhellmann: I don't think so, I think the problem was that people thought they could just ignore what we wrote15:28
cdentsocial conflicts15:28
dhellmannmugsie : yes, well, that is certainly one15:28
cdentlack of alacrity in changing our policies when facing new realities15:29
fungiwhat we wrote was also a catch-2215:29
dhellmanncdent : in other areas where I've seen us make successful changes, the thing that made them successful was placing the burden of doing work on the appropriate people.15:29
mugsiefungi: not really, we didn't say tests couldn't be in tempest, that was thq QA team15:29
fungiif you can't consider tests for a trademark program until they're in tempest, but the tempest team won't add tests until they're approved for a trademark program, _that's_ a catch-2215:29
dhellmannthat either gives them the mandate to do it, or exposes that they aren't really there in the first place15:29
cdentdhellmann: right, and that's what's being argued through this process. who are the right people, and irrespective of who is right, who has the people15:30
mugsieif we hadn't ignored it, the issue of interop choosing tests in a format the QA team doesn't like could have been solved a year ago15:30
dhellmannI personally don't believe the people exist, and I'm trying to expose that by putting it on the group trying to drive the work.15:30
fungiso we could say that the tempest team is required to add tests in advance of them being accepted for a trademark program and can then rip them out again at some later date if the proposed trademark program fails to be approved15:30
cdentdhellmann: in case you missed it at the start of the office-hour I'm a bit slow to keep up:
fungior we could say that tests can be selected for a trademark program in advance of them being added to tempest15:30
mugsiefungi: QA do not want to expand the scope of tempest15:31
dhellmannfungi : what should have happened is when the tests were selected for a draft proposal they were accepted into tempest15:31
fungia draft proposal doesn't mean it will be approved though15:31
cdentdhellmann: the people must exist: the tests are already written, by the service projects15:31
cdentwhat's missing is acceptance that they are competent15:31
dhellmanncdent : I'm not convinced those people know how to manage the tests after they are in use by the trademark program, and I don't think the people to *train* them exist.15:32
mugsieand, as the board has chosen tests, the heat tests are in gabbi, QA refuse to add gabbi based tests, ergo, we cannot add heat tests as written to tempest15:32
cdentwe're going round in circles15:32
TheJuliacdent hit a very valid point that reality has changed15:32
fungijudgement of competence for this purpose is mostly on the interop team though, since they're the ones who have to liaise with the operators/deployers who are running refstack and possibly getting incongruous results from one test version to the next15:34
TheJuliaIt also feels like we're just helping drive conflict amongst ourselves and further delaying the ability of people to execute which comes back to one of the problems as to why we loose contributors.15:34
dhellmannfungi : exactly15:34
mugsieone thing I will say about option 3 is that if things change again in the future, we have already set a precendent that if people ignore what we decide as policy, we will adapt the policy to match what they do later. so why bother setting a policy.15:34
fungipolicy idn't a stick to beat people with, it's an attempt at documenting how our community operates15:35
dhellmannperhaps starting from the beginning and describing what we want the end system to look like would be a way to break out of the circular discussion?15:35
fungiif our community operates in different ways from what our policy states, then our policy is inaccurate15:35
TheJuliafungi: is policy the right word then?15:35
dhellmannmugsie: yes, well, any change in policy at this point may have that effect15:35
mugsieits not a policy then, it is community documentation15:35
TheJuliamugsie: +115:35
fungii expect we inherited the term "policy" from other communities like debian which use it in mostly the same fashion15:35
mugsiea policy is a set of standards we expect people in the community to uphold15:36
fungigenerally in free software communities, community "policy" is a trailing indicator of community behavior, not a leading influence15:36
TheJulia"community standard" "standard procedure" "goals"15:36
persia"Policy follows practice" is a common way to document policy.  Remember that the intended audience for policy is not just the incumbents, but those new to the community (or new to the area covered by policy)15:36
dhellmannin this case the resolution was technical "guidance" on the "future technical direction" aspect of the tests, and the interop team is free to "score" that aspect as they see fit15:36
dhellmannso ignoring the guidance is up to them15:37
mugsiesure, but when a policy has been defined, most communities will follow it until it is changed.15:37
persiaFurther, it is usually considered unsporting for a governance body to establish ex-post-facto policy: so policy only comes into effect when it is passed, and since policy is subject to change, the only difference between writing policy in advance of things happening and in response to things happening is the degree to which the policy authors are engaged with the people doing things.15:38
dhellmann"The TC therefore encourages the DefCore committee to consider it an indication of future technical direction that we do not want tests outside of the Tempest repository used for trademark enforcement"15:38
persiaPersonally, I don't really care how the specific interop item is resolved.  But I don't see a lot of discussion between the teams actually affected: just discussion within the TC (and without TC members disclosing explicit constituencies, so not clearly representing affected teams).15:39
persiaAs a result, I think the best the TC can do is document what the teams apparently decided.  If the teams haven't decided, they probably need to be part of the conversation (which they may be in ways I have not been seeing).15:40
mugsieMy biased summation of conversation so far: Well, QA don't want more review load, or gabbi, InterOp just want this mess to go away, and us to tell them what tests to use, heat want to avoid rewriting tests for the 3rd time, and at this point I just want a decision.15:41
TheJuliaI feel like the question is what will bring the greatest happiness for everyone involved, teams included.15:41
zanebso dhellmann I agree with you to the extent that I think it's pointless to try to make the DefCore committee, who are not under the jurisdiction of the TC, follow our recommendations15:42
dhellmannand what do you think that is?15:42
TheJuliaI think we should create that as a decision matrix and find the best grouping from there.15:42
cdentthat's why I think we need to be somewhat prescriptive, to address the expressed unhappiness15:42
persiamugsie: Understood.  My point is that you need a decision by the teams you mention, as they are the affected body.  Governance is typically by the will of the governed (unless someone has arranged for sufficient prisons).15:42
TheJuliamugsie: I'm kind of at the same peception and point. Ironic would prefer not to move tests again and keep them in a plugin and be able to move forward, but thus far the carrot has felt like it is behind a sheet of glass.15:44
zanebbut I don't agree that it's pointless for us to come up with an organisational and technical framework for the location of trademark tests, based on appropriate technical considerations, and impose that on the technical community (obviously with some sort of consensus on what that would look like)15:44
persiazaneb: Again, I agree with you except your use of "impose" (much like "require" previously).15:45
zanebas a project trying to enter the trademark program, I don't *want* to have to guess where tests should go. I want smarter people than me to have already decided based on their superior knowledge of the requirements15:45
dhellmannzaneb : I agree a framework should exist. I'm not entirely convinced we're the group to specify it, since we're not consuming it.15:45
mugsie is based on a discussion after the friday TC meeting in Dublin, where zaneb, me, mark v, and andreaf talked about an idea jroll posted during the meeting, and is a simplified version of that.15:46
mugsieso we had heat, interop, designate and QA there15:46
cdentthe consumers have said they don't care where they are. the producers, however, have experienced lots of issues they hope _we_ can help resolve15:46
dhellmannI would love to have the interop group publish some documentation that included those details, mugsie15:46
zaneband I definitely don't want to get into a bunfight with another project about where the tests can go, because nobody is in charge and can make a decision15:46
ttxIf it touched on the principles, Im sure we'd react more strongly to violation15:46
ttxThe thing is, TC members don't have a strong opinion on how QA/Interop/ProjectTeam interaction should work15:47
ttxThey just want a solution that is acceptable to all15:47
ttxSo in this case our standing policy was just documenting the trade-off that was found last time15:48
ttxBut since that trade-off does no longer work...15:48
cdentmembers of the tc _do_ have strong opinions, ttx15:48
zanebttx: mugsie posted the review because we thought we *had* found a solution that was acceptable to all15:48
cdentbut the tc itself has not expressed one15:48
fungii'm also slightly concerned that the qa team seems to want to use interest in interop testing as leverage to get more tempest reviewers. that tactic is just as likely to backfire because what they're basically saying is that they lack the bandwidth to review more tests so future interop efforts should stop relying on them to that end15:48
zanebttx: and it is tc members who are trying to break that consensus and substitute a proposal that there is *not* consensus on15:48
ttxcdent: On that topic, I don't have a strong opinion. I just want to find a solution that works for everyone15:48
ttxSo in my case I'm facilitating agreement, rather than push my own opinion on this15:49
persiamugsie: Is your position that refstack, interop, and QA have all endorsed option 2 in 521602, and the TC should not be blocking consensus?15:49
TheJuliafungi: +115:49
cdentttx:  sure, just wanted to correct the over generalization15:49
andreaffungi that's not my personal intention at least15:50
zanebpersia: ok, so have to be careful here because teams are not people...15:50
ttxzaneb: err.. that was not my read... Which solution was acceptable to all and "the tc members are trying to break"15:50
ttx ?15:50
persiazaneb: Understood.  I restricted my review of review comments to folk whose comments indicated they were speaking on behalf of teams and who are identified as important within teams.  I may be mistaken.15:51
ttx(I for one haven't been trying to break anything)15:51
fungiat this point i'd prefer we just say that the interop team can choose tests for whatever capabilities they feel are relevant for deliverables with the tc:approved (or whatever we want to rename it to) tag, and that those tests can be maintained in whatever official deliverable repos teams want as long as the interop team is okay with it and their tooling can consume it, and let the qa team participate15:51
fungiin that process to the extent that they have any available bandwidth to do so15:51
zanebpersia: best summary is this email from andreaf:
zaneb"A group of representatives of the Heat, Designate and Interop teams met15:51
zanebwith the TC and agreed on reviving the resolution started by mugsie in15:51
zaneb to add an alternative to hosting15:51
zanebtests in the Tempest repo. Unfortunately I was only there for the last few15:51
zanebminutes of the meeting, but I understand that the proposal drafted there15:51
zanebwas to allow team to have interop-specific Tempest plugins co-owned by15:51
zanebQA/Interop/add-on project team. mugsie has updated the resolution15:51
zanebaccordingly and I think the discussion on that can continue in gerrit15:51
zanebJust to clarify, nothing has been decided yet, but at least the new15:51
zanebproposal was received positively by all parties involved in the discussion15:51
zanebon Friday." -- andreaf15:52
dhellmannfungi : that was the intent behind
mugsiefungi: which is great, but *will* blow up in our faces when a test breaks an trademark program test15:52
fungimugsie: nope, it won't15:52
fungimugsie: it will blow up in the interop team's faces, perhaps15:52
fungibut ultimately it's their call who they want to trust to procide these tests15:53
fungior whether they want to write the tests themselves15:53
mugsieI would bet that the blow back will end up on the projects15:53
fungieither way, they're taking responsibility for this, as their remit15:53
dhellmannmugsie : I will personally stand in between the project teams and any such blowback.15:53
ttxzaneb: does your quote represent the "consensus" you are saying "tc-members are trying to break" ?15:54
fungiit's not our job to protect teams from responsibilities they expressly take on15:54
mugsiedhellmann: so would I, but I think we should try to avoid the break at all ... but I may just be reaching too far15:54
fungitests _will_ break at some point15:54
mugsiefungi: the same then applies to the QA team who took on all trademark testing15:54
ttxlooks like I missed an episode15:54
mugsiethey expressley took that on15:55
fungimugsie: sure, they can also choose to relinquish that responsibility if they find they no longer have volunteer bandwidth to sustain it15:55
dhellmannmugsie : I would also prefer it not break. The guidance I believe is the best way to avoid it breaking is no longer the way the community wants to approach the problem, and I accept that means we're going to have to change. I think we should take this as an opportunity to clarify who is actually responsible for the *trademark* portion of the situation.15:55
mugsiefungi: not really - we cannot just remove a trademark program when a team  has bandwith issues15:56
persiadhellmann: Absolutely.  Identifying responsible parties will significantly reduce future issues in this area.15:56
zanebttx: yes, that discussion happened after the TC session ended on Friday, and as andreaf said " the new proposal was received positively by all parties involved in the discussion"15:56
fungimugsie: i don't think teams lacking bandwidth to review new tests is equivalent to removing trademark programs15:56
persiaandreaf: Do you feel "all parties" encompasses the teams, or just the people at the table?15:57
ttxzaneb: ok, my impression was that the QA tean was missing from that discussion. If they agree with it too...15:57
andreafpersia people around the table15:57
fungibut also, the board can choose at any time to change how they apply trademarks within the limits specified by the bylaws15:57
zanebnow, to be fair, we had only one member of each team present15:57
ttxzaneb: was there anyone from QA ?15:57
zanebttx: yes, andreaf15:57
mugsiefungi: well, when a team reviews a trademark test they have to test not just supported stable/* branches, but also whatever wierd config some clouds may have who already have the trademark15:58
andreafttx zaneb I don't think I can say I represent the view of everyone in the QA team15:58
mugsiethat requires extra bandwidth15:58
*** dtantsur|brb is now known as dtantsur15:58
zaneband I regret that gmann was surprised by the resolution. in retrospect we should have been more proactive in updating him15:58
zanebon the content of the discussion and the reasons for it15:58
mugsieand if they can't do that, they either have to not write tests, or potentially break a ttrademark program15:58
fungiso even if we ceased to be able to maintain existing interop tests and no new group stepped forward to do so, the board could decide that interoperability testing is not necessary to qualify for a trademark (they'd still be bound by the designated sections/tc approved release stuff because the bylaws would need changes to remove those provisions)15:58
* TheJulia wonders if we've made things so complex that the weight of them is too much to be continued in their present form with distinct teams or groups of people15:59
andreafzaneb I had a chat with gmann during our QA meeting earlier this morning, the main concern I think is the definition of ownership in the resolution15:59
zanebandreaf: yes, that's the point I'm trying to make. it's not like this was signed off by everyone, but it does seem like it's something that all teams could agree on in principle15:59
persiaTheJulia: As soon as "distinct teams" is a thing, that is often true :)15:59
fungimugsie: it feels like you're building a straw man15:59
zanebandreaf: so from my perspective the only special responsibility that comes from 'ownership' in the projects.yaml sense is sign-off on creating new repositories16:00
fungithe only way for us to know for sure how one of these revised models will work out in practice, i think is to agree to try one16:01
andreafEveryone I talked to on the QA team agrees that we will not write the interop tests ourselves - but no-one is concerned about reviewing changes to them (at least at the scale of two projects)16:01
mugsiefungi: e.g. . if this value goes down, it could cause $SLOW_CLOUD to start failing. I know that, because I worked on the tests, but I wont be PTL forever16:01
andreaftbh 90% of the review work for interoperability tests is "do not change it"16:01
mugsieit is not even in a a test that is designate as a trademark one, so reviewers have to trained to look for things like ^16:02
fungimugsie: yes, sounds like a bad test choice16:02
fungifor measuring interoperability16:02
andreafif there is pressure for a change then it becomes getting all relevant parties involved and understand where the need of change come from and make sure everyone is aware of what's going on16:02
zanebandreaf: exactly. and because the interop tests will be segregated in their own repos, there's not even any guesswork to figure which parts not to change (it's everything)16:02
mugsiefungi: like running an ssh command in a nova instance? (That is also an interop test)16:03
fungiandreaf: is the qa team still looking for us to tell the board they can't add new services/capabilities to trademark programs without more volunteers joining the qa team, or would not holding the qa team responsible for reviewing those additions be an acceptable alternative?16:03
fungimugsie: yes16:03
fungimugsie: if the test assumes something about performance which the interoperability specification doesn't, then there's a good chance it will yield inconsistent results16:04
TheJuliaand possibly a reasonable thing to be a knob for the test suite imho16:05
mugsiefungi: and yet ... these were tests that were picked (by both us and InterOp)16:05
andreaffungi I think the bulk of the work would be moving things into Tempest - I don't expect a significant review load increase once tests are settled in their location16:05
ttxso the two competing options are the amended mugsie proposal (allowing additional test location) o[r the simplified version by cdent], and the "let's just say InteropWG should define what they want to work from" approach.16:05
andreaffungi so if we stick to the existing resolution we need more help16:05
fungimugsie: and it's your/their choice which tests you want to support for that. compromises sometimes have to be made for the sake of pragmatism16:06
ttxtrying to make sure I'm up to date16:06
dhellmannttx: I believe that is correct, yes.16:06
pabelangerhow I understand things so far16:06
andreaffungi of course we always could use more contributors - but that's a different conversation16:06
fungiandreaf: but if we don't continue to require interoperability tests to be moved into the tempest repository then you wouldn't seek to have us reduce the tc:approved-release set?16:07
dhellmannfrom what I can tell there seems to be more support for providing a more detailed answer, rather than saying it is up to the interop WG to document their own policies16:07
ttxamended mugsie proposal has some consensus on it from some heat/Designate/Interop/QA folks16:07
ttxwhile the "let's just say InteropWG should define what they want to work from" approach tries to anticipate the next stage, I guess16:07
ttxTheer are two standing -1s on the mugsie amended proposal, so I would not describe it as "consensual"16:08
ttxincluding one from the QA PTL16:09
zanebdhellmann: and fwiw I think it is a fair position to say that that answer doesn't need to be in a TC resolution. but I do believe that we need an answer, and one that has credibility that it will stick16:09
*** david-lyle has quit IRC16:10
andreaffungi I would invest in making the people writing interop tests aware of the implication of reviewing interop tests - that would reduce scale concerns16:10
dhellmannzaneb : yeah, I think we need a resolution to at least declare the old one obsolete16:10
ttxdhellmann: as I said elsewhere, I see the InteropWG-decides approach as a plan B if the other can't get consensus16:10
dhellmannttx: that's fair. I see anything more detailed as another form of guidance, and it's up to the interop WG to decide whether to follow it just like it was with the previous guidance.16:11
ttxzaneb: I'm fine with the mugsie-amended thing if you can get the QA PTL to support it rather than oppose it16:11
zanebdhellmann: right, yeah, but your resolution could be acceptable for that, as long as we have the technical stuff documented somewhere. although I would personally prefer it be documented in the resolution also16:11
zanebttx: yes, that is clearly a prerequisite16:11
andreaffungi rather then reducing the list a priori16:11
ttxbecause simplifying the situation as "we have consensus and teh TC wants to destroy iy" is a bit of an oversimplification16:12
ttxdhellmann: maybe using SHOULD language would make it clearer it's guidance16:14
dhellmannfungi : yeah, I won't be proposing any changes to the tc-approved-release tag at this point. Either way this turns out teams will have the flexibility to put tests somewhere the QA team doesn't have to worry about them, so there's no need.16:14
* mugsie thought we had consensous at least twice in the last 8 or 9 days16:14
dhellmannttx: the previous resolution used the defcore language about "guidance" and "future technical direction"16:14
ttxmugsie: cibsensus is easy when you're not talking to everyone16:14
ttxwow I can't type16:14
fungiultimately, the tc declaring a new (or existing for that matter) directive which at least one of the named constituents isn't going to follow won't really help anyone, so the most we can do is try to help find a compromise which those involved feel like they can agree to follow16:14
ttxI'll try to summarize the status in tomorrow's TC status email16:16
ttxLooks like a busy morning ahead16:16
cdentThe simplified version as I understand things, addresses the concerns of the people who were resistant: tests that go into tempest itself must use only tempest16:16
cdentso people have options16:16
ttxand we haven't been talking about Extended Maintenance yet!16:17
fungiapparently the ops meetup has been though!16:17
dhellmannI'm interested to hear what they had to say about it16:17
*** hongbin has joined #openstack-tc16:19
ttxdhellmann: from reports they echo my concern about making it difficult for some group to step up to extend "ocata"16:19
dhellmanndo they say what they think "ocata" includes?16:19
dhellmannwhich projects do they actually care about, I mean16:19
ttxwhatever the stepping-up group means by that16:19
dhellmannso these are people worried about what other people might be worried about?16:20
dhellmannor are they reluctant to step up themselves?16:20
ttxAFAICT they would prefer to have a clear story, like Ocata is a EM series, Pike is not, Queens is not, Rocky is EM, etc16:20
dhellmannyeah, that's not really a surprise16:21
dhellmannI mean, that's how vendors do it.16:21
ttxI bet smcginnis will have more first-hand reactions16:22
mriedemwhat does "step up" mean?16:23
mriedemwhat is preventing orgs from 'stepping up' today?16:24
*** zhipeng has quit IRC16:24
fungisecond-hand bits and pieces i've heard suggest they're concerned that developers are too tied up in the reputation and ownership of the software they're developing and should be more willing to let others adopt and take over maintenance of it16:24
dhellmannmriedem : I'm not sure. I was trying to differentiate from someone saying "no one will do that" from "I will not do that"16:24
ttxmriedem: the fact that EM is not a thing, first16:24
mriedemttx: what you described above is LTS16:24
mriedemif we pick which releases are going to be "EM"16:25
dhellmannfungi : it's funny how creators become attached to their creations in that way16:25
mriedemit's not just ^16:25
ttxmriedem: without the S16:25
mugsiedhellmann: ++16:25
mriedemit's also that someone goes and backports features or hacks something in an upstream EM stable branch, and they can't upgrade, and all of a sudden they are showing in the nova channel complaining about how they can't upgrade,16:25
dhellmannfungi : it's also a bit disappointing that anyone willing to adopt and maintain it wouldn't consider themselves part of that same team16:25
mriedemor that they are broken on code that the upstream nova team never actually put into that release16:26
mriedemit's basically a fork, as notmyname said16:26
fungidhellmann: yep. hopefully that's not what they're really feeling and we'll get more accurate reporting after the conference16:26
dhellmannmriedem : maybe in any outcome of this we should require upgrade testing16:26
ttxmriedem: one issue is that we are talking about an hypothetical group that would step up if we created a way for them to contribute, but we still don't know who taht would be, so we are all hyopthetizing on what the solution for them should look like16:26
mriedemdoes anyone have any idea if the voices saying they want full control over an EM branch upstream apart from the devs working on the 'supported' stable branches are just a small minority, and the vast majority would just be happy with longer upstream life on the branches, i.e. don't EOL?16:26
mriedemttx: i am not at all interested in building a policy/process for hypothetical contributors that haven't already tried to get involved with stable branch maintenance16:27
mriedemi don't think the tc should be16:27
ttxIf we had a group that said "we sould like to do EM but can't because you don't do $foo yet" the discussion would be simpler16:27
mriedemif this is like 2 orgs that are so backward with forks that they can't upgrade, and they want to be able to just backport features to the branch they are stuck on upstream, then -2 to that16:28
dhellmannmriedem : my theory is that people who might be interested in older branches aren't interested in helping with stable because stable is only dealing with branches they aren't even running yet, so by just extending stable maybe some of those people will show up (without us creating a whole new complicated structure)16:28
mriedemdhellmann: that's fine for me, and is just 'don't EOL anymore'16:28
mriedemwhich is what the resolution is turning into16:28
dhellmannright, that's why I was pushing for that as a first step16:28
mriedemeverything stays basically the same, except don't eol16:29
ttxmriedem: I don't know why you're throwing that "feature backport" scapegoat16:29
mugsiewhich is basically what we said in sydney, right?16:29
persiamriedem: It is at least 4 orgs, and probably more (depending on how many other distros also have long maintenance windows).  Their policies and promises prevent them upgrading.16:29
ttxWe said EM would still follow a common policy16:29
mugsiettx: it has already be said on the review that we should let features go back16:29
mriedemttx: there are people on the review saying they should be able to backport whatever the ywant16:29
ttxmugsie: one individual said that yes, and we said no16:29
ttxon the review ? Missed that16:30
ttx(I was mentioning the Sydney discussion)16:30
mugsie-1 IMO a strict MUST would not work for vendors who strive to backport features or medium bugfixes. Why shall we prohibit what brings prolly the most value for vendors singed to maintain things instead of the official openstack teams?16:30
mugsiefrom the review ^16:30
dhellmannI missed the thing about feature backports, too16:30
mriedemwe also said in sydney that we'd just turn over the core team to whoever wanted to maintain the branch, which we've now flipped on16:31
persiaFor clarity, my arguments in that area were not intended to be in favour of feature backports, but rather to provide an escape valve to avoid folk arguing for feature backports to try to block the proposal as written.16:31
mriedempersia: they can't block it16:31
mriedemif someone -1s saying "i should be able to backport features" we say 'no' and move on16:32
dhellmannmugsie : thanks, I missed that16:32
mriedemif the TC blocks it b/c they want to allow backporting features, that's a different story, but i think the TC is all in agreement that that is not going to happen16:32
dhellmannmriedem : yeah, the original idea of just opening it up was to remove any possible barrier to anyone saying they couldn't contribute. I agree with notmyname that's a bad idea, now, though.16:32
persiamriedem: You and I have different experience of the effect of protracted discussion, possibly involving third parties used as proxies, in delaying, deferring, or cancelling proposed policy.16:32
ttxmriedem: pretty much yes16:33
mriedempersia: i assume you spend a lot more time talking to lawyers than i do :)16:33
dhellmannyeah, I can't see us agreeing to support feature backports16:33
persiamriedem: Very likely, yes :)16:33
mriedemanyway, at this point, i plan on just updating this with simplified wording that says what i've already summarized16:33
mriedemremoving eol being the big thing16:33
persiaI think the TC has been clear about the rules for -em being basically the same as the current stable rules, except for however long people keep trying to submit backports.16:34
ttxI agree with all of it except the idea of project teams vetoing anyone from landing bugfix backports on a given branch16:35
mriedemwhat does vetoing mean?16:36
mriedemthis is the same as any code review process16:36
mriedemif someone proposes a bug fix on an em branch that is clearly a bad idea, the project team can and should -1 it16:36
persiaI think that matters more for the very small number of projects where the project name matches a contributing org's product name.16:36
ttxsure. My point is rejectnig pacthes on a stable branch just because someone decided that this branch should not live.16:36
ttxnot on technical merit16:37
ttxjust as part of a product strategy16:37
dhellmannthey're more likely to pocket veto those anyway, by just not reviewing them, right?16:37
mriedemttx: i haven't heard anyone say they plan on doing that on philosophical grounds16:37
ttxmriedem: they can though16:37
mriedemi guess, that's a pretty dick move though16:37
mriedemand i expect it would be brought to light16:37
fungimy experience would suggest that it's far less likely reviewers would reject backports on aging branches, and more likely they'd just not prioritize reviewing them16:38
mriedemfungi: agree16:38
fungirejecting things is confrontational, and an expenditure of energy16:38
fungieasier to just ignore16:38
persianot prioritising reviewing can be worked around downstream by agreeing on a topic, and having topic landing depend on social norms though, so I think it is less of a problem.16:38
fungiespecially when you already have lots of other things you should be doing, maybe more fun things too16:38
ttxIf we can draw a line that says that patches should only be judged on technical merit... maybe that would work16:39
ttxI just don't want patches to be rejected for political / product-strategy reasons16:39
persiattx: Take care with that: "merit" is a squishy word.16:39
ttxpersia: does it solve a bug ? Is it a good backport ?16:40
persiattx: Much better phrasing.16:40
fungiand given we already have lots of people complaining their proposed changes to master don't get reviewed in a timely manner (or perhaps even at all) i have a hard time believing we're going to see a lot of review bandwidth dedicated to several-years-old branches16:40
ttx*Not" Oh, we'd rather consider Pike dead.16:40
fungibut happy to be proven wrong16:40
persiaThe counterexample is an "open-core" model where some obvious patches are under continual review for various abstract architectural reasons and clearly not because the coincidentally conflict with product (happily, I did not enounter this in OpenStack).16:41
mriedemi don't really want to add that kind of wording into this16:41
mriedemthis is really getting over-thought16:41
TheJuliamriedem: +116:41
mriedemi.e. i don't want to re-define what appropriate fixes are in this resolution, it's just bug fixes16:42
persiaSo, push simplified statement, start with that, and then make other statements as necessary?16:42
mriedemwe soften the phase 3 stuff on -em branches and we don't release them for that reason16:42
TheJuliaseems reasonable16:42
mriedemyes. i will abandon this if it gets to the point of 'see article 3 of declaration VI regarding project foo and their special unicorns'16:43
dhellmannwe could say that if a project team doesn't wish to maintain a branch but someone else does, they must allow a new team to take it over.16:43
fungibetter not to add giodelines for things which should be common sense and respectful of others unless it's demonstrated that we misjudged what common sense is to those involved16:43
mugsiemriedem: branches don't die, no releases post traditional eol, and allow for degrading testing seems a nice easy start16:43
mriedemmugsie: agree16:43
mriedemdhellmann: i don't know about the 'must allow a new team to take it over' stance16:44
ttxdhellmann: that's an option that would surely work for me, but fail the "let then join the stable team if they care' good sides of mriedem's proposal16:44
dhellmannonly under the conditional16:44
mriedemthey should just eol that branch then16:44
persiadhellmann: I believe that is precisely the position that caused the -116:44
ttxmriedem: without specialcasing anyone, I think we could say that stable maint teams are not supposed to reject patches solely based on the branch the backport is targeting16:44
dhellmannpersia : the original proposal was to create separate teams unconditionally16:44
mriedemttx: i'm fine with that clause16:45
ttxLike is a patch is good for O and Q, it should be good for P as well if someone wants it there16:45
mriedemttx: well,16:45
mriedemthat follows the rule that backports go in order16:45
fungiif the original team maintaining a project (or a branch of that project) and also object to a new team taking it over, that's generally fork territory16:45
dhellmannto get to O it would have to land in P, right?16:45
mriedemdhellmann: exactly16:45
* dhellmann checks his alphabet16:45
dhellmannthank you16:45
persiadhellmann: Yes, although I don't see that the existing teams couldn't have been part of the new teams (even with no other members).  I understood the problem to be "don't call my thing foo if we're not still maintaining it"16:45
mriedemif project foo says they do'nt support P, then they drop <=P16:45
fungier, if the original team maintaining a project (or a branch of that project) doesn't want to continue maintaining it and also object to a new team taking it over, that's generally fork territory16:45
* fungi forgot some words the first time16:46
mriedemfungi: yup16:46
dhellmannmriedem : that's a good point16:46
ttxdhellmann: ah? I thought they had to backport to all EM branches, not all branches.16:46
mriedembackports must go in order16:46
dhellmannI think we want them backporting to all relevant branches16:46
mriedemor you break upgrades16:46
persiafungi: I thought the entire point of -em was to provide a collaborative space for the current forks.16:46
fungipersia: it is16:46
ttxi.e if N, O and Q are maintained and someone wants to backport for N they have to backport for O and Q16:47
fungii was following up on the "if a project team doesn't wish to maintain a branch but someone else does" scenario16:47
mriedemso now we're at "branches don't die, no releases post traditional eol, allow for degrading testing, project teams shouldn't block for a branch based on non-technical merit of the proposed backport, and backports MUST go in order"16:47
dhellmannlike if a problem doesn't appear in Q you might only fix it in P and O, but you can't just fix it in P if it applies to O and still claim that P is supported16:47
dhellmannttx: we're saying that you can't claim N and O are supported if P is not also supported16:47
dhellmannmriedem : yes, I think so16:48
fungii expect, at least for now, vmt coverage past traditional eol would likely only be on a best-effort basis16:48
dhellmannand s/supported/maintained/ in my previous statement16:48
mriedemfungi: yes16:48
dhellmannfungi : sure, we probably want the vmt to declare that somewhere but I think that's not going to be too big of a surprise to anyone16:48
ttxAh, hmm..  I see the technical rationale for that, but I see how it can break the ops expectation of some series being EM and some not "Ocata is EM, Pike is not"16:49
dhellmannthe same would go for docs, qa, etc.16:49
fungilike, i don't have confidence that i can research a vulnerability's presence in ancient -em branches, nor confirm that a backported security fix actually addresses the vulnerability there16:49
mriedemttx: we're not picking and choosing branches for EM16:49
mriedemif one project is, then that's on them and they drop support for everything that comes before16:49
mriedemand their users can give them hell w/o the rest of us having to deal with it16:49
fungidhellmann: maybe simply tweaking the vulnerability:managed tag description will be sufficient16:50
fungifor the vmt bit i mean16:50
ttxmriedem: ok. I would make that very clear in the proposal though, since it's not obvious right now16:50
dhellmannfungi : quite likely16:50
TheJuliamriedem raises a good point, each community's users are the drivers and those who need, so ultimately providing the ability to collaborate could help improve things dramatically, as long as the basic principles are adhered to.16:50
fungidhellmann: though we might also transclude or rehash some of that coverage policy in the documentation published to security.o.o too16:50
ttxI'd expect it to trigger "ok, this is not really helping us" ops reaction, but I may be wrong16:50
dhellmannfungi : ++16:51
persiaProviding indication that -em branches do not receive VMT support seems reasonable to me.16:51
TheJuliaSeems reasonable16:51
dhellmannttx: at this point we're not trying to create an EM program. We're trying to open things up so that an EM program can exist when people show up and start trying to work on older branches.16:51
TheJuliaeach community, if they need/want it, can then carry such fixes forward as they need16:51
mriedemttx: "this is not really helping us for <project foo>"16:52
dhellmanndo we think this eliminates the need for driverfixes branches?16:52
mriedemat that point, we say "take it up with project foo"16:52
persiaAbsolutely.  Recruiting folk for -em should not be a goal.  Reaching out to folk *already doing* EM in $dayjob is likely useful.16:52
mriedemdhellmann: i think so16:52
ttxdhellmann: I'm just saying the current phrasing around -em branches does not make it clear that in order to have a ocata-em branch you *have to* have a pike-em and a queens-em branch when the time comes.16:52
mriedem"branches don't die, no releases post traditional eol, allow for degrading testing, project teams shouldn't block for a branch based on non-technical merit of the proposed backport, and backports MUST go in order, and we don't pick and choose EM branches"16:53
mriedem^ amended16:53
TheJuliadhellmann: I think driverfixes may still be needed in some cases because vendors operate on different cadences/schedules, otherwise some things may begin looking like features because it might fix something with new hardware thing16:53
persiattx: I think requiring everything is a sensible place to start.  If the downstreams that need this want to agree on a less common cadence, they can do so, but blocking some or all releases before anyone knows who is participating may be premature.16:54
*** harlowja has joined #openstack-tc16:54
ttxmriedem: that's a clear proposal. At least a good place to start.16:55
mriedem"and cats are better than docs"16:55
ttxEarly on it won't be much of an issue too. Since ocata will be teh only-em for the 1st 6 months16:55
mriedemwe don't have line item veto power do we?16:55
persiamriedem: It's the 'c' key in gerrit.16:55
fungidhellmann: i think dropping phase 3 and just extending phase 2 for the life of the branch elimniates the need for driverfixes branches. they exist mostly because vendors want to backport bug fixes to their drivers which have in the past been seen as nonconforming to stable policy in phase 3 support^Wmaintenance16:56
fungibut as TheJulia says, one person's bug fix is another person's new feature sometimes16:57
TheJuliaand, we all need to be reasonable about it in the end16:57
mriedemi just replied in the review on what i think the phases will be17:00
mriedemsame 3 as we have today - those get released,17:00
mriedemthen a new EM phase which is basically phase 2 wrt appropriate fixes, but not released17:00
mriedemso EM phase is not strictly security/critical fixes,17:00
mriedemlike phase 317:00
mriedembut it's not released either17:00
mriedemreleased == blessed by upstream to me17:00
fungiseems iffy to spend 6 months in phase 3 (only allowing critical and security fixes) only to subsequently relax policy back to an effective phase 2 (allowing general bug fixes) tehreafter17:02
mriedemi think we should start with that,17:02
fungiin the ptg session we'd discussed just dropping phase 3, and there seemed to be some support for that idea17:02
mriedemif it turns out that people are (1) contributing to EM branches and (2) doing so responsibly, then we can look at changes the phase17:02
TheJuliareasonable to me17:03
dimsi like that approach17:03
fungithe idea had been that phase 3 was intended to lead up to closing the branch to new submissions by raising the bar on what backports could qualify, and to reduce the review burden on the (originally centralized) stable core review team17:04
*** david-lyle has joined #openstack-tc17:04
mriedemyes, and it's going to be the same b/c we'll still be doing releases off those17:04
fungibut that the need for phase 3 has declined since decentralizing stable branch maintenance and change reciew17:04
mriedemwe aren't decentralizing17:04
mriedemnot anymore17:04
mriedemwell, maybe i'm not sure what you mean by 'decentralizing'17:05
fungiwe're going back to a common stable-maint team which is responsible for the stable branches of all integrated release projects?17:05
fungithat wasn't my take on this17:05
mriedemwe haven't done that in forever17:05
fungiwe decentralized stable maintenance by adding per-project stable review teams a while back17:05
mriedemthe original proposal was that you'd have your normal stable maint teams per project, and then potentially new core teams for EM branches; that's been rejected17:06
fungiand what i'm saying is that the phases were designed back when there was still just one central team17:06
mriedemfungi: right so we still have the global central team, and per-project teams17:06
fungibut that phase 3 seems less relevant now that we have per-project stable review teams17:06
mriedemyeah i see what you're saying17:06
mriedemphase 3 is very much tied to eol,17:07
fungiand may not need to be as protective of their review bandwidth (especially if we're expecting mostly the same set of reviewers to be caring for those branches during extended maintenance as well)17:07
mriedemi know i am extra cautious about approving backports on the oldest branch for fear of a regression being found after we eol the branch17:07
mriedemso we'd instead be proposing that phase 1 is 6 months, phase 2 + releases is 1 year, and then EM is everything after with no releases?17:08
fungithat was what i took away from the discussion at the ptg17:08
fungibut maybe others remember it differently. we only talked about changes to phases very briefly so perhaps it wasn't as consensual as i thought17:09
mriedemi'm amenable to that if others are17:09
mriedemi don't remember much talk about it on tuesday17:09
mriedemmaybe it was in the secret TC room where the sacrifices happened17:09
mriedemaka the breakfast bar17:09
mriedemi'll wordsmith that up17:10
fungii'm pretty sure i remember tonyb saying he was okay with dropping phase 3 and just continuing phase 2 for better continuity with extended maintenance patch policy later, but it's easy for me to put words in his mouth while he's asleep17:10
ttxmriedem: that was the release cycle room on Tuesday afternoon17:10
mriedemfungi: i'll work it into the resolution17:10
ttxoops ignore me misread you17:10
ttxprobably means it's time for me to step away from the computer17:11
dimsthanks for driving this resolution mriedem17:11
fungithe other thing we said was that our current stable policy is a little too proscriptive, and perhaps would be better positioned as an ietf "should" instead of "must"17:11
persiaDescribing it as 6 months phase I, 12 months phase II, -em after seems easy to swallow.17:12
fungibasically the stable review teams may currently have the impression that they don't possess latitude in determining extenuating circumstances for some fixes17:12
mriedemdims: i do it for the love of the children17:13
mriedemyou know me17:13
fungiyou know, for kids17:13
mriedemfungi: that's something to propose separately for the actual guidelines imo17:13
mriedemthis came up in the ops ML from zioproto17:13
mriedemand i pointed out that the docs do say it's ultimately up to the discretion of the project core team17:14
mriedembut people apparently don't read the fine print17:14
mriedemi know persia does :)17:14
persiamriedem: To be fair, sometimes I read the fine print in order to ignore it.17:14
fungimriedem: yep, i agree that's a separate change, just recapping things we talked about that may have been forgotten in the snow17:15
mriedemthere is an itunes agreement joke in here somewhere17:15
*** jpich has quit IRC17:16
ttxpersia actually only reads the fine prints.17:17
* fungi reads the fine manual17:22
*** rosmaita has quit IRC17:35
TheJuliaWait, are there people that do not read the fine print?17:45
funginope, just sheep17:50
*** dtantsur is now known as dtantsur|afk17:53
*** clarkb has joined #openstack-tc17:58
* harlowja is just sheep18:22
harlowjabut like a fire-breathing sheep18:23
*** harlowja has quit IRC18:26
*** david-lyle has quit IRC18:56
*** cdent has quit IRC18:56
*** harlowja has joined #openstack-tc19:11
*** harlowja has quit IRC19:18
*** harlowja has joined #openstack-tc19:33
*** dtk has joined #openstack-tc19:37
openstackgerritMatt Riedemann proposed openstack/governance master: Add a resolution about stable branch EOL and "extended maintenance"
mriedemding ding ^19:41
*** dtk has quit IRC19:44
*** dtk has joined #openstack-tc19:47
* persia doesn't find anything to complain about this time19:47
*** dtk has quit IRC20:10
*** dtk has joined #openstack-tc20:11
dimsmriedem : you broke persia! fix it20:13
* dims reading20:13
persiadims: Have no fear: I have lots of other things I can complain about: I just think the latest draft is an accurate summary of discussion, and no longer feel that my unaddressed complaints are going to reach consensus.20:19
dimsmriedem : so in the "Core teams" section ... some teams (at least some folks on some existing teams) do not want to pick up the burden. how do we handle that situation?20:24
mriedemwell, they could eol the branch, but that's not good for the people that want it to live for longer20:25
mriedemthey could add people to the stable core team that actually do want to take up the maintenance20:26
mriedemi think the latter is probably the answer20:26
dimsmriedem : can you please add a sentence to that effect?20:26
dimsmriedem : it came up in keystone meeting20:27
mriedemleave a note in the review20:27
dimsack thanks20:27
dimsleft another note20:40
mriedemdims: replied20:41
mriedemgiven what's written, i don't really want to add caveats20:41
mriedemor special case every situation20:42
dimsack thanks20:42
mriedemand to your other20:47
mriedemi'm not worried about people that want everything for free or to do what they want wrt backporting features20:47
mriedemthat's called a fork and they are on their own20:47
dimsagree. not evangelizing for those, just for the record that we considered those points and still stuck to what we think is the right thing to do.20:50
dimsnice work again!20:51
*** david-lyle has joined #openstack-tc21:07
persiaI still think it makes sense to have a playground for folk who want to backport features, but until those folk stand up and say "we want to backport features, and we want to do it in OpenStack, and we're engaged enough with the teams to know why this would sound silly, and we want to do it anyway, and there are enough of us", it doesn't seem worth making any effort to help them.21:08
*** david-lyle has quit IRC21:45
tonybActually I was suggesting that we have Phase I whiel everything is good, and then we drop to Phase II as CI for $project is gettign difficult and/or project teams start to loose interest and then -em after that, with Phase II being about 6 months to as a warning sign22:23
tonybbut the proposal from ~5 hours ago is better structured for now and simplier to implement22:23
persiatonyb: We'll have to wait to see if people show up, but I suspect that if they do, it will be feasible to get them to take over during the second half of Phase II (otherwise the prospect of reaching extended maintenance is bleak)22:30
*** annabelleB has joined #openstack-tc22:32
*** david-lyle has joined #openstack-tc22:32
*** annabelleB has quit IRC22:33
*** annabelleB has joined #openstack-tc22:34
*** kumarmn_ has joined #openstack-tc22:39
tonybpersia: Yup.  If we can get the resolution sorted we can call for help with Ocata22:40
*** kumarmn has quit IRC22:42
fungiand it makes sense for the patch appropriateness during -em to be roughly equivalent to that for stage ii22:47
mriedemthe phase 2 guideline is a bit strict today - it says critical and security fixes,22:56
mriedembut i know we merge backports in phase 2 that aren't 'critical' or security fixes22:56
mriedemjust regular ol bug fixes that are low risk22:56
mriedemwhich is also what people are going to want in EM mode22:56
dhellmannmriedem : maybe we should clarify that policy concurrently with this other change?22:58
mriedemi just don't want to complicate this too much23:00
dhellmannyeah, I just meant "around the same time"23:00
dhellmann"cooperative multitasking" not "parallelism"23:00
mriedemit's also why i put the thing in ps2 about "while we have guidelines, what's appropriate is up to the discretion of the core team based on risk vs reward of the patch itself"23:00
mriedemtried to hedge bets there a bit23:00
dhellmannwe could even link to the project team guide stable guidelines there, if you aren't already23:01
mriedemi did23:01
mriedembut people only read the table, they don't read further down saying it's up to the team23:01
dhellmannwe can lead a horse to water...23:02
smcginnisThat's probably OK. It's better they assume things are more restrictive than they actually are.23:02
mriedemand then drown said horse23:02
* dhellmann does not advocate drowning horses23:02
smcginnisPoor little horse.23:02
dhellmannsmcginnis : maybe. if it means they continue to not contribute, I'm not sure it does us much good.23:02
mriedemwhere do you think ttx gets all his delicious horse meat in france?23:03
smcginnisdhellmann: Good point, that could be the down side.23:03
dhellmannbut one change at a time23:03
mriedembtw this is the thread from zioproto that i keep thinking of
fungiat the ptg we did talk about "loosening" the stable branch review guidelines to make it more obvious they're a malleable suggestion and not a demand of rigorous adherence23:06
dhellmannmriedem : ah, yeah, I remember that thread23:07
fungiseems so long ago... january23:07
smcginnisAncient history.23:07
*** mriedem has quit IRC23:23
*** annabelleB has quit IRC23:24
*** kumarmn_ has quit IRC23:29

Generated by 2.15.3 by Marius Gedminas - find it at!