Steve George <[email protected]> writes: > The big thing is having a 'Team' that's going to be able to commit to > working on this consistently. There were a lot of different installer > options that we published in the 1.4.0 time-frame, but when I looked > at 1.5.0 most of them hadn't been maintained. That's not much of a > problem for a one-off installer image for a dev motherboard, but it > will cause issues for containers. > > I think you need a new team, or an existing team takes responsibility, > and there has to be at least one committer in the team.
Do the release team want to take this on? I'm happy to contribute to a "Guix Container/Cloud Images Team" if one was started. >> 2) I'm not that familiar with the Guix project build system, but I >> suppose the images should be built by centralized by it? Is this >> feasible? What would be involved in making that happen? >> >> 3) Agreement that images should be generated by 'guix pack -f docker'. >> Any alternative? > > There's been a strong desire for automation in the project so > yes. Also, most users will want the 'latest' version of a 'container' > since they'll re-roll the base-container quite often. Yes, having daily/weekly/monthly rebuilds of containers seems to be the norm. >> 6) It would be useful to publish images for a recent 'master' commit but >> also for the Guix v1.5.0 release commit -- which ought to be forever >> bit-by-bit identical once prepared (or?) -- and for future releases. >> > > I expect you'll want both. > > Given that guix pull takes a really long time I would expect that > users that deploy to 'production' would use the latest commit on > master. It's good to have the release commit as a separate one. What I found in my Guix images jobs is that if I 'guix pull --commit=' to a commit that is ca one week old, things are much faster since the substitution servers have cought up. Maybe some people really need latest master to mean really latest master, but I expect most usages will just need a "reasonable fresh image" that can be a couple of weeks old without problem, and even a month or two isn't a problem, but two years is definitely a concern. >> 7) How are they distributed? I suppose the images could be published on >> gnu.org/gnu/guix/ but the container-way is via some public container >> registry. Docker Hub is well-known, but there are many other. I'm not >> sure if Codeberg offers one. What are the concerns here? >> >> What do you think? Other concerns? > (...) > > According to the Codeberg documentation OCI containers can be published: > > https://forgejo.org/docs/latest/user/packages/ > > I can see the 'package' link on the Guix organisation - it's pretty > hidden, so I wouldn't expect many users to know about it. We could > link from the Guix download page as well. Yay! Then getting the packages pushed to codeberg/guix's container registry seems useful. Is Guix using any Forgejo runners, or are everything built on ci.guix? I wonder how to automate the Codeberg container image uploads. > The main concern for me about Docker Hub is I don't know what their > policies are these days. As long as there's no charge for > distribution? I expect it is a horrible mess, but I started pushing my images there to gain experience how that site actually plays out in practice. /Simon
signature.asc
Description: PGP signature
