On Mon, Feb 10, 2020 at 02:39:13PM -0500, Ben Cotton wrote: > The community input period for CPE's git forge initiative is over. I have > collected and distilled the mailing list feedback into the list below. > Please comment by the *end of this week* so we can send Fedora's > requirements to the CPE team. Some annotations and comments... > 1. As a Fedora contributor, I want the git forge to be self-hosted so that > Fedora is not dependent on third parties I don't think this is a requirement. In fact, I think a hosted solution would be preferable if it can fill all of our needs. We, as Fedora Project, should be focusing our expertise on distro-building, and I'd rather free up the infrastructure team to work on other things. However, I think it's important that if we choose a hosted solution, we have a clear migration path _out_, and that includes not just the bare git repo but metadata and all the other features like issues and pull requests and comments. We've already migrated source RPM version control systems twice (from CVS to dist-git to dist-git-with-pagure), and project repos and issue tracking from Trak to Pagure. There's no reason to suppose any migration now is the last. > 2. As a Fedora contributor, I want the git forge to be free/open source > software so that Fedora lives up to its Freedom value. In contrast, I strongly urge the CPE decision-makers to take this into strong consideration. The Fedora Council policy we adapted last year notes that we're willing to make concessions in the name of practicality when there is not a viable alternative. _Especially_ given the strong community sentiment here, if the choice is GitHub, the story for why that's the only workable option needs to be very strong. That said, I do have a little hesitation on the stark lines being drawn in some of the comments on this topic. A huge amount of the free and open source software which goes *into* Fedora is developed on GitHub. It certainly has the largest network for drive-by contributions and easy onboarding. If we were to set up the project from scratch right now, I think we might very well just launch on GitHub without second thought. There was a big-tech-site review of Fedora a while ago when Workstation made it easier to install the Nvidia driver, which was generally positive in the details but had an overall negative tone and headline along the lines of: "I'm sad to see Fedora losing its purism" -- and then casually noted that of course, he uses a different distro that includes all of the things Fedora doesn't. I find this quite frustrating: yes, Fedora should set a positive example, but we want to be an actually popular example that people use, not a theoretical ideal that people cluck at from a distance as they recommend everything else to their friends and family. Sooooo.... let's keep an open mind? Fedora on GitHub wouldn't be the end of the world, or the end of Fedora, or the end of our Freedom foundation. > 3. As anybody, I want the git forge to have no JavaScript/cookie tracking > so that it is privacy-friendly. I think there's a larger thing here too: we need people to be able to contribute to Fedora under terms _we control_. This may be a blocker on any hosted solution, which will of necessity have its own terms of service. > 4. As a Fedora contributor, I want the git forge to integrate with FAS so > that it can use FAS to provide authentication and authorization. Yes, this is a must. We need contributions tied to Fedora accounts -- or else we need someone to go through the work of clearing something else with legal. > 5. As a Fedora contributor, I want the git forge to integrate with > fedora-messaging so that it can be a part of automatic workflows. Absolutely. This isn't just workflows but also metrics. Super-important. [skipping some that I agree with and have no strong comment on] > 12. > As anyone, I want the URI to the archive (tar.xz, tar.bz2, etc) > corresponding to various code states (commit/tag/release/fork…) to be > regular and stable (ideally, identical to the Pagure URIs to avoid > reimplementing existing automation) so that I can point to point-in-time > snapshots of the repository. This feature seems key for possibly moving to or adding a "source git" approach. [more skip] > 14. As a drive-by reader of Fedora docs, I want to click through to make a > suggested improvement without needing to set up a whole code-development > infrastructure so that I can make low-friction contributions. This is something that we haven't quite got with Pagure as it is. > 15. As a Fedora user, I want to easily create pull requests to any > dist-git repo so that I can make contributions to repos that I am not a > maintainer of. And this too is something that we were *planning* to get with Pagure but which (unless something has changed) we aren't actually at yet. (You need to be an approved packager already in order to do this.) > 16. As a package maintainer, I can only commit to a dist-git repo if I am in > the Fedora packager group so that non-packagers cannot directly affect > packages. This seems quite reasonable. Either way, as a project, we need a record of who exactly has (and had) access to what and who made which changes. > 17. As a package maintainer, I can only commit to a dist-git repo if I am a > maintainer of the branch so that EPEL maintainers and Fedora maintainers > can be separate. Or, going forward: so CentOS Stream and Fedora packages can cleanly share dist-git. This is a strong must. > 18. As a proven packager, I can commit to all dist-git repos that do not > have special restrictions set by FESCo or are retired so that I can make > bulk package updates or step in as directed by FESCo. Yes, we absolutely need this kind of access. > 19. As a FESCO member, I can configure exceptions to disallow proven > packager access to a dist-git repo so that I can protect key packages. This may be a legal requirement in some cases. > 20. As dist-git repo admin, I can easily add other maintainers to allow > commit or admin access for dist-git repo by using their FAS username so > that I can enable others to co-maintain a package. Yes, we really, really need this to be easily self-managed. Anything else doesn't scale. > 21. As a dist-git repo admin, I cannot remove access to the repo from Fedora > infra, Releng or proven packagers without FESCo approval so that Releng, > infra, and provenpackagers have the ability to perform their functions. In general, the project needs visibility and history of dist-git repos to persist. On the other hand, for project repos, people should be able to delete at will. [snip some additional reasonable repo management requriements] > 26. As anybody, I can easily see the FAS usernames of maintainers for all > branches of a dist-git repo so that I know who to contact. Ideally, this includes the concept of a main contact vs. co-maintainers. I have co-maintainer access to several packages that I probably shouldn't be asked detailed questions about. :) [skip ahead] > 41. As a Fedora contributor, I can use a public API so that I can develop > workflow tools for myself and my team. >From the QA list, a specific example: "For the planned blocker review async discussion, we need API to be able to add comments and edit the ticket description, ideally also adjust ticket tags, milestones or some other properties. We need a webhook support to get notified of changes or access to a message bus." [snip to the end] > 47. As a Fedora contributor, I can perform issue and pull request actions on > mobile devices via a native mobile app or a mobile-friendly webapp so that > I can contribute while away from my desk. This one I'd classify as nice-to-have. It certainly would be nice but I don't think it's a blocker. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-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/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx
