@.jstone I was thinking, can we just rename ublue-os/base the repo from base to main?
@.jstone I was thinking, can we just rename ublue-os/base the repo from base to main?
Jand change the package name?
MWe could do that, I'd suggest we start with a branch for the changes. Alternatively, start a new repo and when ready archive this one with a new readme
JThat might be one way of doing it, provided it's also coordinated with moving the ublue first-run functionality into another repo
Jright
Jactually, we should create a new one so we're not in a rush to "flip a switch"
JYeah
XI think we should steer the current base towards being the startingpoint image (as proposed in my graph). Strip it down, and make it a custom image starting point intended to be based on the -main, with more customizability in mind.
J@.jstone is there anything I should be doing to prep for the image restructuring?
Jalso I'd like for us to figure out what the scope of images is on the -main image
JI think the easiest thing to do would be to create a
ublue-os/main repo so that we have a clean slate to play with, and ensure that cosign is set upJok so not a copy
Jbase is set to be a template anyway
JThe scope should be A) one parameterized Containerfile for multiple Fedora releases and DEs B) limit the Containerfile defintion to essential rpm-ostree installs with QoL package inclusion/exclusion lists. This will give downstream maintainers a simple path for consuming images and ensuring that they're only adding features and not taking them out
JI think anyone submitting package inclusion requests should be asking themselves if what they're requesting will be generally useful for everyone and won't benefit just one subset of users. If the feature is too specific, then it should instead exist in a downstream image
Joh I know!
JIssue template!
JOoohhh yes please!
JI'd love a template that lets users select versions and whatnot
JGitHub
A base image with batteries included. Contribute to ublue-os/main development by creating an account on GitHub.
Jworking on template now
JPermission to start placing files in the repo?
Jlazy concensus!
Jdon't add any packages though if you can help it, like add the minimum so we can all use the templates
JWhat do you mean by that?
Jlet me make a template so we can use the templates to add packages
Jso I can test the wording, etc. of the template and we can practice
JAck
JI have fancy work templates I can reuse
JI'll be done in a few minutes
Рhow do you guys feel about feature branches instead of repos? It would conflate issues and PRs into one place but it also might be easier for users to work with
JI kind of kept it split on purpose for a few reasons
Jsay in a few months ribbanya-linux blows up and everyone loves it and you have thousands of new fans and admirers
Jand my ubuntu image does the same thing but it's a different community, though a subset of this one
JThis is going to be :lit:
J
J^^^ can someone review that PR?
Рwell in that scenario the fork would be ribbanya/ribbanya-linux which is a fork of ublue/main, and so my fork would have its own PRs, issues, and discussions
(not that I think separate repos are a bad idea, was just wondering)
(not that I think separate repos are a bad idea, was just wondering)
Joh, I meant within the org itself
Jassuming a ublue-os/ribbanya
Jdidn't we try a dev branch in nvidia and then end up regretting it?
РI mentioned this in the discussions but I do think, since we are starting from scratch with
ublue/main, all of the derivative repos should be git clones so they can merge upstreamJWhat commands do we want run in a bug report, I'm thinking
rpm-ostree status -v at a minimum
JI have very mixed feelings about the mono repo model for our needs because we already have a protected branch model to ensure that people must have a pull request, which means more branches, and making sure we don't end up rebasing and merging onto the wrong branch can be a management nightmare
Jfor sure reinvestigate when we're larger though
РI think it definitely comes down to your social structure of maintainers which I'm not familiar with
JHaving feature branches does work in certain contexts like for managing very similar files across a release branches https://src.fedoraproject.org/rpms/kernel
JFor ublue-os, having some separation seems sensible here. Sharing is good, and that's what we're trying to enable with the reorganization of the image inheritance model
JBut also having the ability to silo ourselves and pull in functionality when needed seems to be the pace people want to work at
Jyeah good point now that you mention it