Kubernetes SIG Architecture, 31 Aug 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Architecture Meeting 8-31-2017

Description

http://bit.ly/sig-architecture

A

Really Oh, unfortunately, the change of day seems you have changed quite a few, the participants as well, and it's both good and bad, but the last time we discussed the proposal process, which is our one of our top priorities that we're trying to accelerate Kaleb was I, was kind enough to draft something inspired by the rest. Rfc process where we ended last time was with my comment, which is last comment on that proposal. Let me just paste that into the chat community, PR 967 as we're gonna split it into multiple pieces to make independent progress.

A

The reorganization of the design proposals directory, starting with an attempt to categorize existing dots, to determine whether a categorization by cig or some coarser area, bucketing made the most sense Clayton had volunteered to do that. I haven't seen any movement on that.

A

Paul Mori I think had previously volunteered to take a whack at the proposal process before Caleb's PR, but I didn't see anything out of Paul either there were already a couple of requests to standardize the metadata attached to each proposal. Document and I. Think that's a relatively simple thing that could be figured out like just simple stuff like when was this last updated? What is the current status? Is it a draft? Was it accept it? Is it implemented the alpha-beta GA? What is it so?

A

People can tell the difference between half-baked things and more fully dated things the rest of the proposal template which has a bunch of car three things, because so what rock took a stab at some of this with respect to API reviews as well, there's a lot of overlap and eventually I want to merge those, but- and this PR has a number of reasonable proposed sections as a starting point. Let me just see if I can find it within the midst of all the comments.

A

No it's hard to read with all the comments. I can trim the comments off.

A

Oh here well, its sig's things like what cigs are responsible, summary motivation, examples, detailed design, graduation criteria, drawbacks alternatives, unresolved questions and those are standard, design, dock proposal, kinds of things that I'm sure many people have seen and proposals from many of their previous projects.

A

You know I, think there's there are few additional things which are super critical, like which themselves will need to discuss what the process is like how to actually identify who the approvers and reviewers are so that the person responding to feedback can distinguish feedback and needs to be resolved from just feedback from participants that needs to be taken into consideration.

A

You know ultimately will want to connect this to the feature development process.

A

Although ID the template is a separable thing from the process as a whole, so that was the I think last bit, I suggested peeling off oh and the communication procedure: okay, who should get notified, how they should they be notified? How do we want to do that? Do we want to have a single like proposal list that all the proposals get copy to with the link to the proposal?

A

And then the discussion happens all in the actual proposals to are the github teams, I created a reasonable way to go, and then people interested in proposals in several states can subscribe to those either subscribe to the Google group mirrors or to the gap teams.

A

So just I think these are a bunch of separable pieces that we can attack independently.

A

So we can make start actually making some progress instead of trying to boil the whole ocean in a monolithic way, I'd like to get owners assigned to each of these things, owners who will actually work on them. Clayton is SuperDuper busy, so I don't know if someone else wants to take a stab at the categorizing. These sourcing proposals.

A

But uh it'd be good to make some headway on this. Have some thoughts, opinions once volunteer I.

B

Agree that we can split out, do you up? Hey Brent? Sorry I had dropped in late here, yes, that we can point out the actual template for the process and communication regarding a new proposal process. I want to try and get some time with Jace next week. He's got some great thoughts about how to facilitate a planning process, and so I want to figure out how to how to integrate a updated template in that process. I. Imagine there's going to be three ish, probably primary ways of proposing a new change enhancement.

B

One would be a large-scale planning process where we have. You know: sig lead, whether that's the the facilitation sig lead or the technical sig we'd all together. So we can look at you know large technical projects that would have been proposed and staffed or driven by sig architecture or articular least one of the large cross-cutting SIG's. So we could produce some kind of roadmap and get everyone on the same page.

B

There also I imagine this is going to be a process that the SIG's will manage themselves for tracking their own, more limited technical agenda and then there's the. How do you get general community again, a community member who's not necessarily associated with any stake to get their process, their proposal through and merged, and so I think, starting with that framework, I'm going decent time permitting Jason I can try putting some thoughts there, but how an RFC would go through so but those three starts yeah.

C

Totally happy to do that with you Caleb, that's great.

A

Yeah, that sounds like a good characterization of scenarios. Anyway, it's not clear to me that they're radically different processes necessarily but one thing I was thinking, is as part of the kind of discount. There needs to be some sort of discovery process about figuring out. Where does this proposal belong?

A

The proposal might start in a particular cig or a no SIGINT, like in the case of a new contributor or the one could question whether a new contributor should really be doing anything usually significant, but the that there might be an escalation process. Someone says you know: cig released, really needs to review this or really needs to review it or cigar. Texture really needs to review it, even if it started in a API machinery or cig network, or something like that. Yeah.

B

Totally agree, I think that's where Jo suggestion to look at the Python process will be helpful. I think, certainly for the beginning will probably need dedicated people to help with the routing and the triage perhaps got editors focused on ensuring the process moves smoothly. I think we need a similar kind of community facilitation role.

A

Okay, so did you want to put the template sketch into a separate PR, or would you like some another volunteer to do that? I think the certain sections you suggested are good starting point I'd, just like a little text, boilerplate text for each one explaining what it is, and maybe we can quickly iterate and add a couple of things that need to be added and get that merged and iterate. Further on that, yeah that sounds good I can yeah I can I can take that as.

C

Part of that process to create those top level directories for each sake in your mind, brand tool so basically populate the three posts with the the directory tree and all that stuff. Or is it just to get the what the tablet well.

A

That's specific thing: I was talking about it's just the template, I believe categorization of the existing proposals and reorganizing them is a separate item. If you look, it I can paste a link comments. I suggested breakdown was here.

A

Which is I can paste that in if I can taste it I get it.

A

A

So I'm someone just create a doc or a spreadsheet. You know just do LS one on the directory as it stands and try to bucket each one into you, a cig or something and see. If that we believe that approach holds up or how many would be if we need a umbrella bucket for hugely cross-cutting things. We could have that also.

B

A

A

Do you that surely I really do okay, yeah I mean so I think it's one thing: we that's wearing my governance hat in terms of structuring the projects I think we'll need to have. In addition to six, we don't need to have an official notion of sub-project. That is finer, grading and zig, and that may well impact the design proposal structure as well. So just as a simple example, insta gaps we have helm, which you know is it in kubernetes kubernetes um and it's fairly independent.

A

So maybe it's not covered by this, but just as an example, and then we have the workload controllers or in cig network, which is maybe a better example. There's pod networking their service networking, there's ingress, there's network policy.

A

You know there are at least four or five distinct sub projects and there's some overlap and expertise and a little bit of overlap in people, om DNS, but the components are largely independent and the API surface is largely independent, so I do those as could be declared to be like dis, ting sub-projects have their own approvers and things like that.

A

D

And- and this is Matt Farina here from Sega haps and I kind of like the idea of using helm as a thing, because they have had to set up a little bit of their own structure, and so they could serve as a good template. Because it it's working.

A

Yeah and One Direction not going there, partly because it's so big and partly because of its position in my lair stock of being out in the ecosystem at least way. It's currently factored its functionality.

A

I created a github, org brown and I envisioned multiple pieces of the home, such as the main lifecycle driver tool. It go to go templates mechanism. If that is broken out into a separate tool like I, would like monocular could all go into that separate Georg.

A

They have their own separate releases, and things like that. So that seems like a reasonable way to go. Lets them get like one issue. They've had is that they don't have any org owners, so they can't add members they organ. If you can members, the organ can't have them steams, so they've just been at it outside collaborators directly, it's better repose which more or less works permissions wise, but they would have more autonomy in a separate keyboard. A.

C

Question that some point becomes in the this speaks here detects your model about nucleus versus the rest is when we talk about things like helm. Are we actually talking about radius anymore? Is this we're talking about.

A

Well, because didn't I wear a lot of hats, so, with my seen in CF hat I, am there what the issue that no Jess has with respect to this is that they decided they actually structured the foundation. So they have multiple top-level projects, but in practice there only two which is node and Express and there's really they decided they're not going to take other projects in the space as at least a de facto position. So they direct most some kind of user space or ecosystem.

A

What we call ecosystem projects to the JavaScript foundation, so they like it pushed into a completely separate foundation in another, really just for nodejs I.

A

Don't really like that solution for us I, don't see a kubernetes specific tool like helm ever being a top global project and since yes, skin CF is more broad intended to be more broad than just kubernetes its cloud native systems in general, and we want them to work well with kubernetes. But you know they're not necessarily only for kubernetes like if you look at Prometheus or a link or D, you can use them outside of kubernetes right.

A

So but I do want a home for ecosystem projects and the kubernetes project I think is big enough to host some of those projects. I do think you know ultimately most the developments, and this is probably already true that most of the development is going to be an ecosystem, a non non foundation, repo owned repos, that's a healthy thing.

A

In my opinion, that's the only way it's really gonna scale to massive levels and produce lots of opportunity for businesses to innovate, and things like that you know, but where there are kind of substantial things that are broadly useful for lots of people in the ecosystem.

A

We are gonna need a process for for taking on those cutner projects and we've taken several already. We've taken home, we've taken kubernetes anywhere, we've taken cargo.

A

So well I'll at some point: I want to formalize that both in terms of the process for onboarding those kinds of projects and for how they are managed in a broader ecosystem.

A

Speaking of my just shifting gears a little bit speaking of my layers proposal, I, don't really had time to work out any additional details lately, but I would like to get some directional agreement on the basic direction. So I sent out a summary this morning. How I see my different initiatives sitting together in terms of the layers extension mechanisms like API, aggregation and initializers, and a Mission Control extension, multiple repos feature branches, breaking out things like cloud provider, deprecation of Cuba and development of a stack of cluster lifecycle management tools like humidity and hops.

A

All those things are related in my mind, like part of a coherent direction that basically I tried to paint that picture and that email, but I, think it would be helpful for people they're, actually a lot of directions, I'm pushing pushing things, whether it's moving functionality out of keep control so that it works with extensions, yardies api, our tradition, other client, nan, go clients and so on or.

A

Pushing things out of the main repo and there are kind of a lot of things in flight that were that we're moving towards that aren't really captured very well anywhere. There were a couple others, let me see if I actually remember to write them down in my notes.

A

Oh yeah I'm, graduation of the workloads ap is and to the apps API group.

A

Anyway, I was working a list somewhere I forget where I put it, but you know in aggregate, that's gonna be a pretty all those things together, gonna be a pretty significant changed that how things work now so somewhere I would like to start assembling that vision so that across the entire project, people kind of know where we're headed, because even within Google, it's clear that not everybody really understands that, and a hard team is growing big we're in multiple geographies.

A

Lots of things are moving really fast.

C

So I have a couple concerns. One is sort of one of the rules old time. Rules of operations has never turned more than one knob at a time, because you don't know what actually improved things are made it worse. How do we, how do one increment these in an agile way? So we're not just like you know, burned down the house and then try and build another one? How do we? How do we do this incrementally into?

C

How do we measure efficacy of these things and what are those? What are those benchmarks look like: how do we determine those? How do we, how do we enforce those and ah they're.

A

Getting better so.

C

A

Me tackle this second one first, because that's another thing I've been pushing on which is wearing my sig contributor experience. Godfather hat the UH I think the most critical thing we actually need is actionable metrics that we can use to manage the project because long past or the days where I could just look at all the outstanding issues. All the outstanding key honors all which PRS are signed to which person make sure they're all getting reviewed, figure out.

A

Whether everything that needs to be in the release is in the release or to file things that shouldn't be in the release. Stuff like that, the uh so with CN CF I've been working to. We actually had a couple of people who were working on metrics like Antoine, build velodrome. We weren't able to sustain the effort and get pushed over everything we needed so seen. Cf is: has a contractor Lucas who's working on two approaches?

A

One is investigating whether he can simplify velodrome to make it easier to add new metrics, because the way it built its data models is kind of super painful to add, metrics and weird that we're gonna pay for SAPO.

A

So a our kubernetes users and they'd go some dashboards as demos for us for free, but one of my goals is to make it easy enough dashboards, ideally without coding. If we can quickly get whatever metrics, we find we're lacking right. So things like just just as one example: I watched the commit rate graph on github for the kubernetes communities, repo on a pretty regular basis.

A

I actually was thinking of getting some contributor experience. T-Shirts made that to tilt the graph up and to the right but I, see if I can too many windows, people don't know what I'm talking about here. One thing that happened in 1.7 release is we had our lowest commit rate of any release since 1.0.

A

So is that a good thing or is that a bad thing I don't actually know so it would be super useful if I just had a stock graph of all the repos that roll into a minetti's release, so I could see what, where those are, those commits, shifting I believe they.

A

That is the commitment, I.

C

A

Success that the commits have shifted into other places, but it is also true that one thing the velodrome did to you is produce graphs that show that cases longer and longer to get stuff from for most people right people who are paired up so that you have someone who can review and improve your PRS for all the PRS. You writes, those people are fine and happy and they get stuff emerge quickly and, like everybody else is screwed and it takes longer longer and longer.

A

If you look at like the 80th, their 90th percentile or probably even like the 60th percentile, that the median amount of time even it takes to get something merged in kubernetes communities master, it has been monotonically increasing for almost the entire history. The project, as we add more contributors, it just takes longer minor longer.

A

So so those kinds of metrics things like how many, how many pull requests are? Does each approver getting or is each reviewer getting? So we can tell whether the auto assignment is working correctly or manual. Routing is working.

A

Data is something I used to check manually and I no longer have any insight to that.

A

The leaderboard issue has come up recently like how do we actually identify candidates for new reviewers or approvers, or you know, people who are proposing membership, so it was right, Nikita's tool, so that someone could like put together, run this tool to put together a resume. It does propose that they want to be a member or a reviewer, approver maintainer stuff, like that.

A

We need visibility at scale basically and then, if we had those kinds of metrics that would enable us to be able to tell maybe not which cause and effect, but in aggregate whether things were headed in the right direction or not, and right now like we can change the PR workflow. We can change labels and bot commands and owners and whatever, and we have no idea, it's making things better or, worse, really other than anecdotal evidence.

A

Heeey so I guess you know what do we do about? How do we make incremental progress? And what do we do about changing too many things at the same time and the multi repo thing has actually been an incremental process that has been moving. It's been happening for over a year.

A

It's made, it's been more visible lately and made more noise, but the since it was becoming harder and harder to get things into. Kubernetes communities faster and hearts, build abdill, API, isn't harder to add beam components and we added the incubator process and things like that. Things had been new things at least have didn't each other repos for quite some time. In order to facilitate that the API machinery had to be made available to of the repos and to other cohorts, which is why all the staging stuff was added.

A

Now we're at a point where that stuff is still developed in communities, communities master, but it's copied out into other repost, so they can be eaten. Maurice we've entered in since we saw cases like helm, had to basically copy a bunch of kubernetes api machinery and manually whack at it. Until it was usable in an external client now, hopefully, with things like client go and the other client like that, hunger client libraries that we're working on doing that kind of stuff is much easier.

A

We need to get to the point where we have an SDK for someone who wants to build an API. They can easily whip up an API server generate the types generate. The client libraries, whatever they need to do. That's kind of the goal is get reusable API machinery.

A

Other projects, even that we want to be able to reuse that API machinery, not just other like aggregated api's or non aggregated kubernetes api too many style api's. But you know some closely related projects, we're at the point where the general kind of tooling and meta programming you can do on top of a kubernetes compatible api is a useful thing. So this is something we've actually talked about since 2014 we're now at the point where yeah it'd actually be really valuable to what to enable people to experiment with, for example, infrastructure level.

A

Api is to make it easier to port kubernetes, but have those be you know, non aggregated, api's or SEO is actually considering using kubernetes style API, so that users can write a consistent configuration style.

A

So yeah I think that's where, in the the staff diagram, the API machinery I view as means to an end, it's a library all right, so that's not the whole nucleus. It's just a building block for the nucleus. Dot stuff can be potentially moved out and just be an independent project really, and it's not really domain-specific, and then the nucleus would be the usage of that API machinery for the core of kubernetes, which is executing pods on nodes right.

A

So the API server plus the key blitz, is really the core of everything that kubernetes is and everything else is kind of built. On top of that,.

A

So I think I'm done monologuing. For now it was a really good.

C

Next time you'll have to do it now you have a container to go yeah.

E

I mean I feel like I feel, like the documentation and this the establishment like for cigars, like getting the system diagram, getting the that how the pieces relate and trying to push through.

E

That, like is one of the responsibilities of this sig like if there's one thing that I thought the sig really has to do is once they like, be able to answer the question: what's the architecture of kubernetes and how to relate to everything else and so like, even though these things are coupled with everything else like like we, what do we have to do to merge the things that are uncontroversial and are correct, it's fast and then to get through the backlog of Sagara things to get to the next step, like that's, what I worry about is I continually hear people ask what is the architecture and I think we have an effective de facto answer, because we had an architecture for three years.

E

We just we were always afraid a little bit to say like this is the official architecture, but I mean, let's be honest, like the combined consensus of the long term contributors, maintainer, xand area owners, roughly parallels to what brian has and they'll be details that are wrong, but, like I, don't know that there's anything egregious there. What can we do in the short term to get some more formalism around the architecture so that people can relate to it and see where we go from here.

C

We need to bring it, we just need to draw a line in the sand and say those documents are actually the architecture, and this is how I'm moving forth and.

E

I think it's a good chance to test the process of there's reasonable consensus. They'll always be a small amount of legal stuff. Can we put the lazy consensus model to a test based on cig architecture, the people who attend missing, as well as a general communication that we have done enough to make other SIG's and other people in the community and gotten the right, given an opportunity for feedback to happen and started like building up the the momentum on a process of sucking these things into your capture? Form right.

A

Yeah I mean along the lines of the architecture, diagram I, think there are a couple of different views. We need to create. One is the component level view I'll paste a slide in that you've probably seen a lot of Googler presentations. It's not a hundred percent.

A

What I want to see in the diagram we put into the repo but I think it's closer than the eight old diagram that I removed the link to and I'm just going to delete, I think the PG&E s SPG of the thing that shows C advisor as a component on all this kind of stuff, but- and so part of my objective with the sig- is to get stuff out of my head into other people's heads.

A

So I really need for the things that people already might understand, like what components are part of the community system and how they talk to each other and I.

A

Like this diagram, my route really would like someone else to sign up for putting pen to paper or typing it or drawing a diagram or whatever, and then I can review it and say yeah that reflects reality and intent and get that checked in because I'm SuperDuper time constrained and but also because you know it's helpful, to confirm for me to confirm the degree to which other people actually understand the direction things are going like I can just push things out and then often I hear very little direct feedback, maybe because I black hole gap notifications, but whatever I think it.

A

I really really really want to broaden the participation and get more people involved and more people will happen. Transfers on that institutional knowledge.

E

Yeah I think if I was, if I were to say that I think an important goal.

E

The communication is the first goal and the second goal is ensuring that maintain errs in maintainer zin and influencers and drivers in the kubernetes community are aware of, and can reference back to some of the captured things, but also understand how to ask questions and like that is the goal of the sig it's starting to have when people are coming here, but we're still doing a lot of the process side versus the actual access. This is these.

E

Are we need to move forward, so I don't want to volunteer, because I feel like I know too much of this as well. Yeah I was gonna, say that I'm not a good confirmer of breath, Ryan, because a lot of its in my head as well so I would prefer someone else step.

A

Yeah I think it has to be someone other than me clean or Tim. Basically,.

C

Well, what's frame on this because I'd be willing to do it, but I just tied up with this one did a release so yeah.

A

I mean you don't have to do everything either and that's it. This gonna be successful. It has to be more than like two or three people, yeah acknowledged. Otherwise, it's like a total waste of my time and my time have you better spent just spewing out Doc's right.

C

Well, can I ask you an odd question: Brian um yeah. Does anybody oppose you on this? Do you have an archenemy or an archrival that like has a totally different vision about architecture than you or you? Are you sort of like the yeah? Okay, no lab somewhere that you just come up with this stuff is well Joe's, not here so I'll take on Joe.

C

A

Has come around on some things like multiple repos but yeah I'd, say Joe happens.

E

Me more than anybody and I think challenges that a lot of those discussions happen inside channels or in specific issues and part of the goal, for this was to start surfacing the decision and discussion process to where either we agreed to disagree, whether we identify who's, gonna, go really chase it down and take ownership for understanding the difference between the two two or three or four positions. Brandon's got one, you know, API evolution has been one. Let me talk about labels and labels is actually a really thorny problem.

E

It's very difficult to establish the stake in the ground once some consensus has been reached, such that other people can benefit from it and I think like Brian spewing up, the docs is useful. Someone expressing some form of someone who has acted as an opposition force or a point of disagreement or whatever to any position, doesn't even matter like I disagree with Brian up things like he's crazy and less to go.

E

Remove conditions getting that process of discussion happening in a form that is consumable by other people is the singular failing of this project in terms of at the scale we're at. We can't afford not to have a way to to thread that so.

A

Yeah thanks for posting those examples to the issues by the way.

E

And, like you know, in a lot of these discussions, there actually are concrete examples if the sig like, if other so, maybe like Matt Brian and not knee to some degree, although I should do more of it I'm creating dots that capture a position yeah.

A

This is something is complained like some of the marathon issues that we're discussion happened. You know way beyond sent to thread like pillow thread issues that went on for years, and then we closed them with no summary. What happened and they've.

E

Already decided this in this thread here, seven thousand issue: there's seven thousand comments on it and github won't load it correctly anymore, because yeah what's up, you look bad it anyway. So.

E

So I would say, like rubber-stamping Brian, having some point of comment, feedback to make sure that the rubber, stamping is actually things that no one funded lead it'ss agrees with I think. Maybe their argument is that participation in cigar to some degree requires the time allotment to to the backlog and to offer meaningful feedback, and we need to figure out a way to like, because we only have a maintainer of cigar stuff. Whereas for like the code, repose we'd say you know, your responsibility is to review all of the PRS that come through this process.

E

We're actually lacking that today and a lot of the process stuff is that no one is actually required in order to be seen as participating to go through that process. Yeah.

A

So one thing I will want for this: cig is to decide who the approvers are, and then you know like with every other part of the project, will want to expand that over time. Just as an example, we do have kind of an official notion of API approver.

A

It doesn't court its kind of cross-cutting across all the code, but that is a small set of people who have been who've done a lot of API reviews who participate in the the API conventions and enforcement of them over the years. So we just officially added somebody who should have been added a long time ago to that group.

A

Jordan liggett's I view that as kind of under the umbrella of sega architecture as well, although Jordans not here and Tim and Eric, are not here, but you know, there is kind of a de facto set of people who make those kind of decisions. Similarly, for architecture, I'll, probably start small with the people who basically created the architecture that exists, and that's basically me Clayton and Tim, and then we can decide like how to expand that going forward.

A

But you know, as we get these formalized some of these de facto processes I, think that will help, but I would like to start I. Think one way. Method of attack for Sagarika texture is to start high level and get basic direction approved, and then we can iterate on flushing out the detail, because if we block on all the detail, I think we're not going to make a lot of progress.

A

So that's where you know having the component level ambu checked in and then maybe some simple texts with an outline. Yes, Maya notification, page. Actually it cost a gang-up outage. Is that sense? Yeah there was, it was actually correlated. Somebody confirm it yeah and for a long for a long time it it pulls up the pink unicorn, but I didn't realize it actually took them down yeah. So if people notify me, I came in search for notifications on yeah yeah.

A

Yeah so anyway, about 3/4 away cure time so greatly.

D

Miss Matt, Farina I was just gonna say because you're looking for hope in this, so in a number of ways, I'm not sure how much I can engage at the moment on it. But if you start at the top and work into more detail, I'm happy to be a sounding board or engaged in that if you're looking for somebody from the outside, at least, if something you know because you've got it in your head, it's harder to communicate it to people who don't know I'm happy to be involved in this. Okay, thanks.

A

So I'm gonna pick on you for stepping forward. Do you think you can put together a component level view of the system similar to the link I dropped in to chat and capture that in a PG or something that we can check in the repo sure it'll.

D

Be a few days but yeah sure.

A

A few days is fine, I mean it's been a lingering issue for dinners sure.

D

A

D

A

Cool something with color would be good. I didn't really like the black and white thing they would add. Before no.

D

I can do something with colors. That's no problem. I, don't.

A

We don't really have a standard tool or form. Some things are just P and G's that people created using I, don't know what tools, maybe Google drawings or something and some things are SPG's I. Don't really have a strong opinion. I can't really recommend a tool. Oh I've.

D

Done enough diagrams over time that I'll come up with something that has a nice output that can be embedded at the same time, we'll have the source to alter later cool good, not.

A

A

Circle back on action items Caleb, you said you would break out the template into a separate PR, yep cool Clayton, I think is before you arrived. I want to reassign the categorization of design. Proposals of qiyama already done it I mean I was I was about to. But if you want to reassign some house I'm happy to let some costume can we get another volunteer to do that? I I? Wasn't garrison I'm trying to do it or Garrett Ballentine I, don't know what thread number was.

A

Euler Euler.

A

Alright, well, if I can't can another volunteer wit? What how soon do you think he can get to it? I was gonna.

E

Look at it tomorrow, I mean Italy, with code freeze coming up I'm getting slammed with approvals, which is the only reason I hadn't touched it this week, yeah.

A

Thanks for picking up the slack on that I've been distracted by the thickness I think everybody's similar to strive to this release. Hopefully.

E

We don't get a huge surge of approvals on Friday. We've actually had a big surge this week, so we're doing something right on the release site.

C

I've been pounding, the pavement at every signature in get people are working on this stuff, so Caleb's been doing the same thing.

A

So, even though it's more of a sort of a contributor experience such thing as related to the communication from protocol for proposals, how do people feel about the all the key hub teams and every project I've been on, has had multiple mailing lists to segregates, like bugs from discussion from design proposals seems, and that's been true, multiple projects, multiple companies. It seems like a fairly standard thing, but I don't see it used super consistently.

A

Is it much bureaucracy and for the people like Jase or me, or Clayton or Brandon, who are trying to keep track of things in multiple SIG's? It's pretty much impossible without some kind of way to filter stock.

E

It is interesting because they get the bot integration. I feel like I've, noticed people doing the correct thing which to the botton gives them the worm ring about not being assigned to a sig and I have seen people mention I, don't know that it's totally clear that people know how to map to SIG's, but.

A

I have to think seems to be a lesser problem than mapping to the correct categorizing. What kind of thing it is yeah, I think a.

E

Lot of people just pick, one of those which, in practice for non overwhelms contributors, does end up being fairly effective. I mean.

A

Like we'll pick, misc, which.

E

At the end of the day, as long as some I mean again like some of this- is like ad hoc q minutes small scales as long as as long as someone gets the notification, it's reasonable, it's more. The the builder loans volume ones that tend to be a little picky about which group it is I, mean I'm, seeing it used and I see people using it to coordinator I. Don't know that it's like anecdotally, it's at least 25% or 30% of contributors- use that to get attention.

E

I do see a lot of people of using the assignment. An exhale I can find 10 people.

C

One thing I've noticed, though, is that a lot of the github teams across any particular sake is like an 80% coverage of the same people across all the teams. So I I don't know if people if SIG's are being super selective about who gets added to the various parts of the team like it'll, not the same 10 people across the board, and then two people will be different per four things, but.

A

That's fine if one of those people is me right, like I, think.

C

Working hasn't ended if.

A

I could actually pay attention to proposals and ignore robots right, fair enough. The point yes.

F

Sorry, sir I would suggest through to work a bit on the documentation to describe what is the purpose of every ever team, because discretion has been raised multiple times. I agree the twirling needed stings, but the biggest concern from multiple people that don't really understand. Why do we need these teams and why they simply can use the single team for that so yeah it has. It has to be simply documented and I would also add a requirement when you're creating an ad team.

F

You have to you, have to add a few lines about like a description to to the team and get it up. So any person who is looking up for this thing and understand what what is the merge to perform this day? Well,.

A

Just to give people an idea of the direction I would like to go is Jovita at some point in volunteer to develop a tool to sync from a yamo file to github.

A

That's the direction I would like to go is to actually manage the membership of all the teams and files, and then we could write a description there and synced out to the github description because go you know, as most things doesn't provide great mechanisms for managing those things, and nobody can audit who why people are added to teams or when people were added or removed, and we did that and things like that.

A

Unless you're an owner at the org I, agree about the documentation and there have been questions about what are these teams for, and it seems pretty mostly pretty obvious. Is that something you could take a step out Eve or is flushing out the documentation of that yeah.

F

A dictum, okay.

A

Great, what do you think about eliminating the missed teams or, and instead now, that you have supports nesting, we could have an umbrella team or something like that. Yeah.

F

Been thinking about it but I, don't remember, we probably may have some limitations by github. As far as I remember. Somebody has raised this concern as well, but I don't exactly remember what are their concerns were and for now so.

B

It'll take a look and.

F

We'll figure out the umbrella team umbrella team, scented tree structure will broke for us. Okay,.

A

I know otherwise we could rename all the mist teams the way I did to some of them and say you use only as a last resort or something like.

F

A

Like I, don't care if the mist team is notified, in addition to the other teams, really I guess, because I can just haven't subscribe from all the mist teams right. If that's the only team that's notified, which is what I usually see, then it's not super might as well not notify anybody. Yeah.

E

I agree having that having a group team, also I mean it smoothes. The initial thing like having the mapping between a cig and a general purpose group and then ensuring that some things can get escalated. Is it you know it's a generally good pattern like that, but I, don't know what I'm doing I know what I'm doing yeah I know what I'm doing having value for other people who are working like is. It's probably works better than just uh people use mist because it looks like I, don't know right.

A

Okay, so anyway, we're about out of time. We have these some things, people volunteered to do so thinking you could out. Hopefully we can make a little progress over.

E

The next week, one thing another done or before we 42, where you go. Another thing it could happen is something like we need to start mid when you start tying the mud, your labels, more closely into mention lists, which is health adjustment, yeah yeah, exactly like API change, should notify the zig zag okay group.

A

Automatically I like I, don't like that. The direction we started with was, if you notify, will automatically add illegals for you. Yep people find the bot commands more intuitive. Well,.

E

And the bot goes and identifies things by code as we split out more of like again like we don't have formal, we don't have a formal process in place for a ton of things, other than code review, code, approval and API review as we develop more of those tying those two groups in a strong fashion. So that is a unified. Consistent thing might help yeah.

A

Okay, anybody else have anything.

C

No actually I did that. One thing that I'll put it in the backlog, but essentially we need to determine I'm writing up a proposal on this, but for outside projects. What is the graduation / admission criteria for release blocking and merge blocking tests for external projects, because, as these develop, there's going to be a tendency to want to have everybody put their thing in as merge blocking or release blocking? We need to find a way to sort that out.

A

Well, yeah, and so one thing you might be able to infer from the email I sent out this morning is I. Think we're gonna have fewer things blocking releasing the core bits and making integrating all the things is going to be a downstream activity that.

C

Is as I would hope, so the road between there- and here is this for uh I guess what we'll talk about in the meantime. So yeah.

A

So are those getting disgusted, stick, testing or Sigrid's aware.

C

Hopefully, you think, release and suggesting, but I'm gonna write up something and I'll distribute it well. I I think that yours is the target point right. That's branching! All that yeah.

A

I mean the current reality is 2.0. It never works, it's basically a candidate, because everything comes together at the last minute people, like flip, you know bender and big changes or change which dependent component we're using or.

A

Whatever it is like, we always find out seemingly at the last minute, and we can't get people to try. You know if we're shipping a new beta release every single day leading up to the dot zero. You know we're not gonna, get anybody to try those and give us any significant usage or key back or canary.

A

So I can so we changed something major about how we do development. The dog zero is never gonna work, okay, yeah agreed, and we need to turn. We need to try to make it work every single time or it's really going to be doomed, but I really think getting the develop. The core development out of the main repo is the only way we're gonna be able to make it stable. No Jess has been in the news for not great things lately, but you know they have a model where stuff they hits.

A

The development branch doesn't automatically go into any release. They also have much higher test coverage that there is the good article by Daniel better about the Linux model and I mean kind of going 100%. That way is it going to work for us. We can't pay ten people to just full-time, merge branches together.

A

But the how we do need to keep have some branch- that's relatively stable, that we can vet. The features are fully paid, tested, documented, etcetera before we cut the release from that branch, yeah agreed well.

C

That's it for time, Brian, thanks for all your work on this and thanks for videos pretending, especially given the meeting time change so office hours in exactly one week from today and we'll see you then hopefully, okay.

A

Great yeah, it fun, you have agenda items, we have an agenda doc. Do we? Oh.

C

We do yeah and I've been taking notes in there, and also we have the architectural backlog, that's in the github repository, so that's also linked up yeah.

A

So if you do have something you want to discuss during office hours, please try to send it and put it or put on the agenda yourself. So we can talk to that people with a meeting thanks. Everybody.

A