Council and community,
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.
1.
As a Fedora contributor, I want the git forge to be self-hosted so that Fedora is not dependent on third parties 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. 3.
As anybody, I want the git forge to have no JavaScript/cookie tracking so that it is privacy-friendly. 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. 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. 6.
As a Fedora contributor, I want it to be easy to add new contributors to a project (and optionally to enable self-adding) so that joining new teams is low-friction. 7.
As a Fedora community member, I want to self-organize my personal and team work by creating projects and groups of projects, by defining different access levels, and by having basic contribution allowed for everyone by default, so that I can contribute in full autonomy. 8.
[dist-git] As a Fedora contributor, I want the dist-git to integrate with other packaging services (anitya, koji, Bodhi, etc) so that it can be a part of automatic workflows. 9.
[code hosting] As a Fedora contributor, I want to encourage new contributors with easyfix-like functionality so that newcomers can find easy tasks to get started with. 10.
[code hosting] As anyone, I want good search of code, commits, and issues so that I can find particular parts of the code or project history. 11.
[code hosting] As a software maintainer, I want pull requests to allow me to rebase so that I can accept pull requests without waiting for the submitter to rebase. 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. 13.
As a Fedora contributor, I want the git repos to be fully accessible over https (read and write) so that I can contribute from environments where ssh is filtered for security reasons. 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. 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. 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. 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. 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. 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. 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. 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. 22.
As a package maintainer, I can easily orphan a dist-git repo or branch to show that it is not maintained anymore so that other maintainers can adopt it. 23.
As a package maintainer, I can adopt any orphaned dist-git repo or branch so that it has an active maintainer. 24.
As a package maintainer, I can easily unretire a retired dist-git repo or branch so that it has an active maintainer. 25.
As a release engineer, I can easily approve unretire requests for a dist-git repo or branch so that it has an active maintainer. 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. 27.
As a non-releng member, I cannot remove any commits from any dist-git repo that were used to build a Fedora package so that the release history remains intact. 28.
As an external user, I can easily get a list of all orphaned or retired dist-git repos and branches so that I know what packages need maintainers. 29.
As anybody, I can watch for issues or pull requests that are created for a dist-git repository so that I can stay up-to-date on repositories I care about. 30.
As anybody, I can easily get a list of all dist-git repos that I am watching so that I can be sure it matches my current needs. 31.
As anybody, I can easily get a list of all dist-git repos that a specific Fedora account has admin/commit access to so that I can see what packages the account is associated with. 32.
As anybody, when looking at the dist-git repo it is clearly visible which branches are still maintained so that I know what release versions are supported. 33.
As anybody, when I look for a specific branch, EOL branches do not clutter my view so that I can more easily see the active branches. 34.
As a package maintainer, I can easily request commit/admin access for a specific branch or dist-git repo so that I can help contribute in a low-friction manner. 35.
As Fedora infra, I can easily audit that no git repo was accessed without authorization so that I can maintain the security of the Fedora infrastructure. 36.
As Fedora infra/security response team, I have access to secure logs to analyse the impact of unauthorized access to all dist-git repos so that I can maintain the security of the Fedora infrastructure. 37.
As anybody, the dist-git web page of a repo points me to Bugzilla to report issues for a repository so that I can file bugs for released packages. 38.
As an ISV developer who contributes to Fedora, I can fork a dist-git repo via mirroring, make changes, and submit them back to Fedora as applicable so that I can contribute to Fedora. 39.
As a distro developer, I can fork dist-git repos via mirroring, make changes, and submit them back to Fedora from my Git server so that I can contribute to Fedora. 40.
As a Fedora contributor, I can use a public API so that I can develop workflow tools for myself and my team. 41.
As a repository admin, I can define custom labels for a repo so that it can support my team’s particular workflow. 42.
As a repository admin, I can define arbitrary custom fields for a repo so that it can support my team’s particular workflow. 43.
As a Fedora contributor, I can file bugs and feature requests in an issue tracker so that I can provide feedback or track desired work. 44.
As a Fedora team member, I can vote +1/abstain/-1 on issues so that I can approve or deny proposals. 45.
As a Fedora contributor, I want issues to support inline images in order to simplify the workflow for visual tasks (e.g. design work) 46.
As a Fedora contributor, I want a Kanban board so that I can visually track the status of work and do project planning. 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.
Thank you very much to everyone who contributed and gave their thoughts and opinions on how best to move this forward. I appreciate the time, passion and energy you put into making this happen.
Leigh
On Mon, Feb 10, 2020 at 7:40 PM Ben Cotton bcotton@redhat.com wrote:
Council and community,
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.
As a Fedora contributor, I want the git forge to be self-hosted so that Fedora is not dependent on third parties 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. 3.
As anybody, I want the git forge to have no JavaScript/cookie tracking so that it is privacy-friendly. 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. 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. 6.
As a Fedora contributor, I want it to be easy to add new contributors to a project (and optionally to enable self-adding) so that joining new teams is low-friction. 7.
As a Fedora community member, I want to self-organize my personal and team work by creating projects and groups of projects, by defining different access levels, and by having basic contribution allowed for everyone by default, so that I can contribute in full autonomy. 8.
[dist-git] As a Fedora contributor, I want the dist-git to integrate with other packaging services (anitya, koji, Bodhi, etc) so that it can be a part of automatic workflows. 9.
[code hosting] As a Fedora contributor, I want to encourage new contributors with easyfix-like functionality so that newcomers can find easy tasks to get started with. 10.
[code hosting] As anyone, I want good search of code, commits, and issues so that I can find particular parts of the code or project history. 11.
[code hosting] As a software maintainer, I want pull requests to allow me to rebase so that I can accept pull requests without waiting for the submitter to rebase. 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. 13.
As a Fedora contributor, I want the git repos to be fully accessible over https (read and write) so that I can contribute from environments where ssh is filtered for security reasons. 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. 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. 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. 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. 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. 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. 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. 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. 22.
As a package maintainer, I can easily orphan a dist-git repo or branch to show that it is not maintained anymore so that other maintainers can adopt it. 23.
As a package maintainer, I can adopt any orphaned dist-git repo or branch so that it has an active maintainer. 24.
As a package maintainer, I can easily unretire a retired dist-git repo or branch so that it has an active maintainer. 25.
As a release engineer, I can easily approve unretire requests for a dist-git repo or branch so that it has an active maintainer. 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. 27.
As a non-releng member, I cannot remove any commits from any dist-git repo that were used to build a Fedora package so that the release history remains intact. 28.
As an external user, I can easily get a list of all orphaned or retired dist-git repos and branches so that I know what packages need maintainers. 29.
As anybody, I can watch for issues or pull requests that are created for a dist-git repository so that I can stay up-to-date on repositories I care about. 30.
As anybody, I can easily get a list of all dist-git repos that I am watching so that I can be sure it matches my current needs. 31.
As anybody, I can easily get a list of all dist-git repos that a specific Fedora account has admin/commit access to so that I can see what packages the account is associated with. 32.
As anybody, when looking at the dist-git repo it is clearly visible which branches are still maintained so that I know what release versions are supported. 33.
As anybody, when I look for a specific branch, EOL branches do not clutter my view so that I can more easily see the active branches. 34.
As a package maintainer, I can easily request commit/admin access for a specific branch or dist-git repo so that I can help contribute in a low-friction manner. 35.
As Fedora infra, I can easily audit that no git repo was accessed without authorization so that I can maintain the security of the Fedora infrastructure. 36.
As Fedora infra/security response team, I have access to secure logs to analyse the impact of unauthorized access to all dist-git repos so that I can maintain the security of the Fedora infrastructure. 37.
As anybody, the dist-git web page of a repo points me to Bugzilla to report issues for a repository so that I can file bugs for released packages. 38.
As an ISV developer who contributes to Fedora, I can fork a dist-git repo via mirroring, make changes, and submit them back to Fedora as applicable so that I can contribute to Fedora. 39.
As a distro developer, I can fork dist-git repos via mirroring, make changes, and submit them back to Fedora from my Git server so that I can contribute to Fedora. 40.
As a Fedora contributor, I can use a public API so that I can develop workflow tools for myself and my team. 41.
As a repository admin, I can define custom labels for a repo so that it can support my team’s particular workflow. 42.
As a repository admin, I can define arbitrary custom fields for a repo so that it can support my team’s particular workflow. 43.
As a Fedora contributor, I can file bugs and feature requests in an issue tracker so that I can provide feedback or track desired work. 44.
As a Fedora team member, I can vote +1/abstain/-1 on issues so that I can approve or deny proposals. 45.
As a Fedora contributor, I want issues to support inline images in order to simplify the workflow for visual tasks (e.g. design work) 46.
As a Fedora contributor, I want a Kanban board so that I can visually track the status of work and do project planning. 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.
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ council-discuss mailing list -- council-discuss@lists.fedoraproject.org To unsubscribe send an email to council-discuss-leave@lists.fedoraproject.org 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@lists.fedorapr...
I added one more:
48. As a Fedora contributor, I can reassign issues/bugs to another component so that I can cooperate with other contributors when an issue is mis-assigned.
What is an ISV? Can we rewrite the requirement with full label?
How do we identify mandatory versus nice to have? Can we use nuancier to have collective evaluation?
Related to last question, can we disagree with some assumptions?
On Tue, Feb 11, 2020 at 07:31:38PM +0100, Jean-Baptiste wrote:
What is an ISV? Can we rewrite the requirement with full label?
"Independent Software Vendor".
How do we identify mandatory versus nice to have? Can we use nuancier to have collective evaluation?
I don't know about whether we can or should use nuancier -- that's an interesting idea. Leigh, what is the most helpful thing we can do here?
Related to last question, can we disagree with some assumptions?
Of course!
On Wed, Feb 12, 2020 at 09:05:37AM -0500, Matthew Miller wrote:
On Tue, Feb 11, 2020 at 07:31:38PM +0100, Jean-Baptiste wrote:
What is an ISV? Can we rewrite the requirement with full label?
"Independent Software Vendor".
How do we identify mandatory versus nice to have? Can we use nuancier to have collective evaluation?
I don't know about whether we can or should use nuancier -- that's an interesting idea. Leigh, what is the most helpful thing we can do here?
Nuancier only works with pictures so it wouldn't do, elections would work, but I'm not quite sure what is the goal there.
Pierre
Le 2020-02-12 15:05, Matthew Miller a écrit :
On Tue, Feb 11, 2020 at 07:31:38PM +0100, Jean-Baptiste wrote:
What is an ISV? Can we rewrite the requirement with full label?
"Independent Software Vendor".
Oh, thanks, then could we simplify?
"As an ISV developer who contributes to Fedora, I can fork a dist-git repo via mirroring, make changes, and submit them back to Fedora as applicable so that I can contribute to Fedora." would become: "As a Fedora contributor, I can fork a dist-git repo via mirroring, make changes, and submit them back to the maintainer as applicable so that I can contribute to packages."
If you are an ISV contributing to Fedora, then you are a Fedora contributor. I understand the requirement here basically says: I can easily contribute dist-git content without being a maintainer.
Which is today a blocker for me to contribute packages. Package example: langpacks, I want to allow appstream content translation but can't.
Other option: you want to say should allow people to contribute without a FAS account, which is more a legal issue (FPCA) than a technical one.
Jean-Baptiste
On Wed, Feb 12, 2020 at 9:27 AM Jean-Baptiste Holcroft jean-baptiste@holcroft.fr wrote:
"As an ISV developer who contributes to Fedora, I can fork a dist-git repo via mirroring, make changes, and submit them back to Fedora as applicable so that I can contribute to Fedora." would become: "As a Fedora contributor, I can fork a dist-git repo via mirroring, make changes, and submit them back to the maintainer as applicable so that I can contribute to packages."
If you are an ISV contributing to Fedora, then you are a Fedora contributor.
Makes sense to me. I kept them separate because Neal made a point of listing them separately in his post on devel. Neal, is there a nuance that I'm missing between these cases?
On Wed, Feb 12, 2020 at 9:32 AM Ben Cotton bcotton@redhat.com wrote:
On Wed, Feb 12, 2020 at 9:27 AM Jean-Baptiste Holcroft jean-baptiste@holcroft.fr wrote:
"As an ISV developer who contributes to Fedora, I can fork a dist-git repo via mirroring, make changes, and submit them back to Fedora as applicable so that I can contribute to Fedora." would become: "As a Fedora contributor, I can fork a dist-git repo via mirroring, make changes, and submit them back to the maintainer as applicable so that I can contribute to packages."
If you are an ISV contributing to Fedora, then you are a Fedora contributor.
Makes sense to me. I kept them separate because Neal made a point of listing them separately in his post on devel. Neal, is there a nuance that I'm missing between these cases?
The nuance is usually that ISVs often are forking packages and maintaining their own fixes without being a regular contributor to Fedora. Sometimes that includes just maintaining personal branches in forks in pagure, other times it's on a separate server. I mentioned the *via mirroring* to distinguish from the normal fork+submit+forget case, because there's a slightly unusual concern in that persistent trees might be maintained. I wanted to highlight that we have a path and workflow for handling integration of those fixes, and we should keep having that.
This is often the case for me as an ISV person (rather than Fedora contributor person). And I'm aware of several others that operate this way.
On Wed, Feb 12, 2020 at 9:37 AM Neal Gompa ngompa13@gmail.com wrote:
The nuance is usually that ISVs often are forking packages and maintaining their own fixes without being a regular contributor to Fedora.
Okay. So are:
- As an ISV developer who contributes to Fedora, I can fork a dist-git repo via mirroring, make changes, and submit them back to Fedora as applicable so that I can contribute to Fedora.
- As a distro developer, I can fork dist-git repos via mirroring, make changes, and submit them back to Fedora from my Git server so that I can contribute to Fedora.
distinct from a requirements perspective? It seems like 38 could either be a part of 39 or of a general contributor workflow, depending on how the ISV developer is working. It's not clear that 38 provides any additional information other than another persona.
On Wed, Feb 12, 2020 at 9:42 AM Ben Cotton bcotton@redhat.com wrote:
On Wed, Feb 12, 2020 at 9:37 AM Neal Gompa ngompa13@gmail.com wrote:
The nuance is usually that ISVs often are forking packages and maintaining their own fixes without being a regular contributor to Fedora.
Okay. So are:
- As an ISV developer who contributes to Fedora, I can fork a dist-git repo via mirroring, make changes, and submit them back to Fedora as applicable so that I can contribute to Fedora.
- As a distro developer, I can fork dist-git repos via mirroring, make changes, and submit them back to Fedora from my Git server so that I can contribute to Fedora.
distinct from a requirements perspective? It seems like 38 could either be a part of 39 or of a general contributor workflow, depending on how the ISV developer is working. It's not clear that 38 provides any additional information other than another persona.
They could probably be folded into one requirement, rewording the first clause to be "As an independent software or distro developer,".
On Wed, Feb 12, 2020 at 2:06 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Feb 11, 2020 at 07:31:38PM +0100, Jean-Baptiste wrote:
What is an ISV? Can we rewrite the requirement with full label?
"Independent Software Vendor".
How do we identify mandatory versus nice to have? Can we use nuancier to have collective evaluation?
I don't know about whether we can or should use nuancier -- that's an interesting idea. Leigh, what is the most helpful thing we can do here?
It's a large requirement set and even your own comments identify things that are nice to have. While I could infer that (e.g. the mobile access one), I don't want to be the person to make that assumption. It would be helpful to use a system that gives clear indicators. MoSCoW https://www.productplan.com/glossary/moscow-prioritization/ or some other style system could be beneficial here but I will leave that choice to you. Like anything we will strive to hit the majority of the real needs and knowing what are stretch goals is helpful
Related to last question, can we disagree with some assumptions?
Of course!
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ council-discuss mailing list -- council-discuss@lists.fedoraproject.org To unsubscribe send an email to council-discuss-leave@lists.fedoraproject.org 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@lists.fedorapr...
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...
- 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.
- 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.
- 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.
- 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.
- 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" approach.
[more skip]
- 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.
- 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.)
- 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.
- 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.
- 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.
- 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.
- 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.
- 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]
- 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]
- 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]
- 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.
On Wed, Feb 12, 2020 at 9:04 AM Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Feb 10, 2020 at 02:39:13PM -0500, Ben Cotton wrote:
- 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.)
It is not *well-documented*, but this already works. Once you have a FAS account, you can create forks and clone them with HTTPS using the really-awkward OpenID Connect auth method[1]. You can then commit to forks and make pull requests. Only SSH-based clones won't work without packager group ACL.
[1]: https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits
On Wed, Feb 12, 2020 at 09:03:44AM -0500, Matthew Miller wrote:
On Mon, Feb 10, 2020 at 02:39:13PM -0500, Ben Cotton wrote:
- 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.
Just a small correction here, there was no migration when we put pagure on the top of dist-git. Repos didn't move nor the tooling that packagers are using.
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.
The source git idea, as I understand it, is about using the exploded git repo and generate a tarball locally, so not relying on the forge hosting the repo.
- 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.)
That is something we could get from pagure if we had made a migration from how dist-git has been originally set-up with an account per packager instead of the one account for all that all forges use these days (including pagure.io). But we didn't want to impact the packagers' work and thus never migrated away from this old setup and puts us in a corner for this.
Pierre
On Wed, Feb 12, 2020 at 03:22:03PM +0100, Pierre-Yves Chibon wrote:
We've already migrated source RPM version control systems twice (from
Just a small correction here, there was no migration when we put pagure on the top of dist-git. Repos didn't move nor the tooling that packagers are using.
Okay, fair -- but if we lump that together with the pkgdb deprecation, tooling _did_ change.
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.
The source git idea, as I understand it, is about using the exploded git repo and generate a tarball locally, so not relying on the forge hosting the repo.
We need to have some way to guarantee that a given reference to source control in which the "exploded" repo lives is always the same thing and can't be changed underneath us.
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.)
That is something we could get from pagure if we had made a migration from how dist-git has been originally set-up with an account per packager instead of the one account for all that all forges use these days (including pagure.io). But we didn't want to impact the packagers' work and thus never migrated away from this old setup and puts us in a corner for this.
Yes, I'm not blaming :)
On Wed, Feb 12, 2020 at 02:05:11PM -0500, Matthew Miller wrote:
On Wed, Feb 12, 2020 at 03:22:03PM +0100, Pierre-Yves Chibon wrote:
We've already migrated source RPM version control systems twice (from
Just a small correction here, there was no migration when we put pagure on the top of dist-git. Repos didn't move nor the tooling that packagers are using.
Okay, fair -- but if we lump that together with the pkgdb deprecation, tooling _did_ change.
Fair :)
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.
The source git idea, as I understand it, is about using the exploded git repo and generate a tarball locally, so not relying on the forge hosting the repo.
We need to have some way to guarantee that a given reference to source control in which the "exploded" repo lives is always the same thing and can't be changed underneath us.
My understanding was that we could simply store these exploded repo in dist-git where history cannot be changed, thus guaranteeing this consistency.
Pierre
On Thu, Feb 13, 2020 at 09:18:49AM +0100, Pierre-Yves Chibon wrote:
We need to have some way to guarantee that a given reference to source control in which the "exploded" repo lives is always the same thing and can't be changed underneath us.
My understanding was that we could simply store these exploded repo in dist-git where history cannot be changed, thus guaranteeing this consistency.
Not if our dist-git doesn't have that property anymore....
On Wed, Feb 12, 2020 at 09:03:44 -0500, Matthew Miller mattdm@fedoraproject.org wrote:
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.
That's not strong enough. That wording seems to assume we get warning that a migration is necessary and have time to execute it before we can't any more. Really you'd want to have regular backups of all that, someplace controlled by the project so that in the case of a no warning shutdown, recovery is possible without losing much data.
On Wed, Feb 12, 2020 at 11:32:22AM -0600, Bruno Wolff III wrote:
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.
That's not strong enough. That wording seems to assume we get warning that a migration is necessary and have time to execute it before we can't any more. Really you'd want to have regular backups of all that, someplace controlled by the project so that in the case of a no warning shutdown, recovery is possible without losing much data.
Yes, good point; there's absolutely the risk of a hosted solution abruptly going offline. And as in the old sysadmin saying, it's not really a backup until you've proven you can restore.
Le 10/02/2020 à 20:39, Ben Cotton a écrit :
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.
While this isn't mandatory to me, something really convenient is to be able to answer an email notification by just responding to the email.
I use it a lot with pagure & github. It weirdly doesn't work with gitlab.
Another feature I feel like really useful is the bidirectional internal links between items.
On github: if I quote an issue inside a comment. I see a link to the issue in the comment.
Then I go to the issue itself and see the comment linked to it.
council-discuss@lists.fedoraproject.org
-
Ben Cotton -
Bruno Wolff III -
Jean-Baptiste -
Jean-Baptiste Holcroft
-
Leigh Griffin -
Matthew Miller -
Neal Gompa -
Pierre-Yves Chibon