I think we really just need to embed the tasks in the binaries when built. It makes no sense that everything should be in a single repo. If this was true, no go applications could be built as Go uses always multiple repos from github to build any, even the simplest program.
Michele Sciabarra | CEO m: +44 747 984 8388 e: [email protected] l: https://linkedin.com/in/msciab Nuvolaris Inc | 1209 Orange Street , Wilmington DE www.nuvolaris.io [image: linkedin icon] <https://www.linkedin.com/company/nuvolaris-io> [image: youtube icon] <http://bit.ly/nuvtube> [image: twitter icon] <https://twitter.com/NuvolarisIo> On Sat, 6 Dec 2025 at 13:16, Federico Zambelli <[email protected]> wrote: > Regarding point 2, would it mean we need to completely re-arrange the way > ops is installed, and bring everything under a single repo? > > > > Sent with Notion Mail <https://www.notion.so/product/mail> > > On Fri, 05 Dec 2025 23:17:53 GMT Bruno <[email protected]> wrote: > > Hi all, > > I would like to start a discussion regarding a possible release of Apache > OpenServerless. > > The release would include various OpenServerless components: Apache > OpenServerless Cli, Apache OpenServerless Tasks, Apache OpenServerless > Operator, Apache OpenServerless DevContainer, Apache OpenServerless > Runtimes, Apache OpenServerless Streamer and Apache OpenServerless Admin > Api. > > Before preparing the release candidate, I’d like to gather feedback from > the community about these two facts: > > 1) We should designate a release manager, as stated in the guidelines ( > https://infra.apache.org/release-publishing.html). > > 2) We should find a way to comply with the release rules ( > https://infra.apache.org/release-publishing.html), given that currently, > the OpenServerless installation requires the CLI to download tasks, which > in turn starts the operator, and various docker images are installed > inside > a kubernetes cluster from GH registry. This seems to be contrary to the > following ASF policies: > > - A release must be self-contained and reproducible. > - A release must not download binaries from non-ASF infrastructure during > the build. > - GitHub (including GHCR: ghcr.io/apache/...) is not ASF release > infrastructure. > > Many other release-related topics will probably derives from these. > > Please share your thoughts on this topic. > > Thanks, > Bruno > > > -- > The life is short.. live at your best! > >
