Indeed.
Make it work. Gordon is trying to do exactly that inside the bounds of the project.
He’s looking for that experimental space… and we are having trouble identifying what that space is.
Let me recap.
Infra appears to have a prohibition of using the forge resource as a dist-git for packaging sources. Otherwise @gotmax23 suggestion would be spot on.
I proposed that Gordon might be able to use the /forks namespace in the existing fedora dist-git as a next step. I need to sync with Gordon to see if that suffices for his needs to build a collaborative experimetnal space. There are limitations with that, because he might not be able to use the fedora build system (koji). But it might be sufficent as next experimental step inside the project if he’s okay continuing to use whatever local build mechanism he used in his demo.
My understanding of what Gordon wrote is he’s trying to avoid doing this entirely outside of the project space, because doing that will look like competition with the project. He doesn’t want this work to be viewed that way, he wants to work within the project boundary as much as possible and build a collaborative space inside the project.
I still don’t understand why the “experimental” stage / proof of concept can’t happen with dist-git-like repos in a GitLab / GitHub namespace + builds in COPR? Multiple people have commented here that building things in prod koji would either not work (scratch builds) or require careful policy changes (allow building from non-canonical repositories like forks) - whereas COPR is the place to build “unofficial” packages.
Okay I have clarity on the concern about COPR after syncing with Gordon.
COPR actually doesn’t provide wtite-able dist-git facilities. You point COPR at a dist-git you control.. such as github using the SCM option when defining a new package.
Gordon’s current understanding of the feedback he got from fedora forge infra people is that that using the fedora forge in this way is a policy violation, so he’s been avoiding doing it.
I took a look at what Asahi linux is doing in their copr and the are refering to a forge git repo as the SCM source. So I need to have a follow up discussion with the forge infra team to clarify the policy.
Hopefully this is just a misunderstanding of the policy around forge use as it relates to copr and at worst maybe what we can do is have Gordon working as part of forming up a SIG get provisional exception to make use of forge repo in the same way Asahi is for that group’s copr so he can do the collaborative experimental work he’s looking at doing.
My understanding is that if you aren’t trying to follow Fedora’s guidelines (at least the legal requirements), then yes it’s not allowed on the Fedora Forge, because it isn’t allowed on any Fedora property. The other issue is that the Fedora Forge does not allow personal projects at all. I actually disagreed with this choice by the infra team, but that’s the way that cookie crumbled.
We don’t use it for Koji, though. As far as I know, it’s been fine in COPR. And Asahi SIG is a SIG producing packaging that complies with Fedora Packaging Guidelines. We aren’t trying to violate the rules.
There is no reason he couldn’t do his collaborative “not really Fedora” stuff on Codeberg (if he follows the no-AI rules), GitLab, or GitHub. Those all can integrate with COPR. And personal COPRs can be shared with other people, just like personal GitLab and GitHub projects can.
I don’t understand this? Are you saying you want to have Gordon make a SIG to work around the policy violation so that he can do something that most people who have responded to this have said shouldn’t be a Fedora thing in the first place? That sounds like a bad idea.
He wants work collaboratively inside a SIG. The demo is meant to explain what he wants to achieve, but he wants to do that in a collborative space inside Fedora. A SIG should be that collaborative space yes?
There is a lift and shift from a single person with an idea, gathering people who want work together further as part of a special interest group.
This is not about getting around a policy limitation.. this is about bootstrapping a colaborative space. Gordon has said repeateadly if his goal was jsut to do this work out on his own he could just have it live in github.. outsside of Fedora. He explictly doesn’t want that, he wants to work collboratively inside the project.
A SIG should be that space shouldn’t it?
Its not about most people. SIGs don’t exist because most people want to work in that pocket. SIGs start as small groups. Gordon is trying to find that small group.
Look man, I get it.. you will not be part of that initial group that Gordon needs to collaborate with. You’ve made that very clear. It’s fine. But Gordon wants to find that small group, who understand what he wants to try to achieve and work on it inisde the project space. He should be allowed to build that group, and that group should be allowed to work together and collaborate.
No, I don’t want to avoid or break policy. I’m pretty happy to continue development work outside of Fedora infra, and I’ve tried to be clear about that. e.g.:
From my point of view, infra is not the critical piece right now. I’m inviting interested developers to work with me. Collaboration is a critical piece.
I do not want to create the appearance that I mean to create a new distribution. That would impair the appearance of legitimacy of the project. But if I work outside of Fedora and host an indefinite number of dist-gits derived from Fedora… it’s going to look like a distribution if you squint.
So in addition to developers interested in the project, I would like feedback on how we can present the work as a project intended as a demonstration on which a future proposal will be based.
That’s right. We didn’t want to make Copr’s internal “proxy” DistGit to be a real pet project (with TBs of data). OTOH, starting a custom SIG specific lookaside cache is a triviality (I can help there, within the upstream DistGit project we maintain..). Unless SIG want’s to have a “production ready authentication”. But then, we can easily tell Copr where this “new DistGit instance” lives (it is just a Copr configuration option).
Hey! thanks for that very interesting possible pathway. Maybe we should set up some time to have a 1 on 1 to talk about that.
Actually one of the other things that came up in my sync with Gordon was where to host these containers during the experimental phase. If COPR had a capability to host OCI registries.. OCI registries capable of hosting both traditional linux containers and flatpaks.. or really any OCI artifact.. that would be very interesting as a future looking capability. You and I should have a sync to talk about that. Gordon’s experimental work would benefit. But I think you and I should have a discussion of the long term strategic benefit of have COPR host namespaced OCI artifact registries along with the rpm repos .
I think Gordon is trying to figure out what the best mix of existing resources are because he doesn’t want to buirden anyone with having to do feature or development work to facilite something that is in the experimental phase. But II’m not Gordon, and I’m happy to burden you with the multitude of possible futures that I can envision if you are so inclined to carry the burden of knowing my thoughts.
I think a SIG is a fine way forward. “normal” fedora resources for a SIG should be fine and can be done anytime (matrix channel. mailing list, issue tracker, etc). More complicated resources (place for dist-git repos, place for containers, place to build things) may need to be elsewhere depending. I personally think the repos could be on forge provided they don’t have any content that fedora couldn’t ship, but I’d leave that to @humaton when he is back.
I agree that a lot of the discussion has been focused on ‘how would we change fedora to do this in the regular distribution flow’, but it sounds like thats not a discussion thats ready to happen, so both sides get frustrated by it. ;( I don’t think anyone is doubting that the proof of concept works, instead the focus here is what it would mean if we did it everywhere in fedora.
I would like to also make a plea to my fellow FESCo members to not purport to speak for the entire body. What FESCo might decide happens when there’s a vote. None of us FESCo members can say ‘fesco rejects that’. Of course you may know what other members have said or talked with them and your mental tally is “This wouldn’t pass”, but you still should quality your opinions as being yours and what fesco the body would do or not only speculation.
Forgejo has the feature set to cover this. It provides a package registry component per repository
In our staging/devel instance, we have a structure similar to the one we use in distgit. Meaning there is a Forgejo organization for rpms/containers/test/… We can create one for this initiative and fork packages from rpms/ into the new org. The repositories will be clearly isolated, but allow creation of PR’s into the distribution packages.
That’s very interesting. We should talk more about that. Speaking just for myself, I don’t think I had a full picture of what we are able to do with yet to be exposed forge capabilities in the context of the Forge policy.
Thank you you for showing up even though this topic has become a bit of a spiderweb. Instead of continuing the discussion here, what I would like to do is do a focused follow up with you and some other stakeholders concerning OCI artifacts. I think its clear that for whatever reason the discussion here has been difficult to follow for a number of people.
I am wary of just starting a new topic here in the forum however. I’m getting the sense that something is deeply broken in how we are engaging here in the forum and I don’t want to continue this pattern and just frustrate people further because either I, or collectively, we haven’t figured out how to talk effectively using this channel. So I want to try something else, I’m going to invite some stakeholders into a discussion about OCI artifacts and try to have a discussion that is more organized and report back a summary of that discussion here for the wider community to comment on.
I think you misunderstand the request (or perhaps I do?
Gordon would like to setup a SIG to explore this workflow more.
Toward that end, is it permissible to have a Making sure you're not a bot! (or whatever name) that
has a set of repos under it that look like dist-git repos, but have more
branches, etc. They would then use these to build packages and
containers out of those packages.
I do not think at this time we should have any of this in the main
dist-git repos, this is just a SIG exploring workflows that may someday
be proposed for further integration.
But we won’t have anything in the main repos. What I am proposing is that instead of having a SiG space on forge.fp.o, we can create a space per SiG on the new Forgejo-based version of src. That way, any SiG can just fork the package repo to the SiG org, do whatever they need to do with sources, and still rebase on top of Fedora package sources. No local remotes needed. Pr’s back to packages gated by the maintainer.
I think it’s a Bad Thing that we need to set up additional high-bandwidth conversations (side-channels, DMs, scheduled video calls) that require extra time from volunteer contributors, since we can’t have constructive conversations with each other on public forums and chat. Sometimes these high-bandwidth mediums are helpful, but it shouldn’t be because we can’t have productive discussion otherwise. I’m not saying that anybody is acting maliciously. Nobody is perfect. Communication in a large FOSS community is difficult. Everyone here cares about Fedora and has ideas about how to make it better, even when we disagree or don’t communicate well. Differences of opinion are a sign of a healthy community, but we need to be able to talk and listen to each other despite these differences.
I have unfortunately noticed the same pattern of communication breakdown that you are pointing out. Multiple public Council discussions recently — whether on Discourse or Matrix — have resulted in discussion participants and observers coming out with a bad taste in their mouths. In these discussions, multiple participants have stepped away from the conversation because they don’t feel that they can productively communicate with you, Jef. I hope that you see that as a sign that things are going wrong. When you engage in circular debates with community members, that doesn’t help a discussion move forward. In this topic, you have declared support for this proposal and then left 37 comments (~30% of total), excluding comments on the breakout thread. You have a very powerful voice, not just because of your voting rights on Council, but because of your standing as the Fedora Project Leader. When you are loudly in favor of proposals to which longstanding community members are opposed and keep repeating your position, it frustrates contributors and negatively impacts community culture. I think you need to step back and take more active steps to listen to opposing voices, instead of making them feel disregarded or compelled to accept something.
(if anybody wants to respond to the above, please consider using Reply as linked topic )
As for the overall topic, I don’t see this coming to primary dist-git and Koji any time soon for the aforementioned reasons. But I think treating this proposal as an experimental project and forming a SIG is an acceptable compromise, provided that we have available and appropriate resources in Fedora Infrastructure. So let’s focus on that piece. It sounds like Kevin is on the right track here. I think Gordon’s proposal is very much in line with the Forge Usage Policy that we recently finalized:
(provided this work is organized into a SIG, which I think it should be)
I think this is a very limited view of the problem. If people invest time in building something that is related to the distribution of content, that work will inevitably create dependencies and workflows around the existing sources. It will have duct tape all over it because those sources live in different places. Over time, workflows and workarounds will develop, making any future integration more complicated for whoever takes on the initiative later.
I don’t think that’s what this project is. It’s a system for the single-application-in-container usecase. Each application build has its own dependencies which are housed in separate “upstream release branches” that are detached and maintained separately from the branches that are used to build packages contained in the actual Fedora distribution (yum repos, images, installation media, etc.). I am not a fan of the detached and maintained separately part, but that’s what the project is, so I don’t think it would, from a technical perspective, benefit from being included in a dist-git namespace.
What if my app uses the latest upstream versions, while Fedora is still shipping older ones?
I can pin the latest versions, verify that they work with my app and the relevant system dependencies, and then open a PR against the distribution packages with evidence that the newer versions work correctly.
