j-k

cc: @knqyf263 to get your input before any further changes

Not required but advised. This is what I put in the review > Since the maintainer is interested in this being packaged id advise they tag a version 0.0.1 People...

@papojari is exactly right --- Just some extra detail. A tag is a git feature a bit like a branch fixed in time. A github release can then be created...

yeet is certainly memeworthy. Maybe `trebuchet` with the short hand being `treb`? still leans into the *yeet* throwing angle

I raised a comment on this in the related issue: https://github.com/paketo-buildpacks/rfcs/issues/176#issuecomment-1189903775

For anyone desperate for prebuilt releases right now we have the following releases for gitoxide in nixpkgs: * `aarch64-linux` * `i686-linux` * `x86_64-linux` * `x86_64-darwin` * `aarch64-darwin` https://search.nixos.org/packages?channel=unstable&show=gitoxide&from=0&size=50&sort=relevance&type=packages&query=gitoxide

SLSA is generally any software artifact and increasing the trust in it so you should gain more confidence that between src -> result your artifact wasn't compromised. But then the...

Translating it now means that people more comfortable with Japanese can get involved molding the direction of SLSA ahead of 1.0, also it means we can test out the translation...

In the interest of getting things done I think rather than SLSA starting from scratch we can rely on the great work already done around reproducibility https://reproducible-builds.org/docs/deterministic-build-systems/ https://reproducible-builds.org/docs/perimeter/ https://reproducible-builds.org/docs/virtual-machine-drivers/ https://reproducible-builds.org/docs/rebuilders/...

I guess you'd need to establish a series of requirements that constitute a "trusted robot" in a SLSA context. I'd say it depends what the robot does. If it's dependabot...