Hello all we'll get started at five after so some Pretty big news. It looks like Google won over Oracle in the Supreme Court over the Android API and Java API issues Yeah, I'm seeing that big news Are we supposed to tear or? What are you supposed to do? Keep writing APIs Now you don't have to worry about Oracle suing you for adding two plus two in your code Okay, instead you just have to worry about Google now But we cheer because it's not work or it Exactly Jeffery, can you post that Google doc to the chat? Zoom chat having a hard time getting it up. Actually, I may have spoken too soon. Got it up. Oh, cool. Thanks alright, so If you have an agenda item, please add it to the meeting notes with your name and Add please add your name as well to the attendees list Does anyone have any walk-in items? Try to share my screen here. Okay, and Let's get started. So let's say we've had at least one PR Just point out that got merged during the week since the last weekend The last Hey, yes Your steps not working like I don't see anything. I'll just share for you and Scroll around for you. Oh, you don't say you're this screen at all No, and I'm realizing in the last call that your screen was pretty much frozen like on one frame for like the entirety of the call So I'll share for you and you can kind of just tell me where you want to go Thanks for letting me know right so starting with the This I was just listing some of the PR's that I got Closed so that we can everyone's aware and This one is Around governance so good to point out This is the mainly a refactor to make things consistent that Ian worked on and then added some a little bit more information That we've been discussing for a while Around how we would handle representation and that's towards the end but I think the primary thing was clarifying the wording and then bringing it All into one section, which is the bottom part. Yeah, I mean I think I Would hope we never actually actually never have to use this section but the point is that its presence should basically Keep the whole thing under control That said what this does right now is it talks about how to determine whether people are Potentially, you know over representing their company, but then we've got to deal with some other elements of the Charter which haven't been covered in here because at the moment we seem to think that Representation representation is per company rather than per person and I think that's probably not where we want to be in the long run and We're about to do a tech lead election and the tech lead election is also a bit confused in as much as It would be effectively a majority vote per tech lead gets you in which means that if there is a cabal a group Over you know representing people with anything close to a majority then they can Pretty much push all the you know as many tech leads as they care to name into Into the system quite easily I don't have answers to either of those things I'm just going to raise them and leave you to decide what we want to do about it But I think those two points do need addressing as well. All right. Thanks, Anne Let's move on to the next PR Set of PRs All right, so co-chairs from Bill So this is the result of the elections that we had and We have Three co-chairs Right now the Equally split and as we're moving forward talking about things we can decide what we want and how this works out we have Jeffery salons and from charter communications as the service provider co-chair Ian Wells from Cisco as the CNF developer co-chair myself for the cloud native and kubernetes and This is updated in the charter and the Main read me There's another I think comment about maybe moving some of this out of the charter into a standalone document for the items that may be updated more often than the Maybe our base charter things that we don't expect to update maybe for years to come versus things like this Which will at least be recurring and there's others But we'll tackle that in a another PR I think that was one of your suggestions and that we make those updates and I believe that your Okay, with tackling it in another one Yeah, can you guys find? Okay, great. And so I Think this one is just a notice so Let's go ahead and merge this one Jeffrey and go back to conversation Click the conversation tab. Yep. Cool. It kind of feels like 2020 21 You can delete the branch, okay, yeah, it's good. Otherwise we end up with hundreds of old branches Yeah, just as a general bookkeeping I noticed I had some from previous merge requests that I went in and cleaned up a week or two ago So if you've got some like ones that are hanging out that you don't think are needed any more Go back and then do a little spring cleaning to the group at large Um, good idea. All right Ready for sub directories. Yeah These are ordered and hopefully PRs that we can quickly knock out before we get into some longer discussions and so this one is one Lucina put in and you're on the call if you'd like to speak but the quick overview is it's adding Templates to make things easier for folks Creating a PR for different items and we can add multiple templates in the sub directory Lucina you got anything to add to that. I Just started with the the folder and the general and then if we want to add a Use case full request template we can do so and as well as the best practice And play this can be added with a folder And a new PR. I think this one can be those with just the general and folder Any objections before merging that The general plus the sub directory Yeah, that's good. Probably the only the only thing that I am seen Um, he's just regarding the headers. Um Well, because I've probably the the linter is going to complain about using um Not the proper headers, but yeah, it's something that I can fix later Once that the super linter is March Sorry, I didn't catch that No, well, the only thing that I was saying is like for example description and all the others headers Which are in the the document Jeff if you can go back to the document um, yeah, it's using This is a different header instead of starting from the first one So the the linter is going to complain about about this disorder but I mean, maybe something that I can fix later once Victor can we merge this and then I'll make a note to create an issue and you can go and touch it Yeah, that's fine Are you saying it had no header? There was a miss The header if you looked at your own level two headers from the start, which is going to throw the linter off Yeah, so the template could have a if if we were going to do anything that the simplest would be doing a suggest edit and then add general template or whatever you want to put at the top that um That can be added in a new pr Yeah, also lucy and I won't step on you anymore. I'll let you um Do the note taking so i'm not writing over your stuff Oh, no worries. Thanks for your help Is that how you spell winter? Yep Moving on Victor anything you want to Well, I'm not basically this uh, keep it action From my understanding is just checking them is following for full requests So for now, it's not taking any effect, but for new ones is going to check everything So I don't know if We decided to have it or not a great idea or what you think about But just a suggestion for another tool to minimize Yeah, I think the answer that you just let's commit it and try it and if we hate it then we can fix it Yeah, I like that approach Why not everybody okay with that? Does this um only complying or will it try to auto fix? I think only it's going to complain Is it going to block the pr until the misspelling is fixed? Hmm um Do we have the set in the in the um The flow the get of actions flow to block um I'm not pretty sure Uh, the latin is like oh, yeah, yeah, but it is not active because it's just It's just checking on on prs Mm-hmm. I don't think I mean And again, that's another reason why I say just commit it and let's see if it causes difficulties, but I don't think any of the um Any of the checks are actually blocking Um, I think you're just you know on your own recognizance to fix what they report at this point That sounds I'm totally safe to me if we're saying it's going to give you some type of feedback But it doesn't take action then I'm For merging Yeah, and if I turn out to be wrong then it's you know 20 minutes to fix the whole thing. So I wouldn't um I wouldn't get too wrapped up with that Wow We reviewed it in the future Jeffrey for says problems So right apparently it's not being committed for three weeks All right, victor you're up again Yeah, um Well, this is a little more controversial because it touches a lot of files. Um, probably the most controversial thing is like the The line length which is set to 80 So we can remove that if we decide like it's not something that we want to keep I mean the only technical reason that I have seen is regarding historical Way to do it but um Besides that I can this lean turn is checking Markdown syntaxes Other things from other files. I mean it's not just considered um Markdown files also consider like jammel or Shell scrapes or anything any documents checking the proper syntax is and I think it's useful, but we have to configure in a way that we want it so Probably the only thing that we have to discuss here is like If we want to use it and if we want to use with this configuration um I actually do like the line length limit, but it does seem to be causing a great deal of mess in The way it's breaking links up So I wonder whether we can commit this without the line length limit to begin with and then see how If we can get a slightly more tailored solution to that part of the problem later Yep. Yeah. Um, the only thing that I have seen is in some cases when I am doing reviews in on on github I have noticed that The parser is not It's not detecting the differences or the suggestions. So But Maybe is is another is not The line length is another reason Yeah, I mean honestly, I I agree with you and that's why I wanted to see is start wrapping our text because the Diff is terrible without it um, but on the other hand The number of changes you'd have to put in there Breaking links across multiple lines and this sort of thing and if we ever have a particularly long url. I don't know what will happen. So um It feels like if we Skip that for now and run a few experiments to see exactly how it's treating things then that would be um Better and then at least we get the rest of the benefits because I think the header corrections that it was doing Where it picked up on the fact that we can't nest headers properly by by eye. Um, that was quite handy to know actually And another thing maybe we can start doing like suggestions like uh for future prs we can encourage to reduce the number of lines, I mean Not not reducing the paragraphs, but I mean at least reducing the formatting Away, maybe in the future if we decide to use it Uh, it's not going to be Painful like this point So disable line length for now and resolve the conflicts. Is that Yep. Yeah It will need basically rebasing on the latest master because again if once we do that then The the template issue will basically pop up This one's pretty uh pretty boring Anything to say taylor in Um, can someone just run a oh, I see it's just a um, uh character. Okay. Yeah, I forget that. Um Yeah, no, I Still think well, I think it's weird on one count that this is the second use of use a story when it was the use case When it was the first one committed, but I still not entirely convinced on numbers But for as long as we're living with them then there's nothing wrong with this Maybe and do you want to so merge this but do you want to open up an issue to talk about like what mediators are going to apply I would include something around also mapping. Um, I think we talked about this last week mapping use cases To best practices, etc Yeah, and I think we might need a design document area as well, which we haven't got yet, but yes Taylor, do you want to talk through this discussion? Sure, so this is related to representation and Community Who's involved in the community? He's contributing. There's a lot of things that this was tying into in various conversations and The most recent thing where this is applied was tied in with elections And there's a lot of feedback as we were already in the election that the Seems an interest to move towards individuals voices versus The organizations And so the idea here is to switch the whole interested parties list to show individuals while also showing who they're affiliated with so when we have Whatever company it is if you work for google or Jeff I guess jeffrey you maybe could be a good one so charter communications I think if I didn't put a link to our chart or the interest parties document but where it says If you can open that up they in the cad base and then the The interested parties mark done so where it says charter communications it could now say You're there on the top five We would say Jeffery salons comma charter communications or something like that and if there's more people that's fine at charter That's great actually. So we have a big list and this has no impact on the way we're currently doing limits or the representation PR that we just Did that and worked on that we just merged This is only changing this list. So we could still Look at it and say, okay, there's five people at charter They get one vote if that's what we want Any changes to how it's used would be outside of this PR and maybe another point is we already have a mixture of Orgs and individuals so Frederick as listed there Mars, Nikolai, and then we have Orgs And this would align us more with how other groups have been showing it. So there you go So this this is a get-up discussion and if if there's if I guess we're trying to get some feedback and if folks agree then We can create a PR. We'll need to add the names for the people which I have some of the contacts bill when he's back has Probably the the rest of the list. We could just add the people that put on their names on there but if you already know then we can do that but The PR chain would change that that document to have individual names So how much more of the charter would we have to change if we did this because again the customer voting Sorry customer the the company voting Seems like it would probably have to Be removed to if we were going to flip this round, but um Ian you're you're cutting out for me. I got like one in five words. I don't know if that's Again, so so would we want to remove the company voting part at the same time as we do this? I mean if we're gonna Would we want to remove did anyone else here in? Yeah, I can hear Ian fine. I mean personally Ian. I'm fine with it I mean if we end up having weird hostile takeovers later, we can address that but um Long and short is if you can represent yourself And we're gonna like try to like block people's votes, which I don't think is gonna solve a whole lot Then they'll just list themselves as individual representation anyways, right? Yeah, it was more that Those things stand then if a company is an interested party, then the company gets one vote if we flip it to a Individual being an interested party with company representation then The stuff we've just committed make sure that their company is not over represented that's dealt with But the the bylaws specifically say one company one vote. I'm wondering whether we take that out at this point as well Yeah, like I said, I mean This is um not changing anything about how we use the list. We could stay the same where we Have one vote per org and one vote for an unaffiliated And we still have the thing where if two people Are from a company you can't say i'm unaffiliated If you're if you're actually there soon as one other person from the org So this has no change on how we use it the main focus here is to allow us to communicate a larger number of Individuals that are showing interest which if you look at most of the other projects out there, that's That's the point like what is our community? So if we have 20 orgs there's actually only one person per org and it's not really showing How how large is our community getting or anything else? now we can also use that information for the governance aspects as well, but Trying to give the flexibility of of having an individual and the org So that we can use that information in the best way Let me go and read what the charter actually says because i can't remember but i thought it was basically a interested party company gets one vote effectively Which wouldn't be what we would have in our interested party list if we change to do what you're talking about And that is not in any way shape or form a criticism of what you're suggesting I think it's the right thing to do. I'm just trying to work out whether it's got a knock on effect that we have to deal with immediately All right. Well, this is a discussion. So hop on the um Hop on the github discussion and you can write stuff into this We're there's no pr yet The idea is to put it forward and get some feedback and if it looks like Something to move forward on then we create a pr and if we need to update the charter as well, that's fine We can that may be a blocker We don't have to continue on this one though unless anyone else has more thoughts And let's move on so we have the add values to the charter Taylor you kind of had like a succinct list bill has these kind of like paragraph style little narratives There's been some discussion I don't know what happened, but all my comments got put in the wrong place together, but um I don't know if people when I dive into this is kind of a broad topic of um Kind of the heart and spirit of what we're trying to do here I suspect if we went into this in the meeting, we would be about an hour over the top of the end of the meeting um, I think it's just one of those things where Go luck make your comment um someone needs to basically go and start folding and closing some of those comments off, but um It's probably better done in the um In the uh poll request I agree. I would say the other thing too to think on is do we want You know just the short bulleted list or do we want the narratives? um, I prefer the narratives if I'm being honest, but um You know, that's my own opinion that isn't to say that there are other opinions out there All right. Well, I'll move on. I agree with the end. Um, there's already a lot of discussion here to Like look into you know, please check out the pr way in Um, if you have a third way of stating values, then please chime in PR approval process I don't know this one is one. I think we need probably more discussion on like It says tech leads will do mergers, but we haven't really Fully established what a tech lead does taylor. Um And I'm if I remember correctly, there's no limit on tech leads, right? So What the ratio of like individuals versus tech leads, um Like at that point do we just leave it as individuals in as long as we get a quorum we go or how I don't know what people's thoughts are on this one. This one seems a little bit. Um Underdeveloped in my opinion Um, I might argue that perhaps our concept of tech leads is a bit underdeveloped. So somewhere between Core developers, you would see an open stack where, you know, you would never try and It was done by I but the number of core developers was Constrained you didn't increase it too big because you needed someone you trusted to review Uh poll requests specifically Um, but that doesn't mean to say they couldn't do, you know, they couldn't you couldn't go off and do something adventurous It just means that you didn't need to be a core developer to do that So if we could figure out what we actually Want our tech leads to be are they the part of the approval process is that a primary job? Or are they just, you know, people we've nominated to investigate a specific thing? Uh, which, you know, doesn't necessarily involve election or anything else. How do we want to think about them? online 1a as well says a co-chair of vote can be um jumped but Yeah, I lost. I lost the Line I'll wait until this is done Yeah, so If you look at line 180 as well it says a co-chair vote can be replaced by the approval of two tech leads and That also seems quite like quite a low bar like I could pair up with another tech lead and say hey, let's go start replacing people another Maybe another way to look at this is we don't have the representation Um, that's well established the in the process for electing and the prep and the The powers so we need to handle all that before we put stuff in Yes, for what you're saying Frederick and I think that it's tied in with the the other as well like what what are what are they? What does the tech lead do and there's a follow-up? item on the agenda about Including other types of leads. So what what do these do? Is they're gonna is the next one like also broaching the topic of community leads Taylor? Yeah, that would be part of it. So if I think we shouldn't even call it tech leads um, it's more like a I don't know you can why but it's We need some type of team leads would be equivalent if you thought like a project or something but um Team lead their leads working group leads. So you have the chairs and then you have what are these leads? They're going to take on different things Yeah of them maybe Technical and what does that mean? Of course that can be broken down into different things and then the community side That may be people from other groups that were wanting that are involved with us and maybe involved with several security groups or a whole chaos community. There's multiple litmus chaos Two different cncf projects. There's other ones in there in many different areas. So we may have someone in there that's wanting to ensure that Information from those groups comes over and then feedback from us is flowing in so tying into that There's the whole engagement and you could say marketing to get people involved. So anything around this says what are efforts that we have? And then people doing different types of Facilitation. So these are contributions. So is what type of contributions? Can happen so then leads could be focused in any different area or multiple areas, of course So I think expanding this to say someone is leading within our group to try to help is It'd be good to expand it beyond just saying attack lead Yeah, I personally think we kind of need to Look at this at large too. Like if you're going to lead documentation improvements Do you really need to get voted in for that or? I mean typically we have Self-motivated people that just kind of step up when we have the five second awkward pregnant pause on the call and they say fine. I'll do it You know Technical and community leads probably seem a little bit more official in my mind I don't know and I think I like the idea of a community lead for someone who Maybe doesn't have the confidence yet to Fully dive into like a deep technical subject, but they still want to help push the ball down the field I don't know what people start on Let's talk about what we need versus what we could have what we need right now It seems is is people who kind of are a process for deciding when a pull request is ready and goes in Which again is more like a core developer side of things than it is anything else. It's not leading projects It's not leading initiatives. It's literally taking an active role in making sure that by saying yes on a pull request They're not going to cause anyone great distress That's the thing that will get us moving the rest of it I think we could basically You know take longer to consider calling something a community lead or a project lead or whatever We may want them. There may be a reason for making the official That I think is a lot less well established right now The reason why this I I agree with the individuals being motivated and ideally we just have people willing to contribute or that's what we want and More than having people the titles are not important. So we just we're trying to get people to contribute um The reason why this is in here is primarily around what we have the wording around like the The governance side that last one that we looked at for the pr approvals and stuff like that. So having some Um wording that communicates what How people can get involved and then if If there is any official areas that are helpful for us Then those are documented and then how they relate to governance and stuff is the main thing and agree on Let's take more time to discuss these This item and the related stuff like the pr approval I think one thing that someone mentioned Earlier and it actually came up on the tag is purpose. So what is what is our purpose in any of these? and at the highest level on the CNF working group we're trying to find and and promote adoption of best practices for networking applications that Are going to help the end users service providers and integrators and everyone else So that's at the highest level. So then what is our purpose at a lower level with Having leads or anyone else? How does it help us to that higher level purpose? curious everybody's very quiet like What do people think on the idea of additional leads? Do we have any initial thoughts on like what the bar is set? I do think that whether we call them a tech leader or something else that people who approve pull request should be voted on because My assumption would be that people would want, you know basically a vote of confidence that you know the Documentation here is going to be maintained and it'll be people who are willing to take the time to read through stuff I'm You know, if you're someone who's super super busy and looks pull requests once a month And only like a few at a time Do you volunteer or do you instead try to go for a community lead and try to help lead projects and then Dive into PRs and weigh in on when they're specific to something you're interested in um This all seems a little bit complex to me Uh, I feel like we've been spending months on no building the bureaucracy for this work group uh If if our esteemed co-chairs think that this is the best way to move forward Honestly, I'm like whatever Whatever works best For the co-chairs in terms of management if if co-chairs feel that they need this very specific assignment of roles and responsibilities In the end the work group will work when people step up to do the work um You know, we we can make this official Uh, I'm I'm in favor of making this a little bit looser. I think we we we just have I don't know too too many roles and then too much Too much specificity, but if this works for you guys I'm fine with it Tell part of the point with this is it's not to say let's Actually specify 30 different types of leads and you need to tell us which one It's actually to make it more general and say We need we may need leads actually we can decide, you know, if we're going to move forward at all on that But it should not be specific to tech leads. That's really it So if if if we need other leadership besides co-chairs Let's make it general and if someone wants to say Yeah, I want to be a lead for this And that's what we want to document. That's fine. If you're just saying I want to lead, okay Whatever that means But making it more broad and allowing it to be more flexible is the point Well, the problem with that is that if we don't know what those things are And we don't know whether they even need to be incorporated into as tell says the bureaucracy And then maybe we're just over designing this Um I I think to me the issue is I'm fine with you know trying to understand what the group is doing. I think this is good I guess what we're really trying to divide here is between active members who participate and members who don't participate calling it a lead Well, we can call it lead if you prefer but in the end we're talking about people who are uh We're making we're more formalizing the idea of when people step up to actually contribute Things to the group to the work group. Um, so we want to I don't know give them A title But you know people who are not tech leads or leads. Um, they can still Comment they can still contribute um So to me this seems to be more formalizing okay Who wants to step up and to be a more active of the work group member of the work group? And let's formalize it in some way and create a list of responsibilities Um If that's what we're doing cool uh I just want to point to tal's point to right um The previous one we looked at around how many tech leads versus how many community votes, etc It doesn't say whether or not you can like supplant both tech lead votes So, I mean if we're just saying then that the baseline bar is six community votes Then get six people to review your stuff and then it's merged ready. Then we should just call that out. Um I mean, I don't have strong opinions Sometimes people like to have you know these things like they can tell their boss that oh I'm doing x y and z in the cnc f and it helps them out So i'm fine with putting this in place if if we want it. Um But at the same time too i'm kind of like As long as we decide on something I'd like to start spending these calls going over like the use cases and arguing about layer three networking in kates versus um some of these more procedural ones as soon as possible I'll I'll add another point, you know if this is about people stepping up to to take a more active role I I don't see why we need to vote on anything. Um anybody who wants to Be this kind of active member. It could be just an open list add yourself And uh, that means you have some responsibilities. Um Uh, we yeah We also have a fantastic set of uh of co-chairs and We can rely on them and their judgment to so if someone's acting in bad faith Or is damaging the repositories and uh, we we have some level of control where we can Remove people So I think though the process is important But I I would also recommend doing it as lightweight as as possible Well, my point is Do you guys really think that any of the people who Stepped up to be tech leads or whatever we're calling it Are not going to receive enough votes. I mean we're we're happy for any warm body Anybody in this group who wants to be more active. I mean we'll we'll celebrate that um Like I wonder if you know with this more expansive definition of what it is Do we really need uh to be voted in I mean any but this is a volunteer position So anybody who's volunteering to do more work great and Well, I I agree with you on all of the volunteer and anyone stepping up absolutely We want to get people that contribute and or celebrate that So the the main issue here is if and if we can split it is about Acknowledging who is there to help So that other people can come in and find them So if you're working on something tall and other people like I mentioned that I want to help Or whoever it is then that helps new contributors So that's one side and that can be a just an easy list That has nothing to do with governance. So the other side has to do with How we're doing like PRs And then further than that would be when we get down to adoption and promotion of best practices when we go Here's a set that we as a group if we separate those things and Which will probably mean an update to the charter And so have a separation of that Then it's a lot easier to do what you're suggesting. How just let people Say without voting I'm working on this if and I'd like to help. Okay, great. Just add yourself to the doc And there's no voting. You can just say that Separate that from PR process And we deal with the PR process separate But the problem right now is the PR processes at least suggested was it's tied to these names Um, so maybe we can go back on that PR. We don't have to now But the PR process maybe we want to rethink and have it what I think someone else suggested a few minutes ago maybe we have The PR process is only individuals community individuals and if we need to add something about board representation fine but the PRs And then deal with stuff like adoption of best practices that are promoted also separately I'm in favor of that, you know, as as frederick said, um, our co-chairs are making sure that this repository is okay So the look at PRs if we really have some rogue members somewhere accepting PRs willy-nilly The group will be self-correcting our repository is not a code base, right? There's nothing If a PR comes in it's not going to break everything Uh, I kind of feel like we'll be fine Less the less bureaucracy the better I'm in favor of just having a list people can add themselves to the list. We don't I don't think we need to In my opinion vote things in All right using natural using natural language to compile the straight introduction Right CICD exactly Yeah, when we say PR Another thing is what are we saying PR, uh approval power to change The charter to add a best practice all of it Change the future of the benefit Yeah, so we have that problem of what the power is of a you know PR kind of flipping in Uh, this technical Uh power and it's actually this broad Actual power that goes behind it that I think hasn't been described. So I think that's why people are reluctant or concerned Um, the other thing that was brought up is oh, we're taking a long time to accept these PRs that uh, that's because We don't agree That's what I would submit because we don't agree on what the things that we're talking about Should be in the charter or whatever. It's not I don't think that it is because We don't have enough people assigned to it or that it's a you know that no one's Responsible for it To press the button so Those are my things that Yeah, and nothing is set in stone, you know a PR gets accepted and let's say somebody looks at it and says Well, I actually disagree with this so other people You know, we can Revisit a PR that has already been accepted and do another PR that fixes it Um A repository. I think we all understand it as a living document a living set of documents that will evolve and change and maybe move back um Yeah, as I said, I think we're overthinking this I've got a I just got it because I have to drop but I want to point one other thing out and kind of like to tell us point is When we go to like the next cube con or something like that and we try to sell this We don't want people to think that the barrier of entry is like, you know Here's four thousand weird things and this place has run like, you know some former You know crazy country that like has like 50 layers of bureaucrats standing in your way like if you want to come in and get Involved we want that barrier of entry to be pretty low in my opinion Hmm The only thing I mean the the thing to me That this could do for us which would make us better than we are before Actually plays back to tell's point that we keep discussing bureaucracy because all our pull requests are on the bureaucracy Because all our pull requests get discussed in the meetings because no one's really sure When the right moment is to push the button and say let's commit it And that's why I think they're actually Spreading that responsibility around and actually officially assigning it Would really serve as some good because then you know things will happen in between in the week rather than you know on the meetings Um, I think this reiterates what Started with this we need to rethink from the PR the PR approval process and team leads We need to rethink how to make it easier to enter And we also want to make sure that things are Are are we Protecting anything that we need so maybe re-evaluation of that and say is there anything that we need to have bureaucracy around and then Um add it there Right now it's spread all over uh, and this is something um Jeffrey and Ann and I can focus on like from the governance share site and and looking To some of the I think part of it goes to representation so we can go talk about that and then go back to say how can we At least it's been expressed How can we go to limiting make it smaller amount of bureaucracy? And what are the important things That we do want All right, we're top of the hour. Thanks everyone These are discussion items um as well. So please at least from the standpoint of what Ann you're saying There is discussions and feedback which would help make these calls faster if you go in and Add information and especially references if you have thoughts on something and can give links and references then that'll help So that when we get in these calls They can move forward faster and potentially get completed online before the calls have been here See y'all next week. Thanks everyone. Bye


Their behavior is not your reality, it's theirs. Sometimes we are around people who have a habit of projecting their behavior's causes onto us and want to make that our reality when it's really theirs. And when we can't separate those two things out, we suffer, we get hurt. We all have these people in our lives and we've all been these people. It doesn't make you a bad person. I think we all tend to do this from time to time. Who's in your life today like that? That is always making you responsible for their behavior when you know you're not being separate those two things out. You can still enjoy having that person around, but be less triggered because you have disassociated their behavior from your reality. They're two separate things. Cheers.


My name is Threebeard, I saw you, can you hear me in the microphone? And then if I speak into it, oh there it is, testing, testing. Alright everybody, let's get started. Can you hear me in the microphone? Can you hear me? I have to speak directly into it. Maybe I'll, I'll just do that. I'll just hold it. That works. Hi everybody. Hi. I'm Ralph with NoBeard. My name is Ralph Bean. I work in PNT DevOps now on the productization pipeline used for all Red Hat products. I used to work on the Fedora engineering team for the last four years, working on the tool chain there, all the tools that go into making Fedora something that is able to be shipped and actually used by users there. So, talk today is about Factory 2.0, which is, well, we'll get into exactly what it is. I want to start with some backstory, some context. Can I have people in the room? Raise your hands if you've ever heard of the eternal September, or the September that never ended. It's a minority of hands, I think. So this is educational backstory, hacker lore that you get to learn today. Back in the day when the internet was first becoming a thing, every September there was this tradition that happened. There were a very small number of users on the internet that had their own culture, their own way of interacting with each other, and every September a new influx of university students would go to university, get access to the internet for the first time, and there was this process of about a month in September where the existing internet users would teach the new internet users, the new students how to behave on Usenet, and then after that they were acculturated and things were fine. Well, in 1993, that's when AOL online, the internet service provider, first provided access to users to Usenet, and the influx of new people coming to Usenet was so great that it was never possible for the old guard to kind of keep up with educating new people on how you should behave on the internet, and so it's called retroactively the September that never ended, or the eternal September. So that's a thing that happened, and now you know. What that means for us, I think it's useful to draw an analogy between that point in time and what's happening now in open source ecosystems and that it's changed dramatically from when Red Hat first started as a company, from when Linux distributions were the primary place to go to try and get your software to be something that people would use and people would use as a platform to integrate on top of. This is a graph showing the number of packages in different language ecosystems, RubyGems, PyPI, and NPM, or Node.js. If you can't see the absolute value, the number of NPM.js packages here in like halfway through 2016 is crossing the 300,000 mark. We have 17,000 packages in Fedora right now, which is more than we actually want. It's more than we can handle or maintain. If you think that we're going to be able to somehow keep up with 300,000 packages just for NPM.js, that's a losing proposition. So the point of the analogy with the eternal September is that things like the rise of GitHub and other practices in open source communities just mean that the times have changed and the whole model of how we've built Linux distributions has arranged around a time that doesn't correspond with how things are now. It's a different era. That graph and things that have gone on have had consequent changes in the way that application developers build their apps, whereas they used to look to the Linux distribution as a platform that was common, something they could build their application on and pin their dependencies against that. Today, people do things like this. PIP Freeze is a command for Python that takes all of the specific versions of all of your dependencies in your Python virtual environment, freezes the version and writes it out. Anyone who wants to run your app has to use exactly whatever you had installed at that particular time. That works great for apps to be able to isolate themselves from all the changing things in the ecosystem around them, but it works terribly for a Linux distribution where we're providing a certain set of packages which almost certainly don't correspond with whatever the developer had installed at that particular time. In my opinion, modularity, the whole modularity effort is our attempt to address that situation and make the Linux distribution compatible with the new way that apps are developed and cooperated around. Our entire tool chain is built on a way of building a Linux distribution that isn't compatible with that, so we have to think about the tools, too, which is what we get to here. Factory 2.0, if you've seen other talks, it's not a lot of things. It's not what you might think it is. There's no single Git repo where you can go and check out the Factory 2.0 code. It's not a project in that sense. It's more of an initiative of looking at our tool chain as a whole and trying to make changes to it across the board. You can read our design documents for more on that. Today, I'm not going to cover all of the things like I've tried to in the past because it remains too high-level, and instead I'm going to try and focus in on just three of them. I'm going to talk about measurements, continuous integration, and the modularity effort specifically. My diagrams are going to be weird at this aspect ratio. We'll roll with it. This is a depiction of the existing pipeline. There really is nothing to the right of the diagram. In this case, it just kind of ends with the release checklist. So this looks nice and simple. If you've ever developed on Fedora or Ferrell or for Centos, you know that things then get built in Koji and Brew. They go through a compose process and then a release checklist to get out the door. It's very, very simple, right? If you've ever used it, you know that there's actually a lot more things going on around that and a lot of things about it that are more painful than just moving right through. For now, let's just pretend that things are like this because we're going to elaborate on this basic framework of how things get through and show where there's problems and talk about changes to that. To start with on measurements, this is a screenshot of a dashboard that we've set up internally. We're not doing the same work for Fedora. We're just doing it for the internal pipeline because it's not as easy to duplicate across the two. One of our mandates is to measure things that are a problem with the current existing pipeline to determine how bad things are so that when we make a change, we can be sure that we're either improving the problem or maybe our change had no effect. Here I'll explain these two. This is titled the RPM diff lag. There's a tool called RPM diff that we want to run in response to every new RPM that's being built in the internal pipeline. On average, if you pick a day, this day on average there was 100 hours of lag in between when something was built and when RPM diff was run on it. Having RPM diff results is actually a really useful thing. That should be a small number. That should be zero hours or one hour at most on average between it, but we have 100 hours today. This graph is titled the RPM Signing Lag. When things enter a certain state in our release process, we want them to be signed with a GPG key that signifies that they're gold, they're good and coming from Red Hat. That currently is a manual process and in this graph it's much, much worse between when things are allowed to be signed and when they actually get signed. On this date, the average was 800 hours between those two things. That's a huge amount of wasted time just waiting for something to happen and that's unacceptable. The point of this is to say that both of these are things that we're intending to either solve by automation or by shuffling things around in the pipeline so that things can just happen when they need to happen. We would like both of these graphs to go down to zero, but the point is that we're gathering metrics ahead of time to be able to see what the problem is. That whole project of doing measurements is much more complicated than we originally thought it was going to be. I think just gathering metrics seems like it's simple, but the problem is that anything that's a useful metric that gives us some real insight involves collecting information from multiple systems in the pipeline and correlating it together. As an example of one of our more complicated ones, we have a mandate to make building content into containers as easy, as painless, and as quick as possible. A metric to measure that would be anytime you make a change, say in Fedora, to an RPM package to a spec file that then has to get built as an RPM and once it gets built as an RPM, it can be included in a container. If you want to figure out how fast it is, measure the difference in time between when a container gets built and when was the last commit to any spec file that was included in it. It's hard to get that information in the first place. It's possible. We have code to do it now, but it gets really tricky because what about if there's one RPM that, say, hasn't been updated in three years because it's just super stable and it's not going anywhere? So then that time between the commit and the latest container build is three years and it throws our average off. So thinking about what the metric means and how to produce it in a way that will actually be useful is just harder than we thought. I'm going to say on that, many more metrics to come on that front. So to change topics, continuous integration, this is a depiction of how continuous integration looks today, both in Fedora and in the internal pipelines. This is our friend diagram at the bottom, the existing build-to-release pipeline. And basically all that we have is that each of those systems announces activity about new content that's either been changed or built or composed to a message bus. And then we have, I have this cloud up here for CI infrastructure. Excuse me, CI is in quotes for a reason. Can anyone tell me what is wrong with this diagram? Pingu. The CI is after the change. That's one thing to think about it being wrong. Any others? That's also true. So another way to say that is that there's no gating. The CI doesn't actually impose any restrictions back on the pipeline. Yeah, the arrow from the CI doesn't go down far enough. Yes, yes. That also, although... Sure, yeah, that is a problem, but I don't know if the diagram metaphor... Yes, yes, exactly, exactly. Oh, moving on. It sure does. It's a beefy miracle. So the first step that is on our road to solving this problem is we want to introduce this service. We're actually co-opting it from the Fedora infrastructure called ResultsDB. It's how you start to get... I don't think it was Adam that said it, but it doesn't go down far enough. It's the way that we begin to get that arrow to go down. Notice how the CI infrastructure is in this big cloudy shape, and that is for a reason in that our existing... what we have been calling our CI infrastructure internally is a whole set of Jenkins masters and Jenkins slaves that are available for various teams to run whatever kind of tests in them that they want. And that flexibility is good in that it allows test teams to move at their own pace, make their own decisions and do their own things. But it's bad from a release point of view, a build and release point of view from the point of view of my group of DevOps, because we have no way to consistently query for the results of that information to make decisions in the build to release pipeline, to make decisions about whether a branch should be accepted or not, to make decisions about whether or not something should be gated or not. So the first step is, again, collecting those results in a homogenous fashion behind a homogenous API so we can make decisions. Some more detail on exactly how we're getting that data, because it's not quite so simple, right? It's this big fuzzy cloud of many, many Jenkins masters. This is to show where we're at right now. We have this project called the, we're calling it the CI metrics data feed coming out of platform engineering. That feed was originally established to go through the message bus and populate an elk instance for reporting on metrics about what kind of tests we're running and how frequently we're doing it, not to make decisions about automation. But we are working with that group and we're collaborating to use more negative to work co-opting their data feed, taking it and using the exact same feed to populate ResultsDB using a microservice we've put in front of it called ResultsDB Updater. And this is done and is in production right now. The better plan that is coming down the road and we have agreement with the groups, but it's a matter of getting all the pieces lined up to get there is there's a separate initiative called ShipShift that's about taking all of the artifacts from these Jenkins instances and making sure that they get archived to cold storage so they can be saved forever and looked at. They want to publish information to the message bus also to have workers pull those artifacts out. We want to listen to that feed and use it for the same purpose to store up this metadata in ResultsDB so we can make automation decisions based on that data coming out the bottom. So the key difference is that one is only for one group inside Red Hat, the platform on the left. The other will encompass all the various business units, all the different products in Red Hat so we can have a more comprehensive solution at that point in time. So here expanding the picture a little bit more, this is putting ResultsDB to use, right? Once we have that populated with information there are multiple points in the pipeline where we want to query that data to make a decision about whether to move something forward either automatically or to gate something and not allow it forwards. Starting at the far end in the release checklist like Bodey, the Bodey updates process in Fedora or the Arata tool internally. Today the way this works internally is that when the CI infrastructure completes its tests engineers go and look at the results visually with their eyes to understand whether something worked or not and then they go manually to the release checklist tool and check off and say QE tests passed automatically. We would like instead this tool to automatically display the information from ResultsDB about whether tests passed or failed and then depending on rules that are defined on a per product basis. I'll get to that in a minute about how we define those different rules. Either automatically progress the advisory or simply allow it to move forwards upon some sort of manual click. Here we have determined that we have a need for an automatic rebuild service especially with the advent of containers. We're going to have many, many more different kinds of combinations of content. The process of making a patch to something like a 3-day manual effort to rebuild the world is not acceptable anymore so we need automation to drive that. That sort of service needs a way to consult the results of QE output by looking at ResultsDB to know whether to progress to subsequent tiers or not. And lastly, and this is what Pingu was commenting on early, disk it itself, the real dream for CI is that any change that gets proposed in disk it before it even gets merged is something that needs consultation with QE feedback with the results from CI runs which is we want to gate right here before we get any problems in the pipeline at all but by using ResultsDB like this we can use the same runs from CI, we can use the same set of test cases to drive the decisions made at each of these different places. In the best case all the problems get caught here and nothing happens really in the rest of the pipeline but reusing it I think is important for a redundancy and a resilience perspective. So now we have a complication. In Fedora we do not have an answer to this solution but we do have an answer to it internally. Baked into the Erata tool and some of the tools that form a constellation around the Erata tool like RPMDiff and others there is functionality for waivers meaning if a result coming back from automated tests is wrong a human can say this doesn't really matter just wave it it's fine it can move through. In Fedora we have integration with our updates tool with our test execution but if the tests are wrong and something is being blocked and it should progress anyways the solution is just to change the requirements on your update so it can proceed through which doesn't make sense, right? Having something abstract like this I should explain what this is. WaverDB is a new service that we have a requirements document for in process but we need to actually write and implement that will house an abstracted version of the logic around waivers from our existing tools which will then repurpose and use throughout the pipeline. So to show here the results that go into results DB are immutable and come from automated test runs and we don't want humans to modify any of the results in results DB so they give an accurate reflection of what happened in the test automation. WaverDB however would be human input only where you could wave an individual result in a particular decision context they wave it for a disk it changed but not for the release checklist and furthermore specify auto waivers so if you know a certain kind of test case it's just perpetually broken in these cases but not some other one. That's complicated logic that we don't want to have to duplicate in all our other tools so abstracting it out into its own service makes sense. Here in the middle I have this note about tools cross-reference entries in these services to make decisions and see how there's duplicated lines going from every service to both of those services. That to me is a key that we need to introduce yet another service here. We're working on a name for it we're only calling it the policy engine but it would be the tool that would understand exactly how to cross-reference entries from those two services and make decisions about what should be done. For instance each of these services is going to ask a different kind of question to the policy engine. Given a proposed patch in disk it we want to know is this good to merge or not. In the policy engine we would need to define ahead of time a policy for this kind of product group or for this kind of subsystem. These are the conditions that need to be met for something to be good to automatically merge or not. If they're met or not then we proceed. It's a different set of conditions that may need to be met for the automatic rebuild service and a different set of conditions again for something to be good or not to release so abstracting that in policy engine is the current plan. This last slide on CI again to Pingu's point about blocking branches before they actually get merged the key will be to stand up a pull request interface on top of disk it which I think is going to take different forms in the two environments that we're looking at. In Fedora almost certainly it will be Pagger just because it's the people in the Fedora community already know it and love it but I have a hunch that deploying it internally is not going to be quite as simple or quite as palatable to people around so there's already familiarity internally with both GitLab and Garrett so it'll be a question of deciding which of those two interfaces is the preferred one and standing it up in much the same way. A thing that is interesting about our infrastructure is that we have a lot of implicitly defined workflows that go between systems so currently are again what we have been calling our CI infrastructure the both Taskatron in Fedora and Jenkins internally know how to implicitly respond to new artifacts that are available for testing so when Koji finishes building something it announces it on the message bus and CI picks off and takes off and does its thing. CI systems that work quite well in other environments for other organizations tend to instead of being implicitly defined like this are explicitly defined so if you see like for instance the work that Ari was demoing earlier with Jenkins pipelines or if you see anyone like in upstream OpenStack where they're using Zool in both of those cases this circuit is defined in some sort of file like first there's the build step and then there's the test step and then there's the decision step in Jenkins land with Ansible and Zool it's much the same way but we already have a wealth of tools in both environments that have this implicit step so we're going to have to think creatively about how we write the trigger in the pull request interface how to kick off the first step in the process and then wait for the appropriate conditions to be met with some sort of timeout in order to proceed that's just to point out that I don't think we're going to be able to copy any sort of pre-existing solution to be able to graph this onto our infrastructure that we have and replacing wholesale is too costly in my opinion. Okay, new topic, building modules this is for Fedora 26 and going forwards my team has been working on that we're also extending effort towards the modularity project in Fedora this is a depiction roughly of how the module build service which is a new tool that we've written with the modularity group fits alongside other pieces in the pipeline the main point is to show that the actual work of building the RPMs that become a part of a module is actually done by Koji or Bru the build system that we've been using for an eternity now but the module build service serves as a sort of workflow orchestration layer on top of Koji and Bru to describe what it needs to do I'll move to the next slide the way that things are built today is that we have a tag for a particular release of the distro the F-25 tag and as you build a particular RPM the build root for that build needs to be available to meet the requirements of its build requires come from one repo or come from one tag and once the build is completed it is added back into that tag in most cases or sometimes added to a candidate tag and ultimately promoted to be in that tag a consequence of this is that that tag is a moving target and you can't just say I depend on F-25 at a particular day or a particular moment to know what the contents of that build root are build roots with modules involve something different those tags, those mega tags like F-25 are something that are currently created by RCM by hand at the time when we declare we're going to do a new branch for a new release new tags are created and populated with content from the previous release and things are set into motion modules get their own build roots and their own tags for each build of the module that comes along which means that that's not something that we can ask RCM to do we can't ask a human to do that every time we want to do a new build of a module to create a new tag for us by hand so that module build service like I was talking about being an orchestration layer around Koji and Brew is something that automates the process of creating those tags and preparing the build roots in a way that is sensible for the build of that particular module this is a depiction of the container architecture that the modularity team has come up with to show how different modules map to different layers in containers as we intend to build them and ship them the base runtime module corresponds most closely with the base images that we've been building today for an F25 release or F26 but each individual module that we produce the intent is to build layer 2 images that correspond with install profiles that get defined by those modules so you may have one module that defines two different ways that it could be built into a container but those containers aren't the end product and ready to be used the particular use cases for them the configuration and the running of an application happen at a last step so we can special purpose them for different deployments and different needs but that the software from the module is provided as a reusable layer in the middle so let's talk about diskit this is work that we've been discussing for a while and the plan is to start it shortly after devconf the F26 freeze comes at the end of February we'll be deploying the module build service for that coming after that deployment is where I think things get really interesting and things really start to change for the distribution as a whole this is what branching looks like for any particular component in fedora today say it's python requests we have a branch for each release of the distro including master which maps to rawhide the way we want to change that is actually stop producing new branches that correspond with the release of the distro that's coming up but to instead create branches that correspond with a release of the upstream package the upstream project to which a component relates and this has some pretty interesting implications both challenges and benefits that come to the maintenance of software in the distribution just for comparison we intend to do the same thing with branches for internal components whereas today we would have branches for rel and layered products named as such that has a multiplicative effect where every combination of things we want to produce creates a new branch that has a new maintenance overhead for the entirety of the lifetime of the product the idea here is that by creating branches that correspond with upstream releases will have a much more maintainable way to support back porting security fixes onto those branches that isn't product specific and doesn't grow with the scale of ways that we want to end up delivering that component so the way that we intend for these to get used right is by here showing on the left two rpms python jango and python requests having a master branch and then having branches that correspond with upstream releases of those projects and on the right having a module that corresponds with a whole jango stack that would need to pull in the rpms for jango but also all of the dependencies that go into supporting that release of jango and making it something that's usable we could have a branch 1.9 of this jango module that declares a dependency on the stream declares a dependency on the branch 1.9 of the jango rpms and then also declares a dependency on the 2.12 branch of python requests and so long as 2.12 has lots of sub releases 2.12.4 2.12.5 the point is that all of those depending on the properties that are defined associated with that branch could carry those dot z releases in that branch and that module would consume them but not api breaking changes that come with a 2.13 release of python requests but a module or anything we have that is like an application that would need to sit on top of the base runtime can pick and choose the support streams of its components that need to go into it to fit its own purposes instead of having to choose from what's already available in the whole distro so there's lots to think about with a new branching structure for one are we going to have an f27 branch at all of any components when we get there we're not making this change for f26 itself but for f27 will we even have one and my thought is that no there won't be a point to have one unless there's whole subsections of fedora that aren't ready to make a jump to a new upstream mapped branching pattern having a fallback of an f27 branch makes sense for those cases until we're ready to at every kind of reach of the community move into that world EOLs become really interesting because right now when we branch for a new release every branch in a release has the same EOL for it it's about two years for fedora when that no longer becomes supported but if we break out the components to have their own EOLs that aren't associated with the release we need a way to define an EOL for that component and then propagate the EOLs of multiple components through to the modules that depend on them the thought here in fedora is that we'll use fedora to create a new branch and then we'll have to modify it to define new EOLs that correspond with those packages so when I say I'm going to create a new python request 2.12 branch I may say this has an EOL of only six months and any module that depends on that particular stream of python requests therefore has at maximum an EOL of its own of only six months and that our tooling that goes through and figures out when we need to retire branches currently assumes that branches are retired in mass when the release of the distribution is retired but now we'll need per component tools that go through and figure out when EOLs have expired and retirement needs to take place yet another question comes up is what's the economic force in fedora that goes through to create new branch requests currently that's done for us automatically at new release time when there's a mass branching for F27 or for F26 with branches like this it'll come up I think on a use case basis if there's a module that we decide that we want to ship a postgres module that needs a particular dependency on a particular stream if a suitable stream isn't found then we'll need a mechanism in package DB to request that new branch what will happen to components that don't receive any new branch requests it's an interesting way to identify components in the distribution that have existed only because they continue to be there but if no models are requesting new branches for them and all of the other thank you branches and their EOLs have expired at that point in time then there's no reason to keep them around anymore there's no force to keep their branches alive that is there lots to think about lots to do if there's any questions I'd be glad to take them so the names that I gave for the branches are like 2.12 and other oh I need to repeat the question nah I forget it right how do we deal with upstreams that either don't do releases or don't have semantic versioning there's some projects that use a year based release number and they just do like a time stamp release and they do one every day for instance and so my response would be that the examples that I gave were numeric semantic versioning ones but don't read too much into the the name of the branch the actual metadata associated with what the branch is what it's EOL will be what to expect from changes in it would actually be defined in metadata in packagedb yeah it depends on your use cases for them so how do you want to end up distributing it a nice way to do it might be to create two branches off the bat one called super stable and one called kinda stable and like those are arbitrary names that Tim made up but that's fine any module that wants to consume those streams just needs to know those branch names from you and depend on them and you decide the EOLs on how long you're willing to support that in Fedora right we would have different considerations for how long we're willing to support a maintenance branch of something internally but we have that flexibility now Adam yes that's what we need to think about well I would I would definitely call it a different kind of service it sounds like a corollary to like a TCMS something like that you know yeah so so yes to that when discussing this work in other contexts the idea came up to use policy engine to drive that same kind of work because if we know that in this context this context in this context the union of that is these tests are going to be needed well then really those are the only tests that need to be run one of the things that we we were you could write yeah in reverse but there's a downside to that in that one of the things that we thought would be a bright spot in this architecture is that you could add new tests to be run on every change that were superfluous that were experimental without breaking anything right now with the Rata tool internally if you want to add a new test to it you got to really be sure what you're doing because you're tying it right to the big behemoth yeah yeah it'd be nice to run tests that are silly yeah and you can learn from them and experiment with them when can we expect this in Fedora and rail production yes so the answer is different depending on which part of each of the three themes so on the measurements thing we won't be doing any of that in Fedora just for lack of time and resources on the CI stuff you will see a portion of that in Fedora first and another portion of that internally first and so the portion you'll see in Fedora first before F27 is the pull request based flow with an elementary loop is not let's move down the slide I'm going to refer to it in this one you'll see this in Fedora without this part really soon which is a pull request interface directly querying results DB which means it won't be as flexible it'll mean that all tests matter instead of being smart about which ones do so the MVP the minimum viable product is to do this in Fedora without the policy engine and we'll insert that afterwards the part that you'll see internally first is is actually this part but without this and without this it's about decoupling things that are sistered to the Arata tool right now that make it really slow and cumbersome to develop and so we want to break those things apart things like RPM diff and the other tools that they get run there right now does that answer the question great that's a good question I keep it there because I can't imagine a world without rawhide you could say that master is the only branch that has no EOL I don't know maybe we just kill it really whatever is latest or unless nobody wants 2.12 then 2.12 never gets created but yeah and something would have to have declared a dependency on master beforehand and then absorb a change that broke them and then that meant that they needed to request an old support branch on a new line I think I think to repeat the question into the microphone the question was what to do with the master branch in this diagram yes the Stevens point was that you only have to create a new branch if there's a breaking change but what constitutes a breaking change also gets determined by the confines of what you declared the branch would support you might have a branch that you say is your wild almost upstream branch that's special for your component there might be other things that expect to depend on something that produces breaking changes like that it's not necessarily a bad thing I'll move to other questions Thomas in the back you'll be next yes yes the question is with auto waivers why would you run any test automatically in the end anyways and part of it is repeat the question did I not do it I did I did I did it repeat it again the question was why have auto waivers if you have auto waivers why run the test in the first place if you have somewhere encoded the knowledge that you're going to automatically wave it no matter what the result is we have a lot of things that already exist in our infrastructure tests that get run anyways today and we don't necessarily have control over who decides when they get run and how and we also have defined today a lot of auto waiver rules already in place so it's about making sure we can retain backwards compatibility and actually make this change in production and still be able to do what we did yesterday while at the same time making ourselves flexible enough for tomorrow that's part of our requirements document the point was we certainly need to be aware of waving things for certain products or for certain modules but not for other products and other modules which is the case in the existing auto waving rules that we'll need to make sure we get retained because you spoke earlier Tim I'm going to go a misch on the side of the room the question was did I shave my beard because now I'm working on enterprise products and the real answer is I shave my beard because when it gets cold there's not very much sunlight so now I just need to shake things up so yes some bonuses don't you repeat the question and tell me if I got it right how do we convince QE teams with their existing workflows to provide the data that we would use to populate results DB convince them or force them how did we do one of those two things and the answer is that we did neither is that we identified initiatives that were already ongoing to publish some data from those different Jenkins masters and then we worked with those teams to modify the format of that message enough so it would be suitable for their needs as well as ours the most expensive part of that project would be going through all of the hundreds of Jenkins masters and one by one getting the team to enable publishing so it's about latching on to things that already existed like I say we currently have data from platform for that and we don't yet have the data but we have a plan to get data for all products right now with ShipShift is the initiative yes I plead the fifth is that the thing you say promoting scratch builds repeat the question is there a way to promote scratch builds in this pipeline so they can make it through the system and to be honest that's one of the major problems that we have with NVR uniqueness in Koji and Brew in this situation and promoting scratch builds is one of seven options that we identified to solve that problem but we haven't landed on which solution we're going to use for that one of the competing ideas is to use namespaces in Brew which is a feature that doesn't exist today but is in the Koji 2.0 docs to allow a null namespace where we could rebuild the same NVR multiple times but it wouldn't conflict with previous versions of that same NVR it is a problem Steph yes the question is are they stored are they associated with a package with a module with both and are they versioned with the software in the case in both Fedora as well as internally they're stored in DistGit not in the same repo where the software is stored but they're stored in a repo of the same name under a different directory so we've had discussions about this in the past that aren't in the same repo and it may be resolved that they wind up in the same repo but today they're in different repos to the second question we have namespaces available and capacity to execute tests that are associated both with the RPM or with the module and to the fourth question yes they are versioned along with those things in Fedora the branching structure for those test repos corresponds exactly to the branching structure for the RPM and modules repos as well as the ACLs so anyone who has access to modify the software also by default has access to modify the tests Amanda so the module integration testing gets kind of to that point where oh yeah I gotta do it what's the expectation for module integration and module testing and I think that it's the same that we would have on RPM and RPM integration today even though we don't have a good backstory we're actually doing that testing of combinations of RPMs so in order to test a module that declares dependencies on other modules we would define tests in this diskit repo that corresponds with that module to test that module and by exercising the API of that module it's assumed we would be testing the other modules that depend on it as well but this yes exactly and on streams of modules as well we only showed a module depending on RPMs modules can also depend on other modules yes that's a good point the question is how are we going to deal with user expectations if the release of Fedora previously had a unified EOL of 13 months but the components that go into it have willy-nilly branches with EOLs of their own making is that correct rephrasing yeah so my response would be that we're going to model the core Fedora release core is a loaded word with Fedora but the base release of Fedora the center Fedora server would be modeled as a module that depends on other modules which depend on the RPMs going into them and for any module its EOL would be derived it would be derived from the floor or the minimum of all the EOLs that go into it so if we go to create Fedora 29 and we look at all the RPM branches that are going into it and one of them is going to go EOL three days after release the tooling will have to alert and say Fedora 29 when we release it is going to go EOL three days after we release it and that's the prompt awesome works done that's the prompt to go to that component and say to the maintainer can you create a new branch with another 13 months of EOL and let's say there are community members like listen I don't have time to support a branch of this for that long then we need someone from the community to be able to step in and create that branch and support it to support the release the point is that there will be this disconnect between things that are in the core and things that are on the outside and I just say that that would be the case and it's a change in user experience for this and I think it maps to the rings discussions that's been going on for years now for the room and for the recording the point is that the user experience will be much worse and I think that's a conversation to keep having outside the room we're out of time for now to have any more discussion here so thank you


Hello and welcome to the session. In this session we discuss the following question which says prove that if A is the arachnetic mean, G is the geometric mean and H is the harmonic mean for any two real positive quantities then first, A multiplied by H is equal to G squared. Second, A greater than equal to G is greater than equal to H. If we have any two positive quantities then the arachnetic mean denoted by say A would be equal to A plus B upon 2 then the geometric mean denoted by G is equal to square root of B the harmonic mean denoted by H would be equal to 2AB upon A plus B. Now let's see how do we get this harmonic mean H as 2AB upon A plus B because we have A capital H and B be in HP by this harmonic progression. This means this H would be the harmonic mean between A and B. Now as A, H and B are in HP so this means 1 upon A, 1 upon H, 1 upon B would be in this would be the arachnetic mean between 1 upon A and 1 upon B so 1 upon H would be equal to 1 upon A plus 1 upon B and this 1 upon 2 which would be equal to A plus B upon AB and this 1 upon 2 that is plus B upon 2AB and say that H is equal to 2AB upon A plus B and this H as you know is the harmonic mean between A and B. Now we get the harmonic mean H equal to 2AB upon A plus B. This is the key idea that we use in this question. Let's now move on to the solution. Now in the question we have that A is the arachnetic mean, G is the geometric mean and H is the harmonic mean for any two positive real quantities, positive quantities. Then as we are given that this A is the arachnetic mean that is the arachnetic mean between X and Y would be given by X plus Y upon which is the geometric mean would be given by square root of XY, harmonic mean would be given by 2XY upon X plus Y, multiplied by H is equal to G square, this is equal to A upon 2 multiplied by 2XY upon X plus Y. Now X plus Y, X plus Y cancels, 2 cancels with 2 and so this is equal to XY that is we have is equal to XY. You know that G is equal to square root of XY so this would mean that G square is equal to and we can write G square. Therefore we get A multiplied by H is equal to G square and this is what we were supposed to prove. So the first part of the question, now we are supposed to prove that equal to G is greater than equal to H compared to A minus G this would be equal to now as we know G is we have A minus G is equal to is equal to X plus Y minus and this one is greater than 0 that is it is positive is greater than 0 or you can say that A is greater than G. Now when we take the two quantities X and Y to be equal X is equal to Y this means we would be equal to that A would be equal to G. This is equal to Y, combining these two we can say that A is greater than equal to G and the equality X is equal to H is equal to G square. This means that A multiplied by H is equal to G multiplied by G. We also have that A is greater than equal to G so we can say that H would be less than equal to G or G is greater than equal to we can say that A is greater than equal to G and G is greater than equal to H and the equality X is equal to Y. This is what we were supposed to prove solution of this question.