On Mon, Nov 29, 2021 at 12:06:13PM -0600, Michael Catanzaro wrote: > Hi, I have a question for the FESCo and Council candidates: do you support > allowing Fedora src-git repositories to be hosted on gitlab.com, which a > proprietary software git forge? > > Fedora Council has already effectively stated that dist-git infrastructure > must remain open source, but has no such promises for src-git. I understand > Council has previously stated that Fedora infrastructure should depend on > proprietary software only if no open source alternative is suitable. Do you > believe that there exist no open source git forges that would be suitable > for Fedora src-git? > > The most obvious open source alternative would be the open source version of > GitLab. There is also Pagure. I think we're giving up on open source > infrastructure rather quickly here. I'd like to know what the candidates > think before voting. Hi Michael, this is an excellent question, but complicated. Normally I'd answer inline in response to the other posts in the thread, but since I'm answering as a candidate for FESCo, I'll try to do it here. I agree with what Matthew is saying about the oss/non-oss choices: we need to be pragmatic. I have both a ideological preference for open source, and also I think it'd pragmatically be very useful to be able to tweak and modify the tools we are using. But this preference needs to be weighed against other considerations. If it turns out that we don't have enough resources to keep pagure functioning, or that missing features in pagure are keeping us back from implementing new workflows, we will need to evaluate our options, with "being oss" as one the facets, but not the only one. A lesson from the previous transitions, e.g. to pkgdb2 [1], is that it's easy to provide a solution that provides 80% of the features that are used in Fedora packaging workflows, but the tail is very hard to implement because it requires functionality that is unique to a distribution (thousands of contributors, groups, special permissions, etc.) And then there are various small integrations, like hyperlinks to koji, that seem small, but are important for the "quality of life" of packagers. This is also why it's so crucial to discuss such transitions in public: nobody can remember all the bits of functionality and custom workflows. Thus, if we were to consider switching something else, it is important to enumerate features. Some subset that is required for Fedora workflows like proven packagers, mass rebuilds, shared package ownership, and ownership self-service, is simply a requirement for any solution. FWIW, I think that pagure is "short" on various features like rich diffs and previews and it is hard to do reviews of big patches in pagure, but those features aren't that often used in maintenance of package repos, and can be sacrificed for the core "workflow" features. A solution like gitlab may be better for general repo workflows, but still worse for packaging workflows. And now onto your actual question about source-git: src-git has different meanings in different contexts — I think it is important to distinguish the general technology, and the use of that technology as official in Fedora. People are experimenting with the technology, and (as mentioned even in this thread), some forms of src-git are already being used, with the src-git repo either located in the upstream or separate in some other location. I think experimentation here is important, we haven't yet nailed how this should all look. At that stage, those repos can be anywhere. But when we get to the second meaning — use of src-git for the management of sources of packages in Fedora, we would have to maintain the same access rules as for dist-git. Currently, dist-git "is the canonical location for Fedora spec files. Maintainers MUST expect that other maintainers and automated tooling will make changes to their packages" [2]. If we start allowing src-git as an alternative mechanism, those repositories would have to be under Fedora rel-eng control, and the usual access rules would have to apply (pps, rel-eng, sigs, shared ownership, ownership self-service). This is pretty much the opposite of what Matthew said ;). Maintainers and other accounts with appropriate privileges must be able to manage the src-git repo if this is the canonical location [3]. And this all must be implemented in a way that works reliably, i.e. any situation where the two repos become unsynchronized and we stop being sure what the canonical version is would be a significant bug. The layout of src-git repos (branch naming and steps to build) would also have to be standarized so that e.g. mass changes to spec files can be effectively pushed, just like with dist-git today. And with this, we return to the original question: the functional requirements that I described above set a very high bar. On the one hand, we want various smaller bits of functionality that would be much easier to implement with an open-source solution. On the other hand, we require fairly complex group ownership rules and specials acls, that are only available in the highest-paid tiers of gitlab. We prefer open source, but don't have the human power to maintain complicated infrastructure, or at least we want to minimize that. I don't know which solutions satisfy the requirements, and which solutions are the most cost-effective, but whatever is proposed, I think we should evaluate the choices pragmatically. If if turns out that e.g. a hosted gitlab instance checks all the boxes and allows us to concentrate on other tasks, and CPE wants to switch to that because it is more sustainable than keeping pagure up, I'd accept that. Zbyszek [1] https://pagure.io/fesco/issue/2115 [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity [3] I don't know how the details should look, but I believe that if we have both src-git and dist-git, dist-git would have to be automatically derived from src-git, e.g. by some push-time hook to update the other repo. I also don't much believe in this functioning through some bot in a third location that asynchronously does synchronization. A push-time hook that either updates everything that needs to be updated or atomically rejects the push would be imo much more reasonable. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
