Paketo Buildpacks Working Group, 26 May 2020

Previous Meeting

⏯

youtube image

►

From YouTube: Working Group: 2020-05-26

Description

* RelEng PR permissions
* buildpack.yml replacement: https://github.com/paketo-buildpacks/rfcs/pull/9
* Run image mirrors
* Paketo Registry Proxy
* Standardize release notes
* Go language RFCs: https://github.com/paketo-buildpacks/go

A

You had me worried there Emily somebody stole your bike for a moment. I joined a rosetta joke background from a difference in meeting gotta get back to my usual state of affairs over here.

A

A

A

B

Paul, do you have have you had a chance to look like those screenshots I, say.

B

C

This is my concentrating Faceman mm-hmm.

B

There are notionally letters associated with them, although if you can figure out the mountain slacks you ride, you'd be hard-pressed.

B

Okay, five, after might as well go ahead and get started.

B

We waiting for anybody and anybody want to wait for anybody. I.

C

Can ping Steven really quickly, but also.

D

This time at the top should definitely be 11 a.m. PST right I was like wow California's nine hours.

E

All right people writing stuff in the agenda. Do we have an agenda anymore, yeah.

B

We're all signed in just waiting for you got it.

E

Starting at the top standing item, release planning and updates.

E

Online build packages out to GC our name status, updates on that.

C

We are now currently cutting dot scene, be build packages on all of our meta families, like whatever the latest release, will be we'll have a build package artifact attached to that I. Think Qashqai are gonna talk about what we need to do to also post that in a registry somewhere later today,.

B

Remember that there is actually already a registry waiting for you.

F

On that note, Ben, do you publish your implementation, build packages as well, currently.

B

No, the long-term plan is those don't exist for anything but development. Realistically, especially once the registry kicks into place, the images are, the only real deliverable will ad will always support the other kind, because there are times when you'll need to get those things, but build packages as images I.

E

Think the question was: do you do publish like open, JDK, C and B to GCR as a build package by itself? Oh yeah? Yes,.

B

Absolutely because the package Tamil for the monolithic build pack references it as an image, so got.

F

It makes sense, do you publish to the top level like what you do with like I? Think Java is like picado, build packs, slash Java. There is everything else, just top-level yep, absolutely yeah.

B

Gc are we could have a directory structure underneath it, but given that that is not common across all registries, trying to add that level of depth is problematic and.

E

Our build packs also don't map one-to-one with language groups right like the open, JDK bill pack. Ruby all need that for JRuby. You know like five other language groups, they'll need no tension right. Apm stretched across five right.

C

You you version the bill package: images that you put up for your implementation, CDs yeah,.

B

Absolutely okay.

C

And then you you keep them icing, you just keep them up to date in some better build pack Tom hole that you then use to construct a project, something rather which.

G

E

C

I was just cool: I was just wondering how you've gated the release on specific versions of your implementations. So you just first.

B

Yeah yeah, so any individual one of these, let's take a look at the Belle soft one, for example, is somewhere in here. It is definitely oh, that's a resource home, I'm, sorry or two different points here. That's left library. Okay, here we go each one of them is actually it kept with a version and.

B

Internally, we automatically update for each one of those four pieces, both it's listing in the actual order, definition as well as the package tamil, so we always have build reproducibility, and then this thing is built and tagged as you'd expect it to be as well. Okay,.

C

Cool yeah we'll take a look at this then, when we're doing some of that cool.

B

Yeah reach out, if there's, if you have any questions about how we're doing it.

E

Anything any other release, planning updates, I'm, guessing we're not we haven't released new builders yet because we're waiting on those build packages right.

F

I think they're.

E

F

Have already gotten released, like we I, think forced finished up down that core this morning, so there should already be some updates in that in the tiny builder I'm. Sorry, the base builder yeah.

B

The the automation is continuous now so as soon as I'm releasing my new builders are going out, like I've, probably triggered over the last week, half a dozen new builds so I, don't.

H

I, don't think we're we're triggering on any of the new build packages that feature in just shipping it because we haven't oh yeah right I, don't think we've configured our pipelines to consuming those yet but I mean we can we can do that as they go or we could just wait till they're done just do them. All once seems easier to do that, whatever you.

E

E

All right anything else, release related.

E

Next thing is outstanding: RFC's.

E

Looks like we have two.

E

I'll go ahead and share my screen and we'll run through them. I.

C

Think the two of them are ones that are fighting each other, for which one should actually be implemented and I wanted. Because I don't know that I've discussed.

C

E

Son, so oh I'll start with this I'll present Dan's and then let you present your alternative house.

H

E

We've used this file called build pack Tom wall in the past, to build a camel in the past to provide build configuration when the build configuration supposed to go through like when you want to encapsulate sorry when you want to put that configuration in your git repo and check it in as opposed to setting environment variables, that might be different for the apps, and this was just proposing a lightweight schema for what that file could look like across build text that want to do want to use it, not as the thing that all build packs have to support for every configuration property just when you have built by camel.

E

This is what it could look like. Forest had a different idea that has a little more transparent hooks into the build plan. I'm really excited about it. Forest you want to take it from here. You want to share, maybe it'd be easier.

C

So I was not particularly happy with how del pesci amo looked and how we had.

F

C

Do so much repetitive, parsing of lightly different configurations over span of time when it was kind of just top-level keys that we were making up off the top of our head. So a.

F

Little while ago,.

C

I wrote a pill pack that would allow you to inject requires directly into the build plan through a configuration file. It was sort of a debugging bill bill pack that I wrote, but a little while ago, Ryan went in and fleshed it out, some more to basically accept a file that looks very similar to the bill play a Tamil file.

C

I mean it looks like this I'm sure that you're very well familiar with what this would look like so I'm, proposing that we get rid of bill pack amal and do all of our configuration through, and anyone who would like to do configuration through this means what do work through bill plant in tamil from what I understand for the java bill packs you all just do all that configuration with environment variables that you would set, it fact build time or whatever, so this wouldn't affect you in any way, shape or form.

C

If you all wanted to adopt this that'd be great. If you don't more power to you, I guess, but this sort of is a way for us to offload a bunch of repetitive unique, but not really unique logic that we have been putting in all of our build packs onto the lifecycle and leverage the fact that it's parsing the build plan for us all the time and use those. Instead, this is a little long-winded motivation.

C

We did some back-and-forth and I tried to capture as much of the back-and-forth on the PR as I. Possibly could I just added this section to more this morning about addressing some concerns around people being able to access build packs that they shouldn't, which is not really that big concern but yeah. This is this. Is it's pretty simple? In the end, we add a build, build, packed at the end of our build build pack groups. It accepts a some type of format right now it accepts something called plan Tamil.

C

There is some potential discussion about maybe trying to merge that into something: that's more Universal like project Tamil or coming up with a better interface, something that I have not fully addressed yet, but I think could be iterated on and then I have sort of the conversion that you would do the one-to-one conversion. You would do to make this look like plan, Tamil and I think the reason I was really excited about.

C

This is because it makes our build pack, so it makes us be able to be a lot more stingy about when we hand out, build and launch flags. We can only be very, very guarded about the permissions we hand out, meaning that we don't end up with containers that just have stuff flying around in it, because we thought that maybe the user would potentially want it there.

C

They can instead just ask for it in a sort of straightforward way, instead of sort of having to know how to loop through the build pack to get there and it kind of condenses all of that ability into one place. So that's what I'm proposing right now yeah.

E

Really, like the kind of power and transparency, so it's like, instead of a build pack having to parse the special thing in the app directory. That's basically the same thing in a different format. As you know, Bill Peck has exactly one interface for getting requirements and that can come from the app or come from another build pack, and it looks exactly the same in both cases that that seems like you know, if there's a criticism of our API, it's that we create too much complexity right. This keeps it simple keeps the interface.

E

The same gives the app developer a lot of power, and it opens up things flat, more flexible things like you know, if someone wanted to use just the open, JDK build pack, do everything else themselves. The opportunity build pick doesn't do anything special. They can just say: I need this from open JDK. They don't have to write a build pack and get it installed in the platform and all that, if the operator chooses to support build plan build pack which is like the operator choosing to support app developers having more flexibility right.

E

So it's it's also. It's a nice switch from a platform perspective. Do ya.

B

Concur, this is a perfect level of layering on top of something that already exists, translating the same way we do with something like proc file, for example, into the primitives for the spec itself. The only concern I would have- and it's very light concern is whether we actually want to call it plan about Tamil I, don't have a better main, but that's gonna have some collisions with this pack itself, and this isn't technically part of the CNB spec I am.

C

Not married to any file name or configuration that this looks like I want this, to look exactly like how the build plan looks if and I, don't care what the name is yeah.

B

Sounds good I'll keep thinking about that a little bit. What.

A

If this could eventually roll into the speck like, he could be trialed as a build pack, and then if it goes really well and something that the lifecycle could provide directly and.

E

Could be put in project table, the platform could read it out a project Tomball, and then you just have one file for everything. This.

A

I think it's very clever, and it also gave me a slightly crazier idea that maybe we can move mix-ins into the build plan as well like, instead of doing all that validation up front. If build packs then are like requiring mixings as like a special shield and the merge tamil, then you could have the stack provide things, but also like a route. Build pack in droves proposal could also provide things. You said having two ways to do that.

A

D

Initial concern with adding nixon's at that level would be that it might be to like open at that point or, if, like we, don't because we don't want people necessarily configuring the mix-ins here right like we want that to happen at a lower level. We don't want to give the user that much access to this is that right or no, it.

E

Would be dynamic right, though packs could dynamically require lots of packages like okay, I'm, not saying this is a bad idea, but to your general point, I think we want to avoid like a large proliferation of many different stack images, because build packs can you know like we wouldn't want to wear, build packs, specify a whole bunch of nixon's and then every build everywhere in the world requires a route build pack to install all of those mix ins, because every build would get really slow right, I think I, don't think that's a feature that has to happen with that funnel.

E

But if we weren't careful, I could see that happening, but I don't dislike the idea. I just like that long gotcha. Also in.

A

Some ways build packs. Are you specify they're required a list of mix-ins, but they sort of do it at different mechanism? And then, if we hooked into this mechanism, then you know the stack can provide it or bill pack can which gets around some of the uglier edge cases. We have route bill packs.

A

Also, a user could require something if they like. Take it all the way, just a thought, because we can then use this same mechanism instead of having like a third layer of compatibility going on everything can sort of fold into one place.

A

E

A

They've known that, for now it's not important for this conversation. I'm.

E

Interested in the weird educators, but I don't want to I, don't want to dive in too deep because it's probably go upstream right.

E

Cool I'm really excited about forests. Wait will you propose there? I would be ok proceeding with it called anything with the idea that we, you know or anything other people agree on with the idea that eventually we get it into the spec and you know like tune what that looks like I think.

C

The only other thing that we wouldn't need to do is I would need to move this spell pack from my personal repo into something like the picado community or something along those lines.

C

If we wanted to do that, but I'll see that after we accept it sounds.

E

Good, if you wanted to put as part of this RFC, that the build play and build pack moves into the official repo location, that would be a way to get the boat as part of that right, hey. This is how we're gonna do this we're going to use this build pack that becomes part of the project.

E

I, don't think there any other routes to any RFC is anything else on that.

B

We should probably ask the question whomever started the build pack yeah mo. Do you want us to continue trying to process the Apache mo in parallel, or do we consider this to be a sufficient replacement for Dan.

E

Is not here today, I think you still on vacation, alright yeah.

C

Dan's, not here and I, don't think Ryan is here either, which is unfortunate because I believe they're. The two authors on that rnc I have we I have talked to them both about the and they're both willing to go forward with this plant. But we should definitely probably close one of these before we accept the other one sure.

B

Yeah so that'll be there, but if they're not here and they they- you know they're on vacation or something like that. I think we continue along with yours and their indication of their support, for it will be too close. There's if you just want to communicate that back to them sure.

E

Would really appreciate non blending reviews on forests PR also just want to see who supports it, and if people have questions anything I really encourage people to take a look and an approver or not approver or whatever. You want I think.

C

I need to add both Paul I think Emily's on there, because I talked to you about this. I was not necessarily super concerned about anything Paul or Ben, because it doesn't necessarily directly affect you. But I can add you if you like, no.

B

No, this definitely affects s like the the reason I would never have supported, or we never would have gone to support bill, yeah, Moe or bill packed out yeah moe, but this the key thing about this is: it doesn't require me to support it right. This is, if anybody adds this to an order, all build packs implicitly support this behavior, and that's actually. What makes it so attractive to me is that it requires nothing. So I am very much in support of this.

B

We will absolutely add it to the Java build packs as well once they once it becomes a real build pack image yeah.

C

Then I will put you both on as reviewers parties.

B

C

E

Right next thing on the list is give, via my bill tax relative permissions to manage close PRS in potato repos. Yeah I put this one up here: I.

D

Was talking to Ryan about this as well and Dan, and so currently our workflow is like that our bots open PRS, when we're updating dependencies in the build pack and what happens when we're doing development or if something messes up, is that we have like five or six PRS in a row that you know are doing different things slightly in our erroneous and then we have to message the maintainer z' of these build packs.

D

Are these repos rather and tell them what's going on and just ask them to ignore all these, or only except this one or etc, because we don't have permission currently to close those PRS or do anything with those okay, if you're opening a mic and closing because the bot is opening them, that's.

E

Right but yeah.

B

You have to just sign it into the bot user to do.

E

It because I don't want people signing in as a bot right, because the security model there is pretty bad. If we're saying the bot acts on behalf of rel edge, is that right? Because I come in the model right now yeah, then, if repos can we make the bot part of a team? And if of you know supposed to open and close these PRS? If that makes sense, I guess you can't? If a bot opens a PR, you can't have other people close the PR right without being maintained in there I. Don't.

C

G

C

Know that it might make sense to could you do that all with contributor permissions, so contributors.

F

C

Have write permissions, it might make sense just make people in the relevant team contributors if the bot is working on their behalf right yeah.

D

Ryan was Ryan was saying something about like we don't need to be maintained errs. We just need to there's a way that we can just have permissions to like close PRS and stuff and- and we don't even need to be able to like accept them. I forget the details on how that works, but Ryan.

B

There's a triage here now.

D

There's a triage.

B

Role, possibly yeah, so that's a possibility, but I I'm sure someone I just heard got interrupted. Suggesting did you just write a little script for the bomb techs.

G

That's all I was gonna say just like take the token and then write a script on your workstation. That only knows how to close PRS, because that's essentially the same thing. It's about opening them right, I mean it's just automation, you have it all in it, I mean it'll limit the interaction you have. That's the ball right, like you're, not gonna, do anything. It's just like closed PR PR number X in this repo, then the bot just.

G

Does it that's nice too, because it'll show the bot as being the one that does it, which is maybe good I, don't know.

C

Potentially, a more robust solution is, we could have it so that you could write comments inside the PRS, where, if it's open by the body would be closed by the bot, if you come, did something as well right.

B

Up until I wrote a comment in there, yeah.

C

Saying that it's perfect but yeah.

E

B

I'm not fundamentally opposed to the the idea of adding a triage user or adding a team to the triage group for this I'd prefer not to have to simply because it's not a super common use case. You see and open-source projects I like the idea of the script, but I don't think it matters particularly then.

E

You don't use that bot to bump your implementation, CMBS for your Java C.

B

And B right, I, so I have in commits I, have to put an email address in a bits: robot a professor bio, but it's not a particular user that anything is tied to like.

E

The relative spot is that doing anything on the Java side. Right now like this may just be some team thing within that you can work out with a non Java sub team. If ben is a using it yet, and we can expand it out later and figure out what yeah.

B

Yeah, this is totally I was looking at it from a governance perspective. You know, you'll, never find another open source project. That sort of randomly allows triage permissions to some other group of people that aren't you know, maintainer Zoar contributors and so from that perspective, to maintain consistency. I like the idea of just having the script, but in practice I, don't think it matters at all makes I think.

E

We want the relevant team to be contributors to all their repos, in that they are acting in the open source, contributing to those projects they're just not maintainer- of the particular language sub team, and so that should fit in as long as we're comfortable with I just had no company's rules. If we need to to say that yeah.

B

The issue is I, don't think what I think we're confusing two different things here, or certainly I am as I think about it contributor to the project. It's not necessarily made github contributor permissions which alright sufficient yeah but yeah if they want to be contributors and weak, grant contributors triage sure, let's go for it. If.

H

We did do that, though. I wouldn't want us to be necessarily contributors to the medicine B's, because we don't create the picado bot does create PRS and the meta cm B's that the feature in Jesus but team uses the the relic stream. Isn't the one doing that so it'd be better. If we didn't have access to close those PRS, because we didn't open them. If that's possible.

B

I'll, let you all sort it out.

E

We'll figure that in the end, I think it ends up looking like the biology, makes builders and the rel, and he makes tools and then the governance stuff, all sorts out normally, but we're shifting stuff around right now, I think it's like a very high level way of describing him I think it. The intermediary state makes the problem seemed like the governance is more tricky than it really is. The end.

E

Yeah well I'm happy to help out with that. If there are more questions on it, but I'm gonna move on to the next one for time, that's good, I,.

E

Check on the agenda instead of a check, ok, buildpack, yeah meal replacement. Rfc did we just talk about this? It's cool run, image mirrors.

A

This one was me: I think we should publish run image mirrors on all the major registries. I, definitely notice. Once we moved to GCR now, when I can do run, it comes out, it slows down exporting to docker hub me. Do you have this convenient mechanism, so we can help people find the closest mirror to get the best performance.

A

We don't I'm also happy to just open this as an issue, but I wasn't sure still getting up to speed in the new governance model, where the right place. To start that conversation, it was we.

H

Can actually publish the images to docker everybody? We just need to add them as run image mirrors to the Builder, and we just pointed a story to do that. So hopefully we'll have that done soon. I'm.

A

H

B

A github issue somewhere, that's open when you say a story: no.

H

It's just in our backlog.

B

Can you open.

E

B

Can you open and miss you in github, so that I have something to follow on sure.

E

And figure it out, then what stuff should move to github on a rail inside? Yet quite yet so we still have some tracker stuff. There yeah.

B

Like I think this is an obvious place to open it in stacks, since it's to our stacks or whatever the holy repo name. Is that have the stacks in it and I'll just follow it from there? Wouldn't.

H

It make sense honestly, no, but wouldn't it make sense in the build a repo, because these are under material on the Builder.

B

Yeah that could work as well yeah.

E

That's right run: image mirrors, don't go on the stack images at all they're, just there builder specific, because we don't know a couple: the stack images yeah, that's a great point. Definitely.

B

Does are, does the documentation either for Poquette Oh, broadly or in the stack readme describe where all of those mirrors are.

H

I think the Builder Evo actually does already I'm, not sure I can check.

B

That out, okay and then the final one is: can we also do what it takes to get a mirror on a CR as well.

H

Sure thanks! Oh thank you. Can you open an issue for that? Actually, where would you like me to open.

B

I guess the building rebellion that must be the stock rebut that one must be in Sakura, but right. The stack manages where its mirrors are and then the Builder repo manages the dock and consuming of those.

A

B

A

Places the stack has to get pushed out to all the repos, but they don't those images, don't reference each other and the Builder ties them all together.

H

Stack repo has nothing to do with where those images are pushed, though, all right, that's, it should.

F

Absolutely what.

H

The repo itself doesn't say where it's I mean under other than like the readme I. Don't think the repo itself would tell you where it's pushed to right. Where's that live. I I've.

E

Redefined configuration.

H

Pile where's, the pipeline configuration file, the Raylan's yeah kid every pillow.

B

Every change to the stack should be document or, like should document and trigger out of that right. I. Imagine we didn't do it in concourse. We did it in github actions. Instead, that's where it would live right. That's then vice versa. The consumption right, changing and and setting up the mirrors themselves as a piece of documentation and a builder tamil would go in the Builder yeah.

H

Right make sense.

H

All right, random.

E

Errors, we should also talk about the tracker for rail edge and saying what stuff we should push towards.

E

The Kato registry proxy to pick a delay. Oh.

F

I put this one down: someone on the VMware slack just brought this to my attention and like I, was wondering what you all think about it around setting this up and I think this would redirect something like potato io, / I, don't know Java to the actual registry location, so I felt like this would be like pretty cool. Well, you XY is I wish GCR had something like this to just allow us to have like Vandy, URLs.

E

I've seen this before it routes all traffic through your like, if to set up a proxy that either gets traffic routed through it or it's responsible for reader like relaying a whole bunch of redirect URLs, it's like a little bit of a hack. If that makes sense, also the the images will get written to the registry with potato I/o tagging them instead of the GCR IO tag like in their image config.

E

So it's not totally transparent, I'm, not saying we shouldn't do it it just it's a little bit of a abuse of the registry. That makes sense no.

F

Totally that makes sense, I just wanted to bring it up see if we anyone's interested or not no issues.

B

Yeah I'm not super interested in it today, because I think the vanity redirect URLs are going to be handled by the build pack registry itself. We're gonna eventually have a registry. Build pack saw IO, slash, potato, build packs, slash, Java, right and I. Think that's gonna, be the centralized good-looking URL that everybody's going to use and like where we're gonna stop talking about the GC arnis of it pretty quickly.

B

Once that happens, if I'm willing totally willing to reevaluate that if, in the long term, we still have this problem after the registry comes into existence, we should evaluate vanity URLs like this. Oh.

F

That makes sense. I didn't know that the build packs registry would handle that. Could you link me some talks around that then.

B

The specification PR is now open in those two repos, but fundamentally they're going to do a rest. Like sorry, the rest of rust, like registry, which is basically a git repo with a bunch of files that are indirect pointers and so you'll reference registry, build packs that IO namespace name so basically the the two parts of the ID of a build pack, and then that will resolve locally for you to a pointer to an image registry somewhere in the universe. And so yes, the download will happen from GCR.

B

It will happen from a juror will happen from docker hub. But your perspective is the ID being potato buildpack slash java exclusively got. It makes sense.

B

And keep banging on Joe in the meetings about the registry he's he is like the personal owner. It's clear at Heroku for making that registry happen. I was very much against it for a long time, but he's actually come a long way and I like the design of it now so as soon as it is available.

B

Certainly the Java stuff may, after the Heroku people, finished testing it and make it slightly works, but as the job of stuff what's gonna, be on it instantly to start paving that way getting away from us ever downloading Torvalds hiding the fact that we've chosen GTR is our download site. All of that stuff, I think, is a good long-term.

F

Cool, so it's good.

E

An external list is standardizing on implementation, meta, buildpack, release, notes.

F

This was me as well I think, with the a lot of the stuff, the what we call them feature engineering team is doing to like publish implementation, build packs and meta build packs. They now have like a standardized release. Note format around like where we're listing the full list of dependencies in your build pack. Tamil dependency depredation dates to false things like that. So I wanted to see if we could like standardize on some of that across some of the Java team maintained repos as well.

F

I could think of this being like really helpful, especially for things we want to add in in the future like proc file and then I forget the other one image, something image you souls I think I mean.

C

I wonder if we had.

F

Like a standardized on everything, this would help us quite a bit when we do have eventually meta C&D release, notes which I'd imagine just being like a rolled up level of all of the different implementations yeah. What's the what is an example, I'm working on right now, uh that's a good question. I can share my screen right now. We could find one I think, maybe telnet core awesome.

C

You're gonna want to go to one of the Appel.

F

Actually wants an implementation yeah, so.

C

You can just add asp net runtime pick your favorite one here.

F

We go so. This is the example where we have like dependencies supported stacks and then I think for some of them like that, have deprecated defaults listed in them. You'd see the default as well, so I think like note engine might be an example of that.

F

Yeah exactly so like default dependencies dependencies supported statics and can you click.

B

B

And so when you're assembling it, the key is the you're just looking for the magic phrases dependencies default dependencies support stacks things like that. I.

C

Don't quite remember exactly how it works. We have a tool that helps us generate these by, like I, think it actually flips apart the tar file and reads the pill pack tamil inside of it yeah.

B

Sorry, my my question was about the next layer up the things that consume this release note are just looking for the magic strings and then a table inside of them or table below them. I.

F

Assume that's what we would do like this is again just stuff that I was just thinking about last week with a lot of thee. So we have the implementation, C and B release notes. Language, family level. Stuff would come next, so I'd assume that all of our teams maintain stuff we'd be able to do this. But if you could like have a very similar output or like reused, tooling, that's existing there's.

B

F

Like that, then that would be nice, though, so we could just like reuse that yeah.

B

So very similar isn't good enough for me. I want to it matches exactly so I'm trying to trying to get an idea of what actually was important in that. So, if you can have somebody on the team reach out to me, so I can understand exactly what the magic words are and or if ordering matters things like that. What the table structure is exactly supposed to look like make sure that we start doing that cool.

F

That makes sense, I, think forrest, and I are chatting later today about this, so maybe show you a message after thanks sounds good yeah.

E

All right, okay, next thing: the list is: go language RFC's,.

C

Yeah I just remembered that Ryan and I did this. About a week and a half ago we were trying to find a way to consolidate the decision making process that we had for an individual language language family. So in this case, go since we're both.

F

Containers on that.

C

And we decided that the best I guess middle step until we figured out either a permanent solution or decided that our middle step was. The permanent solution was to put in RFC's folder inside of our meta buildtak language, and we make any large proposals for the language family in particular the one that we were just inspired. This was we want to.

C

We went to reconfigure the structure of the go, build pack and build out new, build packs and simplify other ones that we already have that exist. So if you are deeply invested in the go, build pack language ecosystem- and you have lots of opinions about it by all means you can go there, put an RFC's read the RFC's we have and demon. We disagree with them because they haven't been implemented.

C

Yet you know all your favorite things to do, but yeah I just wanted to call this out as a structure that we were using and either have people not care or really care, and tell me why I'm wrong I.

E

Think it makes sense that you wouldn't want to open a proposal about a big change in the go bill pic to the general project by Darcy's repo I. Imagine Ben will be similar things for Java, where someone wants to propose a big structural change, but you don't want to like you're, not itching to present it to all the other language, maintainer x' I think the structure makes a lot of sense to reduce duplication. I proposed it seems like a reasonable place to put it as long as you're.

E

Okay with you know, our f ckin', that's going in. On top of the you know non RFC stuff, when you pack into the build pack, you probably should package it with the RFC's.

C

F

C

To that I just wanted to call out that was the structure that we were using for any set of maintainer. So it would like to use a similar extra structure or a FOID that structure. Sorry. Why weren't these issues?

C

We didn't feel that issues were the best way of getting making sure that you had consensus from maintainer. So by doing an RFC, you can have maintainer x' half you can make it so. The maintainer x' have to vote on those pull requests that the RFC's are a part of, and then.

F

C

Could have a process where we could approve these changes without going into an issue and, basically writing. This is an issue that be you know approved. We also thought that it was a better paper trail, so you could go into these RFC. Is things and read? Our engineering decision tree basically was.

E

A very practical thing about issues we used to have like you could do an issue instead of a PR for RFC's in the CNB project very early on years ago, and you can't comment on lines and issues, and so it makes it really hard to have a whole bunch of people review something and say what about this part. This doesn't seem right or whatever. If all the conversation is a linear thread and lots of people trying to quote different sections of it, it becomes kind of intractable, fray piercing.

E

You do, though, yeah with a PR with with the text in the repo. You can comment on each line even.

C

E

Changes really easily to.

E

Github as a thing now or you can actually propose a change to a line and the person opening a PR just hits a button and it automatically converts it into a commit, an emerge as the change in which is really good for editing. On text collaboratively. When you try to agree on something to till.

A

Rdc Obot, inevitably barfs on the commit that you've on a committee.

E

Think you can, you can open that up and text then did something and then paste the sign by into the bottom part I. Think I did that once it work anything else at about that.

E

Alright thanks everybody.