Istio Technical Oversight Committee, 10 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Technical Oversight Committee 2022/10/10

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Team member, so with that we do have four people, so we have the Quorum for sure.

B

A

C

Awesome so we have quorum.

C

C

First agenda: the hansman promotions: uh Eric: is this uh your topic.

D

I don't know if it's my topic.

C

Well, nobody but I mean because I wasn't sure who stopped my business.

D

Yeah um so uh the first thing we have the quarterly reminder at the top, which is um the comment up there.

D

That says, you know for work groups to look at the enhancement, repo, there's kind of count and recall on the past, for something like 28 PR's out there, that that Miriam had done where she basically created the uh the page for the various features, um and so whoever owns the various features can just basically look at the page and say yes, this is good um and we can get those in um that's just basically to get back to I.

D

Think the the starting point that I want to say it was Lynn and Brian we're working on on this way way way back when um so uh that was the idea. There was I think just to get the the initial um templates uh merged. So um if the various work groups who own the various features can look at that, that's just sort of the reminder for that, and then my next two bullets, I I put out there is I, know, there's um the basically the top two PR's on that page.

D

uh So the external authorization, the JWT claim based ones, are ones that are looking for the TOC approval, so basically there's a check box in there that says the TOC approves the promotion, um so I think we just have to basically um add a note in there.

D

I don't know if this is you know if it's really a should be an approval, so that one doc member can say yes, this is enough or if it's something that we should vote on, I don't know if the the actual um process for that is but I do know. Those two are out there.

D

D

um The easiest thing to look at um if you want to scroll down like the external authorization one if you open it up, click on files changed. So we can see the files that are changed in this one um and then scroll down to the second file there and typically what I do is I. Think if you click on the three dots on the right hand, side you can do view file uh yeah, whatever just basically it's easier to view the whole file than it is to try to look at the changes.

D

And then this one was beta, so if we scroll down to the beta things, foreign right so I think um the majority of these are checked, except for the TOC has reviewed the API and I see they don't have. The release notes have been added check yet.

D

But other than that I believe all of them were were checked.

D

Well, yeah, so the bottom one is the one that basically, um we have to. You know, review and approve the promotion and then, when this goes in the earlier file will update the features yaml and then that all gets moved to istio.io for the next release.

C

So, do we typically do this uh in this meeting or do we do this offline? Does it require all four members DLC or the majority, or just one.

B

I know that we've done we've taken a look at these in meetings in the past, um and our Charter shows that we operate by consensus. So it's uh it's mostly just sort of checking with each other to make sure we're on the same page.

D

So I I guess I'm fine with either you know bringing these forward I, don't know how many there are typically like I said: there's two here: I'm fine with um you know, looking at these in the meeting and saying you know we vote on them here or if we want, you know if we get four Toc members to say, you know, looks good to me in the in the pr that that's fine with me as well. I think foreign.

B

Just in terms of the template, obviously, they followed the template exactly the way that it appears to be designed, um but like the links to or documentation design, docs uh integration tests, it would be great if there were links there, that we could click to actually see what they're referring to.

B

But that's kind of a meta comment: I, don't think that's necessarily feedback for this particular all right. Okay, it does look like at least an alpha. They did that.

D

A

D

Basically, what Marion was trying to do just so that people understand that was basically what Miriam was trying to do with those other PRS to basically fill out the templates with some of that information.

C

Okay: this is a pretty long design dog um for it to review in.

D

This meeting, yeah I, don't think I, don't think we don't yeah I, don't necessarily think we need to review. You know like the design docs. We don't necessarily need review um all of the test plans and things like that um at least, certainly not in this meeting.

D

And, okay, and and truthfully right these, these things don't need to be determined today and approved. Today, I mean if they really have until we. You know we release um you.

A

D

Branch cut Branch cut 1.16 because, um as long as these PRS are, um you know merge before we do. The branch cut the.

C

C

Go ahead, Eric.

D

Well, the idea here is, if it's Branch cut I mean we can always cherry pick it too, um but if it's done before Branch cut, then it will automatically be in the 1.16 documentation at this level.

C

C

Because Branch cut is next Monday uh exactly when working a week from now. So if you want both of these to be in there, then we got to get them approved this week.

C

Okay, why don't we agree on the the process to get well the process for getting these approved?

C

um We have a week. uh Do we need is do we need the majority of the TLC members and, if so, who to review this and improve it during this week? uh Do we like dedicate one person, let's agree on procedure, and then we can have a plan going forward.

A

Yeah I think majority should be and I do think. The brand team is the branching related to this. Strictly because we were not making additional coaches I mean we're not branching the the enhancement repo right, so it is always a monster. No.

D

No, it's branched. It's branched, I'm.

A

D

Okay, because the features that yaml that is in there will be for that particular branch So. Currently the features dot yaml, that's in the main branch is for 1.16, which is what these changes will be after branch that features that yaml becomes the 1.17.

A

And then the features that yamo is used to automatically generate the documentation related to the.

D

A

Because you, the okay, because the user- this is not a user-facing repo right users are not. Most users is not going to go to enhancementary poetry, checkout status. They are they going to overdog to check out the status right. Okay, that makes sense.

D

Right right, the way I think Brian had had done. This work um is there's a feature Channel, which contains the information and that's actually scraped by the istio.io documentation.

D

So as that feature, yaml changes for a given release, the istio.io documentation will change for that release um and then I guess we also uh we don't. We always have a history of the of the of the index MD file, but um but yeah, the features.yaml at least, has to be by release so that we're pulling that correctly.

A

Okay, very good.

D

um But if, if the answer is, is you know the TOC? You know four people take a look at it in the next week, provide either feedback or you know it looks good to me um I hate to say you know, do some sort of uh you know we have to have four Toc members approve it. We only have two for API, so um I. Don't necessarily think we need to do, but if, but if we have, you know four people looking at a comment, then I think that's good to go.

C

B

Do that sooner rather than later, uh so that the the submitters have time to respond to the comments.

D

Yeah I know I had made remarks in at least one of these already and I thought I think they were all fixed. I know the one I needed it. I wanted the index that MD file added, and they did that because originally.

C

D

Updated in the features yaml.

C

So we have two of these right. How about we uh get the TLC member attack team to two TLC members? uh Look at each.

C

That'd be fair.

D

Well, if we still want four for each I guess.

C

Well, I, don't know again a question for TLC members: do you guys have the bandwidth this week um to look at both sets, or is it better to split up so that half of you look at each one of these foreign.

B

I'm happy to look at both for my part.

D

Yeah same here, I can as well.

C

C

So then, we'll have um four four yeah.

D

Yeah, so let's just plan on on we'll do that and then, um if we don't have for people reviewing each one, I will take it on myself to um repaying the TOC in the slack channels to look at it. So I'll probably do that say: Thursday around you know early afternoon Thursday late morning somewhere in there I'll ping the channel on.

D

If we don't have enough reviewers yeah.

C

I I was gonna um second interest point if we Eric, if you could bring up by one day, say Wednesday, so that uh if we have additional reviewers and get that done by at the end of the week, okay also address comments and so on. So we gotta leave some room for that.

D

Okay, Okay and like I said I mean we can we can. We can certainly cherry pick things later.

D

Okay, I changed my to dude thing here to Wednesday, so I'll ping Wednesday. If we don't have enough reviewers, so hopefully we'll get at least three of us done before then and then worst case. We have one person to pick up after that.

D

And my guess is, is the fourth one would probably should should, hopefully, by that time, be a rubber stamp after three of us have given them comments and they fixed them would be the hope.

C

Okay sounds like a plan: uh should we take a quick look at the JWT claim one or should you let's just do that all fine.

D

I think we can just do that offline.

C

C

So back to the list of topics, uh I want to go back to this one named the enhancement repo, so the request is for all the work group leads to go through this list and uh review improve them right.

D

I believe that was what Miriam was looking for.

C

uh Do we do we have a.

D

uh It's not necessarily indicative that the TOC has to approve at this point right, because I think all she was basically doing was trying to fill out the table for the current level that the features.yaml says. So if it says the feature is- and you know stable, she basically just tried to do the best she could to fill out the table for stable um and maybe below, and then you know, the idea is. Is that at least that is a starting point?

D

um Well stable. You wouldn't necessarily the starting point, but let's say Alpha, um so that would be then a starting point. If that feature decided they needed to move to Beta right. So.

C

Do we know like which one of these match to which feature which worker bleeds or is this the workbook leads as a whole body? In other words, do we need to uh start assigning these to different work? Group leads.

D

Well, I think a feature is probably related to a work group um and I. Think we've been reluctant in the past to force the work on those particular work group leads and let them do that as they can I mean yeah.

D

C

D

Quarterly reminder: okay,.

C

My question: do we need this for 116. no or just get to it whenever.

D

B

Probably I mean this is okay, a backlog right, so so, if ideally, we would not leave this open forever. It's been 18 months for a lot of these pull requests. It would be good to close this out, but it is probably, in my opinion, it's going to be more important to actually handle the promotions in time for 116 than to work. Our way through the backlog also more feasible.

D

Right right and I think part of the thought, and that's why I don't know if they're 28 anymore or not, because I haven't paid much attention to this, um but you know, but the thought is right is: if somebody decides they want to take one of the existing features and move it up um at least there's a PR there with a you know, an index already started for them and I I believe in both of these cases they didn't need it. um I shouldn't say that they didn't have what one available um at.

C

Least I know one of.

D

Them when they had to create it in.

C

C

Sorry go ahead, Eric.

D

No, um my comment was was basically just that of these outstanding ones. They would conceivably get picked up as those features wanted to be promoted. So actually you know this might go back to the old. You know we don't want promotion to be scaling and I, don't know what we're doing with that right now either right. There was I know one time um there was the the thought Brian was around when this was being done as well.

D

If I recall, um there was a thought to try to make, you know, features you know be promoted, you know every I, don't know what the time frame was um say a year um uh or I, I guess I, don't know what would happen with them if they didn't get promoted, but the idea was to help you know, move promotions along and so I assume. There's still from that point.

B

Improve visibility also for users on what the status of the features that they're using right uh a lot of times. Our users are not aware, when they're leveraging, perhaps a an experimental or Alpha feature in production, which carries a decent amount of operational risk.

D

D

But yeah I guess I haven't looked at these other ones that Miriam did I, don't know that there were necessarily adding new features to the table at the various stages. I think if this was just to try to flush out those features in the table today,.

C

So speaking of promotions, I see just at the top. It was this. There are at least two other beta promotions. This one here promote distroll recipe, though um this guy here do. We need these for 116.

B

Resources resource status is not ready as far as I'm aware I'm double checking right now, but last.

C

B

It was not no it's, it hasn't changed.

C

It's been stay over a little while this is the last comments belt mark.

A

D

Don't think it's just gonna say I, don't think this is ready.

A

It's it's close. uh Maybe we need more docs or something, but at least from the tech, the code, it's all ready to go at this point.

C

uh So, what's the consensus understood list right now, let's go, the pr is a little draft state. John is just something that we can wrap up in in this week and get it into 116, or it should wait for a chair. Pick wait for the next release.

A

um So I wanted to wrap it up if they want to take it on, but I'm not going to have time to do that.

C

uh Would you just say should uh wrap this up. Somebody.

A

Anyone, okay, so probably no one is safe for being realistic.

B

Yeah, this PR actually doesn't include a it's on checklist. It's just a one-line change to features.yaml, so I think that it probably has a ways to go.

A

D

Yeah I was going to say that I didn't look closely enough at it, but um it did look like there was a link to the to the table. So maybe we just need to update the table um and include it I. Don't I didn't pay as much attention a lot of times. The link in the table is empty. That's how you know, there's not an MD file, but I thought when we clicked on that one. There actually was a a file named there now whether that file exists right.

D

So the checklist right above the alpha remove line features digital images MD. Now the question is: is whether that checklist really exists um a lot of times that checklist is empty, which means there is no file and typically, if there is a if it does have something in there, I would expect the file to exist. So so, just you know, Mitch's comment that the file doesn't exist might not be totally true. It might actually exist. It might have some data in it, don't know, but no changes in this PR.

C

So for changes like this, if we need the rest of the community to um trying to actually finish it, what's the best way to get the word out, provided we still want this.

B

Realistically, what tends to work is for each of these. We need one or more Champions, uh for instance, for jwat based routing claim routing and the external authorization we've had some very active champions from the security working group pushing these forward and that's been a consistent effort over at least three months. I would say, um if there's nothing willing to invest a time to move these forward, then it's it's unlikely that they will move.

C

So it sounds like I think we're back to um when uh Eric first brought out his topic. The we need leads from the work group leads to Champion leagues and get them over the finish line, or at least take a look at the this list here and see which ones are ready to emerge. Is that correct.

A

Yeah, because one of the requirements is a work group person who.

B

A

The checklist, by the way, I have to confess um I, actually thought um the enhancement repo is merged manually, but apparently we have a bot, that's emergency, so I just approved the JW claim based routing um and it just merged up here. So if you guys see any issue, please uh shell, it out it was done unintentionally without knowing that we actually had a bot for that repo.

D

A

Yeah, that's new.

D

To me, when you first started talking hot I was going to say Yeah, we actually have a lot that will update the features yaml in the dock overnight. So that will happen, but yes, um yeah and- and we don't have um you know we we don't have anything other than like I said I. Think one I think you just verified it. um If one Toc member approves it, it goes so.

A

Yeah it used to be like menu, merge, After, People reviewed it. So now it's just whenever you approve you just say, look good to me. Instead of approve the pr.

D

C

Okay, how about this uh I mean? We have the immediate the two immediate promotions this week. um So TLC members, please do take a look, and uh so we can get those in by 116. for the rest of these I will take a look and um I think to meaningfully talk all these, rather than just leaving the list of 28 open and then leave it up to the water bleeds to go through and take a look at them.

C

uh I will put this I'll I'll put this list into some kind of uh spreadsheet format, and then we can start penciling in which work group this belongs to so at least we know uh of the 28 like which group should be looking at which ones and then we can keep track of that way with some kind of status like, for example, we talked about the resource status.

C

That's already, you know promo this rule, that's also not quite ready, so these are in various stage of Readiness and we can prioritize the ones that are uh higher on people's list, so that, rather than you know, just asking the work group leads to tackle all 28. At the same time, we can prioritize it in some way and start through the rest of this quarter and the next quarter uh start getting this uh uh getting this list done, how's that.

D

Yeah, okay and whether you start a table and work your way down or the other way, I think either one is fine um and then I guess the other comment I would make too is a lot of these would typically come through I think the roadmap discussions so, for example, I think distralis was one of those that was probably on the road map for I want to say 1.15. Maybe it was 1.14 I, don't remember, so we probably at that point had the you know it was. It was on the road it ended up.

D

We didn't have enough. You know people slash time, resources to work on it. So you you know we didn't get it done for that road map. It hasn't showed up again on a roadmap just because people are are busy, whether it be ambient or something else right.

D

um So some of these I think you know are you know, I want to say at least that one um I don't know about the other ones.

C

Are are all the worker blades in this meeting I mean, but by the nature of it? Are we all on TLC, okay, so we'll need some other way to reach out to them.

C

What so, let me take a crack at this first right and then um once I have this into some kind of list, and we can start assigning uh work groups or worker ownerships for each friendly house and we can go from there.

C

Okay, uh moving in now to the maintainers to Emeritus status, I believe I, think yeah.

B

So this is something that uh Eric and I have been working on. uh We we have, as far as we can tell we've, never actually cleaned up our list of maintainers right and these individuals retain some degree of merge and approval rights to the repos, which we've recently see a number of vulnerabilities in open source based on uh the wrong people having right privileges to repositories. So this is an effort to clean this up.

B

We took anyone who we didn't, have a recorded activity for in the last 12 months and tagged them in this issue to let them know that that we were considering moving them to Emeritus. We've had two reach out and ask that they'd not be moved to Emeritus, which uh technically the way that our our rules are defined. Commenting on an issue counts as activity, so they now have activity in the last year.

B

um This is just sort of a a wanted to let the other Toc members know so that if there's someone on this list, you'd like to see retain their their maintainer status, Emeritus maintainers are listed still on ends.org. Well, um basically, is we're thankful for their contribution, but they won't have any continued privileges to repositories.

D

Yeah, so basically, if you look in the community istio community in the dock, it basically says um find it here. It says if a maintainer becomes inactive in the project for an extended period of time, which we don't call out.

D

In this case we're saying a year, the individual transmission to being an Emeritus maintainer Emeritus maintainer loses their ability to approve code contributions, um but they retain their voting rights for up to one year and in that voting rights is um voting rights within the work group, um not voting rights as similar to the member voting rights right so and then, after one year, the um Emeritus maintainers will go back to becoming normal members, so they lose their voting rights.

D

So really all that they really lose at this point would be the ability to approve PR's.

A

Yeah and they can be back as active maintainer, whatever they wanted, if I'm understood corrected it is that right.

D

I think, as long as they do.

B

D

B

Between us sorry, I I think that if an Emeritus maintainer became active again, I wouldn't see any reason not to reinstall them once they're, no longer an Emeritus maintainer. If they became active again, we might want to have a conversation about uh maintainer promotion. Although maintainer promotions are not a big deal, uh we do them on a pretty regular basis. So, okay.

D

Yeah I I was going to say, I think you know to get it back during that year. It's pretty simple, make a comment on something they become active again um other than you know. We don't have any automated way to handle this at this point. At least that I know uh so they might have to you know they might have to actually ask in a PR to be, or you know, fill out a PR to become a maintainer, and then you know we just put something in the in the template.

D

You know, maybe that says, yeah I was I, am Emeritus, put a check mark and and that automatically gets approved. Otherwise, um if they're not Emeritus, then I would assume they would follow the same sort of template that everybody else does to become a maintainer, except for them. Most of that stuff should be um already satisfied at one point, so I don't think it's hard to become a maintainer again after you have been rolled off the list.

A

Okay, cool yeah.

D

But being that things aren't moving, the things aren't automated. It might take a little bit of time.

C

I just want to say this is good timing, uh because we are in the process of uh getting cncp graduating cncf and one of the things that cncf is completely. Let you still project is the number of maintainers. They think we have too much or too many, but.

A

Okay, do they have a guideline.

C

Well, I mean it varies. There's some projects over like 20 maintainers some projects at 40 I think it still have something like 80 right now.

A

C

A

There's there's a lot of different roles in ecoi they're. Actually, County 80 I really suspect that they're counting the wrong thing.

C

uh Yeah I think they'll take a look again. Thank you. Let's.

A

See yeah, maybe they can't remember now that I'm thinking yeah we have 400 members, I'm, not sure, but we have 20 of them are maintainers.

A

It does seem high, but I I think these are inactive. One could contribute to the AED.

C

A

Okay, so that's purge them. If there's no objection, yeah.

C

So I'm, just looking at team's thought, let's see, teams.yaml there's maintainers description, maintaining under the SQL project. It goes from line 15 all the way to line 81 so not quite 80. about 65-ish.

B

Yeah- and this is okay.

A

Yeah, exactly I was going to say that. So let's do that because we've already gave them a week to reply and it's easy to bring back like you get set.

B

Okay, I'll take care of that this afternoon.

C

Thank you, Mitch.

A

That's great, thank you.

D

Yeah I was just trying to quit that I was just trying to quick look at istio issue just to see what our numbers work, because I thought 80 was about right. So if I go back over here click on people and we look at maintainers.

D

Our maintainers lift right now is 86 members, so for people who have authority I think you want to see what I'm talking about uh There's the link that I'm on.

C

So Eric, how uh I'm looking at teams.yaml is that not the right place.

D

Well, teams.yaml, whenever a PR is merged, um teamstack yaml is update, it's GitHub, but the problem with teams.yaml is sometimes there's maintainers that are in a sub team and those will get picked up later. So the problem we have- maybe we should do something and I'll enter- um is to make sure that people are reflected in all the levels, because I think I had a slack with somebody. The other day about this as well um is that maybe it was Craig.

D

um The the the number in the teams that yaml of just straight maintainers is less than um what is on this maintainer list, but I think I. Think the difference is because sometimes we put maintainers in the groups so that you know within the work group maintainer. So if you go, you know scroll down right, there's you know docs and networking and stuff like that and I think you can put somebody down there and not be in the above list and they'll actually get updated in in the repo.

D

um So maybe we should do something linting wise to to verify that, but yeah.

B

D

Now, if I look at maintain the maintainer list on that link, it does say 86, members and I know actually maybe was talking with Mitch, because I know Mitch says in the database. It was like 86 or 87 members in the database, so those two numbers matched up.

B

Foreign, so we'll take this first step, we might have other steps to clean it up later on, um but this is a place to start.

D

B

D

If there was some guidance, you know we could maybe look back and say six months instead of a year um for someplace quick to look. If you look at the maintainer inactive maintainer list in uh or the active maintainer list, I think um if you go to end statistio and you look at active maintainers, that's only people that have been active in the last 90 days, so last quarter versus a year, and so that number is much less.

D

So you know you. You could probably pick somewhere in the middle of 90 days and a year depending on on where we wanted to be. If we had to come up with a specific number, if there was some guidance from cncf on that.

C

Yeah cncf doesn't work, or maybe the age other than I think even their their initial reaction of too many maintainers is compared to the other cncf projects. They they don't make it such that you know you've weigh up 87, maintainers they're not going to set for a project or anything. It's uh it's a comment. I, don't think it's a hard requirement, but we'll see yeah. There's lots.

A

Of things yeah ask them how many kubernetes has.

C

uh uh I, remember it it's a high number, but not quite 80.. Maybe it's a 60s or something okay.

C

Yeah I'm gonna have to um take a look okay, uh so it looks like we're good with that one uh anything else on folks agenda.

C

Right, if not, then I will end the recording here. uh Mitch do you know where we keep recording for this particular meeting.

B

This has a YouTube playlist as well.

C

uh Playlist or in this I mean in the same YouTube uh Channel this one, that's right.

C

Let's see okay, so that's under SEO, all right uh so correct should have given me the access right, the right permission to the istio channel, I'll um I'll, see about updating these or uploading. These I'll try to all my um Home Connection first. If that ended up taking too long like you did, I'll probably go in your office to go. Do it.

A

Sounds good. Thank you. All.

C

Right, thank you. Everyone yeah.

A

Thanks everyone bye.