I would hope that the benefits of this lifecycle structure would make it possible for all new infra projects moving forward could commit to this lifecycle structure. I’ll go even further and say once we gain experience with the full process, we could even put mature infra bits into the process so they gain a maintenance review gate and benefit from explicit sustainability expectations with potential remediation via curation.
I think the Konflux experience is something I think would be reasonable to think through, yes.
My view is, how Konflux has been introduced is effectively a very loosely defined sandbox, with a false start or two. Its on a path towards integration now because its started to get some traction from contributors interested in using the technology. But there’s is less clarlity on the expectations on what a sustainable konflux implementation for Fedora looks like, and as a result there is more anxiety about it then there really needs to be. A lifecycle process with clear stage exit expectations and review points may have helped get clarity around what is expected from a sustainable Konflux integration.
Konflux is also one of those pieces of technology that may eventually be integrated deeply enough to be considered critical path infrastructure. So its also interesting to think about it from that pov. This structure of this proposal very deliberately doesn’t address things that are known critical path items and is expected that everything that goes through the lifecycle process can be retired if its found to be unsustainable and can’t be remediated with curation stage commitments to bring the effort back into a sustainable state.
If you’ll pardon me from going on a tangent just a little bit…
We have to be very careful about designating things critical path, and be very honest with ourselves about how much of the project output requires critical path commitments, who is only the hook for those commitments, what the true critical infra commitment capacity is, and how much of the project should be self-servicable.
I’m happy to breakout a discussion about critical path capacity as a new related topic if there are thoughts on that that need to be explored. I think a much more robust discussion about explicit critical path commitments and capacity will be impactful and in scope once the forge implementations are fully stood up and we can experiment with self-servicable workflows that take advantage of forge action runners.