Thanks for clarification, I haven’t paid attention to this detail.
But I think it doesn’t change much in a way how we should aim to make the service open and accessible, with the transparent decision-making around it.
Even if Fedora critical path will be elsewhere, we let the Fedora users build their own paths and for them services like copr or Image Builder can become important pieces in their workflow.
Like we can say Copr is not critical for the main Fedora release, but it is essential for some of the development process of certain packages which get into Fedora release, and for some of the consumers of Fedora, which add packages after the release, so we still care if it works and functions properly.
And if I am eventually would like to use Image Builder service for CI tasks, again it is technically not a critical path, but it still important piece of the Fedora infrastructure.
This is a complex topic but yes, I don’t think it would really work or scale or be ergonomic at all to expand the current “pipelines as Go code built into an RPM” to a larger set of things.
One of these days, we are going to have to fix this illusion that we have about Copr not being critical infrastructure for Fedora. Not only is this not true, every day we pretend that it is a disservice to the people that rely on it. Virtually every SIG uses it now, it’s a hard dependency of Packit and other services, etc. We rely on it now for package reviews, even!
It is absolutely critical to Fedora development and engineering, and some day we are going to have to talk about moving it back onto the fedoraproject.org domain and declaring it “fully supported” (whatever that means).
Please do not use fedoraproject.org as the domain for your service. Use either fedorahosted.org or fedorainfracloud.org instead. Being called a fedoraproject.org service implies that it’s part of the main services that distribution development is dependent on, and this service is not that.
I think that if we go with console.fedorainfracloud.org, this doesn’t need any further formal approval for the three outlined phases. Let’s get started and see what it looks like!
I would really like to see this proposed as a Fedora Community Initiative. What could be accomplished in the timeline of 8-12 months? A Community Initiative is the vehicle we typically use in Fedora for driving change that touches on several different parts of the Fedora community and spans work that is beyond a single release cycle.
I want to see this as a Community Initiative because I think this project is very exciting for Fedora and we should be mindful of getting more visibility and eyes on this work. We need to work with multiple stakeholders to address the long-term questions that many people have brought up already in this thread. If we limit ourselves to this Fedora Discussion topic, I am concerned that this will work will get lost in the churning ocean of change in Fedora.
I also like the idea of a Community Initiative because it builds in an explicit end date for us to stop, reflect, and ask is this really working for Fedora?
@ochosi Is there something that myself or the Fedora Council could provide to get this tracked as a 8-12 month Community Initiative?
I think this is the most important question. On a practical basis, the “first line of defense” for end-user support and troubleshooting will be the Fedora Infrastructure Team. When community members identify an issue with some kind of Fedora-branded service, they turn to the Fedora Infrastructure team. This could mean a Pagure ticket, messages in the Buildsys/Infra Matrix rooms, and/or posts here on Fedora Discussion.
Ultimately, we need someone to own this and partner up with Fedora Infrastructure for managing this engagement and community expectations. The example of Module Build Service came up earlier in this topic, which I think is the perfect example of ambivalent ownership that we want to avoid.
My question to the Image Builder team would be, how might the team partner with Fedora Infrastructure to make the launch and integration of this new tool into contributor workflows successful? How do we make sure requests for help by the community do not go unanswered?
