and my ubuntu image does the same thing but it's a different community, though a subset of this one
and 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
Jeveryone's moving at a different pace
J"A base image with batteries included "
JI need a better description, any ideas?
Рis
mainyeah
Jlike should I use the same description that we're using in base?
Jmainwe can remove "unfiltered flathub" soon. 
Jyeah main the repo will generate {desktop}-main
JThere will be a
silverblue-main which is Gnome, but there will be all of the other supported DEs as wellJso I guess it's all of them in one
Jinstead of main we should have called it
theoneРoh right main is parameterized, gotcha
Рwhat is happening to the base repo?
JI'll leave it running
Jand then tell people to migrate, we have 90 days of image reaping in the registry, so whenever we freeze it + 90 days. On day 91 we archive the repo. Sound good?
Рah ok so it is being phased out
JTechnically we could keep it running, but maybe we just called that Alpha and this one is the beta, heh
JI fully expected this to be me by myself and whining to @marcoceppi when I needed something fix
Jbut by the reception so far it's clear to be this is the way, this is the model for more people than just us.
Jlike, if I could go back in time and give this to myself as my first linux ... the amount of sheer toil and suffering I could save lol
Рif base is being archived I feel like main should be unsquashed, as in
Рyeah it's amazing, I can't wait to get my friends onto linux this way
C
Jwhat even is dpkg-reconfigure -a
Di'm pretty sure Linux is mainstream rn if distro like Silverblue exist 20 years ago
Jyou mean like ChromeOS is? 
Jok testing the build chain on the new repo, everything is working as expected so far
Jwhich means the template we started on is self-sustaining fork-wise.
Jso that problem is solved other than people who need to figure out cosign when they fork
Jreview from someone please!
J
