| *** mriedem has quit IRC | 00:05 | |
| *** annabelleB has joined #openstack-tc | 00:15 | |
| *** lbragstad has quit IRC | 00:39 | |
| *** david-lyle has quit IRC | 00:53 | |
| *** david-lyle has joined #openstack-tc | 00:56 | |
| *** notmyname has quit IRC | 01:02 | |
| *** notmyname has joined #openstack-tc | 01:03 | |
| *** annabelleB has quit IRC | 01:55 | |
| *** david-lyle has quit IRC | 01:57 | |
| *** annabelleB has joined #openstack-tc | 02:00 | |
| *** diablo_rojo has quit IRC | 02:25 | |
| *** harlowja has quit IRC | 02:49 | |
| *** diablo_rojo has joined #openstack-tc | 02:50 | |
| *** annabelleB has quit IRC | 03:02 | |
| *** annabelleB has joined #openstack-tc | 03:07 | |
| *** annabelleB has quit IRC | 03:47 | |
| *** annabelleB has joined #openstack-tc | 03:50 | |
| *** harlowja has joined #openstack-tc | 04:37 | |
| *** kumarmn has quit IRC | 04:57 | |
| *** pabelanger has quit IRC | 04:58 | |
| *** gcb has joined #openstack-tc | 05:02 | |
| *** kumarmn has joined #openstack-tc | 05:03 | |
| *** harlowja has quit IRC | 06:05 | |
| *** david-lyle has joined #openstack-tc | 06:09 | |
| *** dims has quit IRC | 06:24 | |
| *** dims has joined #openstack-tc | 06:30 | |
| *** annabelleB has quit IRC | 06:33 | |
| *** annabelleB has joined #openstack-tc | 06:46 | |
| *** ykarel has joined #openstack-tc | 06:51 | |
| *** ykarel has quit IRC | 07:40 | |
| *** annabelleB has quit IRC | 08:14 | |
| ttx | wow wall of text | 08:40 |
|---|---|---|
| ttx | Two 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 downstream | 08:41 |
| ttx | which obviously did not happen | 08:41 |
| ttx | And 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 IRC | 08:43 | |
| *** annabelleB has joined #openstack-tc | 08:43 | |
| ttx | which means the interop program is less necessary as an interoperability-driving tool (its trademark usage gatekeeper usefullness remains) | 08:44 |
| *** dtantsur has joined #openstack-tc | 08:50 | |
| *** jpich has joined #openstack-tc | 08:54 | |
| *** annabelleB has quit IRC | 08:56 | |
| *** dtantsur has quit IRC | 09:01 | |
| *** dtantsur has joined #openstack-tc | 09:06 | |
| *** dtantsur has quit IRC | 09:31 | |
| *** dtantsur has joined #openstack-tc | 09:38 | |
| *** pabelanger has joined #openstack-tc | 09:41 | |
| *** cdent has joined #openstack-tc | 09:47 | |
| *** cdent has quit IRC | 10:03 | |
| *** gcb has quit IRC | 10:46 | |
| *** gcb has joined #openstack-tc | 10:49 | |
| *** cdent has joined #openstack-tc | 11:27 | |
| *** pabelanger_ has joined #openstack-tc | 12:27 | |
| *** pabelanger has quit IRC | 12:29 | |
| *** zhipeng has joined #openstack-tc | 12:55 | |
| *** annabelleB has joined #openstack-tc | 13:09 | |
| *** pabelanger_ is now known as pabelanger | 13:10 | |
| *** jpich has quit IRC | 13:21 | |
| *** jpich has joined #openstack-tc | 13:22 | |
| *** kumarmn has quit IRC | 13:32 | |
| *** kumarmn has joined #openstack-tc | 13:33 | |
| *** kumarmn has quit IRC | 13:37 | |
| *** mriedem has joined #openstack-tc | 13:45 | |
| *** rosmaita has joined #openstack-tc | 13:47 | |
| *** kumarmn has joined #openstack-tc | 13:54 | |
| *** kumarmn has quit IRC | 13:54 | |
| *** kumarmn has joined #openstack-tc | 13:54 | |
| *** lbragstad has joined #openstack-tc | 13:54 | |
| *** annabelleB has quit IRC | 14:03 | |
| *** dtantsur is now known as dtantsur|brb | 14:05 | |
| *** dtk has quit IRC | 14:36 | |
| *** dtk has joined #openstack-tc | 14:37 | |
| *** dtk has quit IRC | 14:45 | |
| fungi | well, trademark programs are also the signal we use as a community to communicate the importance we place on interoperability | 14:46 |
| fungi | "not interoperable (per our standards)? then you can't call it openstack!" | 14:47 |
| cdent | that was an awesome long distance context switch | 14:47 |
| persia | Indeed, thinking about trademark-program-as-tool is easier than thinking about social-model-to-support-abstract-program. | 14:49 |
| persia | The Mozilla Foundation trademark program related to "Firefox" is a lovely example of using trademarks in that way. | 14:49 |
| *** melwitt has quit IRC | 14:59 | |
| cdent | tc-members and others assemble | 15:00 |
| EmilienM | o/ (with my 10 fingers) | 15:01 |
| cdent | I was going to suggest we talk about the trademark tests but: https://twitter.com/anticdent/status/971761014676115457 | 15:01 |
| * fungi shakes off the morning and grabs more caffeine | 15:01 | |
| ttx | o/ | 15:01 |
| * cdent shakes huge thumb at EmilienM | 15:01 | |
| cdent | so I'm gonna focus on listening | 15:01 |
| pabelanger | hello | 15:01 |
| * ttx was lost updating himself on Riot/Matrix status | 15:02 | |
| pabelanger | I also wanted to confirm no members had issues with https://wiki.openstack.org/wiki/Release_Naming/S_Proposals proposed names and prepare for the formal vote next week | 15:02 |
| dhellmann | o/ | 15:02 |
| ttx | I'll post a summary of the TC Friday PTG room in the weekly status tomorrow | 15:03 |
| ttx | or at least that's the plan | 15:03 |
| persia | Good day. I would like to change some wording on https://governance.openstack.org/tc/reference/charter.html , 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 |
| mriedem | persia: i think we're talking past each other on https://review.openstack.org/#/c/548916/ | 15:04 |
| persia | Does anyone have specific suggestions on whose authorisation is required for such a change, or the best practice for doing so? | 15:04 |
| ttx | persia: charter change process is described... in the charter | 15:04 |
| persia | mriedem: My apologies if my last comment did not read "please ignore this subthread" loudly enough. | 15:04 |
| mriedem | maybe i should just update this resolution proposal today with new fangled stuff and then we can rathole on the new thing | 15:04 |
| mriedem | persia: i'm a simple man with simple tastes, you need to dumb it down for me :) | 15:05 |
| ttx | persia: https://governance.openstack.org/tc/reference/charter.html#amendment | 15:05 |
| persia | ttx: So use code review, and it needs 9 roll-call votes? | 15:05 |
| ttx | which means code review approved by 2/3 of the members | 15:05 |
| ttx | yes | 15:05 |
| persia | ttx: Thanks for the clarification. | 15:05 |
| ttx | One 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/motions | 15:06 |
| ttx | A task tracker could be used | 15:06 |
| *** melwitt has joined #openstack-tc | 15:06 | |
| cdent | granular goals, something like that? | 15:07 |
| *** melwitt is now known as Guest70075 | 15:07 | |
| ttx | yeah, basically tracking the various headlines on that etherpad more often than once every 3 months at Forums and PTGs | 15:07 |
| mriedem | task tracker? like...storyboard? | 15:08 |
| mriedem | oh the irony | 15:08 |
| ttx | mriedem: Oh! Excellent suggestion! | 15:08 |
| * ttx whistles innocently | 15:08 | |
| persia | https://storyboard.openstack.org/#!/story/list?status=active&project_id=923 might be a reasonable place to put things | 15:09 |
| cmurphy | o/ | 15:10 |
| ttx | Happy to go ahead and create things there if we collectively think it's a good idea | 15:10 |
| dhellmann | wfm | 15:11 |
| pabelanger | persia: neat, didn't know that was a thing yet | 15:11 |
| ttx | pabelanger: that's what we use for tracking goals now | 15:11 |
| openstackgerrit | Graham Hayes proposed openstack/governance master: Update Trademark test locations https://review.openstack.org/550863 | 15:11 |
| fungi | yeah, we did that so goals tracking had a place to land | 15:11 |
| persia | pabelanger: 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 repo | 15:12 | |
| dhellmann | and not the goals | 15:12 |
| pabelanger | ttx: ++ | 15:12 |
| dhellmann | oh, 1565 results | 15:12 |
| persia | dhellmann: 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 |
| dhellmann | ah | 15:12 |
| cdent | so 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 |
| TheJulia | ++ | 15:16 |
| persia | For those interested, https://review.openstack.org/548343 is the project-name issue, and https://review.openstack.org/548058 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 |
| TheJulia | Part of the reason I'm hoping to get ironic over is that as well | 15:17 |
| * ttx reads latest developments on the EM proposal and the Interop proposal | 15:19 | |
| mugsie | there 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 from | 15:20 |
| ttx | Not sure that brings us closer to a solution though... Gerrit is notoriously bad to discuss choosing one of 3 proposals | 15:21 |
| cdent | thanks for doing that mugsie. have dropped my -1 on that third one for the reasons we discussed | 15:22 |
| mugsie | cdent: yup, I agree with you, but I wanted people to have the option | 15:22 |
| cdent | yup, which is what I said in my review | 15:23 |
| TheJulia | I'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 |
| fungi | specific 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 |
| fungi | voting within an n-dimensional matrix seems... hard | 15:25 |
| dhellmann | cdent : 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 |
| TheJulia | or each tc member gets one vote on the topic to pair it down? | 15:25 |
| cdent | fungi: That problem is probably easier to solve simply by humans trying a bit harder despite limits of tools | 15:26 |
| mugsie | I think cdent's simplified version is just a better, shorter version of my long winded one | 15:26 |
| fungi | cdent: so answer is "try harder next time" | 15:26 |
| fungi | got it ;) | 15:26 |
| cdent | dhellmann: 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 |
| cdent | punting to interop will not fix the real problems | 15:27 |
| cdent | nor provide any reduction in complexity for projects (one, but only one, of the problems) | 15:27 |
| dhellmann | isn't the problem that we tried to over-specify the answer to this in the first place? | 15:27 |
| cdent | that may be one of the problems | 15:28 |
| cdent | but there are others | 15:28 |
| cdent | under-resourced groups | 15:28 |
| cdent | under-trained people | 15:28 |
| mugsie | dhellmann: I don't think so, I think the problem was that people thought they could just ignore what we wrote | 15:28 |
| cdent | social conflicts | 15:28 |
| dhellmann | mugsie : yes, well, that is certainly one | 15:28 |
| cdent | lack of alacrity in changing our policies when facing new realities | 15:29 |
| fungi | what we wrote was also a catch-22 | 15:29 |
| dhellmann | cdent : 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 |
| mugsie | fungi: not really, we didn't say tests couldn't be in tempest, that was thq QA team | 15:29 |
| fungi | if 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-22 | 15:29 |
| dhellmann | that either gives them the mandate to do it, or exposes that they aren't really there in the first place | 15:29 |
| cdent | dhellmann: 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 people | 15:30 |
| mugsie | if 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 ago | 15:30 |
| dhellmann | I 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 |
| fungi | so 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 approved | 15:30 |
| cdent | dhellmann: in case you missed it at the start of the office-hour I'm a bit slow to keep up: https://twitter.com/anticdent/status/971761014676115457 | 15:30 |
| fungi | or we could say that tests can be selected for a trademark program in advance of them being added to tempest | 15:30 |
| mugsie | fungi: QA do not want to expand the scope of tempest | 15:31 |
| mugsie | ever | 15:31 |
| dhellmann | fungi : what should have happened is when the tests were selected for a draft proposal they were accepted into tempest | 15:31 |
| fungi | a draft proposal doesn't mean it will be approved though | 15:31 |
| cdent | dhellmann: the people must exist: the tests are already written, by the service projects | 15:31 |
| cdent | what's missing is acceptance that they are competent | 15:31 |
| dhellmann | cdent : 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 |
| mugsie | and, 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 tempest | 15:32 |
| cdent | we're going round in circles | 15:32 |
| TheJulia | indeed | 15:32 |
| TheJulia | cdent hit a very valid point that reality has changed | 15:32 |
| fungi | judgement 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 next | 15:34 |
| TheJulia | It 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 |
| dhellmann | fungi : exactly | 15:34 |
| mugsie | one 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 |
| fungi | policy idn't a stick to beat people with, it's an attempt at documenting how our community operates | 15:35 |
| dhellmann | perhaps 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 |
| fungi | if our community operates in different ways from what our policy states, then our policy is inaccurate | 15:35 |
| TheJulia | fungi: is policy the right word then? | 15:35 |
| dhellmann | mugsie: yes, well, any change in policy at this point may have that effect | 15:35 |
| mugsie | its not a policy then, it is community documentation | 15:35 |
| TheJulia | mugsie: +1 | 15:35 |
| fungi | i expect we inherited the term "policy" from other communities like debian which use it in mostly the same fashion | 15:35 |
| mugsie | a policy is a set of standards we expect people in the community to uphold | 15:36 |
| fungi | generally in free software communities, community "policy" is a trailing indicator of community behavior, not a leading influence | 15: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 |
| dhellmann | in 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 fit | 15:36 |
| dhellmann | so ignoring the guidance is up to them | 15:37 |
| mugsie | sure, but when a policy has been defined, most communities will follow it until it is changed. | 15:37 |
| persia | Further, 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 |
| persia | Personally, 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 |
| persia | As 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 |
| mugsie | My 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 |
| TheJulia | I feel like the question is what will bring the greatest happiness for everyone involved, teams included. | 15:41 |
| cdent | TheJulia++ | 15:41 |
| zaneb | so 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 recommendations | 15:42 |
| dhellmann | and what do you think that is? | 15:42 |
| TheJulia | I think we should create that as a decision matrix and find the best grouping from there. | 15:42 |
| cdent | that's why I think we need to be somewhat prescriptive, to address the expressed unhappiness | 15:42 |
| persia | mugsie: 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 |
| TheJulia | mugsie: 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 |
| zaneb | but 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 |
| persia | zaneb: Again, I agree with you except your use of "impose" (much like "require" previously). | 15:45 |
| zaneb | as 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 requirements | 15:45 |
| dhellmann | zaneb : 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 | https://review.openstack.org/521602 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 https://review.openstack.org/550571 is a simplified version of that. | 15:46 |
| mugsie | so we had heat, interop, designate and QA there | 15:46 |
| cdent | the consumers have said they don't care where they are. the producers, however, have experienced lots of issues they hope _we_ can help resolve | 15:46 |
| dhellmann | I would love to have the interop group publish some documentation that included those details, mugsie | 15:46 |
| zaneb | and 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 decision | 15:46 |
| ttx | If it touched on the principles, Im sure we'd react more strongly to violation | 15:46 |
| ttx | The thing is, TC members don't have a strong opinion on how QA/Interop/ProjectTeam interaction should work | 15:47 |
| ttx | They just want a solution that is acceptable to all | 15:47 |
| ttx | So in this case our standing policy was just documenting the trade-off that was found last time | 15:48 |
| ttx | But since that trade-off does no longer work... | 15:48 |
| cdent | members of the tc _do_ have strong opinions, ttx | 15:48 |
| zaneb | ttx: mugsie posted the review because we thought we *had* found a solution that was acceptable to all | 15:48 |
| cdent | but the tc itself has not expressed one | 15:48 |
| cdent | zaneb++ | 15:48 |
| fungi | i'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 end | 15:48 |
| zaneb | ttx: and it is tc members who are trying to break that consensus and substitute a proposal that there is *not* consensus on | 15:48 |
| ttx | cdent: On that topic, I don't have a strong opinion. I just want to find a solution that works for everyone | 15:48 |
| ttx | So in my case I'm facilitating agreement, rather than push my own opinion on this | 15:49 |
| ttx | YMMV | 15:49 |
| persia | mugsie: 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 |
| TheJulia | fungi: +1 | 15:49 |
| cdent | ttx: sure, just wanted to correct the over generalization | 15:49 |
| andreaf | fungi that's not my personal intention at least | 15:50 |
| zaneb | persia: ok, so have to be careful here because teams are not people... | 15:50 |
| ttx | zaneb: 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 |
| persia | zaneb: 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 |
| fungi | at 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 participate | 15:51 |
| fungi | in that process to the extent that they have any available bandwidth to do so | 15:51 |
| zaneb | persia: best summary is this email from andreaf: http://lists.openstack.org/pipermail/openstack-dev/2018-March/127999.html | 15:51 |
| zaneb | "A group of representatives of the Heat, Designate and Interop teams met | 15:51 |
| zaneb | with the TC and agreed on reviving the resolution started by mugsie in | 15:51 |
| zaneb | https://review.openstack.org/#/c/521602 to add an alternative to hosting | 15:51 |
| zaneb | tests in the Tempest repo. Unfortunately I was only there for the last few | 15:51 |
| zaneb | minutes of the meeting, but I understand that the proposal drafted there | 15:51 |
| zaneb | was to allow team to have interop-specific Tempest plugins co-owned by | 15:51 |
| zaneb | QA/Interop/add-on project team. mugsie has updated the resolution | 15:51 |
| zaneb | accordingly and I think the discussion on that can continue in gerrit | 15:51 |
| zaneb | directly. | 15:51 |
| zaneb | Just to clarify, nothing has been decided yet, but at least the new | 15:51 |
| zaneb | proposal was received positively by all parties involved in the discussion | 15:51 |
| zaneb | on Friday." -- andreaf | 15:52 |
| dhellmann | fungi : that was the intent behind https://review.openstack.org/#/c/550863/ | 15:52 |
| mugsie | fungi: which is great, but *will* blow up in our faces when a test breaks an trademark program test | 15:52 |
| fungi | mugsie: nope, it won't | 15:52 |
| fungi | mugsie: it will blow up in the interop team's faces, perhaps | 15:52 |
| fungi | but ultimately it's their call who they want to trust to procide these tests | 15:53 |
| fungi | or whether they want to write the tests themselves | 15:53 |
| mugsie | I would bet that the blow back will end up on the projects | 15:53 |
| fungi | either way, they're taking responsibility for this, as their remit | 15:53 |
| dhellmann | mugsie : I will personally stand in between the project teams and any such blowback. | 15:53 |
| ttx | zaneb: does your quote represent the "consensus" you are saying "tc-members are trying to break" ? | 15:54 |
| fungi | it's not our job to protect teams from responsibilities they expressly take on | 15:54 |
| mugsie | dhellmann: so would I, but I think we should try to avoid the break at all ... but I may just be reaching too far | 15:54 |
| fungi | tests _will_ break at some point | 15:54 |
| mugsie | fungi: the same then applies to the QA team who took on all trademark testing | 15:54 |
| ttx | looks like I missed an episode | 15:54 |
| mugsie | they expressley took that on | 15:55 |
| fungi | mugsie: sure, they can also choose to relinquish that responsibility if they find they no longer have volunteer bandwidth to sustain it | 15:55 |
| dhellmann | mugsie : 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 |
| mugsie | fungi: not really - we cannot just remove a trademark program when a team has bandwith issues | 15:56 |
| persia | dhellmann: Absolutely. Identifying responsible parties will significantly reduce future issues in this area. | 15:56 |
| zaneb | ttx: 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 |
| fungi | mugsie: i don't think teams lacking bandwidth to review new tests is equivalent to removing trademark programs | 15:56 |
| persia | andreaf: Do you feel "all parties" encompasses the teams, or just the people at the table? | 15:57 |
| ttx | zaneb: ok, my impression was that the QA tean was missing from that discussion. If they agree with it too... | 15:57 |
| andreaf | persia people around the table | 15:57 |
| fungi | but also, the board can choose at any time to change how they apply trademarks within the limits specified by the bylaws | 15:57 |
| zaneb | now, to be fair, we had only one member of each team present | 15:57 |
| ttx | zaneb: was there anyone from QA ? | 15:57 |
| zaneb | ttx: yes, andreaf | 15:57 |
| mugsie | fungi: 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 trademark | 15:58 |
| andreaf | ttx zaneb I don't think I can say I represent the view of everyone in the QA team | 15:58 |
| mugsie | that requires extra bandwidth | 15:58 |
| *** dtantsur|brb is now known as dtantsur | 15:58 | |
| zaneb | and I regret that gmann was surprised by the resolution. in retrospect we should have been more proactive in updating him | 15:58 |
| zaneb | on the content of the discussion and the reasons for it | 15:58 |
| mugsie | and if they can't do that, they either have to not write tests, or potentially break a ttrademark program | 15:58 |
| fungi | so 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 people | 15:59 | |
| andreaf | zaneb 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 resolution | 15:59 |
| zaneb | andreaf: 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 principle | 15:59 |
| persia | TheJulia: As soon as "distinct teams" is a thing, that is often true :) | 15:59 |
| fungi | mugsie: it feels like you're building a straw man | 15:59 |
| zaneb | andreaf: so from my perspective the only special responsibility that comes from 'ownership' in the projects.yaml sense is sign-off on creating new repositories | 16:00 |
| fungi | the 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 one | 16:01 |
| andreaf | Everyone 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 |
| mugsie | fungi: e.g. https://github.com/openstack/designate-tempest-plugin/blob/master/designate_tempest_plugin/config.py#L40-L42 . 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 forever | 16:01 |
| andreaf | tbh 90% of the review work for interoperability tests is "do not change it" | 16:01 |
| mugsie | it 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 |
| fungi | mugsie: yes, sounds like a bad test choice | 16:02 |
| mugsie | designated* | 16:02 |
| fungi | for measuring interoperability | 16:02 |
| andreaf | if 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 on | 16:02 |
| zaneb | andreaf: 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 |
| mugsie | fungi: like running an ssh command in a nova instance? (That is also an interop test) | 16:03 |
| fungi | andreaf: 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 |
| fungi | mugsie: yes | 16:03 |
| fungi | mugsie: if the test assumes something about performance which the interoperability specification doesn't, then there's a good chance it will yield inconsistent results | 16:04 |
| TheJulia | and possibly a reasonable thing to be a knob for the test suite imho | 16:05 |
| mugsie | fungi: and yet ... these were tests that were picked (by both us and InterOp) | 16:05 |
| andreaf | fungi 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 location | 16:05 |
| ttx | so 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 |
| andreaf | fungi so if we stick to the existing resolution we need more help | 16:05 |
| fungi | mugsie: and it's your/their choice which tests you want to support for that. compromises sometimes have to be made for the sake of pragmatism | 16:06 |
| ttx | trying to make sure I'm up to date | 16:06 |
| dhellmann | ttx: I believe that is correct, yes. | 16:06 |
| pabelanger | how I understand things so far | 16:06 |
| andreaf | fungi of course we always could use more contributors - but that's a different conversation | 16:06 |
| fungi | andreaf: 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 |
| dhellmann | from 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 policies | 16:07 |
| ttx | amended mugsie proposal has some consensus on it from some heat/Designate/Interop/QA folks | 16:07 |
| ttx | while the "let's just say InteropWG should define what they want to work from" approach tries to anticipate the next stage, I guess | 16:07 |
| ttx | Theer are two standing -1s on the mugsie amended proposal, so I would not describe it as "consensual" | 16:08 |
| ttx | including one from the QA PTL | 16:09 |
| zaneb | dhellmann: 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 stick | 16:09 |
| *** david-lyle has quit IRC | 16:10 | |
| andreaf | fungi I would invest in making the people writing interop tests aware of the implication of reviewing interop tests - that would reduce scale concerns | 16:10 |
| dhellmann | zaneb : yeah, I think we need a resolution to at least declare the old one obsolete | 16:10 |
| ttx | dhellmann: as I said elsewhere, I see the InteropWG-decides approach as a plan B if the other can't get consensus | 16:10 |
| dhellmann | ttx: 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 |
| ttx | zaneb: I'm fine with the mugsie-amended thing if you can get the QA PTL to support it rather than oppose it | 16:11 |
| zaneb | dhellmann: 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 also | 16:11 |
| zaneb | ttx: yes, that is clearly a prerequisite | 16:11 |
| andreaf | fungi rather then reducing the list a priori | 16:11 |
| ttx | because simplifying the situation as "we have consensus and teh TC wants to destroy iy" is a bit of an oversimplification | 16:12 |
| TheJulia | heh | 16:12 |
| ttx | it* | 16:12 |
| ttx | dhellmann: maybe using SHOULD language would make it clearer it's guidance | 16:14 |
| dhellmann | fungi : 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 days | 16:14 | |
| dhellmann | ttx: the previous resolution used the defcore language about "guidance" and "future technical direction" | 16:14 |
| ttx | mugsie: cibsensus is easy when you're not talking to everyone | 16:14 |
| ttx | wow I can't type | 16:14 |
| fungi | ultimately, 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 follow | 16:14 |
| dhellmann | uses* | 16:14 |
| ttx | consensus | 16:14 |
| ttx | I'll try to summarize the status in tomorrow's TC status email | 16:16 |
| ttx | Looks like a busy morning ahead | 16:16 |
| cdent | The simplified version as I understand things, addresses the concerns of the people who were resistant: tests that go into tempest itself must use only tempest | 16:16 |
| cdent | so people have options | 16:16 |
| ttx | and we haven't been talking about Extended Maintenance yet! | 16:17 |
| fungi | apparently the ops meetup has been though! | 16:17 |
| dhellmann | I'm interested to hear what they had to say about it | 16:17 |
| *** hongbin has joined #openstack-tc | 16:19 | |
| ttx | dhellmann: from reports they echo my concern about making it difficult for some group to step up to extend "ocata" | 16:19 |
| dhellmann | do they say what they think "ocata" includes? | 16:19 |
| dhellmann | which projects do they actually care about, I mean | 16:19 |
| ttx | whatever the stepping-up group means by that | 16:19 |
| dhellmann | so these are people worried about what other people might be worried about? | 16:20 |
| dhellmann | or are they reluctant to step up themselves? | 16:20 |
| ttx | AFAICT they would prefer to have a clear story, like Ocata is a EM series, Pike is not, Queens is not, Rocky is EM, etc | 16:20 |
| dhellmann | yeah, that's not really a surprise | 16:21 |
| dhellmann | I mean, that's how vendors do it. | 16:21 |
| ttx | I bet smcginnis will have more first-hand reactions | 16:22 |
| mriedem | what does "step up" mean? | 16:23 |
| mriedem | what is preventing orgs from 'stepping up' today? | 16:24 |
| *** zhipeng has quit IRC | 16:24 | |
| fungi | second-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 it | 16:24 |
| dhellmann | mriedem : 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 |
| ttx | mriedem: the fact that EM is not a thing, first | 16:24 |
| mriedem | ttx: what you described above is LTS | 16:24 |
| mriedem | if we pick which releases are going to be "EM" | 16:25 |
| dhellmann | fungi : it's funny how creators become attached to their creations in that way | 16:25 |
| mriedem | it's not just ^ | 16:25 |
| ttx | mriedem: without the S | 16:25 |
| mugsie | dhellmann: ++ | 16:25 |
| mriedem | it'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 |
| dhellmann | fungi : it's also a bit disappointing that anyone willing to adopt and maintain it wouldn't consider themselves part of that same team | 16:25 |
| mriedem | or that they are broken on code that the upstream nova team never actually put into that release | 16:26 |
| mriedem | it's basically a fork, as notmyname said | 16:26 |
| fungi | dhellmann: yep. hopefully that's not what they're really feeling and we'll get more accurate reporting after the conference | 16:26 |
| dhellmann | mriedem : maybe in any outcome of this we should require upgrade testing | 16:26 |
| ttx | mriedem: 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 like | 16:26 |
| mriedem | does 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 |
| mriedem | ttx: 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 maintenance | 16:27 |
| mriedem | i don't think the tc should be | 16:27 |
| ttx | If 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 simpler | 16:27 |
| ttx | would* | 16:27 |
| mriedem | if 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 that | 16:28 |
| dhellmann | mriedem : 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 |
| mriedem | dhellmann: that's fine for me, and is just 'don't EOL anymore' | 16:28 |
| mriedem | which is what the resolution is turning into | 16:28 |
| dhellmann | right, that's why I was pushing for that as a first step | 16:28 |
| mriedem | everything stays basically the same, except don't eol | 16:29 |
| ttx | mriedem: I don't know why you're throwing that "feature backport" scapegoat | 16:29 |
| mugsie | which is basically what we said in sydney, right? | 16:29 |
| persia | mriedem: 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 |
| ttx | We said EM would still follow a common policy | 16:29 |
| mugsie | ttx: it has already be said on the review that we should let features go back | 16:29 |
| mriedem | ttx: there are people on the review saying they should be able to backport whatever the ywant | 16:29 |
| ttx | mugsie: one individual said that yes, and we said no | 16:29 |
| ttx | on the review ? Missed that | 16: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 |
| mugsie | from the review ^ | 16:30 |
| dhellmann | I missed the thing about feature backports, too | 16:30 |
| mugsie | https://review.openstack.org/#/c/548916/1/resolutions/20180301-stable-branch-eol.rst@79 | 16:30 |
| mriedem | we 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 on | 16:31 |
| persia | For 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 |
| mriedem | persia: they can't block it | 16:31 |
| mriedem | if someone -1s saying "i should be able to backport features" we say 'no' and move on | 16:32 |
| dhellmann | mugsie : thanks, I missed that | 16:32 |
| mriedem | if 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 happen | 16:32 |
| dhellmann | mriedem : 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 |
| persia | mriedem: 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 |
| ttx | mriedem: pretty much yes | 16:33 |
| mriedem | persia: i assume you spend a lot more time talking to lawyers than i do :) | 16:33 |
| dhellmann | yeah, I can't see us agreeing to support feature backports | 16:33 |
| persia | mriedem: Very likely, yes :) | 16:33 |
| mriedem | anyway, at this point, i plan on just updating this with simplified wording that says what i've already summarized | 16:33 |
| mriedem | removing eol being the big thing | 16:33 |
| dhellmann | ++ | 16:33 |
| persia | I 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 |
| ttx | I agree with all of it except the idea of project teams vetoing anyone from landing bugfix backports on a given branch | 16:35 |
| mriedem | what does vetoing mean? | 16:36 |
| mriedem | this is the same as any code review process | 16:36 |
| mriedem | if someone proposes a bug fix on an em branch that is clearly a bad idea, the project team can and should -1 it | 16:36 |
| persia | I think that matters more for the very small number of projects where the project name matches a contributing org's product name. | 16:36 |
| ttx | sure. My point is rejectnig pacthes on a stable branch just because someone decided that this branch should not live. | 16:36 |
| ttx | not on technical merit | 16:37 |
| ttx | just as part of a product strategy | 16:37 |
| dhellmann | they're more likely to pocket veto those anyway, by just not reviewing them, right? | 16:37 |
| mriedem | ttx: i haven't heard anyone say they plan on doing that on philosophical grounds | 16:37 |
| ttx | mriedem: they can though | 16:37 |
| mriedem | i guess, that's a pretty dick move though | 16:37 |
| mriedem | and i expect it would be brought to light | 16:37 |
| fungi | my 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 them | 16:38 |
| mriedem | fungi: agree | 16:38 |
| fungi | rejecting things is confrontational, and an expenditure of energy | 16:38 |
| fungi | easier to just ignore | 16:38 |
| persia | not 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 |
| fungi | especially when you already have lots of other things you should be doing, maybe more fun things too | 16:38 |
| ttx | If we can draw a line that says that patches should only be judged on technical merit... maybe that would work | 16:39 |
| ttx | I just don't want patches to be rejected for political / product-strategy reasons | 16:39 |
| persia | ttx: Take care with that: "merit" is a squishy word. | 16:39 |
| ttx | persia: does it solve a bug ? Is it a good backport ? | 16:40 |
| persia | ttx: Much better phrasing. | 16:40 |
| fungi | and 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 branches | 16:40 |
| ttx | *Not" Oh, we'd rather consider Pike dead. | 16:40 |
| fungi | but happy to be proven wrong | 16:40 |
| persia | The 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 |
| mriedem | i don't really want to add that kind of wording into this | 16:41 |
| mriedem | this is really getting over-thought | 16:41 |
| TheJulia | mriedem: +1 | 16:41 |
| mriedem | i.e. i don't want to re-define what appropriate fixes are in this resolution, it's just bug fixes | 16:42 |
| persia | So, push simplified statement, start with that, and then make other statements as necessary? | 16:42 |
| mriedem | we soften the phase 3 stuff on -em branches and we don't release them for that reason | 16:42 |
| TheJulia | seems reasonable | 16:42 |
| mriedem | yes. 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 |
| dhellmann | we 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 |
| fungi | better 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 involved | 16:43 |
| mugsie | mriedem: branches don't die, no releases post traditional eol, and allow for degrading testing seems a nice easy start | 16:43 |
| mriedem | mugsie: agree | 16:43 |
| fungi | s/giodelines/guidelines/ | 16:43 |
| mriedem | dhellmann: i don't know about the 'must allow a new team to take it over' stance | 16:44 |
| ttx | dhellmann: 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 proposal | 16:44 |
| dhellmann | only under the conditional | 16:44 |
| mriedem | they should just eol that branch then | 16:44 |
| persia | dhellmann: I believe that is precisely the position that caused the -1 | 16:44 |
| ttx | mriedem: 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 targeting | 16:44 |
| dhellmann | persia : the original proposal was to create separate teams unconditionally | 16:44 |
| mriedem | ttx: i'm fine with that clause | 16:45 |
| ttx | Like is a patch is good for O and Q, it should be good for P as well if someone wants it there | 16:45 |
| mriedem | ttx: well, | 16:45 |
| mriedem | that follows the rule that backports go in order | 16:45 |
| fungi | if 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 territory | 16:45 |
| dhellmann | to get to O it would have to land in P, right? | 16:45 |
| mriedem | dhellmann: exactly | 16:45 |
| * dhellmann checks his alphabet | 16:45 | |
| mriedem | Q->P->O | 16:45 |
| dhellmann | thank you | 16:45 |
| persia | dhellmann: 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 |
| mriedem | if project foo says they do'nt support P, then they drop <=P | 16:45 |
| fungi | er, 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 territory | 16:45 |
| * fungi forgot some words the first time | 16:46 | |
| mriedem | fungi: yup | 16:46 |
| dhellmann | mriedem : that's a good point | 16:46 |
| ttx | dhellmann: ah? I thought they had to backport to all EM branches, not all branches. | 16:46 |
| mriedem | backports must go in order | 16:46 |
| dhellmann | I think we want them backporting to all relevant branches | 16:46 |
| mriedem | or you break upgrades | 16:46 |
| dhellmann | right | 16:46 |
| persia | fungi: I thought the entire point of -em was to provide a collaborative space for the current forks. | 16:46 |
| fungi | persia: it is | 16:46 |
| ttx | i.e if N, O and Q are maintained and someone wants to backport for N they have to backport for O and Q | 16:47 |
| fungi | i was following up on the "if a project team doesn't wish to maintain a branch but someone else does" scenario | 16:47 |
| mriedem | so 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 |
| dhellmann | like 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 supported | 16:47 |
| dhellmann | ttx: we're saying that you can't claim N and O are supported if P is not also supported | 16:47 |
| dhellmann | mriedem : yes, I think so | 16:48 |
| fungi | i expect, at least for now, vmt coverage past traditional eol would likely only be on a best-effort basis | 16:48 |
| dhellmann | and s/supported/maintained/ in my previous statement | 16:48 |
| mriedem | fungi: yes | 16:48 |
| dhellmann | fungi : 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 anyone | 16:48 |
| ttx | Ah, 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 |
| dhellmann | the same would go for docs, qa, etc. | 16:49 |
| fungi | like, 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 there | 16:49 |
| mriedem | ttx: we're not picking and choosing branches for EM | 16:49 |
| mriedem | if one project is, then that's on them and they drop support for everything that comes before | 16:49 |
| mriedem | and their users can give them hell w/o the rest of us having to deal with it | 16:49 |
| fungi | dhellmann: maybe simply tweaking the vulnerability:managed tag description will be sufficient | 16:50 |
| fungi | for the vmt bit i mean | 16:50 |
| ttx | mriedem: ok. I would make that very clear in the proposal though, since it's not obvious right now | 16:50 |
| dhellmann | fungi : quite likely | 16:50 |
| TheJulia | mriedem 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 |
| fungi | dhellmann: though we might also transclude or rehash some of that coverage policy in the documentation published to security.o.o too | 16:50 |
| ttx | I'd expect it to trigger "ok, this is not really helping us" ops reaction, but I may be wrong | 16:50 |
| dhellmann | fungi : ++ | 16:51 |
| persia | Providing indication that -em branches do not receive VMT support seems reasonable to me. | 16:51 |
| TheJulia | Seems reasonable | 16:51 |
| dhellmann | ttx: 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 |
| TheJulia | each community, if they need/want it, can then carry such fixes forward as they need | 16:51 |
| mriedem | ttx: "this is not really helping us for <project foo>" | 16:52 |
| dhellmann | do we think this eliminates the need for driverfixes branches? | 16:52 |
| mriedem | at that point, we say "take it up with project foo" | 16:52 |
| persia | Absolutely. Recruiting folk for -em should not be a goal. Reaching out to folk *already doing* EM in $dayjob is likely useful. | 16:52 |
| mriedem | dhellmann: i think so | 16:52 |
| ttx | dhellmann: 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 |
| dhellmann | brb | 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 | ^ amended | 16:53 |
| TheJulia | dhellmann: 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 thing | 16:53 |
| persia | ttx: 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-tc | 16:54 | |
| ttx | mriedem: that's a clear proposal. At least a good place to start. | 16:55 |
| mriedem | "and cats are better than docs" | 16:55 |
| mriedem | *dogs | 16:55 |
| mriedem | heh | 16:55 |
| TheJulia | lol | 16:55 |
| ttx | Early on it won't be much of an issue too. Since ocata will be teh only-em for the 1st 6 months | 16:55 |
| mriedem | we don't have line item veto power do we? | 16:55 |
| persia | mriedem: It's the 'c' key in gerrit. | 16:55 |
| fungi | dhellmann: 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^Wmaintenance | 16:56 |
| fungi | but as TheJulia says, one person's bug fix is another person's new feature sometimes | 16:57 |
| TheJulia | and, we all need to be reasonable about it in the end | 16:57 |
| mriedem | i just replied in the review on what i think the phases will be | 17:00 |
| mriedem | same 3 as we have today - those get released, | 17:00 |
| mriedem | then a new EM phase which is basically phase 2 wrt appropriate fixes, but not released | 17:00 |
| mriedem | so EM phase is not strictly security/critical fixes, | 17:00 |
| mriedem | like phase 3 | 17:00 |
| mriedem | but it's not released either | 17:00 |
| mriedem | released == blessed by upstream to me | 17:00 |
| fungi | seems 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) tehreafter | 17:02 |
| mriedem | i think we should start with that, | 17:02 |
| fungi | in the ptg session we'd discussed just dropping phase 3, and there seemed to be some support for that idea | 17:02 |
| mriedem | if it turns out that people are (1) contributing to EM branches and (2) doing so responsibly, then we can look at changes the phase | 17:02 |
| mriedem | *phases | 17:02 |
| TheJulia | reasonable to me | 17:03 |
| dims | i like that approach | 17:03 |
| fungi | the 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 team | 17:04 |
| *** david-lyle has joined #openstack-tc | 17:04 | |
| mriedem | yes, and it's going to be the same b/c we'll still be doing releases off those | 17:04 |
| fungi | but that the need for phase 3 has declined since decentralizing stable branch maintenance and change reciew | 17:04 |
| fungi | review | 17:04 |
| mriedem | we aren't decentralizing | 17:04 |
| mriedem | not anymore | 17:04 |
| mriedem | well, maybe i'm not sure what you mean by 'decentralizing' | 17:05 |
| fungi | we're going back to a common stable-maint team which is responsible for the stable branches of all integrated release projects? | 17:05 |
| fungi | that wasn't my take on this | 17:05 |
| mriedem | no | 17:05 |
| mriedem | we haven't done that in forever | 17:05 |
| fungi | we decentralized stable maintenance by adding per-project stable review teams a while back | 17:05 |
| mriedem | the 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 rejected | 17:06 |
| fungi | and what i'm saying is that the phases were designed back when there was still just one central team | 17:06 |
| mriedem | fungi: right so we still have the global central team, and per-project teams | 17:06 |
| fungi | but that phase 3 seems less relevant now that we have per-project stable review teams | 17:06 |
| mriedem | yeah i see what you're saying | 17:06 |
| mriedem | phase 3 is very much tied to eol, | 17:07 |
| fungi | and 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 |
| mriedem | i know i am extra cautious about approving backports on the oldest branch for fear of a regression being found after we eol the branch | 17:07 |
| mriedem | so 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 |
| fungi | that was what i took away from the discussion at the ptg | 17:08 |
| fungi | but maybe others remember it differently. we only talked about changes to phases very briefly so perhaps it wasn't as consensual as i thought | 17:09 |
| mriedem | i'm amenable to that if others are | 17:09 |
| mriedem | i don't remember much talk about it on tuesday | 17:09 |
| mriedem | maybe it was in the secret TC room where the sacrifices happened | 17:09 |
| mriedem | aka the breakfast bar | 17:09 |
| mriedem | i'll wordsmith that up | 17:10 |
| fungi | i'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 asleep | 17:10 |
| ttx | mriedem: that was the release cycle room on Tuesday afternoon | 17:10 |
| mriedem | fungi: i'll work it into the resolution | 17:10 |
| ttx | oops ignore me misread you | 17:10 |
| ttx | probably means it's time for me to step away from the computer | 17:11 |
| dims | thanks for driving this resolution mriedem | 17:11 |
| fungi | the 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 |
| persia | Describing it as 6 months phase I, 12 months phase II, -em after seems easy to swallow. | 17:12 |
| fungi | basically the stable review teams may currently have the impression that they don't possess latitude in determining extenuating circumstances for some fixes | 17:12 |
| mriedem | dims: i do it for the love of the children | 17:13 |
| mriedem | you know me | 17:13 |
| dims | awwwwwww | 17:13 |
| fungi | you know, for kids | 17:13 |
| mriedem | fungi: that's something to propose separately for the actual guidelines imo | 17:13 |
| mriedem | this came up in the ops ML from zioproto | 17:13 |
| mriedem | and i pointed out that the docs do say it's ultimately up to the discretion of the project core team | 17:14 |
| mriedem | but people apparently don't read the fine print | 17:14 |
| mriedem | i know persia does :) | 17:14 |
| persia | mriedem: To be fair, sometimes I read the fine print in order to ignore it. | 17:14 |
| fungi | mriedem: yep, i agree that's a separate change, just recapping things we talked about that may have been forgotten in the snow | 17:15 |
| mriedem | there is an itunes agreement joke in here somewhere | 17:15 |
| *** jpich has quit IRC | 17:16 | |
| ttx | persia actually only reads the fine prints. | 17:17 |
| dims | LOL | 17:17 |
| * fungi reads the fine manual | 17:22 | |
| *** rosmaita has quit IRC | 17:35 | |
| TheJulia | Wait, are there people that do not read the fine print? | 17:45 |
| fungi | nope, just sheep | 17:50 |
| *** dtantsur is now known as dtantsur|afk | 17:53 | |
| *** clarkb has joined #openstack-tc | 17:58 | |
| * harlowja is just sheep | 18:22 | |
| harlowja | but like a fire-breathing sheep | 18:23 |
| *** harlowja has quit IRC | 18:26 | |
| *** david-lyle has quit IRC | 18:56 | |
| *** cdent has quit IRC | 18:56 | |
| *** harlowja has joined #openstack-tc | 19:11 | |
| *** harlowja has quit IRC | 19:18 | |
| *** harlowja has joined #openstack-tc | 19:33 | |
| *** dtk has joined #openstack-tc | 19:37 | |
| openstackgerrit | Matt Riedemann proposed openstack/governance master: Add a resolution about stable branch EOL and "extended maintenance" https://review.openstack.org/548916 | 19:41 |
| mriedem | ding ding ^ | 19:41 |
| *** dtk has quit IRC | 19:44 | |
| *** dtk has joined #openstack-tc | 19:47 | |
| * persia doesn't find anything to complain about this time | 19:47 | |
| mriedem | o.O | 19:49 |
| *** dtk has quit IRC | 20:10 | |
| *** dtk has joined #openstack-tc | 20:11 | |
| dims | mriedem : you broke persia! fix it | 20:13 |
| * dims reading | 20:13 | |
| persia | dims: 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 |
| dims | :) | 20:22 |
| dims | mriedem : 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 |
| mriedem | well, they could eol the branch, but that's not good for the people that want it to live for longer | 20:25 |
| mriedem | they could add people to the stable core team that actually do want to take up the maintenance | 20:26 |
| mriedem | i think the latter is probably the answer | 20:26 |
| dims | mriedem : can you please add a sentence to that effect? | 20:26 |
| mriedem | bleh | 20:26 |
| dims | mriedem : it came up in keystone meeting | 20:27 |
| mriedem | leave a note in the review | 20:27 |
| dims | ack thanks | 20:27 |
| dims | left another note | 20:40 |
| mriedem | dims: replied | 20:41 |
| mriedem | given what's written, i don't really want to add caveats | 20:41 |
| mriedem | or special case every situation | 20:42 |
| dims | ack thanks | 20:42 |
| mriedem | and to your other | 20:47 |
| mriedem | i'm not worried about people that want everything for free or to do what they want wrt backporting features | 20:47 |
| mriedem | that's called a fork and they are on their own | 20:47 |
| dims | agree. 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 |
| dims | nice work again! | 20:51 |
| *** david-lyle has joined #openstack-tc | 21:07 | |
| persia | I 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 IRC | 21:45 | |
| tonyb | Actually 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 sign | 22:23 |
| tonyb | but the proposal from ~5 hours ago is better structured for now and simplier to implement | 22:23 |
| persia | tonyb: 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-tc | 22:32 | |
| *** david-lyle has joined #openstack-tc | 22:32 | |
| *** annabelleB has quit IRC | 22:33 | |
| *** annabelleB has joined #openstack-tc | 22:34 | |
| *** kumarmn_ has joined #openstack-tc | 22:39 | |
| tonyb | persia: Yup. If we can get the resolution sorted we can call for help with Ocata | 22:40 |
| *** kumarmn has quit IRC | 22:42 | |
| fungi | and it makes sense for the patch appropriateness during -em to be roughly equivalent to that for stage ii | 22:47 |
| mriedem | the phase 2 guideline is a bit strict today - it says critical and security fixes, | 22:56 |
| mriedem | but i know we merge backports in phase 2 that aren't 'critical' or security fixes | 22:56 |
| mriedem | just regular ol bug fixes that are low risk | 22:56 |
| mriedem | which is also what people are going to want in EM mode | 22:56 |
| dhellmann | mriedem : maybe we should clarify that policy concurrently with this other change? | 22:58 |
| mriedem | :/ | 22:59 |
| dhellmann | after? | 22:59 |
| mriedem | sure | 22:59 |
| mriedem | i just don't want to complicate this too much | 23:00 |
| dhellmann | yeah, I just meant "around the same time" | 23:00 |
| dhellmann | "cooperative multitasking" not "parallelism" | 23:00 |
| mriedem | it'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 |
| mriedem | tried to hedge bets there a bit | 23:00 |
| dhellmann | yeah | 23:00 |
| dhellmann | we could even link to the project team guide stable guidelines there, if you aren't already | 23:01 |
| mriedem | i did | 23:01 |
| dhellmann | k | 23:01 |
| mriedem | but people only read the table, they don't read further down saying it's up to the team | 23:01 |
| dhellmann | we can lead a horse to water... | 23:02 |
| smcginnis | That's probably OK. It's better they assume things are more restrictive than they actually are. | 23:02 |
| mriedem | and then drown said horse | 23:02 |
| * dhellmann does not advocate drowning horses | 23:02 | |
| smcginnis | Poor little horse. | 23:02 |
| dhellmann | smcginnis : maybe. if it means they continue to not contribute, I'm not sure it does us much good. | 23:02 |
| mriedem | where do you think ttx gets all his delicious horse meat in france? | 23:03 |
| smcginnis | dhellmann: Good point, that could be the down side. | 23:03 |
| dhellmann | but one change at a time | 23:03 |
| mriedem | btw this is the thread from zioproto that i keep thinking of http://lists.openstack.org/pipermail/openstack-dev/2018-January/126851.html | 23:05 |
| fungi | at 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 adherence | 23:06 |
| dhellmann | mriedem : ah, yeah, I remember that thread | 23:07 |
| fungi | seems so long ago... january | 23:07 |
| smcginnis | Ancient history. | 23:07 |
| *** mriedem has quit IRC | 23:23 | |
| *** annabelleB has quit IRC | 23:24 | |
| *** kumarmn_ has quit IRC | 23:29 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!