Thursday, 2019-04-04

*** mriedem has quit IRC01:09
*** mriedem has joined #openstack-stable02:23
*** mriedem has quit IRC02:29
*** udesale has joined #openstack-stable04:09
*** ekcs has joined #openstack-stable04:27
*** ricolin has joined #openstack-stable04:57
*** pcaruana has joined #openstack-stable04:58
*** e0ne has joined #openstack-stable05:12
*** e0ne has quit IRC05:18
*** e0ne has joined #openstack-stable06:47
*** rpittau|afk is now known as rpittau06:48
*** dims has quit IRC07:22
*** dims has joined #openstack-stable07:24
*** dims has quit IRC07:31
*** dims has joined #openstack-stable07:34
*** elod_off has quit IRC07:45
*** elod_off has joined #openstack-stable07:52
*** jpich has joined #openstack-stable07:53
*** dtantsur|afk is now known as dtantsur08:25
*** e0ne has quit IRC08:30
*** e0ne has joined #openstack-stable08:40
*** e0ne has quit IRC08:42
*** e0ne has joined #openstack-stable08:50
*** ricolin has quit IRC08:53
fricklertonyb: I've pushed https://review.openstack.org/649945 for the Chef OpenStack newton-eol tags, but it looks like this is failing because we didn't cut that branch from a common tag09:42
fricklertonyb: so I'm thinking that I should just push those tags manually and then put on my infra hat and drop the branches09:43
*** e0ne has quit IRC09:44
fricklerprobably the same procedure will be needed for all the other stable branches we currently have in place. and I'd look into using release tooling properly once we're ready to cut stable/rocky09:44
*** e0ne has joined #openstack-stable09:54
*** dtantsur is now known as dtantsur|brb10:07
*** derekh has joined #openstack-stable10:35
*** udesale has quit IRC10:54
*** cdent has joined #openstack-stable11:17
*** e0ne has quit IRC11:50
*** dtantsur|brb is now known as dtantsur11:57
*** zul has joined #openstack-stable12:52
*** mriedem has joined #openstack-stable12:54
*** udesale has joined #openstack-stable13:05
smcginnisfrickler: I think for the untagged type, you just need to put the commit hash as the location.13:17
fricklersmcginnis: the problem with that is that it is a different hash per repo. and it looks to me like I need to specify the location globally in that file13:19
smcginnisHmm, yeah. Guess we can't branch untagged when they are grouped into one file.13:20
smcginnisfrickler: Ah, just noticing you were adding the whole file. Still waking up I guess. :)13:22
*** e0ne has joined #openstack-stable13:22
smcginnisfrickler: That hasn't been managed by the release team, so I think your plan is right.13:23
smcginnishttps://github.com/openstack/governance/blob/master/reference/projects.yaml#L17813:23
*** altlogbot_2 has quit IRC13:54
*** e0ne has quit IRC13:59
*** e0ne has joined #openstack-stable14:05
*** udesale has quit IRC14:06
*** udesale has joined #openstack-stable14:07
*** udesale has quit IRC14:11
*** udesale has joined #openstack-stable14:11
*** mlavalle has joined #openstack-stable14:16
*** e0ne has quit IRC14:46
*** e0ne has joined #openstack-stable14:52
*** e0ne has quit IRC14:57
*** udesale has quit IRC15:32
*** e0ne has joined #openstack-stable15:46
*** e0ne has quit IRC15:48
*** e0ne has joined #openstack-stable15:48
*** e0ne has quit IRC15:48
*** e0ne has joined #openstack-stable16:05
*** e0ne has quit IRC16:12
*** jpich has quit IRC16:34
*** rpittau is now known as rpittau|afk16:44
*** dtantsur is now known as dtantsur|afk17:00
*** derekh has quit IRC17:18
*** derekh has joined #openstack-stable18:09
*** derekh has quit IRC18:10
fungianybody interested in getting a stable/ocata backport added for https://review.openstack.org/#/q/I17ab643abbd2ec21eda4ae1dfb9abf2d4b0657f2 (looks like we'll be issuing a security advisory for that one soon)18:17
smcginnismlavalle: Is neutron still supporting extended maintenance for ocata? ^18:20
smcginnisIf it's a security issue, might be good to get it back to there.18:20
*** cdent has quit IRC18:40
*** eharney has quit IRC18:55
*** eharney has joined #openstack-stable18:58
mlavallesmcginnis: yes19:38
mlavallesmcginnis: well, let me take that back. we are not merging backports to ocata anymore19:39
smcginnismlavalle: OK, thanks. We should probably EOL that branch for neutron then.19:40
smcginnisfrickler: ^19:40
mlavallesmcginnis: this is the communication we sent to the ML in January regarding ocata branch: http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001383.html19:49
mlavalleso we have it in extended maintenance19:51
mlavalleif I undertstand correctly, there is a 6 months perior before we eol it, right? https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance19:52
smcginnismlavalle: When you're in extended maintenance, it's entirely up to the project whether to continue maintaining it or not.19:56
smcginnismlavalle: So if you're not accepting any more backports to it, then it would make sense to just EOL it.19:56
mlavallesmcginnis: let me raise this in the next Neutron meeting. I'll get back to you Tueday of next week19:57
smcginnismlavalle: That ML post is a little misleading.19:57
mlavallesmcginnis: please educate me....19:57
smcginnisIt was already in extended maintenance by that point. That happened in 2017.19:57
smcginnisFor Ocata.19:57
smcginnisErr, wait.19:58
smcginnisI forget the exact date it happened. But it's for all projects, not a per-project decision.19:59
mlavalleso let me see if I can summarize this:19:59
smcginnisIndividual projects can decided whether to extend their maintenance on it or end of life it.19:59
mlavalle1) The branch stays as maintained for about 18 months20:00
smcginnisBut the transition from stable/maintained to extended maintenance is a function of the time since release.20:00
mlavalle2) After that period, whether we like it or not, it goes to extended maintenace20:00
mlavalle3) We, the project team, keep the branch in extended maintenace for as long as we want / can20:00
smcginnisCorrect. And if a team does not like it, they can just kill it.20:01
mlavalle4) Once we don't maintain it, it goes to unmaintained status and at that point, after 6 months it reached EOL20:01
mlavalleis that a good summary, smcginnis?20:02
smcginnismlavalle: Yep.20:02
smcginnisBut clarification on 4, that 6 month period is a safety if no one does anything with the branch anymore. The team can decide to mark it EOL as soon as they decide they are not going to maintain it anymore.20:03
mlavallesmcginnis: thanks. in that case I will make the clarification to the entire team in our next team meeting on Tuesday and I'll get back to you on our position by next Tuesday. Does that work?20:03
smcginnisSounds good. Don't really need me to do anything. My interest was mainly to be able to get frickler an answer about that security backport. :)20:06
smcginnisI did find it - ocata official transitioned to extended maintenance almost exactly a year ago.20:06
mlavallesmcginnis: that's ok. it was a good opportunity to de-dumbify myself20:08
smcginnisHah! :)20:08
mlavallesmcginnis: still I think I should share this with them team, so I'm going to bring it up in the next meeting20:09
smcginnis++20:09
smcginnisGood to make sure the knowledge is shared.20:09
smcginnisPike is really overdue to be transitioned. I should probably send a note about that.20:10
*** pcaruana has quit IRC20:29
*** pcaruana has joined #openstack-stable20:30
mlavallesmcginnis: I'm going to tell the team that I was sternly admonished by my releases guru ;-)20:37
mlavalleand got a couple of slaps20:37
smcginnisHaha!20:38
*** cdent has joined #openstack-stable20:58
*** ltomasbo has quit IRC21:01
*** pcaruana has quit IRC21:51
*** rcernin has joined #openstack-stable22:23
*** cdent has quit IRC22:26
tonybfrickler: Yeah newton is 'hard' because we marked it dead in openstack/releases so we have extra steps to do22:27
tonybfrickler: so they 'right' way to do it is22:27
tonyb1. Annoucne the EOL on openstack-discuss22:27
tonyb2. With your infra hat on run roles/copy-release-tools-scripts/files/release-tools/eol_branch.sh from 989103cfdeb5f7e1bc8569ad2e6999600a587dbd^22:28
tonybmerge the openstack/releases change to keep it in sync with git22:29
tonybfor >= Ocata we can do it 'right'22:29
tonyband when we get gerrit 2.14? ew can do it all in repo22:29
tonybWe can't EOL ocata as we didn't annouce 6 months ago that we were going to do that so the best we can do is announce that in 6 mnoths we will22:31
tonybbut really why would we do that?  Ocata isn't broken (AFACIT) infra works and the back ports have been done so we really *are* in EM for Ocata and pike and can stay that way until something chnages22:31
* tonyb thinks we probably shoudl have a discussion at the PTG about this as project wide we seem to have very different ideas about what we did with EM 22:32
smcginnistonyb: We had said it was up to the teams if they want to perform "extended maintenance", so we can't EOL across the board. It's really up to each team.23:05
tonybsmcginnis: That's true but teams seem to be of the opionion that we automatically transition from EM -> EOL on a schedule23:06
tonybsmcginnis: and we were explict that that wasn't the case23:06
tonybwe'd transition from EM -> EOL 6 months after we decided that $project wasn't working in EM23:07
tonybperhaps I'm wrong23:07
tonybYeah so https://docs.openstack.org/project-team-guide/stable-branches.html is reasonably clear23:08
tonybwe transition into EM after ~18 months23:08
tonybthen per-project we can decide to do EM (or not)23:08
tonybprojects that decide not to need to flag the #project is unmaintained on $branch23:09
tonybduring which time if inteested community members step up they can do EM23:09
tonybafter 6 months in unmaintained we can EOL23:09
tonybso the idea that 'Pike is really overdue to be transitioned.' seems wrong23:10
tonybprojects don't *need* to move to EM if they don't want/need to23:11
smcginnistonyb: Wait, I think you're mixing two things.23:27
smcginnisYou confirmed what I was saying about EM > EOL except I forgot the part that we would give other teams that 6 month window to step in if they wanted to.23:27
smcginnisPike was something different though.23:27
smcginnisThat discussion was not about EOL, it was about going from maintained to extended maintenance.23:27
smcginnisWhich as you pointed out is supposed to happen at the 18 month point.23:28
smcginnisAnd we just haven't done that yet but should have.23:28
tonybsmcginnis: Well it's a per team decision isn't it?23:28
smcginnisNo23:28
smcginnisNot going to EM.23:28
tonybso *we* don't need to do anything23:28
smcginnisThat is explicit.23:28
smcginnisWe need to switch that branch to EM.23:29
smcginnisThen they can decide if they want to do the EM or leave it for 6 months and go EOL.23:29
tonybI thought it was per team so *some* teams could keep control over the 'core' team23:29
smcginnis< tonyb> we transition into EM after ~18 months23:29
tonybsome teams don't want the EM transition as it meant that there is potential for other to be given coer access23:30
smcginnisPer team if they want to continue to support it after our normal "maintained" window.23:30
smcginnisRight, that was one of the debates about that.23:30
smcginnisThat's why I thought teams could explicitly decide to go right to EOL if they chose.23:30
smcginnisBut transitioning out of "maintained" isn't a team choice.23:31
tonybso you're saying that en,masse we switch to EM and then any projects that don't wnat to can switch back to M?23:31
smcginnisThat was supposed to have happend.23:31
smcginnisNo, they can't switch back to M.23:31
smcginnisM is done for that branch.23:31
tonyb(but in reality that'd be my -1'ing the switc)23:31
smcginnisIt's either do EM or do EOL.23:31
tonybOkay that isn't what I thought we agreeed to23:31
smcginnisThat's what we wrote up and accepted. :)23:31
tonybthat's not how I read it23:32
tonyband not what some teams wanted23:32
smcginnisLike you quoted, maintenance ends at 18 months.23:32
tonyband not what I *thought* I was agreeing to23:32
smcginnisWe didn't want that going on forever.23:32
tonybHmmm23:33
smcginnisSo if the teams still care, it's like it describes for Extended Maintenance - "While there are community members maintaining it."23:33
tonybThis is a bit of a worry as apparently I wrote a lot of that :/23:34
smcginnisIt's a big switch we flip in releases too. After we say Pike is extended maintenance, no one gets to do releases there anymore.23:34
tonybokay23:34
* tonyb messed all that up23:34
smcginnisThe other big concern raised was that we can't have stable branches forever, so that's why it was proposed it should only be what was our normal stable for 18 months. After that, up to them if they care.23:35
tonybwe didn't ever really enter EM for ocata, and we're 'late' for pike23:35
smcginnisWe did ocata in April of last year, but we are late for pike.23:35
tonyb[tony@thor keystone]$ git tag -l | grep ocata-em23:36
tonyb[tony@thor keystone]$23:36
tonybI bet we didn't tag most of the projects23:36
smcginnisIt's not a tag.23:36
tonybThe HEAD of the appropriate branch will be tagged as $series-em, for example: https://review.openstack.org/608296/23:36
smcginnisWe do a final release if they request it, then we enter EM and no more releases.23:36
smcginnisOh, yep, I guess we did miss a step.23:37
tonyb^^^ that's what we wrote as a process23:37
smcginnisAh, I was right "Some project teams may choose to NOT enter extended maintenance and go directly to End of Life"23:37
tonybWe need to think about how that's supposed to work23:38
tonybI feel like it should be annoucned ahead of time23:38
smcginnisShould work fine if we actually follow through on the process. :D23:38
smcginnisIt really should. That's why I sent out my note today.23:38
* tonyb hasn't made it to email today23:39
smcginnisThough I think we should have something a little more official, since my point there was that teams should get a release done while they can.23:39
tonybokay I'll go find youre email and reply with words to the effect of23:39
tonybactually don't knwo what I'll say23:40
*** eharney has quit IRC23:40
smcginnis:)23:40
tonyb#string_of_bad_language23:41
smcginnisMaybe pick a date in the near future and declare that will be the transition date?23:41
tonybYeah23:41
tonybI don'23:41
tonybt like that we're goign to muck up operators23:42
smcginnisOK, I gotta run. I'll probably check back in a little later if there are any last minute RCs to get out.23:42
tonybok23:42
tonybI23:42
smcginnisWe shouldn't impact operators, I wouldn't think.23:42
tonybneed to head out anyway23:42
smcginnisThe ones I've spoken to about this thought it was a reasonable policy.23:42
smcginnisOK, really gotta run. Thanks!23:42
tonybI feel lik eoperators are expecting to get 6months notic if $project will go EOL23:42
tonyboh wait23:43
tonybI'm confusing myself23:43
tonybI give up23:43
tonybI'll go to my appoinment and think wheil I'm driving23:43
tonybThanks smcginnis23:43

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