| opendevreview | Kristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance https://review.opendev.org/c/openstack/governance/+/888771 | 14:18 |
|---|---|---|
| knikolla | tc-members: I did my best to update the proposal, though I struggled with being able to make a clear case for opt-in, and the lack of a Unmaintained -> EOL process. ^^ | 14:29 |
| dansmith | I'm reviewing now, | 14:29 |
| dansmith | currently typing about | 14:29 |
| dansmith | why there is no opt-in like last time | 14:29 |
| JayF | I'm really waffling on opt-in | 14:30 |
| dansmith | I was expecting to keep that part... are you saying you dropped it because you felt unable to articulate the justification for it? | 14:30 |
| JayF | because either we have to have people willing to do it *at EOL time* or we have to be willing to resurrect an EOL tag to create an unmaintained branch | 14:30 |
| JayF | both of those are unfortunate cases | 14:30 |
| knikolla | dansmith: yes. Justification and process. Because the previous proposal said the project team is responsible for opt-in, whereas now we have a new group. And we haven't really defined who this group is lead by. | 14:31 |
| knikolla | And also because opt-in doesn't still solve the issue about interdependencies and the problems with testing through tags rather than branches. | 14:32 |
| fungi | if keeping branches open isn't continuously opt-in, then instead we need some means of identifying and closing down branches which have become abandoned | 14:32 |
| dansmith | knikolla: okay I said in the last one that I think it's okay for the project to handle the opt-in, and those people are the ones that would have a good judgment of whether or not there really is a group able and willing to keep renewing it | 14:32 |
| dansmith | fungi: yep | 14:32 |
| knikolla | dansmith: So group maintaining branch may be different from group doing the opt-in. That's a bit awkward from a process perspective. | 14:34 |
| dansmith | well, the group maintaining it may not exist, the group running the project does | 14:35 |
| dansmith | seems okay to me, much like the group running the project has say over who they add to their stable-maint group | 14:35 |
| knikolla | And you mentioned branch resurrection, which is also something I was thinking about needs to be defined timeline wise. Because a group might show for that branch after a failed renewal, so do we want to handle that case? | 14:36 |
| dansmith | well, JayF did as well | 14:36 |
| dansmith | I *think* resurrecting an eol tag to an unmaintained branch should be okay, assuming the contiguous-releases requirement is satisfied, right? | 14:37 |
| JayF | well, today the -eol tag is the final anything for a given project | 14:38 |
| knikolla | And we still don't solve for the Cinder is not renewing, but Nova needs them for testing their Unmaintained branch. | 14:38 |
| JayF | is that going to change with the move to unmaintained? | 14:38 |
| JayF | I'll note; I likely won't have SQLAlchemy resolution updated before the meeting; but it seems like one of the biggest discoveries is "this has less time pressure than we thought", so it shouldn't be a big deal | 14:38 |
| knikolla | We would end up with eol-1, eol-2, eol3-final, eol-4-for-real-thistime-final tags if we resurrect multiple times. | 14:38 |
| JayF | yeah that is far from ideal | 14:39 |
| dansmith | knikolla: I see no reason for that | 14:39 |
| dansmith | tags can move right? | 14:39 |
| JayF | Moving a -eol tag is going to be extremely annoying to anyone consuming that downstream with the expectation (set over years) that those tags don't move | 14:39 |
| knikolla | they can, but in my head they shouldn't. | 14:39 |
| JayF | giving a downstream a surprise rebase is not ideal :/ | 14:40 |
| dansmith | meh, I don't see the problem, but whatever | 14:40 |
| JayF | maybe we need some kind of waiting/inactivity period | 14:41 |
| dansmith | well, I made a comment about that | 14:41 |
| dansmith | a minimum TTL for the unmaintained branch before the requirement to opt-in comes due | 14:42 |
| JayF | ack; I'll check gerrit then, it's easier to follow threads of discussion with actual threads anyway :D | 14:42 |
| fungi | updating existing tags in a remote doesn't update local versions on a remote update | 14:42 |
| JayF | fungi: oh that is devious | 14:42 |
| fungi | get doesn't pull changes for (non-lightweight) tags | 14:42 |
| fungi | s/get/git/ | 14:43 |
| fungi | this is one of the reasons we consider tags to be effectively undeletable too | 14:45 |
| fungi | git similarly won't pull the absence of a tag on a remote update | 14:45 |
| fungi | mainly it doesn't have any way to know if the presence of a local tag which doesn't exist on the remote or differences in what they contain/point to may be intended | 14:46 |
| fungi | so it safely chooses to only ever pull new tags | 14:47 |
| dansmith | unless you 'git fetch -t' as part of your process, which I would think anyone mirroring a repository would be doing | 14:47 |
| dansmith | that said, things like pip and other such tools that don't keep a local copy will always see the remote set of tags | 14:47 |
| fungi | and -P to explicitly prune local tags yes | 14:48 |
| dansmith | we're talking about something that probably won't be happening very much, and if someone is tracking an eol release and actually building from it, I can't imagine they're just doing so blindly without any sort of oversight, and/or they have their own branches created from where that tag was at some point | 14:48 |
| dansmith | they would rebase their branch if and when that was ever appropriate, and probably not automatically | 14:49 |
| knikolla | I think I would be happier with X cycles grace (ex. 3) and no resurrection. | 14:49 |
| dansmith | fwiw, fungi also suggested at one point (I think) that we tag as eol immediately, and allow the unmaintained branch to co-exist and move beyond the "first point of EOLing" tag | 14:50 |
| dansmith | I don't really like that personally but if we had some emergency need to resurrect we could try that | 14:50 |
| fungi | i was thinking about grace periods, and i don't immediately see how to discourage the (typical human) behavior of procrastinating until the end of the grace period, so we probably still end up with a similar problem of people not being around for a timely response when the (real) deadline is reached | 14:51 |
| dansmith | this is basically why I don't care to ever delete branches, especially ones that are clearly named "unmaintained" and/or why allowing those to be in a different repo/namespace gives us more flexibility about stuff like this | 14:52 |
| fungi | we used to eol and delete branches much sooner, and if there was a bug discovered later for an eol version we just said "too bad, upgrade or patch it downstream" | 14:53 |
| fungi | i'm not sure why that can't be an option again | 14:53 |
| dansmith | it can, | 14:53 |
| dansmith | but the "do that in a thousand different places" argument (against) seems reasonable to me | 14:54 |
| fungi | anyway, to my earlier suggestion you mentioned for leaving the branch open past eol, what i was actually suggesting was moving when the eol tag occurs, to be synchronous with the transition out of normal maintenance | 14:55 |
| dansmith | right | 14:56 |
| dansmith | so eol when we move it from stable to unmaintained yeah? | 14:56 |
| fungi | so when normal maintenance ends we tag the branch eol but leave it open, then later when nobody responds to the question of whether it should remain open we delete the branch. if at some later date someone wants to resume updating it we recreate the branch from the prior state | 14:57 |
| dansmith | er, eol-tag | 14:57 |
| knikolla | prior state being marked by a different tag? | 14:57 |
| fungi | rename it "end of maintenance" instead of "end of life" if that helps, but basically get rid of the idea that there's a tag which means the branch will never receive further updates | 14:58 |
| JayF | so 18 months then -> $release-eol -> unmaintained/release -> ??? ($release-eol-um ?) | 14:58 |
| JayF | fungi: I thought for technical reasons we'd have to close branches at some point | 14:58 |
| JayF | so I assume we either have to terminate in a tag *or* lose those commits forever (tag is much preferable to losing commits) | 14:58 |
| fungi | yes, i'm saying close them as early as right away even, but be willing to recreate them later if requested (and if reasonable) | 14:59 |
| JayF | I think that still means we'd need an end-of-not-maintenance (whatever we'd call "unmaintained" period lol) | 14:59 |
| JayF | hard to say "this is even less maintained now" when we call it unmaintained lol | 14:59 |
| fungi | there would, as an implementation detail, need to be a tag added to preserve that state any time the branch was deleted so it can be recreated from that state later, we can simply increment some identifier each time | 15:00 |
| fungi | but we get rid of the idea that there's a singular tag that means no new updates on this branch ever again | 15:00 |
| JayF | fungi: I wonder if instead of doing "one tag at the end", we would switch to "tag the state of the branch periodically" | 15:00 |
| JayF | fungi: like $release-um-$dateStamp at the churn of each cycle | 15:01 |
| JayF | that would give us a place to preserve the work and to see if something got inactive (if $release-um-$dateStamp is the same SHA as $release-um-$dateStamp+6months ---- the branch is dead?) | 15:01 |
| fungi | if you wanted to schedule the tagging, it would probably be synchronized with when bulk deletion of abandoned branches is scheduled | 15:02 |
| fungi | so that you don't lose state (instead of tagging just the branches for the projects where you're deleting them, tag the state of that branch on all projects?) | 15:02 |
| fungi | but i don't really see what that gets you | 15:03 |
| JayF | I'm a little more hand-wavey at that point | 15:03 |
| JayF | but I'm saying, if we have, for instance | 15:03 |
| JayF | Ironic unmaintained/train | 15:03 |
| fungi | and it veers dangerously close to people thinking those are stable branch releases again | 15:03 |
| JayF | oh that's a good point | 15:03 |
| JayF | I withdraw my idea | 15:03 |
| slaweq | knikolla: hi, sorry for last minute notice but I will not be able to attend today's meeting. I have some family stuff to do which just popped up | 17:31 |
| knikolla | Thanks for the heads up slaweq | 17:34 |
| knikolla | tc-members: reminder, weekly meeting on irc in around 26 minutes | 17:34 |
| knikolla | #startmeeting tc | 18:00 |
| opendevmeet | Meeting started Tue Jul 18 18:00:04 2023 UTC and is due to finish in 60 minutes. The chair is knikolla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:00 |
| opendevmeet | The meeting name has been set to 'tc' | 18:00 |
| knikolla | Hi all, welcome to the weekly meeting of the OpenStack Technical Committee | 18:00 |
| knikolla | A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct | 18:00 |
| knikolla | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 18:00 |
| knikolla | #topic Roll Call | 18:00 |
| noonedeadpunk | o/ | 18:00 |
| JayF | o/ | 18:00 |
| knikolla | We have one noted absence: slaweq. | 18:00 |
| knikolla | o/ | 18:00 |
| dansmith | o/ | 18:00 |
| rosmaita | o/ | 18:00 |
| jamespage | o/ | 18:00 |
| gmann | o/ | 18:00 |
| knikolla | #topic Follow up on past action items | 18:02 |
| knikolla | knikolla will amend the proposal for Unmaintained branches. | 18:02 |
| knikolla | I have done so, and we can circle back on this item in the next topic. | 18:02 |
| knikolla | #topic Extended Maintenance / Unmaintained | 18:02 |
| knikolla | #link https://etherpad.opendev.org/p/openstack-exteneded-maintenance | 18:02 |
| knikolla | I have updated the proposal from last week | 18:03 |
| knikolla | #link https://review.opendev.org/c/openstack/governance/+/888771 | 18:03 |
| knikolla | I have renamed the status to Unmaintained. That’s what we already call branches that are EOL and this sends a strong signal about the differences between unmaintained and maintained, rather than introducing new words. | 18:03 |
| knikolla | There’s a few things that we need to iron out. | 18:03 |
| dansmith | I do like that symmetry, but someone else suggested obsolete, which I also like, fwiw | 18:03 |
| knikolla | The transition from Maintained to Unmaintained: opt-in process, etc. | 18:04 |
| knikolla | The transition from Unmaintained to branch deletion: criteria, timelines, possible grace periods, etc. | 18:04 |
| knikolla | And the transition from branch delete to Unmaintained branch: tagging, etc. | 18:04 |
| gmann | I think unmaintained compare to obsolete especially with our 'Maintained' phase naming | 18:04 |
| gmann | * like unmaintained | 18:04 |
| knikolla | I think the symmetry helps a lot. | 18:04 |
| rosmaita | yes, let's keep it simple | 18:05 |
| jamespage | +1 | 18:05 |
| knikolla | And it reduces the perceived difference between Unmaintained with a branch, and unmaintained with no branch. | 18:05 |
| knikolla | Namely, only the existence of the branch. | 18:05 |
| gmann | we have some suggestion and discussion on those open item in gerrit too | 18:05 |
| dansmith | as long as we can handle the unmaintained-maint group name problem :P | 18:05 |
| fungi | unmaintainers | 18:05 |
| knikolla | We can bikeshed on the group name in Gerrit :) | 18:06 |
| rosmaita | knikolla: can you give a quick description of the workflow from master->stable->unmaintained->EOL ... i am unclear on the branch renaming and deletion | 18:06 |
| gmann | we can rename that to unmaintained-core group | 18:06 |
| gmann | master->maintained->unmaintained->EOL | 18:06 |
| knikolla | Stable to unmaintained: stable/<branch> is deleted, tagged as <branch>-eol, new branch is created in unmaintained/<branch> | 18:07 |
| rosmaita | ok, so EOL happens before unmaintained ? | 18:07 |
| gmann | how about all open changes ? | 18:08 |
| spotz[m] | o/ | 18:08 |
| fungi | open changes have to be abandoned or merged first | 18:08 |
| knikolla | gmann: good point, those would have to be recreated. | 18:08 |
| gmann | rosmaita: not EOL as such but a new branch for that to maintained as unmaintained | 18:08 |
| knikolla | But we need this kind of friction as it sends a clear signal of lack of continuity. | 18:08 |
| knikolla | This is now a new thing, in a difference status. | 18:08 |
| gmann | yeah, we need to cleanup open changes also, hope we do not have many | 18:08 |
| knikolla | different* | 18:08 |
| fungi | just keep in mind we used to do something similar at the transition from pre-release to release, and stopped doing that because of the challenges it created, but hopefully the degree of churn around end of maintenance is not as great as around end of release candidate period | 18:09 |
| noonedeadpunk | Then we're in territory of timelines, as changes could be valid backports, that needs to be merged but lack reviews | 18:09 |
| gmann | and it explicitly call out that existing EM model does not work so this is new model and who need these branches need to step up for maintenance | 18:10 |
| knikolla | noonedeadpunk: that would send a strong signal to get those merged now, because this is the last opportunity to cut a release with those fixes. | 18:10 |
| gmann | noonedeadpunk: that valid backport can be re-proposed right | 18:10 |
| noonedeadpunk | cherry-picked to another branch... but yeah | 18:10 |
| knikolla | as whatever is still open at the time of transition will not be able to receive releases anymore. | 18:11 |
| fungi | if nobody's reviewing proposed backports on a branch, that's a good indicator that either there needs to be a different group reviewing them or the branch isn't serving a purpose | 18:11 |
| gmann | exactly | 18:11 |
| noonedeadpunk | But then there's no sense to rename the branch kind of? | 18:11 |
| noonedeadpunk | I am not sure I catched if moving to unmaintained is default behaviour or on-request? | 18:12 |
| JayF | renaming the branch is part of the marketing to ensure that users know if it breaks they get the pieces | 18:12 |
| noonedeadpunk | or per-demand | 18:12 |
| fungi | noonedeadpunk: that's why i suggested just closing branches at that point, and recreating them later if a group of interested reviewers comes forward | 18:12 |
| JayF | since one of the big problems with EM right now is operator misunderstanding about what is supported in what ways | 18:12 |
| knikolla | noonedeadpunk: renaming is marketing, but also to ensure we can use different group with different permissions. | 18:12 |
| fungi | the "renaming" happens in two basic steps already: delete old branch, create new branch from the previous branch state. you can stop after the first step and then do the second step later if there's interest | 18:13 |
| knikolla | noonedeadpunk: as per automatic or manual, I'm open to feedback. So far I think we're leaning on manual. | 18:13 |
| gmann | on-request create more inconsistency and confusion. i think default behaviour make sense | 18:13 |
| JayF | The biggest difficulty I've had nailing down about on-demand based branching | 18:13 |
| JayF | is what do we do about tagging and communicating state of things | 18:13 |
| gmann | and it is one time transition we have to do which is not smooth or best for everyone but solve the long term problem | 18:14 |
| dansmith | moving to unmaintained is dictated by the schedule, just as it is today right? | 18:14 |
| JayF | which I guess we have as a lesser problem when it comes time to retire the unmaintained/ branches | 18:14 |
| dansmith | if you mean "unmaintained vs straight to eol" I think we need to do the former to allow for time for a group to materialize | 18:14 |
| dansmith | gmann: ++ | 18:14 |
| knikolla | a group which can later renew the branch every cycle | 18:14 |
| noonedeadpunk | Also - are there technical reasons we don't wanna close ability to create tags on this new branch (do releases)? As that kinda would make sense, if we allow to have like post releases or smth like that? | 18:14 |
| knikolla | because on-demand creation would have to fall on the project team. | 18:15 |
| noonedeadpunk | or like development releases | 18:15 |
| JayF | So release [18 months pass] -> unmaintained/ automatically -> must be renewed every 6 months | 18:15 |
| JayF | I like that, because it builds in a grace period | 18:15 |
| knikolla | ++ ^^ | 18:15 |
| dansmith | yes | 18:15 |
| JayF | but still gives up opt-in style semantics | 18:15 |
| JayF | so after that first 6 months, nobody comes, unmaintained/ branch is retired -- two questions: | 18:15 |
| gmann | renewed every 6 month ? | 18:15 |
| JayF | 1) What do we tag that final commit? | 18:15 |
| dansmith | alternately, you get a little longer in unmaintained before you need to renew, but I'm not super opinionated about that I think | 18:15 |
| dansmith | as long as it's one cycle for "free" | 18:16 |
| JayF | 2) What do we do if someone doesn't renew it after 6 months but someone shows up a year later and wants to resurrect it | 18:16 |
| gmann | IMO we can go with the 4 or 5 years policy and after that move unmaintained -> EOL | 18:16 |
| fungi | noonedeadpunk: if teams are already uneasy about people getting the impression that these branches are still maintained, i expect they'd be even more uneasy about someone tagging more releases from unmaintained branches | 18:16 |
| knikolla | yeah, I think the first free cycle makes sense. Was leaning towards that today while rewriting the patch. | 18:16 |
| dansmith | JayF: right, that's why I think maybe a little longer default free period might help avoid needing to answer the resurrection question as much | 18:16 |
| gmann | I wrote here how it looks like if time based moving to EOL https://review.opendev.org/c/openstack/governance/+/888771/1/resolutions/20230707-extended-maintenance-new-requirements.rst#74 | 18:16 |
| JayF | dansmith: the period of time matters less to me right now than the answer to those two questions, regardless of how long "grace period" is | 18:16 |
| dansmith | JayF: ack | 18:17 |
| JayF | dansmith: I chose a cycle just b/c it's simpler to think in those terms since it's our automatic stopping point now | 18:17 |
| dansmith | ack^2 | 18:17 |
| gmann | main idea if to keep them open as much as we can | 18:17 |
| noonedeadpunk | fungi: well, but if we're talking about oslo-ish, not being able to release some fixes is really a bummer | 18:17 |
| noonedeadpunk | As then you can't have this in your constraints/requirements | 18:17 |
| noonedeadpunk | or well.. you can, by SHA, but well... | 18:17 |
| JayF | noonedeadpunk: we already experience a version of that problem today as well, fwiw | 18:18 |
| gmann | on-demand basis have its own challenges on how fast we can communicate it operators to come and ask for unimantaiend branche | 18:18 |
| JayF | noonedeadpunk: given how some bugs in Ironic can be related to sushy (and I think os-brick/cinder are similarly tied) | 18:18 |
| noonedeadpunk | Well, yes, so I was wondering why to prohibit some post/dev releases on unmaintained branches | 18:19 |
| noonedeadpunk | As that would make more easy to consume, and hopefully to get some involvement | 18:19 |
| JayF | As an Ironic core and PTL of Ironic; I don't want software released that's called "ironic" that installs via `pip install ironic`, that may have been reviewed/maintained to a lesser standard | 18:19 |
| fungi | if teams are still tagging releases from branches, it seems like those branches are still actually maintained | 18:19 |
| JayF | which I thought was also the original impetus behind 'no releases from EM branches' as well | 18:20 |
| noonedeadpunk | As what point of spending time on keeping alive unmaintained version if there is no straight way to consume there | 18:20 |
| noonedeadpunk | *these | 18:20 |
| knikolla | ++, if a specific project needs longer maintenance schedules, that's a different problem to solve than this one. | 18:20 |
| JayF | noonedeadpunk: there is a large number of larger deployers who are already setup to build and use their own downstream git repos | 18:20 |
| fungi | it sounds more like there's interest in some libraries staying in maintained phase longer than other projects | 18:20 |
| spotz[m] | Unless it's standalone I can see them being potentially around longer | 18:20 |
| noonedeadpunk | JayF: these would never contribute back to unmaintained branches | 18:20 |
| JayF | noonedeadpunk: that is decidedly untrue | 18:21 |
| noonedeadpunk | Not even sure about maintained ones | 18:21 |
| JayF | noonedeadpunk: I've personally backported changes of that nature, at almost every place I've worked | 18:21 |
| gmann | if we do release it add testing things also | 18:21 |
| noonedeadpunk | but what's the point of spending time when you still have to maintain the same thing downstream? | 18:21 |
| noonedeadpunk | ppl like to do the work twice? | 18:21 |
| gmann | we need to test them well before release so I agree it move towards maintained phase | 18:21 |
| fungi | noonedeadpunk: the argument for having no-longer maintained branches is that downstream distributions tell us they want to collaborate on backports of fixes in those branches without burdening the project teams | 18:21 |
| JayF | noonedeadpunk: two reasons: 1) Changes that are not acceptable to backport upstream (features; object changes) and 2) downstream moves much, much faster than upstream -- you can solve your own problem easier than solving the problem for all cases generically | 18:22 |
| JayF | noonedeadpunk: I'm happy to talk about these use cases in depth in another venue; it seems off topic a bit for this discussion | 18:22 |
| JayF | noonedeadpunk: but I do assure you the process as I laid out is how it's worked literally everywhere I've worked that ran openstack :) | 18:23 |
| noonedeadpunk | fungi: yes, I get that. The point is that the only deliverable openstack does release on their own, without unclear (or hidden) development in downstream, are releases in PIP | 18:23 |
| knikolla | noonedeadpunk: even if those branches do not get the idealized level of contribution that we were hoping, there was a significant number of people who really wanted them still around, even without releases, and if we can do that in a way that clearly says "we as upstream are not maintaining this" and not much burden to our teams, I think we should. | 18:23 |
| noonedeadpunk | So by doing effort in having such scheme with maintained/unmaintained, we disable ourselves to produce deliveravbles | 18:23 |
| JayF | Yes; but that's also the status quo with EM projects | 18:24 |
| fungi | we release tags in git, and source tarballs. the installable artifacts built from those (wheels, container images, et cetera) are not the releases | 18:24 |
| gmann | for fast discussion, I think we need another call to short out the open items one by one. I am getting mixed up here from what item we started to discuss and which one we are in :) | 18:24 |
| noonedeadpunk | And I kinda find EM pretty much useless because of that | 18:24 |
| noonedeadpunk | ANd we're trying to fix EMs | 18:24 |
| rosmaita | gmann++ | 18:24 |
| knikolla | EM is useless to most of us, but not all of us :) | 18:24 |
| gmann | :) | 18:25 |
| JayF | I think we shuold all, individually, take an action to make sure our concerns are represented and asked in gerrit | 18:25 |
| JayF | so we can assess them in a threaded format where things won't get lost | 18:25 |
| gmann | or let;s have a another call | 18:25 |
| noonedeadpunk | I get we're enabling downstreams, but I also want openstack to have some profit from that as well | 18:25 |
| JayF | then maybe from there go to another call | 18:25 |
| gmann | and out things in gerrit like we did for initial discussion | 18:25 |
| knikolla | If I don't see progress towards a consensus in Gerrit by end of week I'll think about organizing another call for next week. | 18:25 |
| JayF | gmann: I know at least for me, I need that first step to get thoughts organized so we can have an agenda and avoid talking about everything all at once :D | 18:25 |
| fungi | or on the mailing list if the concerns aren't specific to a particular proposal | 18:26 |
| noonedeadpunk | ++ sounds good knikolla | 18:26 |
| gmann | knikolla: but we need to add unmaintained->EOL in that proposal right which is open | 18:26 |
| knikolla | In the meanwhile, to be more inclusive of the whole community, Gerrit and ML are great venues of collaboration. | 18:26 |
| knikolla | gmann: yes. That part needs to be ironed out. | 18:27 |
| gmann | but do you want to merge the proposal without that and do that as follow up ? | 18:27 |
| knikolla | Currently the various ideas are: 1) renew every cycle after the first X cycles, or 2) a set timed Y number of cycles unmaintained across all repos. | 18:27 |
| knikolla | gmann: I would really prefer to merge something that clearly defines the Unmaintained -> branch deletion step. | 18:28 |
| knikolla | As that will answer the Cinder question. | 18:28 |
| rosmaita | also, we need to address the SLURP issue | 18:29 |
| noonedeadpunk | Yes, I like idea of coordinated approach... | 18:29 |
| gmann | knikolla: as this is resolution, I will suggest to do it in one shot instead of keeping ->EOL moving open which is important part to understand proposal as whole | 18:29 |
| noonedeadpunk | But downstream maintainers obviously don't like that | 18:29 |
| rosmaita | i think seanmooney had a good point that we should *not* allow skipping branches | 18:29 |
| JayF | ++ | 18:29 |
| gmann | yeah | 18:30 |
| dansmith | I se no reason we need to keep non-slurp branches between slurps, | 18:30 |
| gmann | that is why I am suggesting to have another call this week and figure out those things | 18:30 |
| knikolla | I compromised on not skipping SLURP branches when revising the proposal. | 18:30 |
| dansmith | if we're saying it's allowed to upgrade normally and skip the intermediate ones | 18:30 |
| dansmith | otherwise the burden goes *up* in unmaintained | 18:30 |
| JayF | My only concern is that it's consistent | 18:30 |
| rosmaita | i am ok with the burden going UP in unmaintained | 18:31 |
| gmann | it makes people moving to SLURP model more | 18:31 |
| JayF | it'll get confusing if we have some SLURP unmaintained/ and some mid-slurp having/not having them inconsistently | 18:31 |
| dansmith | I totally don't understand why it's okay to skip non-slurps during the maintained phase and not after | 18:31 |
| dansmith | in fact, | 18:31 |
| rosmaita | let's skip them during development too | 18:31 |
| dansmith | I'd go so far as to say we could just make it so that non-slurps aren't even eligible for unmaintained status | 18:31 |
| dansmith | that will reduce the number of branches we could have in this status, and eliminate some process | 18:32 |
| noonedeadpunk | to be fair, skipping non-slurps during development is a good topic to discuss... Another time:) | 18:32 |
| dansmith | i.e. non-slurps go straight to EOL, no renewal allowed | 18:32 |
| noonedeadpunk | I like that idea actually | 18:32 |
| gmann | I think it does not harm much. | 18:33 |
| JayF | dansmith: I like that almost as much as I like rosmaita's suggestion :D | 18:33 |
| fungi | the only reason we disallowed skipping branches previously was because we didn't support branch-skipping upgrades, so now that we do... i agree | 18:33 |
| JayF | I do think that's osmething we should explicitly check w/consituency for | 18:33 |
| noonedeadpunk | This will also align downstreams more on versions | 18:33 |
| knikolla | (gentle ping that I want to timebox this conversation at 40 mins past the hour to allow for the next item in the agenda) | 18:33 |
| dansmith | fungi: right | 18:33 |
| gmann | keeping SLURP open for long term maintaining make sense | 18:33 |
| dansmith | noonedeadpunk: yep | 18:33 |
| knikolla | Ok, I will revise resolution to make non-SLURP branches ineligible for Unmaintained. | 18:34 |
| dansmith | sounds good to me | 18:34 |
| rosmaita | -2 from me right now | 18:34 |
| gmann | can we schedule a another call tomorrow same time as our meeting? 18.00 UTC | 18:34 |
| rosmaita | i think everyone should re read sean's comment on the patch | 18:34 |
| JayF | I do not think I'll be ready for a call on this topic by tomorrow this time | 18:34 |
| gmann | otherwise it is hard to progress on gerrit with those items open | 18:35 |
| knikolla | gmann: I don't think there is enough reason to justify a call on such short notice. | 18:35 |
| spotz[m] | -2 because of the non-SLURP or that's where you're at currently rosmaita? | 18:35 |
| dansmith | rosmaita: sean is talking about during the maintained phase no? | 18:35 |
| gmann | knikolla: JayF may be day after tomorrow ? | 18:35 |
| gmann | without that we are not going to progress much and will hang around whole cycle on this | 18:35 |
| JayF | I have to read the full proposal again and make a review pass, I'd rather have enough time for a little async figuring before going sync again | 18:35 |
| rosmaita | spotz[m]: becasuse of non-slurp | 18:35 |
| dansmith | rosmaita: also sean describes "or closing the branch" which I think means straight to eol, which is what we're describing here | 18:36 |
| JayF | gmann: maybe monday before next meeting, perhaps, if you are champing at the bit to get one scheduled :D | 18:36 |
| rosmaita | dansmith: o dpmt | 18:36 |
| rosmaita | try to translate that! | 18:36 |
| dansmith | ? | 18:36 |
| gmann | JayF: sure, I was thinking this week but Monday is ok also | 18:36 |
| knikolla | gmann: I do want to see progress stall first before I call a video-meeting as it's not super inclusive to the community as a whole. | 18:36 |
| dansmith | knikolla: I think we're talking all over ourselves right now, and a call would help clear that up a lot, FWIW | 18:36 |
| gmann | sure, let's have on Monday then | 18:36 |
| rosmaita | i thought he was talkinga aobut unmaintained, because the maintained branches are the normal stable branches that this proposal doesn't touch | 18:37 |
| dansmith | this sort of thing gets pretty thorny with all the parallel threads here | 18:37 |
| gmann | yeah | 18:37 |
| knikolla | Hence why there is a gerrit proposal which will be updated by EOD today to reflect these threads. | 18:37 |
| dansmith | "we cannot skip non-slurp release either while the non-slurp release is still maintianed." | 18:37 |
| gmann | we are not going to get any outcome with IRC discussion, call is helpful in such situation | 18:37 |
| dansmith | "we likely either shoudl not allow that or close the branch" | 18:37 |
| dansmith | I think the first sentence means we should not change current stable policy, which is true, | 18:38 |
| dansmith | and that we should not have an *open* unmaintained branch that gets skipped | 18:38 |
| dansmith | and instead we should either require the backport to hit that branch too *or* close it so it's clear | 18:38 |
| dansmith | and this would achieve the second thing there, which is no non-slurp would ever be in unmaintained state, so there's nothing to skip | 18:38 |
| gmann | So current open items: 1. unmaintained -> EOL process 2. SLURP/non-SLURP in unmaintained phase 3. release of unmaintained branches 4 ? | 18:39 |
| knikolla | That's all the time we have for this specific topic. Please participate in the discussion in Gerrit. | 18:40 |
| knikolla | gmann: that's a good summary I think. | 18:41 |
| knikolla | #topic Release notes guidelines for SLURP/NON-SLURP cadence | 18:41 |
| knikolla | Speaking of SLURP... | 18:41 |
| knikolla | gmann: do you want to provide an introduction for this topic? | 18:41 |
| gmann | I was reviewing one of the nova change of AZ sch filter removal and then realized we have not figure out the release guidelines for SLURP/non-SLURP | 18:41 |
| gmann | this was one of the open items since SLURP model and is in c tracker also | 18:42 |
| gmann | TC tracker | 18:42 |
| gmann | #link https://etherpad.opendev.org/p/tc-2023.2-tracker#L47 | 18:42 |
| noonedeadpunk | iirc it was boiling down to tooling | 18:42 |
| noonedeadpunk | and how to copy renos nicely from non-SLURP to SLURP kinda | 18:43 |
| gmann | yeah but I do not have much status on that | 18:43 |
| noonedeadpunk | (and render these) | 18:43 |
| gmann | but at least we should finalize one approach and provide guidelines to community | 18:43 |
| rosmaita | i think we need to agree on the strategy before doing the tooling | 18:43 |
| rosmaita | this has been open for over a year: https://review.opendev.org/c/openstack/project-team-guide/+/843457 | 18:43 |
| JayF | rosmaita: added that to my list, will read and comment soon | 18:44 |
| knikolla | ++, added to my todo list for review. | 18:44 |
| gmann | ok so let's review that and figure out what is closed way to move | 18:45 |
| knikolla | #action tc-members to review https://review.opendev.org/c/openstack/project-team-guide/+/843457 | 18:45 |
| noonedeadpunk | ++ | 18:45 |
| gmann | rosmaita: I remember you have some example patch also from cinder to show how it will looks like ? | 18:45 |
| knikolla | homework for everyone :) | 18:45 |
| rosmaita | gmann: i dont' know if those still exist, i will look | 18:46 |
| JayF | knikolla: we're just cramming because the exam is coming soon ;) | 18:46 |
| gmann | rosmaita: no issue, just checking. | 18:46 |
| knikolla | anything else on the topic? | 18:48 |
| knikolla | Moving on | 18:48 |
| knikolla | #topic Gate health check | 18:48 |
| knikolla | Any updates on the state of the gate? | 18:48 |
| dansmith | not good | 18:49 |
| JayF | Ironic has continued to focus on correcting some CI issues; things aren't great but they are better than they were 3 weeks ago at this time so... progress? I guess? | 18:49 |
| dansmith | a number of things have been creeping up, guest kernel crashes, another volume issue it seems | 18:49 |
| JayF | Ironic actually ID'd a major issue: dnsmasq is failing in newer ubuntu | 18:49 |
| dansmith | mkfs occasionally times us out formatting a volume and there are iscsi errors in the syslog and io errors on the guest kernel console | 18:49 |
| JayF | We are having to use the package from older ubuntu to avoid the *segfaults* killing the daemon | 18:49 |
| dansmith | I've been rechecking one patch for days now | 18:49 |
| JayF | so if any of you are relying on dnsmasq (I think that's only Ironic?) beware the SIGSEGV | 18:50 |
| noonedeadpunk | JayF: thanks for letting know | 18:51 |
| gmann | also, we have seen many timeout in last couple of weeks, I am refactoring the test run | 18:51 |
| gmann | like 1. running slow tests in parallel which helped to reduce tempest-slow job execution time to 60% 2. increase the concurrency of test runner #link https://review.opendev.org/q/topic:job-timeout+project:openstack/tempest | 18:51 |
| gmann | 2nd one is failing on other failure like mkfs dansmith mentioned | 18:51 |
| gmann | but if that work at least it will help running tests on more worker. though it does not solve the worker test balance issue | 18:52 |
| knikolla | thanks for doing that work. | 18:53 |
| knikolla | # topic Reviews and Open Discussion | 18:54 |
| knikolla | #topic Reviews and Open Discussion | 18:54 |
| knikolla | #link https://review.opendev.org/q/project:openstack/governance+status:open | 18:54 |
| rosmaita | i found the review gmann was referring to (sample SLURP release notes) | 18:54 |
| rosmaita | https://review.opendev.org/c/openstack/cinder/+/840996 | 18:54 |
| rosmaita | i just hit recheck to regenerate the release notes, but who knows if the job will pass | 18:54 |
| rosmaita | also, it's old enough so that it still uses the "tick-tock" vocabulary | 18:54 |
| rosmaita | "tick" == SLURP | 18:54 |
| rosmaita | "tock" == non-SLURP | 18:54 |
| gmann | rosmaita: great, thanks | 18:55 |
| knikolla | awesome, thanks for finding that. | 18:55 |
| knikolla | Unless there's anything else. I propose closing the meeting. | 18:57 |
| knikolla | #endmeeting | 18:57 |
| opendevmeet | Meeting ended Tue Jul 18 18:57:45 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:57 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2023/tc.2023-07-18-18.00.html | 18:57 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-07-18-18.00.txt | 18:57 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2023/tc.2023-07-18-18.00.log.html | 18:57 |
| knikolla | Thanks all! | 18:57 |
| spotz[m] | Thanks knikolla and everyone! | 18:58 |
| opendevreview | Merged openstack/governance master: Deep link to ops-sunbeam README https://review.opendev.org/c/openstack/governance/+/886453 | 19:04 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!