Hence "just about" and no absolute terms about scope
Hence "just about" and no absolute terms about scope
XWell, it's doing builds and publishing them, but it's not intended for people to directly use as it doesn't really do anything main doesn't (except the template flatpaks install on firstboot)
XWell obviously not absolute, maybe Linus Torvalds would be there, and maybe I was going a bit far. I don't think peoples custom images and main are on the same level. If we give instructions like
make a new main, and then switch the FROM field to be main, I reckon that's a bit confusing. Not to mention that the scope of main is to build all of the desktops whereas one persons custom image should probably only build one desktop by default.
CTo phrase my confusion differently, what does "starting point" do that main, which was specifically made for that purpose, does not, and why should a weak link be introduced with the potential to diverge and splinter off? What do images inherit from "starting point" that should not be in main?
XMy intention for startingpoint was as follows:
A repository for clear instructions and a fantastic starting point as yall've created for making your own native container image, with clear documentation for all parts so you don't have to get lost in a codebase not made for what you're doing.
A repository for clear instructions and a fantastic starting point as yall've created for making your own native container image, with clear documentation for all parts so you don't have to get lost in a codebase not made for what you're doing.
CSo Main.
CBut splintered off to add inheritance steps
XMain is the uBlue upstream image.
CYes. Upstream.
XIt is not a starting point, and I did not believe there'd be a reason to make it into one.
CThat is what everyone has been talking about it as and working toward designing it for
XI'm confused at your confusion, sorry. Images don't inherit from starting point, they're generated FROM it.
CTo me, "starting point" looks like an attempt to splinter the custom images away from the Ublue project into your own thing, instead of having one organized modular inheritance tree
XSplinter which custom images?
CAll of them.
XStarting point is literally in the uBlue org, intended for people making a personal custom image. I don't think we want everybody's custom image where they just changed a few flatpaks and added some rpms to be an official part of the uBlue project.
XAnd even less do I have an idea of where you got your idea of it trying to split custom images away from uBlue?
CAnd it was never going to be.
XWhat was?
CI don't think that is the actual intent; I was just trying to express how incredibly bad it looks from a technical perspective
XIt is technically the same as ublue-os/base.
CWhich was specifically deprecated in favor of main and its better structure
XWell obviously. So not trying to have them as part of it is not splintering.
XMain is based on Base, the deprecation was done because it's role and name changed. Main is the upstream image, which other uBlue images are based on. Base was both an image with some goodies and a template for people to use. Main is intended to be those goodies, and startingpoint is intended to be the template.
XIt's true that it was my plan, and I executed it because I saw it fit. If yall don't want it then alright I'll just remove the repo or something and redo all the documenting on main.
XMy point is; Why have a repository that serves two purposes, and inherits itself? Why not have a clear structure of inheritance, where the inheritee is another image that serves another purpose?
CI've been following discussions in this channel fairly consistently and I'm confused by "starting point" because everyone else was ironing out how to structure the project such that Main functions as a unified template for all of the official AND unofficial images, and the diagram they used, which you created, supported that.
I do think that documentation was/is/should be a priority on the to-do list for Main, but I don't see what would be different from Main in "starting point"
I do think that documentation was/is/should be a priority on the to-do list for Main, but I don't see what would be different from Main in "starting point"
COf course, anything I say can be overridden by the people I'm trying to indirectly relay information from, if I misunderstood something
XThe graph I created specifically included a starting point, and as far as I know nobody was complaining then. As far as I knew, Main was supposed to be just an upstream image, but apparently it actually was not and was intended to be multipurpose.
CMaybe I misremembered the diagram or it was maybe interpreted multiple ways, I'm looking for a copy to refresh my memory
MI think overall a lot of this can be avoided if we do more consensus seeking and PRs for reviews
XChanged it! See above link
Coh
I think I see what went weird
I think I see what went weird
MI’m going to fill in branch protections everywhere but even Jorge does everything via PRs for reviews and it’s a standard we should embrace
XWell, yeah. The bane of an open source multi-person project. Heh.
XStartingpoint was a new repo though, so nothing to PR to.
XYall should probably remove my write access to the website though.
MBut checking in this discord first could solve a lot of headache
MOr a discussion to outline the goal and purpose
MIn GitHub
XI just happen to be active at times many other people are not. Except for the people seeking help with their custom images of course, who get many conflicting sources of info.
MThat’s why we have GitHub discussions! 
CI interpreted the "starting point" box as a categorical representation that any of the above could be forked as the basis of a custom image, rather than one concrete "starting point" repo.
I think the former makes more sense because it allows people to fork custom images from any point in the modular inheritance they want to, including the bare-bones upstream main, rather than all starting from one bare-bones template identical to the upstream main
Either way, I'm glad that the communication snag maybe got found so it can be addressed
I think the former makes more sense because it allows people to fork custom images from any point in the modular inheritance they want to, including the bare-bones upstream main, rather than all starting from one bare-bones template identical to the upstream main
Either way, I'm glad that the communication snag maybe got found so it can be addressed
Xbut then I would've had to ask yesterday for what I did today, and I didn't have time for that, so I couldn't have done it today, so I wouldn't have done it this week,...
in the end, it's a new repo, I didn't do anything that breaks things. I went with the lazy concensus https://ublue.it/CONTRIBUTING/#i-want-to-contribute
in the end, it's a new repo, I didn't do anything that breaks things. I went with the lazy concensus https://ublue.it/CONTRIBUTING/#i-want-to-contribute
XThe concept of “lazy consensus” is very important in your project. Lazy consensus means that when you are convinced that you know what the community would like to see happen, you can assume that you have consensus in favor of the proposed work and can get on with it. You don’t have to insist people discuss and/or approve your plan, and you certainly don’t need to call a vote to get approval. You just assume you have the community’s support unless someone says otherwise.
XI view the approach of somebody being encouraged to fork any other uBlue image as a base for their own custom container image for just doing a couple of tweaks way more confusing, than having a clearly simple documented single-purpose template repository.
CThe trouble with that view is that it breaks half of the purpose of the Ublue inheritance tree after the current restructuring, because it somewhat forces everyone who wants to make a custom image to start entirely from scratch and duplicate 80% of the Ublue project effort instead of just making a few tweaks
CMaking just a few tweaks to get what you want is only possible if you can choose where you want to start from
Bpersonally im not sure there is any point for startingpoint repo imo
