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
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
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
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
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.
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
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
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]
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"
14. As a drive-by reader of Fedora docs, I want to click through to
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
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
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
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
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
21. As a dist-git repo admin, I cannot remove access to the repo from
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
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. :)
41. As a Fedora contributor, I can use a public API so that I can
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
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.
Fedora Project Leader