-
Improvement
-
Resolution: Fixed
-
Normal
-
None
-
None
Opening this bug in response to FL-8232, so that the discussion can be focused properly on the boundaries for stable-release, next-release and where the bleeding edge should live:
drobbins opened with an explanation of the new bootstrap project:
We just launched the 'evolved bootstrap' project which is a true clean-room environment to build whatever toolchain and build tools (including musl) we want without having to worry about impact of these changes on any ebuilds that people are working on. I agree we need a place to unmask the latest build tools – the problem arises when it breaks a bunch of other things that people are trying to stabilize. evolved bootstrap solves the problem because it can exist on its own as just a minimal build, without the upstream packages that we have to worry about. Getting those working can then be a separate process, not an unplanned-for disruption, so we do not have to worry about impact to desktop environments, etc. Otherwise are always getting held up by potential breakage of ebuilds that someone is working on getting to build. Hopefully that clarifies the predicament we are trying to dance our way through but I think we have a way forward. Just have to adjust the course a bit.
calrama responded with
First, maybe this should be discussed in a separate bug report (for later visibility)? Anyway:
I was under the impression - though it may not have been explicit - that next was supposed to be the bleeding edge, and when we wanted to stabilize things, we were going to fork something like X.Y-release-rcZ off of next and then stabilize that.
If we don't want next to be bleeding edge, then I propose we do add an `edge` or `dev` branch for that.