Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin lgriffin@redhat.com wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
Alright, I have some questions that are not answered by the blog post.
- What is going to happen to the two pagure instances at pagure.io, and src.fedoraproject.org?
I think pagure.io is a good home for fedora-related projects (it was the successor to fedorahosted.org, after all, IIRC). I know that many group efforts are hosting their source code, ticketing system, etc. there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to shut down pagure.io, I assume those projects will have to be moved somewhere?
Also, it's very nice to have a PR-based workflow for some shared-maintenance packages on src.fedoraproject.org, and I don't think losing that feature would be a good thing for fedora.
- How is GitHub considered to be an alternative here?
I don't think (public or hosted) GitHub can do what is currently done on src.fedoraproject.org, can it? I'd also not want to see fedora use a closed-source product for such a core service ...
- Which features are missing from pagure, compared to the other forges?
For my purposes, I don't miss any feature on pagure.io compared to my repositories on github.com, and OTTOMH, I can't come up with any missing features, at all ...
TL;DR: Can we please keep pagure? It already has the fedora-specific features we need, and I don't mind a "slow" pace of development. In my experience, it works really well, and I actually *like* to use it (which is not true for GitLab ... which is slow and horrible)
Fabio
--
Leigh Griffin
Engineering Manager
Red Hat Waterford
Communications House
Cork Road, Waterford City
lgriffin@redhat.com M: +353877545162 IM: lgriffin
@redhatjobs redhatjobs @redhatjobs _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Jan 21, 2020, 17:17 Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin lgriffin@redhat.com wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a
recent blog post which you may be impacted by:
https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent
manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
Alright, I have some questions that are not answered by the blog post.
- What is going to happen to the two pagure instances at pagure.io,
and src.fedoraproject.org?
I think pagure.io is a good home for fedora-related projects (it was the successor to fedorahosted.org, after all, IIRC). I know that many group efforts are hosting their source code, ticketing system, etc. there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to shut down pagure.io, I assume those projects will have to be moved somewhere?
That scenario assumes a certain result and decision from the requirements analysis so I genuinely have no answer here. Whatever choice we make, an impact analysis would be needed in some shape or form. That (and our next steps) will be done collaboratively in the open.
Also, it's very nice to have a PR-based workflow for some shared-maintenance packages on src.fedoraproject.org, and I don't think losing that feature would be a good thing for fedora.
- How is GitHub considered to be an alternative here?
I don't think (public or hosted) GitHub can do what is currently done on src.fedoraproject.org, can it? I'd also not want to see fedora use a closed-source product for such a core service ...
- Which features are missing from pagure, compared to the other forges?
For my purposes, I don't miss any feature on pagure.io compared to my repositories on github.com, and OTTOMH, I can't come up with any missing features, at all ...
TL;DR: Can we please keep pagure? It already has the fedora-specific features we need, and I don't mind a "slow" pace of development. In my experience, it works really well, and I actually *like* to use it (which is not true for GitLab ... which is slow and horrible)
Fabio
--
Leigh Griffin
Engineering Manager
Red Hat Waterford
Communications House
Cork Road, Waterford City
lgriffin@redhat.com M: +353877545162 IM: lgriffin
@redhatjobs redhatjobs @redhatjobs _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin lgriffin@redhat.com wrote:
On Tue, Jan 21, 2020, 17:17 Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin lgriffin@redhat.com wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
Alright, I have some questions that are not answered by the blog post.
- What is going to happen to the two pagure instances at pagure.io,
and src.fedoraproject.org?
I think pagure.io is a good home for fedora-related projects (it was the successor to fedorahosted.org, after all, IIRC). I know that many group efforts are hosting their source code, ticketing system, etc. there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to shut down pagure.io, I assume those projects will have to be moved somewhere?
(snip)
That scenario assumes a certain result and decision from the requirements analysis so I genuinely have no answer here. Whatever choice we make, an impact analysis would be needed in some shape or form. That (and our next steps) will be done collaboratively in the open.
I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe this is a language barrier issue ... but I'd hope that an impact analysis of the different possibilities would be done *before* making a decision, not after?
I mean, whatever the "Git Forge Requirements" will be, we'd need to know how any change will affect the projects and groups that are currently using pagure ...
Fabio
Also, it's very nice to have a PR-based workflow for some shared-maintenance packages on src.fedoraproject.org, and I don't think losing that feature would be a good thing for fedora.
- How is GitHub considered to be an alternative here?
I don't think (public or hosted) GitHub can do what is currently done on src.fedoraproject.org, can it? I'd also not want to see fedora use a closed-source product for such a core service ...
- Which features are missing from pagure, compared to the other forges?
For my purposes, I don't miss any feature on pagure.io compared to my repositories on github.com, and OTTOMH, I can't come up with any missing features, at all ...
TL;DR: Can we please keep pagure? It already has the fedora-specific features we need, and I don't mind a "slow" pace of development. In my experience, it works really well, and I actually *like* to use it (which is not true for GitLab ... which is slow and horrible)
Fabio
--
Leigh Griffin
Engineering Manager
Red Hat Waterford
Communications House
Cork Road, Waterford City
lgriffin@redhat.com M: +353877545162 IM: lgriffin
@redhatjobs redhatjobs @redhatjobs _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Jan 21, 2020, 20:02 Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin lgriffin@redhat.com wrote:
On Tue, Jan 21, 2020, 17:17 Fabio Valentini decathorpe@gmail.com
wrote:
On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin lgriffin@redhat.com
wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to
a recent blog post which you may be impacted by:
https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent
manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
Alright, I have some questions that are not answered by the blog post.
- What is going to happen to the two pagure instances at pagure.io,
and src.fedoraproject.org?
I think pagure.io is a good home for fedora-related projects (it was the successor to fedorahosted.org, after all, IIRC). I know that many group efforts are hosting their source code, ticketing system, etc. there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to shut down pagure.io, I assume those projects will have to be moved somewhere?
(snip)
That scenario assumes a certain result and decision from the
requirements analysis so I genuinely have no answer here. Whatever choice we make, an impact analysis would be needed in some shape or form. That (and our next steps) will be done collaboratively in the open.
I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe this is a language barrier issue ... but I'd hope that an impact analysis of the different possibilities would be done *before* making a decision, not after?
I mean, whatever the "Git Forge Requirements" will be, we'd need to know how any change will affect the projects and groups that are currently using pagure ...
Sorry I should have been more detailed on the steps, that's on me. So we have a few steps in this process, first and foremost is this ODF document to figure out what are the real requirements/ use cases / features of a git forge. We gather and analyze that, combining the multiple stakeholder views and have our requirements to base an analysis on. We then evaluate what solution(s) meets the requirements and bring those solutions forward. We then perform impact analysis on what each path might look like from multiple perspectives which will include obvious costs from a time, money, resources perspective of using a git forge. A decision can be made then in an informed way as we know what we want to have, why we want it and what the cost may be. We haven't fully defined the criteria for that analysis yet as the requirements will no doubt throw up use cases and scenarios that we have to factor in. So this is very much a call to arms to help inform us of how you use a git forge and what your requirements are for one.
Hope that clears it up and sorry for the lack of clarity.
Fabio
Also, it's very nice to have a PR-based workflow for some shared-maintenance packages on src.fedoraproject.org, and I don't think losing that feature would be a good thing for fedora.
- How is GitHub considered to be an alternative here?
I don't think (public or hosted) GitHub can do what is currently done on src.fedoraproject.org, can it? I'd also not want to see fedora use a closed-source product for such a core service ...
- Which features are missing from pagure, compared to the other forges?
For my purposes, I don't miss any feature on pagure.io compared to my repositories on github.com, and OTTOMH, I can't come up with any missing features, at all ...
TL;DR: Can we please keep pagure? It already has the fedora-specific features we need, and I don't mind a "slow" pace of development. In my experience, it works really well, and I actually *like* to use it (which is not true for GitLab ... which is slow and horrible)
Fabio
--
Leigh Griffin
Engineering Manager
Red Hat Waterford
Communications House
Cork Road, Waterford City
lgriffin@redhat.com M: +353877545162 IM: lgriffin
@redhatjobs redhatjobs @redhatjobs _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Jan 21, 2020 at 10:02 PM Leigh Griffin lgriffin@redhat.com wrote:
On Tue, Jan 21, 2020, 20:02 Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin lgriffin@redhat.com wrote:
On Tue, Jan 21, 2020, 17:17 Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin lgriffin@redhat.com wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
Alright, I have some questions that are not answered by the blog post.
- What is going to happen to the two pagure instances at pagure.io,
and src.fedoraproject.org?
I think pagure.io is a good home for fedora-related projects (it was the successor to fedorahosted.org, after all, IIRC). I know that many group efforts are hosting their source code, ticketing system, etc. there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to shut down pagure.io, I assume those projects will have to be moved somewhere?
(snip)
That scenario assumes a certain result and decision from the requirements analysis so I genuinely have no answer here. Whatever choice we make, an impact analysis would be needed in some shape or form. That (and our next steps) will be done collaboratively in the open.
I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe this is a language barrier issue ... but I'd hope that an impact analysis of the different possibilities would be done *before* making a decision, not after?
I mean, whatever the "Git Forge Requirements" will be, we'd need to know how any change will affect the projects and groups that are currently using pagure ...
(...)
Sorry I should have been more detailed on the steps, that's on me. So we have a few steps in this process, first and foremost is this ODF document to figure out what are the real requirements/ use cases / features of a git forge. We gather and analyze that, combining the multiple stakeholder views and have our requirements to base an analysis on. We then evaluate what solution(s) meets the requirements and bring those solutions forward. We then perform impact analysis on what each path might look like from multiple perspectives which will include obvious costs from a time, money, resources perspective of using a git forge. A decision can be made then in an informed way as we know what we want to have, why we want it and what the cost may be. We haven't fully defined the criteria for that analysis yet as the requirements will no doubt throw up use cases and scenarios that we have to factor in. So this is very much a call to arms to help inform us of how you use a git forge and what your requirements are for one.
Hope that clears it up and sorry for the lack of clarity.
Yes! Absolutely, thank you. Is there a place where we can suggest such formal "requirements"? I don't think either mailing list posts nor comments on the community blog post are a good medium for that.
Fabio
Fabio
Also, it's very nice to have a PR-based workflow for some shared-maintenance packages on src.fedoraproject.org, and I don't think losing that feature would be a good thing for fedora.
- How is GitHub considered to be an alternative here?
I don't think (public or hosted) GitHub can do what is currently done on src.fedoraproject.org, can it? I'd also not want to see fedora use a closed-source product for such a core service ...
- Which features are missing from pagure, compared to the other forges?
For my purposes, I don't miss any feature on pagure.io compared to my repositories on github.com, and OTTOMH, I can't come up with any missing features, at all ...
TL;DR: Can we please keep pagure? It already has the fedora-specific features we need, and I don't mind a "slow" pace of development. In my experience, it works really well, and I actually *like* to use it (which is not true for GitLab ... which is slow and horrible)
Fabio
--
Leigh Griffin
Engineering Manager
Red Hat Waterford
Communications House
Cork Road, Waterford City
lgriffin@redhat.com M: +353877545162 IM: lgriffin
@redhatjobs redhatjobs @redhatjobs _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Jan 21, 2020 at 3:01 PM Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin lgriffin@redhat.com wrote:
On Tue, Jan 21, 2020, 17:17 Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin lgriffin@redhat.com wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
Alright, I have some questions that are not answered by the blog post.
- What is going to happen to the two pagure instances at pagure.io,
and src.fedoraproject.org?
I think pagure.io is a good home for fedora-related projects (it was the successor to fedorahosted.org, after all, IIRC). I know that many group efforts are hosting their source code, ticketing system, etc. there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to shut down pagure.io, I assume those projects will have to be moved somewhere?
(snip)
That scenario assumes a certain result and decision from the requirements analysis so I genuinely have no answer here. Whatever choice we make, an impact analysis would be needed in some shape or form. That (and our next steps) will be done collaboratively in the open.
I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe this is a language barrier issue ... but I'd hope that an impact analysis of the different possibilities would be done *before* making a decision, not after?
I mean, whatever the "Git Forge Requirements" will be, we'd need to know how any change will affect the projects and groups that are currently using pagure ...
I think this is the CPE team's way of telling us that they want to yank pingou from Pagure as part of $PINGOU_DAYJOB work. Otherwise, this is grotesquely premature, given that the Pagure community is slowly growing, and we have an increasing contributor base (slowly growing, but it is growing).
As someone who has run GitHub Enterprise and is currently running GitLab Enterprise for $MY_DAYJOB work, Pagure is loads easier to manage and deal with. The "burden", as it were, is considerably lower. The much saner rate of code churn also means that upgrading and maintaining the system is much more manageable, which is why I switched my personal Git server from GitLab CE to Pagure.
I suspect the features that they're thinking of are the trivial CI setup stuff. Pagure has no equivalent to GitLab CI nor do we have a service like Travis CI in place to support projects hosted there. We do have CentOS CI, but because Jenkins is crap and requires the Jenkins admins to approve projects, it's basically garbage for self-service CI.
There's no reasonable chance we'd be able to migrate all our integrations from Pagure to either GitHub or GitLab (self hosted or otherwise). Aside from GitLab being very anti-integration and GitHub increasingly going down the same path, the fundamental architecture of our integrations is quite difficult to do with those two solutions (message based on a broker). We have hacked around it for GitHub.com with github2fedmsg, but it's not quite as expressive as the native functionality Pagure provides is.
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Honestly, I think the only reason fixes and releases don't come more frequently for Pagure is because there just aren't many people allowed to merge and do things. And the CentOS CI frequently breaks. :(
If there's something I'd *love* to see replaced, it's the Jenkins thing the CentOS Project runs. It's awful and provides a horrible user and developer experience.
On Tuesday, January 21, 2020 2:04:33 PM MST Neal Gompa wrote:
Aside from GitLab being very anti-integration
This is no longer the case, by the way. GitLab has recently made it easier to add plugins, with the new method not requiring patching the source tree.
Even before that change, webhook integrations + API calls were fairly powerful in GitLab.
On Tue, Jan 21, 2020 at 4:18 PM John M. Harris Jr johnmh@splentity.com wrote:
On Tuesday, January 21, 2020 2:04:33 PM MST Neal Gompa wrote:
Aside from GitLab being very anti-integration
This is no longer the case, by the way. GitLab has recently made it easier to add plugins, with the new method not requiring patching the source tree.
Even before that change, webhook integrations + API calls were fairly powerful in GitLab.
I'm aware of those and the capabilities implied. Unfortunately, this is very difficult to manage with GitLab Omnibus based deployments, and there are other caveats and restrictions that make this not as usable as it looks at first glace. And everyone I've talked to indicates that the a from-source deployment is a recipe for insanity, so I'm not even going to go there.
On Tuesday, January 21, 2020 2:33:11 PM MST Neal Gompa wrote:
Unfortunately, this is very difficult to manage with GitLab Omnibus based deployments
The new plugin interface makes it so that this is not the case. I make use of it on git.splentity.com, for example.
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
Michael
On 1/21/20 4:31 PM, Michael Catanzaro wrote:
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
I second this. FOSS is what's allowed RedHat to succeed and it would really suck to see Fedora switch to a closed source platform that's owned by Microsoft...
Also, as somebody who runs a self hosted pagure server I would really hate to see pagure go away. I understand Pingou may not have the time to work on the project as in the past but the torch should definitely be passed to somebody else or the community to continue work on the project.
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
I second this. FOSS is what's allowed RedHat to succeed and it would really suck to see Fedora switch to a closed source platform that's owned by Microsoft...
Also, as somebody who runs a self hosted pagure server I would really hate to see pagure go away. I understand Pingou may not have the time to work on the project as in the past but the torch should definitely be passed to somebody else or the community to continue work on the project.
It's open source now so what's stopping people/companies using it now from contributing rather than relying on Pingou? Similarly if it ceases to be a core piece of infrastructure for Fedora there's nothing stopping the pagure community to continue it's development.
----- Original Message -----
From: "Michael Catanzaro" mcatanzaro@gnome.org To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Tuesday, January 21, 2020 4:31:47 PM Subject: Re: Git Forge Requirements: Please see the Community Blog
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
I'd mention sr.ht (sourcehut) and gitea; the latter I run myself.
https://sourcehut.org/ (live: https://git.sr.ht/) https://github.com/go-gitea/gitea demo: https://try.gitea.io/)
YMMV.
Michael
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Jan 21, 2020 at 11:01:59PM +0100, Felix Schwarz wrote:
Am 21.01.20 um 22:31 schrieb Michael Catanzaro:
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source.
+1
I am with you on open source, but I don't understand the 'self-hosted' requirement. I guess I agree that self hosting should be possible, in case someone wants to fork our distro and use our tools, but if we can convince a open source project to maintain our dist git for us, why is that bad?
kevin
Am 31.01.20 um 03:01 schrieb Kevin Fenzi:
I am with you on open source, but I don't understand the 'self-hosted' requirement. I guess I agree that self hosting should be possible, in case someone wants to fork our distro and use our tools, but if we can convince a open source project to maintain our dist git for us, why is that bad?
First there is a bit of paranoia: Often there is software which you could self-host but if you actually try there are some proprietary bits or you need some very special patched dependencies. So switching from "hosted externally" to "self hosted" might be quite hard.
Also dist-git is the very core of Fedora (+ build/update infrastructure and ticketing). If this is hosted externally we would also need to trust the external operator. In the end having write access to a spec file means having root access on all machines which install that package (though you could detect the modification via git - but I don't want to rely only on git's hash sums).
In the end I'm also ok with a hosted solution (as I'm not the one doing the work) as long as there is a (realistic!) backup plan to self-host the code.
As far as I know Debian and Freedesktop maintain their own gitlab instances so it should be possible to benefit from their experience and tooling.
Felix
On Thu, Jan 30, 2020 at 06:01:22PM -0800, Kevin Fenzi wrote:
I am with you on open source, but I don't understand the 'self-hosted' requirement. I guess I agree that self hosting should be possible, in case someone wants to fork our distro and use our tools, but if we can convince a open source project to maintain our dist git for us, why is that bad?
Because of the legal issues? If Fedora starts using e.g. GitHub for dist-git, then all packagers would have to agree with GitHub use of terms. And I can imagine that there are people (like me) for whom they are unaccaptable. And also these terms can change on a whim without consent of the Fedora Project. I.e. by using a third-party service, you increases the burdends the users have to overcome.
It's like all the modern payment methods for public transpartation systems that require you to have a local phone number or an application from Google application store. They are convenient for most of the users, but they also discriminate. To take a ride you have to enter into a legal contract with a third party.
-- Petr
On Fri, Jan 31, 2020 at 10:02:36AM +0100, Petr Pisar wrote:
On Thu, Jan 30, 2020 at 06:01:22PM -0800, Kevin Fenzi wrote:
I am with you on open source, but I don't understand the 'self-hosted' requirement. I guess I agree that self hosting should be possible, in case someone wants to fork our distro and use our tools, but if we can convince a open source project to maintain our dist git for us, why is that bad?
Because of the legal issues? If Fedora starts using e.g. GitHub for dist-git, then all packagers would have to agree with GitHub use of terms. And I can imagine that there are people (like me) for whom they are unaccaptable. And also these terms can change on a whim without consent of the Fedora Project. I.e. by using a third-party service, you increases the burdends the users have to overcome.
Thats definitely something to consider. I would think if we have another company host things for us, we should be able to decide the terms. I agree just using general github wouldn't work (not only because it's non free)
It's like all the modern payment methods for public transpartation systems that require you to have a local phone number or an application from Google application store. They are convenient for most of the users, but they also discriminate. To take a ride you have to enter into a legal contract with a third party.
Sure, but I am supposing the Fedora Project would enter into some sort of hosting agreement with a 3rd party, I wasn't assuming we would just use general github or gitlab.
kevin
On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
Michael
Both Gitea and Gogs are potential options, in my opinion, both are lightweight and easy to extend.
On Tue, Jan 21, 2020 at 5:14 PM John M. Harris Jr johnmh@splentity.com wrote:
On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
Michael
Both Gitea and Gogs are potential options, in my opinion, both are lightweight and easy to extend.
Neither of those two are designed to be extended. There have been other examples of attempts to do this, which has led to effectively forking it. NotABug.org runs a fork of gogs for that reason. There are some instances of Gitea that I'm aware of that had to be forked to be extended. Forking to extend is not anything close to desirable.
On Tue, Jan 21, 2020 at 3:13 pm, John M. Harris Jr johnmh@splentity.com wrote:
Both Gitea and Gogs are potential options, in my opinion, both are lightweight and easy to extend.
I have some experience with Gogs. I don't recommend it.
On 21/01/2020 23:13, John M. Harris Jr wrote:
On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
Michael
Both Gitea and Gogs are potential options, in my opinion, both are lightweight and easy to extend.
If we go this way, in a few years we will end up in the same situation as with Pagure today. We will have many custom patches (which we need to take care of) and we will not have manpower to compete with the features of other major git forges.
On 1/22/20 1:56 AM, Michal Konecny wrote:
If we go this way, in a few years we will end up in the same situation as with Pagure today. We will have many custom patches (which we need to take care of) and we will not have manpower to compete with the features of other major git forges.
Which just begs the question, do you *need* to compete with other git forges. Seems like pagure fills a niche that the others don't.
On Wed, Jan 22, 2020 at 10:22 AM Michael Watters wattersm@watters.ws wrote:
On 1/22/20 1:56 AM, Michal Konecny wrote:
If we go this way, in a few years we will end up in the same situation as with Pagure today. We will have many custom patches (which we need to take care of) and we will not have manpower to compete with the features of other major git forges.
Which just begs the question, do you *need* to compete with other git forges. Seems like pagure fills a niche that the others don't.
We don't need to. There are improvements that people would like, and that does take development effort. That's the piece that requires manpower to go faster.
On Wed, Jan 22, 2020 at 10:28:52 -0500, Neal Gompa ngompa13@gmail.com wrote:
We don't need to. There are improvements that people would like, and that does take development effort. That's the piece that requires manpower to go faster.
In my opinion, I think this is where Red Hat should be helping. Pagure has a chance to change what free projects use for software development. Github isn't free (though they do some nice things for free software). Gitlab is open core, which means they have a conflict of interest when accepting improvements from outsiders. They could also stop supporting the open core at any time, leaving users who want infrastructure running on free software in a poor place.
On 2020-01-23 11:26, Bruno Wolff III wrote:
On Wed, Jan 22, 2020 at 10:28:52 -0500, Neal Gompa ngompa13@gmail.com wrote:
We don't need to. There are improvements that people would like, and that does take development effort. That's the piece that requires manpower to go faster.
In my opinion, I think this is where Red Hat should be helping. Pagure has a chance to change what free projects use for software development. Github isn't free (though they do some nice things for free software). Gitlab is open core, which means they have a conflict of interest when accepting improvements from outsiders. They could also stop supporting the open core at any time, leaving users who want infrastructure running on free software in a poor place.
I completely agree with this. I find it rather bizarre that I came to know FOSS almost exclusively because of Red Hat, yet it seems the majority of the projects I contribute to are now being hosted on Github, a Microsoft-owned company. I'd be rather incredulous if someone told me it was going to be like this back in the 90s. I've little experience with Gitlab, but plenty with Pagure from an internal instance and a few projects on pagure.io like Koji. I love Pagure and all this talk of possibly pushing it aside for Fedora makes me sad. I thought it was the way forward and was just getting to an excellent footing. Pagure might not be a money-making product but it sure can help build a community in an environment that is void of any potential corporate hostility.
On Tue, 21 Jan 2020, 21:32 Michael Catanzaro, mcatanzaro@gnome.org wrote:
So if we can agree on that much, then we can avoid wasting time by
including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
In the blog post they state that there aren't. Certainly GitHub and GitLab have the most momentum.
I happen to like Phabricator, and appreciate the developer's opinionated design approach, but perhaps it's right to pick the most mainstream thing we can with the goal of not wanting to move again for, say, another decade or so.
On Wed, Jan 22, 2020 at 08:40:54AM +0000, Peter Oliver wrote:
On Tue, 21 Jan 2020, 21:32 Michael Catanzaro, <[1]mcatanzaro@gnome.org> wrote:
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
In the blog post they state that there aren't. Certainly GitHub and GitLab have the most momentum. I happen to like Phabricator, and appreciate the developer's opinionated design approach, but perhaps it's right to pick the most mainstream thing we can with the goal of not wanting to move again for, say, another decade or so.
IIRC phabricator does not issue tracking which mean it would not fit the use-case of FESCo, FPC and other groups that are mostly using pagure as a ticketing system.
Pierre
On Wed, 2020-01-22 at 10:01 +0100, Pierre-Yves Chibon wrote:
IIRC phabricator does not issue tracking which mean it would not fit the use-case of FESCo, FPC and other groups that are mostly using pagure as a ticketing system.
Sure it does, we used to use it for this. It calls them 'tasks', but it's the same paradigm.
https://phacility.com/phabricator/maniphest/
On Wed, 2020-01-22 at 08:40 +0000, Peter Oliver wrote:
On Tue, 21 Jan 2020, 21:32 Michael Catanzaro, mcatanzaro@gnome.org wrote:
So if we can agree on that much, then we can avoid wasting time by
including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
In the blog post they state that there aren't. Certainly GitHub and GitLab have the most momentum.
I happen to like Phabricator, and appreciate the developer's opinionated design approach, but perhaps it's right to pick the most mainstream thing we can with the goal of not wanting to move again for, say, another decade or so.
We used Phabricator for Fedora QA work for a while, before migrating to Pagure. It had some really nice features, but it was quite a lot of work to maintain, and the fact that its workflow is not like Github's and requires some specific tooling would likely be a barrier to contribution since the Github workflow is such a de facto standard these days.
On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
Thanks for actually proposing some requirements :-).
In my opinion there are 2 different use cases :
- pagure.io : For me the requirements here is to provide a place for community members to host there projects. And project here can mean anything it can be actual source code, documentation, or just a README with some info about a team or like many team have just a ticket tracker. Once of the strong requirement is that whatever the solution is it needs to integrate with Fedora Account System and user should be able to use Single Sign On. Regarding the use case where a team wants to have a issue tracker and maybe a README to give details about how to contribute to that team I think teams.fedoraproject.org should be the prefered solution, for the second where people want to host a git project (code, documentation, book, etc ...) I don't think this needs to be solved by the Fedora community, there are many options (free and non free, as in freedom) which have dedicated infrastructure and dedicated teams running this type of service.
- dist-git (src.fedoraproject.org): This is a different use case, since here the solution needs to integrate with the rest of the infrastructure. the list of requirements here will be more specific for example it needs to be able to integrate with Fedora FAS but also to have the FAS group synced, branch ACLs, a way to integrate with release-monitoring, a way to integrate with bugzilla, a way to integrate with fedora-messaging (RabbitMQ), .... In general I think most of the integration with our infrastructure can be done with any solution either using the solution APIs or plugins system. After we need to compare the cost of developing and maintaining these pieces of glue to integrate everything against the current situation.
Michael
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, Jan 22, 2020 at 9:48 AM Clement Verna cverna@fedoraproject.org wrote:
On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
Thanks for actually proposing some requirements :-).
In my opinion there are 2 different use cases :
- pagure.io :
For me the requirements here is to provide a place for community members to host there projects. And project here can mean anything it can be actual source code, documentation, or just a README with some info about a team or like many team have just a ticket tracker. Once of the strong requirement is that whatever the solution is it needs to integrate with Fedora Account System and user should be able to use Single Sign On. Regarding the use case where a team wants to have a issue tracker and maybe a README to give details about how to contribute to that team I think teams.fedoraproject.org should be the prefered solution, for the second where people want to host a git project (code, documentation, book, etc ...) I don't think this needs to be solved by the Fedora community, there are many options (free and non free, as in freedom) which have dedicated infrastructure and dedicated teams running this type of service.
- dist-git (src.fedoraproject.org):
This is a different use case, since here the solution needs to integrate with the rest of the infrastructure. the list of requirements here will be more specific for example it needs to be able to integrate with Fedora FAS but also to have the FAS group synced, branch ACLs, a way to integrate with release-monitoring, a way to integrate with bugzilla, a way to integrate with fedora-messaging (RabbitMQ), .... In general I think most of the integration with our infrastructure can be done with any solution either using the solution APIs or plugins system. After we need to compare the cost of developing and maintaining these pieces of glue to integrate everything against the current situation.
If we go for splitting up use cases, than I'd like to highlight one thing:
src.fedoraproject.org is not a GitForge, it is a centrally managed code-review platform
Git Forges play a lot with the idea of users being able to create their own forks of the repository, their own projects, with their own rules. src.fp.org is the integrated platform where Fedora rules are in action. This is different from the use case KDE and Gnome have, as they manage development of projects, while we manage the integration.
And while GitHub and GitLab are well know leaders in the Git Forge business, they are actually not that good when it comes to the topics of 1) managing the large multi-component project in a unified way under central authority; 2) managing actual code review process.
Code Review platforms, like Gerrit are way better at that.
To see an example, take a look at the management of projects and groups in Gerrit. Or take a look on integration of CI systems. GitHub still struggles to make it natural part of the interface.
We _can_ implement centralized code review platform on top of any Git Forge service. But let's maybe consider using the right tool for the right job?
The obvious counter-argument here is: most of the users are uncomfortable with any interface other than GitHub. No matter if the interface is superior, or lighter, or nicer, there is still going to be that thing that it is _unusual_.
We, as a Linux distribution, know this argument pretty well. We, as Fedora Linux distribution, know it even better: you can not bring something new if you are scared of unusual things. Should it stop us?
We do need a better discoverability and visibility in the generic development community. But it is a solvable task: we can create a read-only mirror of our code on every common platform out there. We can use it as an opportunity to show what we do, but also to teach how we do it. For example OpenStack has a bot which replies on every GitHub issue and pull-request to the read-only mirrored repository with a manual on how one can send the same change through the OpenStack development process. We would need to do it the same way anyway, if we land on anything other than GitHub.
On Wed, Jan 22, 2020 at 6:06 AM Aleksandra Fedorova alpha@bookwar.info wrote:
On Wed, Jan 22, 2020 at 9:48 AM Clement Verna cverna@fedoraproject.org wrote:
On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
Thanks for actually proposing some requirements :-).
In my opinion there are 2 different use cases :
- pagure.io :
For me the requirements here is to provide a place for community members to host there projects. And project here can mean anything it can be actual source code, documentation, or just a README with some info about a team or like many team have just a ticket tracker. Once of the strong requirement is that whatever the solution is it needs to integrate with Fedora Account System and user should be able to use Single Sign On. Regarding the use case where a team wants to have a issue tracker and maybe a README to give details about how to contribute to that team I think teams.fedoraproject.org should be the prefered solution, for the second where people want to host a git project (code, documentation, book, etc ...) I don't think this needs to be solved by the Fedora community, there are many options (free and non free, as in freedom) which have dedicated infrastructure and dedicated teams running this type of service.
- dist-git (src.fedoraproject.org):
This is a different use case, since here the solution needs to integrate with the rest of the infrastructure. the list of requirements here will be more specific for example it needs to be able to integrate with Fedora FAS but also to have the FAS group synced, branch ACLs, a way to integrate with release-monitoring, a way to integrate with bugzilla, a way to integrate with fedora-messaging (RabbitMQ), .... In general I think most of the integration with our infrastructure can be done with any solution either using the solution APIs or plugins system. After we need to compare the cost of developing and maintaining these pieces of glue to integrate everything against the current situation.
If we go for splitting up use cases, than I'd like to highlight one thing:
src.fedoraproject.org is not a GitForge, it is a centrally managed
code-review platform
Git Forges play a lot with the idea of users being able to create their own forks of the repository, their own projects, with their own rules. src.fp.org is the integrated platform where Fedora rules are in action. This is different from the use case KDE and Gnome have, as they manage development of projects, while we manage the integration.
And while GitHub and GitLab are well know leaders in the Git Forge business, they are actually not that good when it comes to the topics of 1) managing the large multi-component project in a unified way under central authority; 2) managing actual code review process.
Code Review platforms, like Gerrit are way better at that.
To see an example, take a look at the management of projects and groups in Gerrit. Or take a look on integration of CI systems. GitHub still struggles to make it natural part of the interface.
We _can_ implement centralized code review platform on top of any Git Forge service. But let's maybe consider using the right tool for the right job?
The obvious counter-argument here is: most of the users are uncomfortable with any interface other than GitHub. No matter if the interface is superior, or lighter, or nicer, there is still going to be that thing that it is _unusual_.
We, as a Linux distribution, know this argument pretty well. We, as Fedora Linux distribution, know it even better: you can not bring something new if you are scared of unusual things. Should it stop us?
We do need a better discoverability and visibility in the generic development community. But it is a solvable task: we can create a read-only mirror of our code on every common platform out there. We can use it as an opportunity to show what we do, but also to teach how we do it. For example OpenStack has a bot which replies on every GitHub issue and pull-request to the read-only mirrored repository with a manual on how one can send the same change through the OpenStack development process. We would need to do it the same way anyway, if we land on anything other than GitHub.
I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack uses. To me, the only thing worse than Gerrit is the email/bz patch submission workflow we used prior to Pagure. Gerrit would be a step up from that legacy workflow, but it pushes too much crap onto the contributor that it's a great way to demotivate people.
Having contributed to projects using Gerrit, and previously dealt with Gerrit based workflows, I can honestly say that Gerrit is absolutely a miserable experience and the OpenStack project should feel bad about the fact that they think Gerrit provides a good user experience. What's worse is that the stupid bot that they use on GitHub mirrors is completely unfriendly to drive-by contributors. The OpenStack Project is an example of how to make it fundamentally driven by corporate developers who force asinine workflows because they can't be bothered to make a proper community full of a mixture of hobbyists and corporate contributors. And don't get me started on the fact that there are no distributions of OpenStack on community Linux distributions anymore, which I further indicate as evidence that the OpenStack community is too insular for its own good. RDO does not count since it doesn't work on *real* community distributions like Fedora.
(Sorry, but OpenStack makes me angry for a variety of reasons, and in my view, it's a failure as a community)
At least with Pagure, we have a bloody chance of being able to do something interesting like synchronize PR states across different mirrors of Fedora packages.
An idea I've had for the Pagure project itself would be to monitor when PRs are made on the GitHub.com and GitLab.com mirrors and automatically open up remote PRs pointing to the canonical Pagure repo and synchronize review information from Pagure to GitHub/GitLab and back. This is possible because Pagure is so flexible with how pull requests work, and because I don't particularly care if a PR shows up as "merged" on the GitHub.com/GitLab.com side. :)
The main reason I haven't pursued it is because CentOS CI is so unreliable and awful. It's demoralizing getting failures and then looking at Jenkins and seeing there are no logs of the failure. Or the increasing number of "error" states where it just breaks...
On 22. 01. 20 12:19, Neal Gompa wrote:>> We do need a better discoverability and visibility in the generic
development community. But it is a solvable task: we can create a read-only mirror of our code on every common platform out there. We can use it as an opportunity to show what we do, but also to teach how we do it. For example OpenStack has a bot which replies on every GitHub issue and pull-request to the read-only mirrored repository with a manual on how one can send the same change through the OpenStack development process. We would need to do it the same way anyway, if we land on anything other than GitHub.
I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack uses. To me, the only thing worse than Gerrit is the email/bz patch submission workflow we used prior to Pagure. Gerrit would be a step up from that legacy workflow, but it pushes too much crap onto the contributor that it's a great way to demotivate people.
Having contributed to projects using Gerrit, and previously dealt with Gerrit based workflows, I can honestly say that Gerrit is absolutely a miserable experience and the OpenStack project should feel bad about the fact that they think Gerrit provides a good user experience. What's worse is that the stupid bot that they use on GitHub mirrors is completely unfriendly to drive-by contributors. The OpenStack Project is an example of how to make it fundamentally driven by corporate developers who force asinine workflows because they can't be bothered to make a proper community full of a mixture of hobbyists and corporate contributors. And don't get me started on the fact that there are no distributions of OpenStack on community Linux distributions anymore, which I further indicate as evidence that the OpenStack community is too insular for its own good. RDO does not count since it doesn't work on *real* community distributions like Fedora.
While I don't necessarily agree with the tone, I must agree the the Gerrit experience for drive by contributors is one of the most horrible ones I had.
I even think sending patches over e-mail is probably better.
The main reason I haven't pursued it is because CentOS CI is so unreliable and awful. It's demoralizing getting failures and then looking at Jenkins and seeing there are no logs of the failure. Or the increasing number of "error" states where it just breaks...
This has been reported a year ago, without a fix so far:
During running tests, it's very hard to see what's happening https://pagure.io/fedora-ci/general/issue/2
CI errors are undecipherable https://pagure.io/fedora-ci/general/issue/43
CI errors happen far to often https://pagure.io/fedora-ci/general/issue/44
I've been trying to make those issues a priority when we adapted gating, but I was outvoted at FESCo.
On Wed, 22 Jan 2020 at 12:38, Miro Hrončok mhroncok@redhat.com wrote:
On 22. 01. 20 12:19, Neal Gompa wrote:>> We do need a better discoverability and visibility in the generic
development community. But it is a solvable task: we can create a read-only mirror of our code on every common platform out there. We can use it as an opportunity to show what we do, but also to teach how we do it. For example OpenStack has a bot which replies on every GitHub issue and pull-request to the read-only mirrored repository with a manual on how one can send the same change through the OpenStack development process. We would need to do it the same way anyway, if we land on anything other than GitHub.
I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack uses. To me, the only thing worse than Gerrit is the email/bz patch submission workflow we used prior to Pagure. Gerrit would be a step up from that legacy workflow, but it pushes too much crap onto the contributor that it's a great way to demotivate people.
Having contributed to projects using Gerrit, and previously dealt with Gerrit based workflows, I can honestly say that Gerrit is absolutely a miserable experience and the OpenStack project should feel bad about the fact that they think Gerrit provides a good user experience. What's worse is that the stupid bot that they use on GitHub mirrors is completely unfriendly to drive-by contributors. The OpenStack Project is an example of how to make it fundamentally driven by corporate developers who force asinine workflows because they can't be bothered to make a proper community full of a mixture of hobbyists and corporate contributors. And don't get me started on the fact that there are no distributions of OpenStack on community Linux distributions anymore, which I further indicate as evidence that the OpenStack community is too insular for its own good. RDO does not count since it doesn't work on *real* community distributions like Fedora.
While I don't necessarily agree with the tone,
+1 I appreciate that people are passionate about this topic, but let's stay respectful of other people work and opinion.
I must agree the the Gerrit experience for drive by contributors is one of the most horrible ones I had.
I even think sending patches over e-mail is probably better.
The main reason I haven't pursued it is because CentOS CI is so unreliable and awful. It's demoralizing getting failures and then looking at Jenkins and seeing there are no logs of the failure. Or the increasing number of "error" states where it just breaks...
This has been reported a year ago, without a fix so far:
During running tests, it's very hard to see what's happening https://pagure.io/fedora-ci/general/issue/2
CI errors are undecipherable https://pagure.io/fedora-ci/general/issue/43
CI errors happen far to often https://pagure.io/fedora-ci/general/issue/44
I've been trying to make those issues a priority when we adapted gating, but I was outvoted at FESCo.
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, Jan 22, 2020 at 12:38 PM Miro Hrončok mhroncok@redhat.com wrote:
On 22. 01. 20 12:19, Neal Gompa wrote:>> We do need a better discoverability and visibility in the generic
development community. But it is a solvable task: we can create a read-only mirror of our code on every common platform out there. We can use it as an opportunity to show what we do, but also to teach how we do it. For example OpenStack has a bot which replies on every GitHub issue and pull-request to the read-only mirrored repository with a manual on how one can send the same change through the OpenStack development process. We would need to do it the same way anyway, if we land on anything other than GitHub.
I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack uses. To me, the only thing worse than Gerrit is the email/bz patch submission workflow we used prior to Pagure. Gerrit would be a step up from that legacy workflow, but it pushes too much crap onto the contributor that it's a great way to demotivate people.
Having contributed to projects using Gerrit, and previously dealt with Gerrit based workflows, I can honestly say that Gerrit is absolutely a miserable experience and the OpenStack project should feel bad about the fact that they think Gerrit provides a good user experience. What's worse is that the stupid bot that they use on GitHub mirrors is completely unfriendly to drive-by contributors. The OpenStack Project is an example of how to make it fundamentally driven by corporate developers who force asinine workflows because they can't be bothered to make a proper community full of a mixture of hobbyists and corporate contributors. And don't get me started on the fact that there are no distributions of OpenStack on community Linux distributions anymore, which I further indicate as evidence that the OpenStack community is too insular for its own good. RDO does not count since it doesn't work on *real* community distributions like Fedora.
While I don't necessarily agree with the tone, I must agree the the Gerrit experience for drive by contributors is one of the most horrible ones I had.
Ok, I knew I would trigger a lot of wrong conversation if I mention it out in the open.
So let me just reiterate the main points:
1) src.fedoraproject.org is not a Git Forge
Implementation of src.fp.org via GitForge is the option which we used through Pagure, but there are other possibilities.
@jlanda just posted an awesome summary on the features, some of them support my point.
Proven packages for example is not a Git Forge concept.
Or the question of the ownership of the Pull request: in Git Forge pull-request are defined by the branch in someone's personal forked repository. And no one else has access to manage it. In Code Review system (yes, like Gerrit) change requests belong to the project repository. Anyone is able to work on anyone else's pull request, for example rebase it, or take over the work if the original owner doesn't want to continue by some reason.
2) Being afraid of everything which is not GitHub is not a good reason to choose GitHub.
It is a reason to look into how to make some integrations and ways out from GitHub possible for the end user. Things like mirroring, like allowing GitHub accounts in the Single Sign On system for sending patches and so on can help with that.
3) No matter what we choose, it would anger someone, and makes someone's life harder.
I would prefer if we choose tools by alignment of the purpose, the problem which those tools are trying to solve, rather then by the "niceness". Because if we have a same purpose - we have a way to improve the "niceness", sometimes by just waiting, sometimes by contributing...
But if we have different purposes in mind, then we are not going to get any improvements, because "we are not the target audience" and our features are always going to be out of priority and out of scope.
I even think sending patches over e-mail is probably better.
I think that it would be more productive if you try to rationalize this opinion. I don't want to argue about the feeling you have, but I would be interested in comparing notes on what exactly "Gerrit workflow" means to you, and whether or not it is the same thing to me.
The main reason I haven't pursued it is because CentOS CI is so unreliable and awful. It's demoralizing getting failures and then looking at Jenkins and seeing there are no logs of the failure. Or the increasing number of "error" states where it just breaks...
This has been reported a year ago, without a fix so far:
During running tests, it's very hard to see what's happening https://pagure.io/fedora-ci/general/issue/2
CI errors are undecipherable https://pagure.io/fedora-ci/general/issue/43
CI errors happen far to often https://pagure.io/fedora-ci/general/issue/44
I've been trying to make those issues a priority when we adapted gating, but I was outvoted at FESCo.
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On 22. 01. 20 13:12, Aleksandra Fedorova wrote:
I think that it would be more productive if you try to rationalize this opinion. I don't want to argue about the feeling you have, but I would be interested in comparing notes on what exactly "Gerrit workflow" means to you, and whether or not it is the same thing to me.
Note that I don't describe an experience with a workflow. I am describing a drive by contributor experience:
1. you send a Pull Request over a familiar channel 2. a bot tells you that you cannot do this and you need to follow this tutorial instead 3. you push your code to some place that is far to overocmplicated to navigate 4. magic happens, there is no way to see what's going on unless you have experienced this before 5. you get dozens of bot e-mail you don't understand 6. eventually hopefully the bot merges the thing
I realize that (4) might be true about "anything new". What I am trying to say is that e-mail is a familiar channel. GitHub / GitLab / Pagure etc. almost looks like a bulletin board or a more code-oriented Facebook comments. However gerrit is like a nuclear power plant control center -> you are afraid to touch anything. You need a tutorial to handle it. It's not beginners friendly and it enhances a cargo cult behavior.
* Miro Hrončok:
On 22. 01. 20 13:12, Aleksandra Fedorova wrote:
I think that it would be more productive if you try to rationalize this opinion. I don't want to argue about the feeling you have, but I would be interested in comparing notes on what exactly "Gerrit workflow" means to you, and whether or not it is the same thing to me.
Note that I don't describe an experience with a workflow. I am describing a drive by contributor experience:
- you send a Pull Request over a familiar channel
- a bot tells you that you cannot do this and you need to follow this
tutorial instead 3. you push your code to some place that is far to overocmplicated to navigate 4. magic happens, there is no way to see what's going on unless you have experienced this before 5. you get dozens of bot e-mail you don't understand 6. eventually hopefully the bot merges the thing
Does that really matter for src.fedoraproject.org and the current dist-git model?
Even if you want to make a really simple change (such as fixing a typo in the --help message), src.fedoraproject.org will not show you the file you need to edit, or provide you with tools to produce a patch/commit to submit.
The Github model is different: you would just click on the 🖉 button, make your change, add a description, and click “Propose file change”. But even if we switched src.fedoraproject.org to Github, this would only work for RPM spec file changes. You would still not be able to edit the --help message directly. That's why I think that there is little risk of random drive-by contributions: people just won't find a place to make the changes they want. (The potential FPCA issue I raised separately still exists, though.)
Thanks, Florian
On Wed, 2020-01-22 at 13:51 +0100, Florian Weimer wrote:
- Miro Hrončok:
On 22. 01. 20 13:12, Aleksandra Fedorova wrote:
I think that it would be more productive if you try to rationalize this opinion. I don't want to argue about the feeling you have, but I would be interested in comparing notes on what exactly "Gerrit workflow" means to you, and whether or not it is the same thing to me.
Note that I don't describe an experience with a workflow. I am describing a drive by contributor experience:
- you send a Pull Request over a familiar channel
- a bot tells you that you cannot do this and you need to follow this
tutorial instead 3. you push your code to some place that is far to overocmplicated to navigate 4. magic happens, there is no way to see what's going on unless you have experienced this before 5. you get dozens of bot e-mail you don't understand 6. eventually hopefully the bot merges the thing
Does that really matter for src.fedoraproject.org and the current dist-git model?
Even if you want to make a really simple change (such as fixing a typo in the --help message), src.fedoraproject.org will not show you the file you need to edit, or provide you with tools to produce a patch/commit to submit.
The Github model is different: you would just click on the 🖉 button, make your change, add a description, and click “Propose file change”. But even if we switched src.fedoraproject.org to Github, this would only work for RPM spec file changes. You would still not be able to edit the --help message directly.
Weren't there some suggestions to use upackaged source code/git subtree instead of the tarball we have now ?
Then the upstream source code would be there and you could fix the --help message directly in Fedora distgit. The result would be a fixed Fedora package & ideally also the same change automatically submitted to upstream for review.
That's why I think that there is little risk of random drive-by contributions: people just won't find a place to make the changes they want. (The potential FPCA issue I raised separately still exists, though.)
Thanks, Florian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, Jan 22, 2020 at 1:25 PM Miro Hrončok mhroncok@redhat.com wrote:
On 22. 01. 20 13:12, Aleksandra Fedorova wrote:
I think that it would be more productive if you try to rationalize this opinion. I don't want to argue about the feeling you have, but I would be interested in comparing notes on what exactly "Gerrit workflow" means to you, and whether or not it is the same thing to me.
Note that I don't describe an experience with a workflow. I am describing a drive by contributor experience:
- you send a Pull Request over a familiar channel
- a bot tells you that you cannot do this and you need to follow this tutorial
instead 3. you push your code to some place that is far to overocmplicated to navigate 4. magic happens, there is no way to see what's going on unless you have experienced this before 5. you get dozens of bot e-mail you don't understand 6. eventually hopefully the bot merges the thing
I realize that (4) might be true about "anything new". What I am trying to say is that e-mail is a familiar channel. GitHub / GitLab / Pagure etc. almost looks like a bulletin board or a more code-oriented Facebook comments. However gerrit is like a nuclear power plant control center -> you are afraid to touch anything. You need a tutorial to handle it. It's not beginners friendly and it enhances a cargo cult behavior.
OK, I can understand that.
Though when people talk about simplicity of the GitHub interface, I usually tend to point at this page: https://github.com/kubernetes/kubernetes/pulls and the k8s-bot actions there If this page doesn't look overwhelming for you, I don't know what does :)
I admit, being a gerrit user for couple of years I actually miss the "nuclear plant" interface, where you can get a full state of a change request in one glance, rather then by browsing through several "Facebook-like" tabs and pages to see the full picture: comments, ci results, files changed, people who need to review the task, their comments,..
And we haven't even started about the CLI interface (git review) it has, which none of GitLab/GitHub things can compete with.
So you argument for me sounds like Gerrit is too powerful and too good. Which is a valid argument, actually. We don't want newcomer to go the full speed with it from a day one.
The question here is:
can we have the power, scalability and feature-richness of a platform like Gerrit, but (optionally) hidden under the hood so that there is a "simple mode" for people who just need a one-time contribution?
I've just checked, there is a GitHub plugin [1] for Gerrit which manages the integration. Could it be the option?
[1] https://gerrit.googlesource.com/plugins/github/
-- Aleksandra Fedorova bookwar
On 22. 01. 20 14:03, Aleksandra Fedorova wrote:
can we have the power, scalability and feature-richness of a platform like Gerrit, but (optionally) hidden under the hood so that there is a "simple mode" for people who just need a one-time contribution?
I won't go there, becasue I don't think we need the power, scalability and feature-richness of a platform like gerrit in the first place.
1. Not for dist git 2. Not for ticketing projects on pagure.io 3. Code projects on pagure.io can choose a platform that fits their needs
On Wed, Jan 22, 2020 at 2:21 PM Miro Hrončok mhroncok@redhat.com wrote:
On 22. 01. 20 14:03, Aleksandra Fedorova wrote:
can we have the power, scalability and feature-richness of a platform like Gerrit, but (optionally) hidden under the hood so that there is a "simple mode" for people who just need a one-time contribution?
I won't go there, becasue I don't think we need the power, scalability and feature-richness of a platform like gerrit in the first place.
- Not for dist git
This is where we disagree heavily I guess.
We do need scalability, especially if we consider moving from source tarballs to unpacked sources at some point. And I hope we do (which is a yet another discussion we need to have).
In my previous life we hosted Gerrit server for the entire custom Linux distribution (syncing all OpenStack commits in "real-time") on a VM with 2Gb of RAM, which never had an issue.
We do need feature richness in terms of central management of the repositories in src.fp.org: default policies, groups, users, permissions, CI labels, branching,.. We do need integration, which Gerrit provides through the stream of events. And we already have CI system (Zuul engine) which can integrate nicely with it. We do need features like topics, where pull-requests to different projects are linked together as an implementation of one larger cross-project feature. This is something Git Forges don't have as an object at all, as they treat individual projects as isolated custom playgrounds, each with a separate workflow.
If we don't get these features from a platform, we are going to implement it on our own, through bots and external services. Which will not make the contributor life easier. See the k8s link above: when integrations are done by bots rather than by internal platform features, they are not going to look nice or easy.
- Not for ticketing projects on pagure.io
- Code projects on pagure.io can choose a platform that fits their needs
Pagure.io story is different.
Hello,
Thanks for the thread. Lots of good stuff there. Would it be also OK to add a non technical requirement into the mix:
- whatever we do choose, we stick to it for N years.
I add this because an important reason for moving away from Pagure seems to be that we don't have the man-power to keep developing/maintaining it, and yet, moving core pieces of community infra to new platforms makes it even harder to:
- keep existing contributors (who have to migrate their work and learn the new workflow around the new platform, even if it is similar to the previous one),
- gain new ones (because it takes time to move our processes and update community knowledge which new contributors need).
So, such changes, while positive and necessary for us to improve, must also not be frequent enough to disrupt us.
* Aleksandra Fedorova:
I even think sending patches over e-mail is probably better.
I think that it would be more productive if you try to rationalize this opinion.
Gerrit makes it really hard to figure out your open tasks. You can see a list of the reviews you have “started” (unfortunate terminology IMHO—starting a review means submitting it for others to review, not starting to review it). But at the individual review level, it is really hard to figure out what your next steps are and if you have addressed all reviewer comments (especially after rebasing).
With email, you can view the entire review thread in your client and tag messages with action items as needed, and then get back to them for the next version of the patch.
When we looked at Gerrit for glibc, our conclusion was that it would need lots of customization. That's okay if you derive benefit from actually running the tool (as in, you like to provide this kind of service personally or you can grow your team as a result), but it's much more difficult to justify if you are just looking at it as a tool to support what you are really interested in.
Thanks, Florian
On Wed, Jan 22, 2020 at 12:20 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 22, 2020 at 6:06 AM Aleksandra Fedorova alpha@bookwar.info wrote:
On Wed, Jan 22, 2020 at 9:48 AM Clement Verna cverna@fedoraproject.org wrote:
On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa ngompa13@gmail.com wrote:
And any discussion of GitHub isn't going to involve self-hosted, it's going to involve GitHub.com, which means we're talking about losing more of our independence as a project. This is one of those things that I'm not sure is a wise move.
Well since we have a request for requirements: I propose requirements #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora community would be outraged if we fail to meet either requirement.
So if we can agree on that much, then we can avoid wasting time by including GitHub in the list of options. That would bring us to a choice between GitLab CE and Pagure. (Are there any other serious options?)
Thanks for actually proposing some requirements :-).
In my opinion there are 2 different use cases :
- pagure.io :
For me the requirements here is to provide a place for community members to host there projects. And project here can mean anything it can be actual source code, documentation, or just a README with some info about a team or like many team have just a ticket tracker. Once of the strong requirement is that whatever the solution is it needs to integrate with Fedora Account System and user should be able to use Single Sign On. Regarding the use case where a team wants to have a issue tracker and maybe a README to give details about how to contribute to that team I think teams.fedoraproject.org should be the prefered solution, for the second where people want to host a git project (code, documentation, book, etc ...) I don't think this needs to be solved by the Fedora community, there are many options (free and non free, as in freedom) which have dedicated infrastructure and dedicated teams running this type of service.
- dist-git (src.fedoraproject.org):
This is a different use case, since here the solution needs to integrate with the rest of the infrastructure. the list of requirements here will be more specific for example it needs to be able to integrate with Fedora FAS but also to have the FAS group synced, branch ACLs, a way to integrate with release-monitoring, a way to integrate with bugzilla, a way to integrate with fedora-messaging (RabbitMQ), .... In general I think most of the integration with our infrastructure can be done with any solution either using the solution APIs or plugins system. After we need to compare the cost of developing and maintaining these pieces of glue to integrate everything against the current situation.
If we go for splitting up use cases, than I'd like to highlight one thing:
src.fedoraproject.org is not a GitForge, it is a centrally managed
code-review platform
Git Forges play a lot with the idea of users being able to create their own forks of the repository, their own projects, with their own rules. src.fp.org is the integrated platform where Fedora rules are in action. This is different from the use case KDE and Gnome have, as they manage development of projects, while we manage the integration.
And while GitHub and GitLab are well know leaders in the Git Forge business, they are actually not that good when it comes to the topics of 1) managing the large multi-component project in a unified way under central authority; 2) managing actual code review process.
Code Review platforms, like Gerrit are way better at that.
To see an example, take a look at the management of projects and groups in Gerrit. Or take a look on integration of CI systems. GitHub still struggles to make it natural part of the interface.
We _can_ implement centralized code review platform on top of any Git Forge service. But let's maybe consider using the right tool for the right job?
The obvious counter-argument here is: most of the users are uncomfortable with any interface other than GitHub. No matter if the interface is superior, or lighter, or nicer, there is still going to be that thing that it is _unusual_.
We, as a Linux distribution, know this argument pretty well. We, as Fedora Linux distribution, know it even better: you can not bring something new if you are scared of unusual things. Should it stop us?
We do need a better discoverability and visibility in the generic development community. But it is a solvable task: we can create a read-only mirror of our code on every common platform out there. We can use it as an opportunity to show what we do, but also to teach how we do it. For example OpenStack has a bot which replies on every GitHub issue and pull-request to the read-only mirrored repository with a manual on how one can send the same change through the OpenStack development process. We would need to do it the same way anyway, if we land on anything other than GitHub.
I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack uses. To me, the only thing worse than Gerrit is the email/bz patch submission workflow we used prior to Pagure. Gerrit would be a step up from that legacy workflow, but it pushes too much crap onto the contributor that it's a great way to demotivate people.
Having contributed to projects using Gerrit, and previously dealt with Gerrit based workflows, I can honestly say that Gerrit is absolutely a miserable experience and the OpenStack project should feel bad about the fact that they think Gerrit provides a good user experience. What's worse is that the stupid bot that they use on GitHub mirrors is completely unfriendly to drive-by contributors. The OpenStack Project is an example of how to make it fundamentally driven by corporate developers who force asinine workflows because they can't be bothered to make a proper community full of a mixture of hobbyists and corporate contributors. And don't get me started on the fact that there are no distributions of OpenStack on community Linux distributions anymore, which I further indicate as evidence that the OpenStack community is too insular for its own good. RDO does not count since it doesn't work on *real* community distributions like Fedora.
(Sorry, but OpenStack makes me angry for a variety of reasons, and in my view, it's a failure as a community)
Sorry but I don't see any actual argument in this text other than that you personally don't like OpenStack. And this doesn't really contribute to the discussion.
At least with Pagure, we have a bloody chance of being able to do something interesting like synchronize PR states across different mirrors of Fedora packages.
An idea I've had for the Pagure project itself would be to monitor when PRs are made on the GitHub.com and GitLab.com mirrors and automatically open up remote PRs pointing to the canonical Pagure repo and synchronize review information from Pagure to GitHub/GitLab and back. This is possible because Pagure is so flexible with how pull requests work, and because I don't particularly care if a PR shows up as "merged" on the GitHub.com/GitLab.com side. :)
I don't see how Pagure is special in this regard. Synchronizing between two different APIs via external service is always possible. Though complexity of this solution makes benefits questionable.
The main reason I haven't pursued it is because CentOS CI is so unreliable and awful. It's demoralizing getting failures and then looking at Jenkins and seeing there are no logs of the failure. Or the increasing number of "error" states where it just breaks...
Jenkins is not really a right tool for implementing such a service. There should be a microservice-like stateless thing, which you can deploy to Commushift for example.
-- Aleksandra Fedorova bookwar
* Aleksandra Fedorova:
If we go for splitting up use cases, than I'd like to highlight one thing:
src.fedoraproject.org is not a GitForge, it is a centrally managed
code-review platform
Git Forges play a lot with the idea of users being able to create their own forks of the repository, their own projects, with their own rules. src.fp.org is the integrated platform where Fedora rules are in action. This is different from the use case KDE and Gnome have, as they manage development of projects, while we manage the integration.
Like the other services, src.fedoraproject.org has no built-in knowledge of the git-on-git model we currently use for most packages, so I think as far as Fedora usage is concerned, those differences are pretty minor.
Thanks, Florian
Il giorno 21 gen 2020, alle ore 18:15, Fabio Valentini decathorpe@gmail.com ha scritto:
On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin@redhat.com mailto:lgriffin@redhat.com> wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/ https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
Alright, I have some questions that are not answered by the blog post.
- What is going to happen to the two pagure instances at pagure.io http://pagure.io/,
and src.fedoraproject.org http://src.fedoraproject.org/?
I think pagure.io http://pagure.io/ is a good home for fedora-related projects (it was the successor to fedorahosted.org http://fedorahosted.org/, after all, IIRC). I know that many group efforts are hosting their source code, ticketing system, etc. there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to shut down pagure.io http://pagure.io/, I assume those projects will have to be moved somewhere?
+1
Also, it's very nice to have a PR-based workflow for some shared-maintenance packages on src.fedoraproject.org http://src.fedoraproject.org/, and I don't think losing that feature would be a good thing for fedora.
+1
- How is GitHub considered to be an alternative here?
+1 …and to my knowledge GitHub is closed source.
I don't think (public or hosted) GitHub can do what is currently done on src.fedoraproject.org http://src.fedoraproject.org/, can it? I'd also not want to see fedora use a closed-source product for such a core service ...
- Which features are missing from pagure, compared to the other forges?
+1 It’s not clear reading the original POST
For my purposes, I don't miss any feature on pagure.io http://pagure.io/ compared to my repositories on github.com http://github.com/, and OTTOMH, I can't come up with any missing features, at all …
+1
TL;DR: Can we please keep pagure? It already has the fedora-specific features we need, and I don't mind a "slow" pace of development. In my experience, it works really well, and I actually *like* to use it (which is not true for GitLab ... which is slow and horrible)
+1
Fabio
I totally agree with Fabio, I can’t think of a single reason we should dismiss pagure.
Ciao Guido FAS: tartina
I had replied to Fabio on IRC but... :-)
----- Original Message -----
From: "Guido Aulisi" guido.aulisi@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Tuesday, January 21, 2020 3:48:31 PM Subject: Re: Git Forge Requirements: Please see the Community Blog
Il giorno 21 gen 2020, alle ore 18:15, Fabio Valentini decathorpe@gmail.com ha scritto:
On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin@redhat.com mailto:lgriffin@redhat.com> wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/ https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
Alright, I have some questions that are not answered by the blog post.
- What is going to happen to the two pagure instances at pagure.io
http://pagure.io/, and src.fedoraproject.org http://src.fedoraproject.org/?
I think pagure.io http://pagure.io/ is a good home for fedora-related projects (it was the successor to fedorahosted.org http://fedorahosted.org/, after all, IIRC). I know that many group efforts are hosting their source code, ticketing system, etc. there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to shut down pagure.io http://pagure.io/, I assume those projects will have to be moved somewhere?
+1
Also, it's very nice to have a PR-based workflow for some shared-maintenance packages on src.fedoraproject.org http://src.fedoraproject.org/, and I don't think losing that feature would be a good thing for fedora.
+1
- How is GitHub considered to be an alternative here?
+1 …and to my knowledge GitHub is closed source.
I don't think (public or hosted) GitHub can do what is currently done on src.fedoraproject.org http://src.fedoraproject.org/, can it? I'd also not want to see fedora use a closed-source product for such a core service ...
- Which features are missing from pagure, compared to the other forges?
+1 It’s not clear reading the original POST
For my purposes, I don't miss any feature on pagure.io http://pagure.io/ compared to my repositories on github.com http://github.com/, and OTTOMH, I can't come up with any missing features, at all …
+1
From a _development_ POV, there's a number of things missing for it being the primary git forge for pagure.io (not arguing about src.fedoraproject.org or packaging use cases -- but some of those will benefit by these as well):
- Real full-text search across issues and PRs. No need to RTFM. ( For those not having RTFM'd, you use "content:<keyword>" to do a full-text search in current Pagure. I've argued that it should behave like other forge's searches: https://pagure.io/pagure/issue/2505#comment-582516 ) - A UI with a UX that makes sense. https://pagure.io/pagure/issue/4543 https://pagure.io/pagure/issue/2193 https://pagure.io/pagure/issue/42 (duped: 343) https://pagure.io/pagure/issue/2167 (and you could keep cherry-picking issues. There's a section of opened ones with UI tags). - The above is a huge category and I think its worth restating some items: - Search, search, search. - Split diff - Real line numbers in the diff - Expanding context around the diff (Diff, diff, diff?) - Workflow on reviewing PRs is sub-optimal compared to most other forges. - Pagure is often slower than GitLab for me. YMMV. - ...
For a period of time, IDM tried using Pagure for FreeIPA development. They filed a huge number of issues. Now we host issues on Pagure, and have moved development to GitHub. [*] I think we've mostly quit filing bugs; the Pagure team has done a good job with the resources they've been given, but they definitely need more resources to pull this off to a high level.
I still try and file issues from time to time...
...but Pagure really doesn't compare in quality to Gogs/Gitea, much less GitLab or GitHub from strictly a development point of view.
My 2c.
- Alex
[*]: My team (Dogtag) is also considering moving our issues off of Pagure onto GitHub, to host them along side our code. I don't claim to speak for all of IDM here though, just noting what they've done.
TL;DR: Can we please keep pagure? It already has the fedora-specific features we need, and I don't mind a "slow" pace of development. In my experience, it works really well, and I actually *like* to use it (which is not true for GitLab ... which is slow and horrible)
+1
Fabio
I totally agree with Fabio, I can’t think of a single reason we should dismiss pagure.
Ciao Guido FAS: tartina _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On ti, 21 tammi 2020, Alex Scheel wrote:
For a period of time, IDM tried using Pagure for FreeIPA development. They filed a huge number of issues. Now we host issues on Pagure, and have moved development to GitHub. [*] I think we've mostly quit filing bugs; the Pagure team has done a good job with the resources they've been given, but they definitely need more resources to pull this off to a high level.
FreeIPA does not use Github for its primary code hosting. We do use Pagure for that and would like to stay with open source forge. We do use Github to mirror source code from Pagure and utilize pull requests flow, though, purely because there are two things available there: - an easier new contributors' flow - ability to integrate with a larger number of CI systems
The first one sometimes is a deal breaker but not really too much. For example, for Samba a move of existing Github mirror to Gitlab didn't really reduced inflow of external contributors. Samba project does host its git tree on own servers and maintains gitlab mirror for actually doing reviews and accepting external and in-team contributions.
I still try and file issues from time to time...
...but Pagure really doesn't compare in quality to Gogs/Gitea, much less GitLab or GitHub from strictly a development point of view.
My 2c.
- Alex
[*]: My team (Dogtag) is also considering moving our issues off of Pagure onto GitHub, to host them along side our code. I don't claim to speak for all of IDM here though, just noting what they've done.
TL;DR: Can we please keep pagure? It already has the fedora-specific features we need, and I don't mind a "slow" pace of development. In my experience, it works really well, and I actually *like* to use it (which is not true for GitLab ... which is slow and horrible)
+1
Fabio
I totally agree with Fabio, I can’t think of a single reason we should dismiss pagure.
Ciao Guido FAS: tartina _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Alexander Bokovoy abokovoy@redhat.com writes:
On ti, 21 tammi 2020, Alex Scheel wrote:
For a period of time, IDM tried using Pagure for FreeIPA development. They filed a huge number of issues. Now we host issues on Pagure, and have moved development to GitHub. [*] I think we've mostly quit filing bugs; the Pagure team has done a good job with the resources they've been given, but they definitely need more resources to pull this off to a high level.
I was one of the people filing under IdM (mostly due to another IdM component, gssproxy, which is wholly on pagure). While there was some activity on them, it has definitely felt like there's no capacity for new features.
FreeIPA does not use Github for its primary code hosting. We do use Pagure for that and would like to stay with open source forge. We do use Github to mirror source code from Pagure and utilize pull requests flow, though, purely because there are two things available there:
- an easier new contributors' flow
Hmm. As an occasional drive-by contributor, I don't find this easier. The problem for me is that the issue tracker and PR interface are on separate platforms, and there's some pressure to create issues before filing PRs. While I prefer the Github workflow (and I agree it's easier for new contributors), I honestly think it's better to have it in just one place.
- ability to integrate with a larger number of CI systems
The first one sometimes is a deal breaker but not really too much. For example, for Samba a move of existing Github mirror to Gitlab didn't really reduced inflow of external contributors. Samba project does host its git tree on own servers and maintains gitlab mirror for actually doing reviews and accepting external and in-team contributions.
As long as the distinction between "canonical source of truth" and "the one everyone interacts with all the time" doesn't affect non-maintainers (and they can just use the second), it doesn't really matter - admins just can't use any of the nice tools for integrating PRs. I don't personally think it's a useful distinction in a DVCS world, so I don't make it in my projects.
Thanks, --Robbie
Am 21.01.20 um 21:48 schrieb Guido Aulisi:
I totally agree with Fabio, I can’t think of a single reason we should dismiss pagure.
Gitlab is used by many free software communities like Freedesktop, Gnome, Debian. Using the same tools could help to facilitate inter-process/inter-distro collaboration.
Personally I guess github would attract most contributions for Fedora from new contributors but it is closed source so I'd prefer gitlab for Fedora. (Though I somehow got used to pagure and getting the gitlab integration to the same level as pagure currently will be a lot of work for sure.)
Felix
On 1/21/20 4:59 PM, Felix Schwarz wrote:
(Though I somehow got used to pagure and getting the gitlab integration to the same level as pagure currently will be a lot of work for sure.)
Maybe I'm just a grumpy old system admin but it sounds like a lot of work for little, if any, gain.
On Tue, 2020-01-21 at 17:04 -0500, Michael Watters wrote:
On 1/21/20 4:59 PM, Felix Schwarz wrote:
(Though I somehow got used to pagure and getting the gitlab integration to the same level as pagure currently will be a lot of work for sure.)
Maybe I'm just a grumpy old system admin but it sounds like a lot of work for little, if any, gain.
The gain would be not having to maintain Pagure any more. It's essentially one-time work for long-term gain, assuming the alternative solution continues to exist and to be maintained and to meet our needs.
Felix Schwarz fschwarz@fedoraproject.org writes:
Am 21.01.20 um 21:48 schrieb Guido Aulisi:
I totally agree with Fabio, I can’t think of a single reason we should dismiss pagure.
Gitlab is used by many free software communities like Freedesktop, Gnome, Debian. Using the same tools could help to facilitate inter-process/inter-distro collaboration.
Personally I guess github would attract most contributions for Fedora from new contributors but it is closed source so I'd prefer gitlab for Fedora. (Though I somehow got used to pagure and getting the gitlab integration to the same level as pagure currently will be a lot of work for sure.)
On top of that Gitlab is a huge Ruby on Rails application and (at least I have the feeling that) the Fedora community doesn't have so many Ruby developers in comparison to Python developers, so implementing something comparable could be challenging let alone from the manpower point of view. And then there's the issue that we are not upstream and might have to maintain the integration as a downstream patch forever as upstream might not want it.
Cheers,
Dan
On Tuesday, January 21, 2020 9:57:59 PM MST Dan Čermák wrote:
Felix Schwarz fschwarz@fedoraproject.org writes:
Am 21.01.20 um 21:48 schrieb Guido Aulisi:
I totally agree with Fabio, I can’t think of a single reason we should dismiss pagure.
Gitlab is used by many free software communities like Freedesktop, Gnome, Debian. Using the same tools could help to facilitate inter-process/inter-distro collaboration.
Personally I guess github would attract most contributions for Fedora from new contributors but it is closed source so I'd prefer gitlab for Fedora. (Though I somehow got used to pagure and getting the gitlab integration to the same level as pagure currently will be a lot of work for sure.)
On top of that Gitlab is a huge Ruby on Rails application and (at least I have the feeling that) the Fedora community doesn't have so many Ruby developers in comparison to Python developers, so implementing something comparable could be challenging let alone from the manpower point of view. And then there's the issue that we are not upstream and might have to maintain the integration as a downstream patch forever as upstream might not want it.
Cheers,
Dan
If these Python people really can't figure out Ruby, a language binding can be generated.. However, Ruby is much more clean than Python, and there's no requirement for downstream patches anyway. GitLab has a plugin interface these days.
On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Felix Schwarz fschwarz@fedoraproject.org writes:
Am 21.01.20 um 21:48 schrieb Guido Aulisi:
I totally agree with Fabio, I can’t think of a single reason we should dismiss pagure.
Gitlab is used by many free software communities like Freedesktop, Gnome, Debian. Using the same tools could help to facilitate inter-process/inter-distro collaboration.
Personally I guess github would attract most contributions for Fedora from new contributors but it is closed source so I'd prefer gitlab for Fedora. (Though I somehow got used to pagure and getting the gitlab integration to the same level as pagure currently will be a lot of work for sure.)
On top of that Gitlab is a huge Ruby on Rails application and (at least I have the feeling that) the Fedora community doesn't have so many Ruby developers in comparison to Python developers, so implementing something comparable could be challenging let alone from the manpower point of view.
That's the whole point of APIs, and I'm sure they provide bindings for those APIs to assist in the process.
And then there's the issue that we are not upstream and might have to maintain the integration as a downstream patch forever as upstream might not want it.
They've provided pretty good support to various other open source communities such as GNOME and Freedesktop/Xorg.
I think we should be looking at this from a different PoV.... like the given the resources that we currently have attempting to develop a git forge what could they do if someone else was doing that what other awesome things could they achieve if they were able to deal with integration as opposed to just playing catch up.
On Wed, Jan 22, 2020 at 1:05 AM Peter Robinson pbrobinson@gmail.com wrote:
On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Felix Schwarz fschwarz@fedoraproject.org writes:
Am 21.01.20 um 21:48 schrieb Guido Aulisi:
I totally agree with Fabio, I can’t think of a single reason we should dismiss pagure.
Gitlab is used by many free software communities like Freedesktop, Gnome, Debian. Using the same tools could help to facilitate inter-process/inter-distro collaboration.
Personally I guess github would attract most contributions for Fedora from new contributors but it is closed source so I'd prefer gitlab for Fedora. (Though I somehow got used to pagure and getting the gitlab integration to the same level as pagure currently will be a lot of work for sure.)
On top of that Gitlab is a huge Ruby on Rails application and (at least I have the feeling that) the Fedora community doesn't have so many Ruby developers in comparison to Python developers, so implementing something comparable could be challenging let alone from the manpower point of view.
That's the whole point of APIs, and I'm sure they provide bindings for those APIs to assist in the process.
Sorry, no they don't. There are some community projects that provide some overlays to some of the APIs, but they are in various states of disrepair. Some are doing somewhat okay, but it's difficult since their churn rate also includes API breakages.
And then there's the issue that we are not upstream and might have to maintain the integration as a downstream patch forever as upstream might not want it.
They've provided pretty good support to various other open source communities such as GNOME and Freedesktop/Xorg.
Yes, but neither of those communities actually have terribly special requirements. In fact, those communities either had *nothing* in terms of infrastructure (FreeDesktop/Xorg) or were willing to throw everything away for GitLab (GNOME). We would not fit in either bucket, which makes GitLab a very awkward fit for us.
And GitLab CI is a poor fit for Fedora because it doesn't offer a good model for distribution-scale integration and delivery. At $DAYJOB, I have been maintaining a heavily used GitLab system for three years, and I have some fairly good experience understanding where it fits well since $DAYJOB folks try to exploit as many features that are reasonably useful as possible. And frankly, it works well for GNOME and FDO because multi-project integration is not a fundamental requirement for the projects hosted there. For Fedora, this *is* a fundamental requirement, and the Fedora CI people are working gloriously towards the goal of having that be fully in place.
I think we should be looking at this from a different PoV.... like the given the resources that we currently have attempting to develop a git forge what could they do if someone else was doing that what other awesome things could they achieve if they were able to deal with integration as opposed to just playing catch up.
That's not the motivation here. And honestly, I've *never* seen that happen.
That's also a somewhat negative view of this, because it implies we're not doing something awesome now. Pagure fills a niche that currently isn't filled by anything else today and works rather well in doing so. Pagure is actually a pretty awesome forge that provides some unique capabilities:
* Remote pull requests, allowing people working on their own servers to contribute to projects on Pagure * Support for fully offline workflows (this is actually possible due to Pagure's fundamental design) * Full state project mirroring in a reasonably portable manner * Full themeability without pain (that's fairly recent, but it's nice!) * First-class support for integrating with other solutions (best of breed combinations rather than difficult monoliths)
Downstream distributions can actually fully mirror src.fp.o without too much pain, including PRs, and do further work based on it. That's not really a thing in other forges. I know that I've been using that property for some of $DAYJOB work and personal work too, and it really makes life quite nice.
Since Pagure 5.0, I've been a very happy user of the Pagure forge, as the usability of the system has gone way up and it is very close to my vision of what a Free Software forge should be like. Pagure makes our island have bridges to other islands, as opposed to all these GitLab servers that are closed islands.
And there's this worry that GitLab will go the same path Transifex did. They have a ton of incentives to do so, and they already are starting to with the consideration of injecting nonfree JavaScript in all variants. And if you think community forks are going to survive on the GitLab codebase, oh boy, nope. That codebase is *huge* and complex. It's a combination of Ruby and Go that has one of the most baffling architectures I've observed. The RhodeCode fork Kallithea is many times smaller and is equally struggling.
Pagure is also slowly growing as a community in its own right and there are various groups aligned with Pagure's vision that are interested in adopting it as their solution and contributing to the project. Part of this has been somewhat due to my campaigning for it in aligned communities, of course, but it's also because Pagure is genuinely good and unique among Git forge solutions.
Pagure is also proof that Fedora can be innovative in a very positive way. It was a rough start, but we've got a groove going, let's not kill it!
The Pagure.io forge really is only missing some kind of self-service CI to make it generically useful. CentOS CI is a trash heap and needs to be replaced by a better solution that allows self-service enablement. I'm sorry, but whoever thought that CentOS CI would scale or work reasonably well needs to rethink their priorities. It's the only part of the Pagure.io forge system that isn't self-service, and it shows with the poor levels of CI adoption.
On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
On top of that Gitlab is a huge Ruby on Rails application and (at least I have the feeling that) the Fedora community doesn't have so many Ruby developers in comparison to Python developers, so implementing something comparable could be challenging let alone from the manpower point of view.
That's the whole point of APIs, and I'm sure they provide bindings for those APIs to assist in the process.
Sorry, no they don't. There are some community projects that provide some overlays to some of the APIs, but they are in various states of disrepair. Some are doing somewhat okay, but it's difficult since their churn rate also includes API breakages.
https://github.com/python-gitlab/python-gitlab looks like a pretty actively maintained thing which claims to be compatible with current Gitlab API.
On Wed, Jan 22, 2020 at 6:04 AM Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
On top of that Gitlab is a huge Ruby on Rails application and (at least I have the feeling that) the Fedora community doesn't have so many Ruby developers in comparison to Python developers, so implementing something comparable could be challenging let alone from the manpower point of view.
That's the whole point of APIs, and I'm sure they provide bindings for those APIs to assist in the process.
Sorry, no they don't. There are some community projects that provide some overlays to some of the APIs, but they are in various states of disrepair. Some are doing somewhat okay, but it's difficult since their churn rate also includes API breakages.
https://github.com/python-gitlab/python-gitlab looks like a pretty actively maintained thing which claims to be compatible with current Gitlab API.
I'm using that one at work for some stuff, and most of the basic APIs are in place, but the coverage of the GitLab API isn't very high. It's mostly because GitLab keeps adding more stuff to the API and people can't keep up, though. When I started using it around GitLab 10.5, it was considered a lot more complete than it is now.
That said, basic interactions work pretty well, and as far as I know, it's the most complete of the community API modules.
On Wed, Jan 22, 2020 at 12:04:15PM +0100, Adam Williamson wrote:
On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
On top of that Gitlab is a huge Ruby on Rails application and (at least I have the feeling that) the Fedora community doesn't have so many Ruby developers in comparison to Python developers, so implementing something comparable could be challenging let alone from the manpower point of view.
That's the whole point of APIs, and I'm sure they provide bindings for those APIs to assist in the process.
Sorry, no they don't. There are some community projects that provide some overlays to some of the APIs, but they are in various states of disrepair. Some are doing somewhat okay, but it's difficult since their churn rate also includes API breakages.
https://github.com/python-gitlab/python-gitlab looks like a pretty actively maintained thing which claims to be compatible with current Gitlab API.
I've used this library in a moderately complicated project (automatically bridging email list development to GitLab and vice versa) and it's worked fine. As far as I can tell it covers the whole API. Nothing has broken for me, documentation is reasonable, etc. The GitLab API itself is much better than Pagure.
As far as I can tell GitLab actually versions its API and Pagure has broken its API without a version bump repeatedly (e.g. some unpaginated APIs suddenly became paginated).
- Jeremy
On Wed, 22 Jan 2020 at 11:02, Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 22, 2020 at 1:05 AM Peter Robinson pbrobinson@gmail.com wrote:
On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Felix Schwarz fschwarz@fedoraproject.org writes:
Am 21.01.20 um 21:48 schrieb Guido Aulisi:
I totally agree with Fabio, I can’t think of a single reason we
should dismiss
pagure.
Gitlab is used by many free software communities like Freedesktop,
Gnome,
Debian. Using the same tools could help to facilitate inter-process/inter-distro collaboration.
Personally I guess github would attract most contributions for
Fedora from new
contributors but it is closed source so I'd prefer gitlab for
Fedora. (Though
I somehow got used to pagure and getting the gitlab integration to
the same
level as pagure currently will be a lot of work for sure.)
On top of that Gitlab is a huge Ruby on Rails application and (at least I have the feeling that) the Fedora community doesn't have so many Ruby developers in comparison to Python developers, so implementing
something
comparable could be challenging let alone from the manpower point of view.
That's the whole point of APIs, and I'm sure they provide bindings for those APIs to assist in the process.
Sorry, no they don't. There are some community projects that provide some overlays to some of the APIs, but they are in various states of disrepair. Some are doing somewhat okay, but it's difficult since their churn rate also includes API breakages.
And then there's the issue that we are not upstream and might have to maintain the integration as a downstream patch forever as upstream
might
not want it.
They've provided pretty good support to various other open source communities such as GNOME and Freedesktop/Xorg.
Yes, but neither of those communities actually have terribly special requirements. In fact, those communities either had *nothing* in terms of infrastructure (FreeDesktop/Xorg) or were willing to throw everything away for GitLab (GNOME). We would not fit in either bucket, which makes GitLab a very awkward fit for us.
And GitLab CI is a poor fit for Fedora because it doesn't offer a good model for distribution-scale integration and delivery. At $DAYJOB, I have been maintaining a heavily used GitLab system for three years, and I have some fairly good experience understanding where it fits well since $DAYJOB folks try to exploit as many features that are reasonably useful as possible. And frankly, it works well for GNOME and FDO because multi-project integration is not a fundamental requirement for the projects hosted there. For Fedora, this *is* a fundamental requirement, and the Fedora CI people are working gloriously towards the goal of having that be fully in place.
I think we should be looking at this from a different PoV.... like the given the resources that we currently have attempting to develop a git forge what could they do if someone else was doing that what other awesome things could they achieve if they were able to deal with integration as opposed to just playing catch up.
That's not the motivation here. And honestly, I've *never* seen that happen.
It just happened last year, a lot of the development effort of the CPE team was focused on rawhide gating. It meant that projects that were not related to that effort suffered from this, for example pagure, anitya (release-minotoring), speeding up the compose, moving away from PDC, moving from the current FAS, etc ...
That's also a somewhat negative view of this, because it implies we're not doing something awesome now. Pagure fills a niche that currently isn't filled by anything else today and works rather well in doing so. Pagure is actually a pretty awesome forge that provides some unique capabilities:
- Remote pull requests, allowing people working on their own servers
to contribute to projects on Pagure
- Support for fully offline workflows (this is actually possible due
to Pagure's fundamental design)
- Full state project mirroring in a reasonably portable manner
- Full themeability without pain (that's fairly recent, but it's nice!)
- First-class support for integrating with other solutions (best of
breed combinations rather than difficult monoliths)
Downstream distributions can actually fully mirror src.fp.o without too much pain, including PRs, and do further work based on it. That's not really a thing in other forges. I know that I've been using that property for some of $DAYJOB work and personal work too, and it really makes life quite nice.
Since Pagure 5.0, I've been a very happy user of the Pagure forge, as the usability of the system has gone way up and it is very close to my vision of what a Free Software forge should be like. Pagure makes our island have bridges to other islands, as opposed to all these GitLab servers that are closed islands.
And there's this worry that GitLab will go the same path Transifex did. They have a ton of incentives to do so, and they already are starting to with the consideration of injecting nonfree JavaScript in all variants. And if you think community forks are going to survive on the GitLab codebase, oh boy, nope. That codebase is *huge* and complex. It's a combination of Ruby and Go that has one of the most baffling architectures I've observed. The RhodeCode fork Kallithea is many times smaller and is equally struggling.
Pagure is also slowly growing as a community in its own right and there are various groups aligned with Pagure's vision that are interested in adopting it as their solution and contributing to the project. Part of this has been somewhat due to my campaigning for it in aligned communities, of course, but it's also because Pagure is genuinely good and unique among Git forge solutions.
Pagure is also proof that Fedora can be innovative in a very positive way. It was a rough start, but we've got a groove going, let's not kill it!
I agree with you that Pagure is a cool project and is particularly unique in the world of git forges. I have also made my first FOSS contribution to Pagure and if I am part of the Fedora Community today it is because of Pagure and Pingou. But I also have to pragmatic and realistic and I think that to be successful Pagure needs more development effort and I don't think that in the current state of the Fedora Infrastructure we can afford that development. My opinion from working day to day in this infrastructure is that we are now reaching a point where we have to pay for the technical debt we have accumulated. Like any sort of debt, you have to pay its interests and for many year we did not, now with have the debt collector knocking at the door, looking at the televisor in the living room. The more we wait to pay back this technical debt the worst it becomes, you also have to add to that, that a lot of the technical and domain knowledge about the tools and the infra in general was lost when most of the creator of these applications moved to new adventures.
The Fedora community is also not growing much, more and more community member ends up having more and more things to do, because of that they are even more dependent on the infrastructure being reliable and stable. For example many people might have planned to contribute during the end of the year holidays but could not because of the problem we have experience with Koji, Bodhi and RabbitMQ. It means that users of the infra are getting frustrated because Koji is slow again, a Bodhi update was not pushed again, there is a problem pushing a commit to fork again, or there is no progress on my 2 year old ticket that ask to rename my group in FAS. It also means that people working on the infra are getting more and more frustrated because there are just too many fires to fight at once and whatever they do it will suck or someone will complain.
All this technical debt, also make it harder to attract new contributor who would be interested to contribute development time to these applications. Being innovative and creative is fun, creating new cool application for the Fedora Community is really great and rewarding, the other side of the medal is a little bit less shiny, maintaining a large code base, making sure that it runs well in production is not that interesting and rewarding.
In my opinion, as a community we have to make a choice either we continue as we are now, knowing very well that the things will only get worst, or do we try to refocus on the essential and make some sacrifice and compromise ? Alternative to Pagure will not be perfect and will not cover 100% of the use cases, but can we live with it ? are we ready to make some trade off ? Another solution is to find 20 developers that are willing to invest a few hours a week fixing bugs on all the applications we have.
The Pagure.io forge really is only missing some kind of self-service CI to make it generically useful. CentOS CI is a trash heap and needs to be replaced by a better solution that allows self-service enablement. I'm sorry, but whoever thought that CentOS CI would scale or work reasonably well needs to rethink their priorities. It's the only part of the Pagure.io forge system that isn't self-service, and it shows with the poor levels of CI adoption.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
And then there's the issue that we are not upstream and might have to maintain the integration as a downstream patch forever as upstream might not want it.
They've provided pretty good support to various other open source communities such as GNOME and Freedesktop/Xorg.
Yes, but neither of those communities actually have terribly special requirements. In fact, those communities either had *nothing* in terms of infrastructure (FreeDesktop/Xorg) or were willing to throw everything away for GitLab (GNOME). We would not fit in either bucket, which makes GitLab a very awkward fit for us.
“Throw everything away”? Just how much of the transition did you follow?
GitLab was more than accommodating in pulling features out of the enterprise edition into the community one that were crucial for our workflows. It was not done on a whim and I really resent your statements here.
On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik ekulik@redhat.com wrote:
On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
And then there's the issue that we are not upstream and might have to maintain the integration as a downstream patch forever as upstream might not want it.
They've provided pretty good support to various other open source communities such as GNOME and Freedesktop/Xorg.
Yes, but neither of those communities actually have terribly special requirements. In fact, those communities either had *nothing* in terms of infrastructure (FreeDesktop/Xorg) or were willing to throw everything away for GitLab (GNOME). We would not fit in either bucket, which makes GitLab a very awkward fit for us.
“Throw everything away”? Just how much of the transition did you follow?
GitLab was more than accommodating in pulling features out of the enterprise edition into the community one that were crucial for our workflows. It was not done on a whim and I really resent your statements here.
I followed it pretty closely. In the GNOME case, you were willing to throw away Bugzilla, CGit, and older CI infrastructure to replace it with GitLab. You guys also renamed some of your repositories to accommodate the restrictions on project naming by GitLab. A lot of retooling was required as part of the transition to GitLab for GNOME.
That, by my definition, is throwing away everything. It had knock on effects for everyone downstream as well, as all the tools for tracking GNOME also broke and needed to change. Again, that's fine if the community is generally accepting of this pain, but it is still pain, even if you refuse to acknowledge it.
On Wed, 2020-01-22 at 09:12 -0500, Neal Gompa wrote:
On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik ekulik@redhat.com wrote:
On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
And then there's the issue that we are not upstream and might have to maintain the integration as a downstream patch forever as upstream might not want it.
They've provided pretty good support to various other open source communities such as GNOME and Freedesktop/Xorg.
Yes, but neither of those communities actually have terribly special requirements. In fact, those communities either had *nothing* in terms of infrastructure (FreeDesktop/Xorg) or were willing to throw everything away for GitLab (GNOME). We would not fit in either bucket, which makes GitLab a very awkward fit for us.
“Throw everything away”? Just how much of the transition did you follow?
GitLab was more than accommodating in pulling features out of the enterprise edition into the community one that were crucial for our workflows. It was not done on a whim and I really resent your statements here.
I followed it pretty closely. In the GNOME case, you were willing to throw away Bugzilla, CGit, and older CI infrastructure to replace it with GitLab. You guys also renamed some of your repositories to accommodate the restrictions on project naming by GitLab. A lot of retooling was required as part of the transition to GitLab for GNOME.
What? Do you suggest adding more infrastructure to maintain on (at the time) a singular sysadmin? Bugzilla and cgit were to be made redundant, that’s the whole point here.
The “older CI infrastructure” is still there and has been semi-broken forever, so that’s as immaterial as it gets. The development for the replacement was only nudged by the GitLab transition.
I don’t even know how to approach the accusation that we bent over backwards to appease the overlords, dictating repository naming. Yes, GTK, most prominently, was renamed as a result. It really was more a pretext, because no one cares about the plus and it was historical baggage.
That, by my definition, is throwing away everything. It had knock on effects for everyone downstream as well, as all the tools for tracking GNOME also broke and needed to change. Again, that's fine if the community is generally accepting of this pain, but it is still pain, even if you refuse to acknowledge it.
Please don’t say I’m in denial just because I don’t agree with what you’re trying to convey here.
My observation is that the pipelines that were built only managed to improve developers’ workflows by automating as much as possible with a tool that tries to provide that. Those, who preferred the old ways, adjusted as best they could, too, even only taking patches in GitLab issues instead of working with merge requests. You can only imagine how many external contributions those projects see.
On Wed, 22 Jan 2020 at 15:37, Ernestas Kulik ekulik@redhat.com wrote:
On Wed, 2020-01-22 at 09:12 -0500, Neal Gompa wrote:
On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik ekulik@redhat.com wrote:
On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
And then there's the issue that we are not upstream and might have to maintain the integration as a downstream patch forever as upstream might not want it.
They've provided pretty good support to various other open source communities such as GNOME and Freedesktop/Xorg.
Yes, but neither of those communities actually have terribly special requirements. In fact, those communities either had *nothing* in terms of infrastructure (FreeDesktop/Xorg) or were willing to throw everything away for GitLab (GNOME). We would not fit in either bucket, which makes GitLab a very awkward fit for us.
“Throw everything away”? Just how much of the transition did you follow?
GitLab was more than accommodating in pulling features out of the enterprise edition into the community one that were crucial for our workflows. It was not done on a whim and I really resent your statements here.
I followed it pretty closely. In the GNOME case, you were willing to throw away Bugzilla, CGit, and older CI infrastructure to replace it with GitLab. You guys also renamed some of your repositories to accommodate the restrictions on project naming by GitLab. A lot of retooling was required as part of the transition to GitLab for GNOME.
What? Do you suggest adding more infrastructure to maintain on (at the time) a singular sysadmin? Bugzilla and cgit were to be made redundant, that’s the whole point here.
The “older CI infrastructure” is still there and has been semi-broken forever, so that’s as immaterial as it gets. The development for the replacement was only nudged by the GitLab transition.
I don’t even know how to approach the accusation that we bent over backwards to appease the overlords, dictating repository naming. Yes, GTK, most prominently, was renamed as a result. It really was more a pretext, because no one cares about the plus and it was historical baggage.
That, by my definition, is throwing away everything. It had knock on effects for everyone downstream as well, as all the tools for tracking GNOME also broke and needed to change. Again, that's fine if the community is generally accepting of this pain, but it is still pain, even if you refuse to acknowledge it.
Please don’t say I’m in denial just because I don’t agree with what you’re trying to convey here.
My observation is that the pipelines that were built only managed to improve developers’ workflows by automating as much as possible with a tool that tries to provide that. Those, who preferred the old ways, adjusted as best they could, too, even only taking patches in GitLab issues instead of working with merge requests. You can only imagine how many external contributions those projects see.
For the curious like me, is the GNOME GitLab instance self hosted ? or hosted by GitLab ?
-- Ernestas Kulik Associate Software Engineer - Base Operating Systems (Core Services/ABRT) Red Hat Czech, s.r.o. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, Jan 22, 2020 at 3:43 PM Clement Verna cverna@fedoraproject.org wrote:
On Wed, 22 Jan 2020 at 15:37, Ernestas Kulik ekulik@redhat.com wrote:
On Wed, 2020-01-22 at 09:12 -0500, Neal Gompa wrote:
On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik ekulik@redhat.com wrote:
On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
> And then there's the issue that we are not upstream and might > have to > maintain the integration as a downstream patch forever as > upstream might > not want it.
They've provided pretty good support to various other open source communities such as GNOME and Freedesktop/Xorg.
Yes, but neither of those communities actually have terribly special requirements. In fact, those communities either had *nothing* in terms of infrastructure (FreeDesktop/Xorg) or were willing to throw everything away for GitLab (GNOME). We would not fit in either bucket, which makes GitLab a very awkward fit for us.
“Throw everything away”? Just how much of the transition did you follow?
GitLab was more than accommodating in pulling features out of the enterprise edition into the community one that were crucial for our workflows. It was not done on a whim and I really resent your statements here.
I followed it pretty closely. In the GNOME case, you were willing to throw away Bugzilla, CGit, and older CI infrastructure to replace it with GitLab. You guys also renamed some of your repositories to accommodate the restrictions on project naming by GitLab. A lot of retooling was required as part of the transition to GitLab for GNOME.
What? Do you suggest adding more infrastructure to maintain on (at the time) a singular sysadmin? Bugzilla and cgit were to be made redundant, that’s the whole point here.
The “older CI infrastructure” is still there and has been semi-broken forever, so that’s as immaterial as it gets. The development for the replacement was only nudged by the GitLab transition.
I don’t even know how to approach the accusation that we bent over backwards to appease the overlords, dictating repository naming. Yes, GTK, most prominently, was renamed as a result. It really was more a pretext, because no one cares about the plus and it was historical baggage.
That, by my definition, is throwing away everything. It had knock on effects for everyone downstream as well, as all the tools for tracking GNOME also broke and needed to change. Again, that's fine if the community is generally accepting of this pain, but it is still pain, even if you refuse to acknowledge it.
Please don’t say I’m in denial just because I don’t agree with what you’re trying to convey here.
My observation is that the pipelines that were built only managed to improve developers’ workflows by automating as much as possible with a tool that tries to provide that. Those, who preferred the old ways, adjusted as best they could, too, even only taking patches in GitLab issues instead of working with merge requests. You can only imagine how many external contributions those projects see.
For the curious like me, is the GNOME GitLab instance self hosted ? or hosted by GitLab ?
It is self-hosted.
-- Ernestas Kulik Associate Software Engineer - Base Operating Systems (Core Services/ABRT) Red Hat Czech, s.r.o. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, Jan 22, 2020 at 9:12 am, Neal Gompa ngompa13@gmail.com wrote:
I followed it pretty closely. In the GNOME case, you were willing to throw away Bugzilla, CGit, and older CI infrastructure to replace it with GitLab.
To be clear, getting rid of Bugzilla was the goal, not a compromise. cgit is a nice interface but it's mostly obsoleted by GitLab as well. We didn't *have* to get rid of cgit, but there just wasn't a compelling reason to keep it. And we never had any CI prior to GitLab. CI is surely the most important part. GitLab CE has tremendously improved our development workflow.
When I say GitLab, I mean GitLab CE (Community Edition), the open-source self-hosted version of GitLab, not gitlab.com (which is GitLab Enterprise Edition). It doesn't have as many features as github.com, but it's been adopted by many related projects: GNOME, freedesktop.org, KDE, and Debian. Each of these projects had their own long and difficult search to determine which git forge would be best for them, and they all picked GitLab CE.
Michael
On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote:
they all picked GitLab CE.
Hi, I do not want to pollute this thread with unrelated information, but for what it worth, I only recently realized that GitLab CE, the one hosted on GNOME, does not have searching working properly. I filled a bug upstream [1]. Being able to reliably search in issues is rather essential function, from my point of view. I'm wondering how they can search for anything when they've filled 10k+ issues.
Anyway, if you think this doesn't belong to this thread then I apologize. Bye, Milan
On Wed, Jan 22, 2020 at 12:58 PM Milan Crha mcrha@redhat.com wrote:
On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote:
they all picked GitLab CE.
Hi,
I do not want to pollute this thread with unrelated information, but for what it worth, I only recently realized that GitLab CE, the one hosted on GNOME, does not have searching working properly. I filled a bug upstream [1]. Being able to reliably search in issues is rather essential function, from my point of view. I'm wondering how they can search for anything when they've filled 10k+ issues.
Anyway, if you think this doesn't belong to this thread then I apologize.
Fulltext search in GitLab is an Enterprise Edition feature and requires a separate deployment of ElasticSearch.
On Wed, 2020-01-22 at 13:28 -0500, Neal Gompa wrote:
On Wed, Jan 22, 2020 at 12:58 PM Milan Crha mcrha@redhat.com wrote:
On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote:
they all picked GitLab CE.
Hi,
I do not want to pollute this thread with unrelated information, but for what it worth, I only recently realized that GitLab CE, the one hosted on GNOME, does not have searching working properly. I filled a bug upstream [1]. Being able to reliably search in issues is rather essential function, from my point of view. I'm wondering how they can search for anything when they've filled 10k+ issues.
Anyway, if you think this doesn't belong to this thread then I apologize.
Fulltext search in GitLab is an Enterprise Edition feature and requires a separate deployment of ElasticSearch.
Ouch - really ? :-(
Well, I guess that demonstrates quite nicely the dangers of open core projects right here and there...
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, 28 Jan 2020 at 12:17, Martin Kolman mkolman@redhat.com wrote:
On Wed, 2020-01-22 at 13:28 -0500, Neal Gompa wrote:
On Wed, Jan 22, 2020 at 12:58 PM Milan Crha mcrha@redhat.com wrote:
On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote:
they all picked GitLab CE.
Hi,
I do not want to pollute this thread with unrelated information, but for what it worth, I only recently realized that GitLab CE, the one hosted on GNOME, does not have searching working properly. I filled a bug upstream [1]. Being able to reliably search in issues is rather essential function, from my point of view. I'm wondering how they can search for anything when they've filled 10k+ issues.
Anyway, if you think this doesn't belong to this thread then I apologize.
Fulltext search in GitLab is an Enterprise Edition feature and requires a separate deployment of ElasticSearch.
Ouch - really ? :-(
Well, I guess that demonstrates quite nicely the dangers of open core projects right here and there...
Well even if it wasn't opencore .. the search tools would still require a lot of infrastructure to work. An allure of pagure has been that it runs on 1 system front and back. To get the feature set that people seem to want from gitlab would require about 6 to 18 systems (the 'this is how it should be done if you want the minimum of dealing with corner cases') with each sub-service adding on more systems for its own cluster. You also find that you need to upgrade your hardware to have 10 gigabit switches, fast storage, and other clustering tools which were not budgeted for. Yes you can do it with less but you will keep running into corner cases as you have more and more use-cases from different developer groups. So you end up standing up a large set of hardware and find yourself still focusing on running something other than building software.
And that is the real allure of going to an outsourced software stack. They deal with running things and fixing all the corner cases your developers will find. [Whether those fixes actually ever occur is for some future crisis.] You can then focus on the main job that you started off on, regularly making an OS.
On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro mcatanzaro@gnome.org wrote:
It doesn't have as many features as github.com,
Sorry, this was a typo. I meant: it doesn't have as many features as gitlab.com.
Way we were discussing this, I think there were several points I didn't really see here.
a) we are gathering requirements for Git Forge, but we need a good Dist Git as well.
There might be difference in requirements and tooling for Dist Git compared to generic fully featured Git Forge. It might still be useful to abandon Pagure as a full-featured git-forge and instead focus on making it really useful as a dist-git solution.
b) Whatever we decide, there will be significant investment required. Either by re-investing in our existing solution, or in the migration effort.
I think we really want to avoid the `Polarion` situation, where we wouldn't be clear about all of the costs involved in migration, and end up with a solution that only saved effort/money on paper, and in reality it could cost many a man-day of migration/maintenance/workaround efforts.
I am not yet sure how to make this less vague, and more "Gathering requirements", @Leigh Griffin lgriffin@redhat.com will there be some sort of a poll in the end, or how do we actually get a list of requirements?
I assume we are in the "Research" phase of ODF [1], but this is first time I am interacting with the framework :-)
Adam
[1] https://github.com/red-hat-people-team/open-decision-framework/blob/master/O...
On Fri, Jan 24, 2020 at 4:56 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro mcatanzaro@gnome.org wrote:
It doesn't have as many features as github.com,
Sorry, this was a typo. I meant: it doesn't have as many features as gitlab.com.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Jan 28, 2020, 15:58 Adam Saleh asaleh@redhat.com wrote:
Way we were discussing this, I think there were several points I didn't really see here.
a) we are gathering requirements for Git Forge, but we need a good Dist Git as well.
There might be difference in requirements and tooling for Dist Git compared to generic fully featured Git Forge. It might still be useful to abandon Pagure as a full-featured git-forge and instead focus on making it really useful as a dist-git solution.
b) Whatever we decide, there will be significant investment required. Either by re-investing in our existing solution, or in the migration effort.
I think we really want to avoid the `Polarion` situation, where we wouldn't be clear about all of the costs involved in migration, and end up with a solution that only saved effort/money on paper, and in reality it could cost many a man-day of migration/maintenance/workaround efforts.
I am not yet sure how to make this less vague, and more "Gathering requirements", @Leigh Griffin lgriffin@redhat.com will there be some sort of a poll in the end, or how do we actually get a list of requirements?
This thread is serving as a source of requirements (although it has meandered dramatically away from that) but I will default to the Fedora Council for how a combined set from the input in this thread and others is collated and presented. When all requirements are gathered from all stakeholders I will share the distilled version out.
I assume we are in the "Research" phase of ODF [1], but this is first time I am interacting with the framework :-)
We are in that phase of getting requirements and analyzing them. Sorry on my phone here so I can't be 100% sure of the formal phases off hand.
Adam
[1] https://github.com/red-hat-people-team/open-decision-framework/blob/master/O...
On Fri, Jan 24, 2020 at 4:56 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro mcatanzaro@gnome.org wrote:
It doesn't have as many features as github.com,
Sorry, this was a typo. I meant: it doesn't have as many features as gitlab.com.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, 28 Jan 2020 at 20:58, Leigh Griffin lgriffin@redhat.com wrote:
This thread is serving as a source of requirements (although it has meandered dramatically away from that)
When I first read the post, my thought was: wow, what a convoluted and abstruse way of saying "we want to abandon Pagure". Probably this wasn't your intent, but that's what I got. And given the reactions, other people too.
Iñaki
On Tue, Jan 28, 2020, 22:06 Iñaki Ucar iucar@fedoraproject.org wrote:
On Tue, 28 Jan 2020 at 20:58, Leigh Griffin lgriffin@redhat.com wrote:
This thread is serving as a source of requirements (although it has
meandered dramatically away from that)
When I first read the post, my thought was: wow, what a convoluted and abstruse way of saying "we want to abandon Pagure". Probably this wasn't your intent, but that's what I got. And given the reactions, other people too.
The linked blog to the ODF is very explicit that Pagure is one of the 3 forge options we are considering. I can't stress enough that it's a viable choice and ultimately what we opt for will come down to an analysis driven by the requirements gathered. I'm unsure how the blog has been interpreted any other way but hopefully this clears it up.
If you (and others) elaborate on how you use Pagure (and other forges) and what you value from your day to day usage, we will take that on board and use it to drive our decision making.
Iñaki _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, 29 Jan 2020 at 00:08, Leigh Griffin lgriffin@redhat.com wrote:
On Tue, Jan 28, 2020, 22:06 Iñaki Ucar iucar@fedoraproject.org wrote:
On Tue, 28 Jan 2020 at 20:58, Leigh Griffin lgriffin@redhat.com wrote:
This thread is serving as a source of requirements (although it has meandered dramatically away from that)
When I first read the post, my thought was: wow, what a convoluted and abstruse way of saying "we want to abandon Pagure". Probably this wasn't your intent, but that's what I got. And given the reactions, other people too.
The linked blog to the ODF is very explicit that Pagure is one of the 3 forge options we are considering. I can't stress enough that it's a viable choice and ultimately what we opt for will come down to an analysis driven by the requirements gathered. I'm unsure how the blog has been interpreted any other way but hopefully this clears it up.
The ODF is very explicit in the problem statement, and it specifically and clearly says that:
1. Pagure does not align with CPE. 2. CPE is not gonna commit a development team to Pagure. 3. The feature gap is big and growing, and basically Pagure is gonna die because of this (and the document goes on saying that you're not trying to solve the feature gap).
Then the ODF lists Pagure as a solution. How am I supposed to interpret the above?
If you (and others) elaborate on how you use Pagure (and other forges) and what you value from your day to day usage, we will take that on board and use it to drive our decision making.
Asking for requirements for a *forge* is pointless. A forge doesn't have requirements. What you do with a forge has requirements. As others have already pointed out, Pagure is being used at the very least for 3 distinct use cases: to maintain rpm packages, to maintain upstream projects, and as an issue tracker. And they all have distinct requirements. Only that, as it happens, Pagure has grown to cover their necessities with more or less success, which doesn't necessarily mean that a forge is the best solution for all of them (as, again, others have pointed out already). But the ODF only lists forges as solutions.
So solutions for what? What are we talking about here? Requirements for src.fp.org? Requirements for things that are in pagure.io? All? Other?
Iñaki
On Wed, 29 Jan 2020 at 11:36, Iñaki Ucar iucar@fedoraproject.org wrote:
On Wed, 29 Jan 2020 at 00:08, Leigh Griffin lgriffin@redhat.com wrote:
On Tue, Jan 28, 2020, 22:06 Iñaki Ucar iucar@fedoraproject.org wrote:
On Tue, 28 Jan 2020 at 20:58, Leigh Griffin lgriffin@redhat.com
wrote:
This thread is serving as a source of requirements (although it has
meandered dramatically away from that)
When I first read the post, my thought was: wow, what a convoluted and abstruse way of saying "we want to abandon Pagure". Probably this wasn't your intent, but that's what I got. And given the reactions, other people too.
The linked blog to the ODF is very explicit that Pagure is one of the 3
forge options we are considering. I can't stress enough that it's a viable choice and ultimately what we opt for will come down to an analysis driven by the requirements gathered. I'm unsure how the blog has been interpreted any other way but hopefully this clears it up.
The ODF is very explicit in the problem statement, and it specifically and clearly says that:
- Pagure does not align with CPE.
- CPE is not gonna commit a development team to Pagure.
- The feature gap is big and growing, and basically Pagure is gonna
die because of this (and the document goes on saying that you're not trying to solve the feature gap).
Then the ODF lists Pagure as a solution. How am I supposed to interpret the above?
That the current situation is not ideal and before making any decisions it is better to know exactly what are the use cases. It makes sense to keep Pagure as a solution since we already know that it is matching most of Fedora's needs, but Pagure has a few down side too and the main one is that we have to develop and maintain it. So while the current situation works, it is not great. We might just find out that the other options are actually worst, or not. To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Also there are many possibilities, for example a group of people could step up and take over the maintenance of Pagure so that CPE would just run the instances, just like it is done with Koji. Or another distro, project could be willing to use and contribute to Pagure so that we would share the development and maintenance effort. It is not forbidden to imagine such possibilities :-)
If you (and others) elaborate on how you use Pagure (and other forges)
and what you value from your day to day usage, we will take that on board and use it to drive our decision making.
Asking for requirements for a *forge* is pointless. A forge doesn't have requirements. What you do with a forge has requirements.
As
others have already pointed out, Pagure is being used at the very least for 3 distinct use cases: to maintain rpm packages, to maintain upstream projects, and as an issue tracker. And they all have distinct requirements. Only that, as it happens, Pagure has grown to cover their necessities with more or less success, which doesn't necessarily mean that a forge is the best solution for all of them (as, again, others have pointed out already). But the ODF only lists forges as solutions.
So solutions for what? What are we talking about here? Requirements for src.fp.org? Requirements for things that are in pagure.io? All? Other?
My understanding is that we are looking at all use cases.
Iñaki _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
Regards,
On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
So let's revert the question, pagure does the what it needs to do and enough of it, otherwise we would not be using it.
What does pagure miss that other solutions have and that could be considered a requirement?
It could be that we don't **need** pagure to do anything more than what it does today, which moves the discussion off a technical ground.
Pierre
On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
So let's revert the question, pagure does the what it needs to do and enough of it, otherwise we would not be using it.
What does pagure miss that other solutions have and that could be considered a requirement?
It could be that we don't **need** pagure to do anything more than what it does today, which moves the discussion off a technical ground.
From a Dist-Git perspective, there is are two things I need: * per-branch ACLs * the ability to set bugzilla owners without granting commit access.
The first thing is because I get nervous granting people access to the Git project who want to build EPEL8 packages but clearly aren't good at managing Git workflows. I don't want them breaking my workflows with Fedora packages.
The second thing is because there are a number of packages that I maintain where upstream would like to be notified on bugzilla bugs but not otherwise be involved in packaging. Pagure itself has the ticket ACL for this, but I don't think this does anything in the Dist-Git setup.
From the Git forge perspective, the two big things I need are: * working self-service CI * workflow for self-service integration management per-user and per-repo
The first item is because the current Pagure CI with CentOS CI Jenkins is inexcusably bad. Jenkins is often unresponsive and broken, and configuring it requires manual intervention from the CentOS CI folks. Part of the reason we have Pagure was to move to more of a self-service model, and our default offering for CI services fails at that.
The second item is because there are an array of third party Free Software services out there that people should be able to use without having to talk to the Pagure admin to activate or enable. We do have webhooks for basic integrations, but doing authentication and authorization flows for generating app tokens and such is something we don't have today. Having this would allow far more sophisticated integrations than what we have now without always having to involve an admin over it.
On Wed, Jan 29, 2020 at 09:37:36AM -0500, Neal Gompa wrote:
On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
So let's revert the question, pagure does the what it needs to do and enough of it, otherwise we would not be using it.
What does pagure miss that other solutions have and that could be considered a requirement?
It could be that we don't **need** pagure to do anything more than what it does today, which moves the discussion off a technical ground.
From a Dist-Git perspective, there is are two things I need:
- per-branch ACLs
- the ability to set bugzilla owners without granting commit access.
The first thing is because I get nervous granting people access to the Git project who want to build EPEL8 packages but clearly aren't good at managing Git workflows. I don't want them breaking my workflows with Fedora packages.
The second thing is because there are a number of packages that I maintain where upstream would like to be notified on bugzilla bugs but not otherwise be involved in packaging. Pagure itself has the ticket ACL for this, but I don't think this does anything in the Dist-Git setup.
If they have a FAS account, they can go to dist-git: Watch issues on the package and they will be added to the CC list on bugzilla.
We are working on moving off the bugzilla overrides from the scm-requests git repo into pagure, like we did for the anitya integration.
Pierre
Per git ref acls is not a common thing on git forges. If this is a final requirement, we should start analyzing the viability of implementing and maintain it on the different forges (and it should be feasible with all of the rest of our strange ACLs on dist-git)
On pagure side, now that our downstream instances are not using gitolite, implementing them needs much less work that migrating all our toolings to other solutions.
2020(e)ko urtarrilaren 29(a) 15:37:36 (CET)-(e)an, Neal Gompa ngompa13@gmail.com-(e)k hau idatzi zuen:
On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured
git
forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
So let's revert the question, pagure does the what it needs to do and
enough of
it, otherwise we would not be using it.
What does pagure miss that other solutions have and that could be
considered a
requirement?
It could be that we don't **need** pagure to do anything more than
what it does
today, which moves the discussion off a technical ground.
From a Dist-Git perspective, there is are two things I need:
- per-branch ACLs
- the ability to set bugzilla owners without granting commit access.
The first thing is because I get nervous granting people access to the Git project who want to build EPEL8 packages but clearly aren't good at managing Git workflows. I don't want them breaking my workflows with Fedora packages.
The second thing is because there are a number of packages that I maintain where upstream would like to be notified on bugzilla bugs but not otherwise be involved in packaging. Pagure itself has the ticket ACL for this, but I don't think this does anything in the Dist-Git setup.
From the Git forge perspective, the two big things I need are:
- working self-service CI
- workflow for self-service integration management per-user and
per-repo
The first item is because the current Pagure CI with CentOS CI Jenkins is inexcusably bad. Jenkins is often unresponsive and broken, and configuring it requires manual intervention from the CentOS CI folks. Part of the reason we have Pagure was to move to more of a self-service model, and our default offering for CI services fails at that.
The second item is because there are an array of third party Free Software services out there that people should be able to use without having to talk to the Pagure admin to activate or enable. We do have webhooks for basic integrations, but doing authentication and authorization flows for generating app tokens and such is something we don't have today. Having this would allow far more sophisticated integrations than what we have now without always having to involve an admin over it.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
-- Julen Landa Alustiza jlanda@fedoraproject.org
On Wed, Jan 29, 2020 at 04:06:22PM +0100, Julen Landa Alustiza wrote:
Per git ref acls is not a common thing on git forges. If this is a final requirement, we should start analyzing the viability of implementing and maintain it on the different forges (and it should be feasible with all of the rest of our strange ACLs on dist-git)
On pagure side, now that our downstream instances are not using gitolite, implementing them needs much less work that migrating all our toolings to other solutions.
I believe, and Leigh correct me if I'm wrong, that this will be the next step in the analysis.
1/ gather all the requirement 2/ figure out which option have which requirement 3/ figure out if it is "cheaper" to fix feature A in option 2, or add feature B in option 3 or leave without feature C in option 1
Pierre
On Wed, Jan 29, 2020 at 3:30 PM Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jan 29, 2020 at 04:06:22PM +0100, Julen Landa Alustiza wrote:
Per git ref acls is not a common thing on git forges. If this is a
final
requirement, we should start analyzing the viability of implementing
and
maintain it on the different forges (and it should be feasible with
all of
the rest of our strange ACLs on dist-git)
On pagure side, now that our downstream instances are not using
gitolite,
implementing them needs much less work that migrating all our
toolings to
other solutions.
I believe, and Leigh correct me if I'm wrong, that this will be the next step in the analysis.
1/ gather all the requirement 2/ figure out which option have which requirement 3/ figure out if it is "cheaper" to fix feature A in option 2, or add feature B in option 3 or leave without feature C in option 1
Correct we will perform an analysis on the requirements Vs the offerings. It then becomes a cost benefit analysis to build out (or acquire) feature A at the cost of refactoring process B and so on. We will publish the wider requirements and the analysis to help support a transparent decision.
Pierre _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, Jan 29, 2020 at 10:07 AM Julen Landa Alustiza jlanda@fedoraproject.org wrote:
Per git ref acls is not a common thing on git forges. If this is a final requirement, we should start analyzing the viability of implementing and maintain it on the different forges (and it should be feasible with all of the rest of our strange ACLs on dist-git)
On pagure side, now that our downstream instances are not using gitolite, implementing them needs much less work that migrating all our toolings to other solutions.
It's usually called "branch protection" in GitHub and GitLab. The functionality varies a bit, but the feature exists.
* Neal Gompa:
On Wed, Jan 29, 2020 at 10:07 AM Julen Landa Alustiza jlanda@fedoraproject.org wrote:
Per git ref acls is not a common thing on git forges. If this is a final requirement, we should start analyzing the viability of implementing and maintain it on the different forges (and it should be feasible with all of the rest of our strange ACLs on dist-git)
On pagure side, now that our downstream instances are not using gitolite, implementing them needs much less work that migrating all our toolings to other solutions.
It's usually called "branch protection" in GitHub and GitLab. The functionality varies a bit, but the feature exists.
It's also sometimes enforced externally by bots which only perform merges if they are requested by authorized developers (and nobody updates refs directly under this model).
Thanks, Florian
On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza jlanda@fedoraproject.org wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
It depends on the use case, doing development work projects hosted on pagure.io is not great in my opinion. In particular working with pull requests.
In terms of issue trackers, it is missing the ability to visualize issues in a board for example. Again this my opinion and maybe these are maybe not *really* *really* needed.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
I personally don't think we can release Fedora without people across the project doing heroics and a crazy amount of hours which seems to have become a norm rather than an exception.
Regards, _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote:
On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza jlanda@fedoraproject.org wrote:
(snip) 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen: > To me that's the all point of this > process, let's put down what we *really* *really* need and then look at > the different options. > Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
It depends on the use case, doing development work projects hosted on pagure.io is not great in my opinion. In particular working with pull requests. In terms of issue trackers, it is missing the ability to visualize issues in a board for example. Again this my opinion and maybe these are maybe not *really* *really* needed.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
I personally don't think we can release Fedora without people across the project doing heroics and a crazy amount of hours which seems to have become a norm rather than an exception.Â
I don't think anyone can disagree with this, but this begs the question: are these heroics related to pagure? If not, I'm not sure what is the point you were trying to make for this thread.
Pierre
On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote:
On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza jlanda@fedoraproject.org wrote:
(snip) 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen: > To me that's the all point of this > process, let's put down what we *really* *really* need and then
look
at > the different options. > Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem.
Well,
imo we don't *really* *really* need to compete with them.
It depends on the use case, doing development work projects hosted on pagure.io is not great in my opinion. In particular working with
pull
requests. In terms of issue trackers, it is missing the ability to visualize
issues
in a board for example. Again this my opinion and maybe these are maybe not *really* *really* needed.
Actually we already have the features that we *really* *really*
need.
Otherwise we could not release fedora using pagure as we are using, could we? :)
I personally don't think we can release Fedora without people across
the
project doing heroics and a crazy amount of hours which seems to have become a norm rather than an exception.Â
I don't think anyone can disagree with this, but this begs the question: are
these heroics related to pagure?
If not, I'm not sure what is the point you were trying to make for this
thread.
My point is that we have to dedicate a team to work on Pagure, I would rather have these people working on improving the infrastructure so that we don't need these heroics to happen. If we don't put people to work on Pagure it will end up being another fedora-packages, badges or FAS and in couple years it will be too difficult to do anything with it. It is not only about Pagure, for example I would love to be able to replace Bodhi with something that we don't have to maintain but it is much more difficult to find an alternative to Bodhi than Pagure.
My general feeling is that an infrastructure team should avoid as much as possible to maintain large applications, the focus should be to develop the glue needed to for the different services to work together in the most efficient manner, to monitor the applications, the respond to outages.
Does that clarify my thoughts ?
Pierre _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, 29 Jan 2020 at 11:38, Clement Verna cverna@fedoraproject.org wrote:
On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon pingou@pingoured.fr wrote:
these heroics related to pagure?
If not, I'm not sure what is the point you were trying to make for this thread.
My point is that we have to dedicate a team to work on Pagure, I would rather have these people working on improving the infrastructure so that we don't need these heroics to happen. If we don't put people to work on Pagure it will end up being another fedora-packages, badges or FAS and in couple years it will be too difficult to do anything with it. It is not only about Pagure, for example I would love to be able to replace Bodhi with something that we don't have to maintain but it is much more difficult to find an alternative to Bodhi than Pagure.
We would instead need a dedicated team to work on integrating all our tools with some other dist-git. Either using the people who are already working on pagure, or some new set of people who have to be hired in with a background in how-ever Git*** works. There will still always be some group having to deal with how and what we do with our source code. All we are doing is changing it from something we have more control to direct to something we constantly adapt to its changes. In other words, the heroics just change because we have worked on a symptom for the cause of the heroics.. not the root cause of the heroics.
My general feeling is that an infrastructure team should avoid as much as possible to maintain large applications, the focus should be to develop the glue needed to for the different services to work together in the most efficient manner, to monitor the applications, the respond to outages.
The issue is that we are not going to see less work here and so there is not going to be less heroics. Some group is going to have to make tooling changes to make fedpkg, bodhi, koji, pdc, authentication etc etc work with Git*** and keep up with every API change that occurs over the years there. Some group is going to have to engineer new caching layers to deal with source code in XYZ area and builders in ABC area. Some group is going to have to add in all the documentation and rules for dealing with any outage/burp/authentication Git***.
This doesn't mean that work should not be done.. but do not try to sell it that it will drop the need for heroics and long hours. That needs different changes and have nothing to do whether we have our source code in Pagure or Gitlab. It has nothing to do with whether we use OBS or Koji. It has to do with things much more fundamental about what we are supposed to be doing, what we are supposed to not be doing, and how much we are supposed to do towards either set. Trying to lop off things one by one while we are adding in things 2x2 doesn't help.
On Wed, 29 Jan 2020 at 18:26, Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 29 Jan 2020 at 11:38, Clement Verna cverna@fedoraproject.org wrote:
On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon pingou@pingoured.fr
wrote:
these heroics related to pagure?
If not, I'm not sure what is the point you were trying to make for this
thread.
My point is that we have to dedicate a team to work on Pagure, I would
rather have these people working on improving the infrastructure so that we don't need these heroics to happen. If we don't put people to work on Pagure it will end up being another fedora-packages, badges or FAS and in couple years it will be too difficult to do anything with it. It is not only about Pagure, for example I would love to be able to replace Bodhi with something that we don't have to maintain but it is much more difficult to find an alternative to Bodhi than Pagure.
We would instead need a dedicated team to work on integrating all our tools with some other dist-git. Either using the people who are already working on pagure, or some new set of people who have to be hired in with a background in how-ever Git*** works. There will still always be some group having to deal with how and what we do with our source code. All we are doing is changing it from something we have more control to direct to something we constantly adapt to its changes. In other words, the heroics just change because we have worked on a symptom for the cause of the heroics.. not the root cause of the heroics.
I completely agree that changing solution would be a massive effort and I honestly don't know if it is worth it or not. In my opinion the root cause of the heroics is that we keep adding and building new things on top of foundation that is not stable. One of the reason for this foundation not been stable is that we have too much to do, so we cut corners (the famous quick fixes which becomes a permanent hack that everyone is scared to touch). We cannot win this battle without reducing the number of things we have to care for. Maybe I am too naive but for me the only way to reduce these heroics is first to reduce the number of applications we have, second take the time it takes to reduce the technical debt we have.
You have way more history and knowledge than me, so I am genuinely interested to know what are the root cause for you ? And what would it take to improve the situation ?
My general feeling is that an infrastructure team should avoid as much
as possible to maintain large applications, the focus should be to develop the glue needed to for the different services to work together in the most efficient manner, to monitor the applications, the respond to outages.
The issue is that we are not going to see less work here and so there is not going to be less heroics. Some group is going to have to make tooling changes to make fedpkg, bodhi, koji, pdc, authentication etc etc work with Git*** and keep up with every API change that occurs over the years there.
This assumes that Pagure will never break its API compatibility and that we will never have to update all the different tools in that case. For me the effort is the same here maybe even less for Git*** since we would most likely use an library wrapping the API which could deal with the backward compatibility.
Some group is going to have to engineer new caching layers to deal with source code in XYZ area and builders in ABC area. Some group is going to have to add in all the documentation and rules for dealing with any outage/burp/authentication Git***.
This doesn't mean that work should not be done.. but do not try to sell it that it will drop the need for heroics and long hours. That needs different changes and have nothing to do whether we have our source code in Pagure or Gitlab. It has nothing to do with whether we use OBS or Koji. It has to do with things much more fundamental about what we are supposed to be doing, what we are supposed to not be doing, and how much we are supposed to do towards either set. Trying to lop off things one by one while we are adding in things 2x2 doesn't help.
I agree that this will probably not make a huge difference, but I am an optimistic and I prefer to take one tiny step in one direction without knowing if it will make a difference rather than stay still waiting for selling to fall on my head. "When eating an elephant, take one bite at a time.” - Creighton Abrams
What are the different changes needed to avoid heroics ? What stops us from making these ?
-- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Dne 29. 01. 20 v 17:37 Clement Verna napsal(a):
On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon <pingou@pingoured.fr mailto:pingou@pingoured.fr> wrote:
On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote: > On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza > <jlanda@fedoraproject.org <mailto:jlanda@fedoraproject.org>> wrote: > > (snip) > > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen: > > To me that's the all point of this > > process, let's put down what we *really* *really* need and then look > at > > the different options. > > > > Do we *really* *really* need to compete with other full featured git > forges on features? The ODF says that this is one of the problem. Well, > imo we don't *really* *really* need to compete with them. > > It depends on the use case, doing development work projects hosted on > pagure.io <http://pagure.io> is not great in my opinion. In particular working with pull > requests. > In terms of issue trackers, it is missing the ability to visualize issues > in a board for example. > Again this my opinion and maybe these are maybe not *really* *really* > needed. > > Actually we already have the features that we *really* *really* need. > Otherwise we could not release fedora using pagure as we are using, > could we? :) > > I personally don't think we can release Fedora without people across the > project doing heroics and a crazy amount of hours which seems to have > become a norm rather than an exception. I don't think anyone can disagree with this, but this begs the question: are these heroics related to pagure? If not, I'm not sure what is the point you were trying to make for this thread.
My point is that we have to dedicate a team to work on Pagure, I would rather have these people working on improving the infrastructure so that we don't need these heroics to happen. If we don't put people to work on Pagure it will end up being another fedora-packages, badges or FAS and in couple years it will be too difficult to do anything with it. It is not only about Pagure, for example I would love to be able to replace Bodhi with something that we don't have to maintain but it is much more difficult to find an alternative to Bodhi
cough cough errata cough cough
Honestly, sometimes the disconnect between what is going on in Fedora and internally in Red Hat is intriguing.
Vít
than Pagure.
My general feeling is that an infrastructure team should avoid as much as possible to maintain large applications, the focus should be to develop the glue needed to for the different services to work together in the most efficient manner, to monitor the applications, the respond to outages.
Does that clarify my thoughts ?
Pierre _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-leave@lists.fedoraproject.org <mailto:devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
My point is that we have to dedicate a team to work on Pagure, I would rather have these people working on improving the infrastructure so that we don't need these heroics to happen. If we don't put people to work on Pagure it will end up being another fedora-packages, badges or FAS and in couple years it will be too difficult to do anything with it. It is not only about Pagure, for example I would love to be able to replace Bodhi with something that we don't have to maintain but it is much more difficult to find an alternative to Bodhi
cough cough errata cough cough
Honestly, sometimes the disconnect between what is going on in Fedora and internally in Red Hat is intriguing.
Do you really think the entire CPE team is blissfully unaware of Errata Tool's existence? I mean, is that really the scenario that makes the most sense in your head, as opposed to 'they have already considered it but don't find it a suitable replacement'?
You might ask 'why not errata tool?', but it seems pretty silly to just assume that they don't even know it exists, or something.
Dne 30. 01. 20 v 18:45 Adam Williamson napsal(a):
On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
My point is that we have to dedicate a team to work on Pagure, I would rather have these people working on improving the infrastructure so that we don't need these heroics to happen. If we don't put people to work on Pagure it will end up being another fedora-packages, badges or FAS and in couple years it will be too difficult to do anything with it. It is not only about Pagure, for example I would love to be able to replace Bodhi with something that we don't have to maintain but it is much more difficult to find an alternative to Bodhi
cough cough errata cough cough
Honestly, sometimes the disconnect between what is going on in Fedora and internally in Red Hat is intriguing.
Do you really think the entire CPE team is blissfully unaware of Errata Tool's existence?
I have never say that. I merely pointed out that there is disconnect between what Fedora does and what Red Hat does internally. I see a lot of duplication and I see a lot of lost opportunities. Bodhi vs Errata is just one example.
The other example is that Red Hat adopted Pagure internally, so if CPE decides to let Pagure go, that decision will impact Red Hat as well and it somehow seems to be completely fine by everybody. If there was one person fulltime coordinating Pagure upstream, we would save a lot of time which was already wasted here by this discussion and we would save all the costs of possible future migration where there will be suddenly helping whole teams just to let later the whole migration project in unfinished state and slowly dying.
And the another thread about Java packaging is of similar nature (not going to details here).
Vít
I mean, is that really the scenario that makes the most sense in your head, as opposed to 'they have already considered it but don't find it a suitable replacement'?
You might ask 'why not errata tool?', but it seems pretty silly to just assume that they don't even know it exists, or something.
On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
cough cough errata cough cough
Honestly, sometimes the disconnect between what is going on in Fedora and internally in Red Hat is intriguing.
I did think about Errata tool* a bit back when I worked on Bodhi. I like the idea of sharing code on one hand, but on the other hand it is pretty oriented towards workflows that are designed for a product release cycle. Bodhi is designed around community feedback (and now CI feedback).
It could be interesting to hold a chat with the Errata tool developers to see if there is interest in sharing tooling, but it may be a lot of effort to make Errata tool flexible enough to support two pretty different workflows. I'd be willing to have that conversation; I could be wrong.
* Red Hat uses a project called Errata tool to publish updates.
On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
cough cough errata cough cough
Honestly, sometimes the disconnect between what is going on in Fedora and internally in Red Hat is intriguing.
I did think about Errata tool* a bit back when I worked on Bodhi. I like the idea of sharing code on one hand, but on the other hand it is pretty oriented towards workflows that are designed for a product release cycle. Bodhi is designed around community feedback (and now CI feedback).
It could be interesting to hold a chat with the Errata tool developers to see if there is interest in sharing tooling, but it may be a lot of effort to make Errata tool flexible enough to support two pretty different workflows. I'd be willing to have that conversation; I could be wrong.
Why not go the other way? Bodhi could be extended to support the internal product workflows.
Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):
On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
cough cough errata cough cough
Honestly, sometimes the disconnect between what is going on in Fedora and internally in Red Hat is intriguing.
I did think about Errata tool* a bit back when I worked on Bodhi.
Thank you for that.
I like the idea of sharing code on one hand, but on the other hand it is pretty oriented towards workflows that are designed for a product release cycle. Bodhi is designed around community feedback (and now CI feedback).
It could be interesting to hold a chat with the Errata tool developers to see if there is interest in sharing tooling, but it may be a lot of effort to make Errata tool flexible enough to support two pretty different workflows. I'd be willing to have that conversation; I could be wrong.
Of course, there is a lot of business logic specific to Red Hat projects backed into Errata, but ultimately, it does not help to anybody if Fedora release process is using different tools then Red Hat internally. What Red Hat does internally should be just extension to what Fedora does. The processes used internally should be proven in Fedora first.
Why not go the other way? Bodhi could be extended to support the internal product workflows.
In ideal world, Bodhi would be upstream project to Errata or possibly Bodhi could be the open core of Errata. It does not really matter.
Vít
On 31/01/2020 12:11, Vít Ondruch wrote:
Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):
On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
cough cough errata cough cough
Honestly, sometimes the disconnect between what is going on in Fedora and internally in Red Hat is intriguing.
I did think about Errata tool* a bit back when I worked on Bodhi.
Thank you for that.
I like the idea of sharing code on one hand, but on the other hand it is pretty oriented towards workflows that are designed for a product release cycle. Bodhi is designed around community feedback (and now CI feedback).
It could be interesting to hold a chat with the Errata tool developers to see if there is interest in sharing tooling, but it may be a lot of effort to make Errata tool flexible enough to support two pretty different workflows. I'd be willing to have that conversation; I could be wrong.
Of course, there is a lot of business logic specific to Red Hat projects backed into Errata, but ultimately, it does not help to anybody if Fedora release process is using different tools then Red Hat internally. What Red Hat does internally should be just extension to what Fedora does. The processes used internally should be proven in Fedora first.
This is a very nice vision that will potentially make life of Red Hat and Fedora much easier. I'm not that long in the Fedora project to know, why Fedora and Red Hat internal tools are that different, but this idea doesn't sound that bad. Few questions first: Are those internal tools open source? Could we as Fedora community use them? Is there any legal issue? Is this tool in good shape?
And talking about the git forge, what is Red Hat using internally as git forge? And then the above questions applies.
Michal
Why not go the other way? Bodhi could be extended to support the internal product workflows.
In ideal world, Bodhi would be upstream project to Errata or possibly Bodhi could be the open core of Errata. It does not really matter.
Vít
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Fri, Jan 31, 2020 at 10:23 AM Michal Konecny mkonecny@redhat.com wrote:
On 31/01/2020 12:11, Vít Ondruch wrote:
Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):
On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
cough cough errata cough cough
Honestly, sometimes the disconnect between what is going on in Fedora and internally in Red Hat is intriguing.
I did think about Errata tool* a bit back when I worked on Bodhi.
Thank you for that.
I like the idea of sharing code on one hand, but on the other hand it is pretty oriented towards workflows that are designed for a product release cycle. Bodhi is designed around community feedback (and now CI feedback).
It could be interesting to hold a chat with the Errata tool developers to see if there is interest in sharing tooling, but it may be a lot of effort to make Errata tool flexible enough to support two pretty different workflows. I'd be willing to have that conversation; I could be wrong.
Of course, there is a lot of business logic specific to Red Hat projects backed into Errata, but ultimately, it does not help to anybody if Fedora release process is using different tools then Red Hat internally. What Red Hat does internally should be just extension to what Fedora does. The processes used internally should be proven in Fedora first.
This is a very nice vision that will potentially make life of Red Hat and Fedora much easier. I'm not that long in the Fedora project to know, why Fedora and Red Hat internal tools are that different, but this idea doesn't sound that bad. Few questions first: Are those internal tools open source? Could we as Fedora community use them? Is there any legal issue? Is this tool in good shape?
And talking about the git forge, what is Red Hat using internally as git forge? And then the above questions applies.
It was mentioned in a different part of this thread that Red Hat is using pagure internally.
Neal Gompa ngompa13@gmail.com writes:
Michal Konecny mkonecny@redhat.com wrote:
Vít Ondruch wrote:
Neal Gompa napsal(a):
Randy Barlow bowlofeggs@fedoraproject.org wrote:
Vít Ondruch wrote:
cough cough errata cough cough
Honestly, sometimes the disconnect between what is going on in Fedora and internally in Red Hat is intriguing.
I like the idea of sharing code on one hand, but on the other hand it is pretty oriented towards workflows that are designed for a product release cycle. Bodhi is designed around community feedback (and now CI feedback).
It could be interesting to hold a chat with the Errata tool developers to see if there is interest in sharing tooling, but it may be a lot of effort to make Errata tool flexible enough to support two pretty different workflows. I'd be willing to have that conversation; I could be wrong.
Of course, there is a lot of business logic specific to Red Hat projects backed into Errata, but ultimately, it does not help to anybody if Fedora release process is using different tools then Red Hat internally. What Red Hat does internally should be just extension to what Fedora does. The processes used internally should be proven in Fedora first.
This is a very nice vision that will potentially make life of Red Hat and Fedora much easier. I'm not that long in the Fedora project to know, why Fedora and Red Hat internal tools are that different, but this idea doesn't sound that bad. Few questions first: Are those internal tools open source? Could we as Fedora community use them? Is there any legal issue? Is this tool in good shape?
And talking about the git forge, what is Red Hat using internally as git forge? And then the above questions applies.
It was mentioned in a different part of this thread that Red Hat is using pagure internally.
Using, not standardized on. It depends on the team.
Thanks, --Robbie
On Fri, 2020-01-31 at 10:35 -0500, Neal Gompa wrote:
And talking about the git forge, what is Red Hat using internally as git forge? And then the above questions applies.
It was mentioned in a different part of this thread that Red Hat is using pagure internally.
Well, it's not that simple.
RH uses Pagure *for the internal equivalent of dist-git*. But it is, of course, not the only git forge RH uses. (If there's one thing you can bank on with RH, it's that there will be at least three tools being used for any given job in different bits of the company). I'm aware of RH teams using Github, Gitlab (various instances) and Gerrit. There are probably more.
On Fri, Jan 31, 2020 at 12:11:08PM +0100, Vít Ondruch wrote:
Of course, there is a lot of business logic specific to Red Hat projects backed into Errata, but ultimately, it does not help to anybody if Fedora release process is using different tools then Red Hat internally. What Red Hat does internally should be just extension to what Fedora does. The processes used internally should be proven in Fedora first.
Welcome to our lives! If it was mathematically possible to go above 100% that's how much agreement you would have from us.
Pierre
Hi
On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
Welcome to our lives! If it was mathematically possible to go above 100% that's how much agreement you would have from us.
If Red Hat is using Pagure internally, it is really odd to discuss replacing Pagure with something else. The only viable replacement is Gitlab which is a open code project written in a language that isn't a strong fit for Fedora. Red Hat should be assigning more resources (development & infrastructure) to add the features needed to extend Pagure going forward and reduce the burden on the CPE team. Has CPE leadership considered talking internally about that?
Rahul
On Fri, Jan 31, 2020 at 3:53 PM Rahul Sundaram metherid@gmail.com wrote:
Hi
On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
Welcome to our lives! If it was mathematically possible to go above 100% that's how much agreement you would have from us.
If Red Hat is using Pagure internally, it is really odd to discuss replacing Pagure with something else. The only viable replacement is Gitlab which is a open code project written in a language that isn't a strong fit for Fedora. Red Hat should be assigning more resources (development & infrastructure) to add the features needed to extend Pagure going forward and reduce the burden on the CPE team. Has CPE leadership considered talking internally about that?
This ODF is being shared internally to get requirements as well.
Rahul _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Rahul Sundaram metherid@gmail.com writes:
Hi
On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
Welcome to our lives! If it was mathematically possible to go above 100% that's how much agreement you would have from us.
If Red Hat is using Pagure internally, it is really odd to discuss replacing Pagure with something else. The only viable replacement is Gitlab which is a open code project written in a language that isn't a strong fit for Fedora. Red Hat should be assigning more resources (development & infrastructure) to add the features needed to extend Pagure going forward and reduce the burden on the CPE team. Has CPE leadership considered talking internally about that?
I have to second this: why are we even *having* this discussion, when Pagure is used internally at RedHat and thus RedHat will require some form of maintenance anyway? Why is then the RedHat CPE team pushing to move away from Pagure, especially to Gitlab? Which albeit being a great platform, is written in Ruby and there's a lot less Ruby devs in the Fedora community than Python devs.
Imho it would be a good idea that Pagure is not retired and is developed further, as it is currently one of its kind in many aspects and can be fully tweaked and customized to our needs without being huge in the way gitlab is.
Cheers,
Dan
Dan Čermák dan.cermak@cgc-instruments.com writes:
Rahul Sundaram metherid@gmail.com writes:
Hi
On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
Welcome to our lives! If it was mathematically possible to go above 100% that's how much agreement you would have from us.
If Red Hat is using Pagure internally, it is really odd to discuss replacing Pagure with something else. The only viable replacement is Gitlab which is a open code project written in a language that isn't a strong fit for Fedora. Red Hat should be assigning more resources (development & infrastructure) to add the features needed to extend Pagure going forward and reduce the burden on the CPE team. Has CPE leadership considered talking internally about that?
I have to second this: why are we even *having* this discussion, when Pagure is used internally at RedHat and thus RedHat will require some form of maintenance anyway? Why is then the RedHat CPE team pushing to move away from Pagure, especially to Gitlab? Which albeit being a great platform, is written in Ruby and there's a lot less Ruby devs in the Fedora community than Python devs.
I have to apologize, this was far too harsh. What I wanted to say is the following: wouldn't it be mutually beneficial for RedHat, Fedora and specifically the CPE Team too, that someone¹ takes over maintenance of Pagure since it's used by us all and there appear to be enough people that want to continue using it?
Cheers,
Dan
¹: Yeah, I know that this is actually the tricky part to find this someone…
On Sat, Feb 1, 2020 at 10:16 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Dan Čermák dan.cermak@cgc-instruments.com writes:
Rahul Sundaram metherid@gmail.com writes:
Hi
On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
Welcome to our lives! If it was mathematically possible to go above 100% that's how much agreement you would have from us.
If Red Hat is using Pagure internally, it is really odd to discuss replacing Pagure with something else.
The usage is not uniform and not being 100% supported / hosted by the CPE team. The rationale behind a requirements gathering process is clearly outlined in the blog post and we have never said we are replacing Pagure, we may opt to drive resourcing and time into it as one of the viable paths forward.
The only viable replacement is
Gitlab which is a open code project written in a language that isn't a strong fit for Fedora.
There are 3 viable forges under consideration.
Red Hat should be assigning more resources
(development & infrastructure) to add the features needed to extend
Pagure
going forward and reduce the burden on the CPE team. Has CPE
leadership
considered talking internally about that?
This is a key factor in the requirements exercise to know if Pagure is the optimal choice and to know how much to build and at what cost Vs other initiatives we could be focusing on.
I have to second this: why are we even *having* this discussion, when Pagure is used internally at RedHat and thus RedHat will require some form of maintenance anyway? Why is then the RedHat CPE team pushing to move away from Pagure, especially to Gitlab?
We never stated we are moving to Gitlab. We stated why the CPE team are considering this exercise, if you have questions I'm happy to try clarify them but I urge you to re-read the problem statement and approach in the blog post.
Which albeit being a great
platform, is written in Ruby and there's a lot less Ruby devs in the Fedora community than Python devs.
I have to apologize, this was far too harsh.
It seems to be an emotive topic but thank you for apologising! I still wanted to address the above though in case there was a concern.
What I wanted to say is the following: wouldn't it be mutually beneficial for RedHat, Fedora and specifically the CPE Team too, that someone¹ takes over maintenance of Pagure since it's used by us all and there appear to be enough people that want to continue using it?
It possibly might be, when the analysis is complete we can check that out. It would be premature and based on no real data to form that decision right now, hence the requirements exercise. Whatever solution is chosen will hopefully satisfy the requirements put forward by Fedora, CentOS, Red Hat and the CPE team. We might not hit all of them perfectly, there might be some trade offs in functionality but we hope to transparently show what those trade offs would be and why we take a certain path.
Cheers,
Dan
¹: Yeah, I know that this is actually the tricky part to find this someone… _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Sat, Feb 01, 2020 at 11:15:43AM +0100, Dan Čermák wrote:
Dan Čermák dan.cermak@cgc-instruments.com writes:
Rahul Sundaram metherid@gmail.com writes:
Hi
On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
Welcome to our lives! If it was mathematically possible to go above 100% that's how much agreement you would have from us.
If Red Hat is using Pagure internally, it is really odd to discuss replacing Pagure with something else. The only viable replacement is Gitlab which is a open code project written in a language that isn't a strong fit for Fedora. Red Hat should be assigning more resources (development & infrastructure) to add the features needed to extend Pagure going forward and reduce the burden on the CPE team. Has CPE leadership considered talking internally about that?
I have to second this: why are we even *having* this discussion, when Pagure is used internally at RedHat and thus RedHat will require some form of maintenance anyway? Why is then the RedHat CPE team pushing to move away from Pagure, especially to Gitlab? Which albeit being a great platform, is written in Ruby and there's a lot less Ruby devs in the Fedora community than Python devs.
I have to apologize, this was far too harsh. What I wanted to say is the following: wouldn't it be mutually beneficial for RedHat, Fedora and specifically the CPE Team too, that someone¹ takes over maintenance of Pagure since it's used by us all and there appear to be enough people that want to continue using it?
Thats one option sure, but also, if Fedora changes to something, Red Hat could also choose to change, keeping alignment with Fedora too.
I think we want to be aware of the sunk cost falicy here.
kevin
2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna cverna@fedoraproject.org-(e)k hau idatzi zuen:
On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza jlanda@fedoraproject.org wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then
look at
the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem.
Well,
imo we don't *really* *really* need to compete with them.
It depends on the use case, doing development work projects hosted on pagure.io is not great in my opinion. In particular working with pull requests.
I don't have excesive problems with pagure on PR workflows. Right now for me centos-ci is a much bigger problem for PR workflows on pagure.io than pagure itself for example.
In terms of issue trackers, it is missing the ability to visualize issues in a board for example. Again this my opinion and maybe these are maybe not *really* *really* needed.
Is a great forge the beste solution for this? Or are there other solutions for issue tracking/kanban/boards etc that could better suit this use cases?
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
I personally don't think we can release Fedora without people across the project doing heroics and a crazy amount of hours which seems to have become a norm rather than an exception.
+1. But is this a git forge problem?
We are again on the same place: we have different use cases hosted on pagure. Some of them could need a big effort on pagure side to compete with other options (on technical features), some others could benefit of migrating to other solutions, and some others could not have a better solution than our own custom one
-- Julen Landa Alustiza jlanda@fedoraproject.org
On Wed, 2020-01-29 at 16:17 +0100, Julen Landa Alustiza wrote:
2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna cverna@fedoraproject.org-(e)k hau idatzi zuen:
On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza jlanda@fedoraproject.org wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then
look at
the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem.
Well,
imo we don't *really* *really* need to compete with them.
It depends on the use case, doing development work projects hosted on pagure.io is not great in my opinion. In particular working with pull requests.
I don't have excesive problems with pagure on PR workflows. Right now for me centos-ci is a much bigger problem for PR workflows on pagure.io than pagure itself for example.
So, there was an interesting talk at Devconf this year:
https://devconfcz2020a.sched.com/event/YOtV/cicd-for-fedora-packaging-with-z...
summary: you can use Zuul as CI on Pagure. Both src.fp.o and pagure.io. I set it up for a project with some help from Tristan Cacqueray over the last couple of days, to try it out. It works, and it wasn't too hard:
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/140
that PR does a lot more than just set up the Zuul CI, but the point is that it works, see the last couple of 'success'es. The failures were teething troubles getting the CI setup right, but it was nothing too major (mostly boiled down to the default environment being CentOS 7, and that distro having a very old tox that doesn't have 'py37' and 'py38' as standard environments - we just had to tweak the config to run the tests in a Fedora 31 environment instead).
The actual work to set up the CI was not too hard: send a pull request to a special repo to 'enable' things:
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/140
and then add just a couple of little files to the repo:
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/5b518d107d62e0fa9... https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/05cfd0aff616e0216...
Obviously don't know if it's more reliable than CentOS CI yet as I only just turned it on, but...I wouldn't bet against it :P
On Wed, 29 Jan 2020 at 16:18, Julen Landa Alustiza jlanda@fedoraproject.org wrote:
2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna < cverna@fedoraproject.org>-(e)k hau idatzi zuen:
On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza jlanda@fedoraproject.org wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then
look at
the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem.
Well,
imo we don't *really* *really* need to compete with them.
It depends on the use case, doing development work projects hosted on pagure.io is not great in my opinion. In particular working with pull requests.
I don't have excesive problems with pagure on PR workflows. Right now for me centos-ci is a much bigger problem for PR workflows on pagure.io than pagure itself for example.
Things that I would in my opinion improve Pagure PRs :
* In the PR diff should start from the correct line number, not always 1. ( https://pagure.io/pagure/issue/724) * Every time a branch is forced pushed you loose the comments from the diff view. (somewhat related to https://pagure.io/pagure/issue/751) * It should be possible to display a few lines of code before or after the diff to help having more context when making the review
Things that would be really nice to have * Have a way to suggest changes directly while reviewing PRs
Some unrelated to PRs improvement:
* Being able to rename, move projects * Being able to move a ticket between projects ( https://pagure.io/pagure/issue/737) * Full Text search projects, users, groups * Code search (https://pagure.io/pagure/issue/539) * Support GPG signing commit (https://pagure.io/pagure/issue/751) * Be able to select which event you want to send on the webhook, ie everything or nothing
A lot of these a not necessary things we *really* *really* need to have, but they would make using Pagure much better in my opinion.
In terms of issue trackers, it is missing the ability to visualize issues in a board for example. Again this my opinion and maybe these are maybe not *really* *really* needed.
Is a great forge the beste solution for this? Or are there other solutions for issue tracking/kanban/boards etc that could better suit this use cases?
Possibly but having the feature available at least gives you one more option.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
I personally don't think we can release Fedora without people across the project doing heroics and a crazy amount of hours which seems to have become a norm rather than an exception.
+1. But is this a git forge problem?
We are again on the same place: we have different use cases hosted on pagure. Some of them could need a big effort on pagure side to compete with other options (on technical features), some others could benefit of migrating to other solutions, and some others could not have a better solution than our own custom one
-- Julen Landa Alustiza jlanda@fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
20/1/29 18:19(e)an, Clement Verna igorleak idatzi zuen:
Things that I would in my opinion improve Pagure PRs :
- In the PR diff should start from the correct line number, not always
- Every time a branch is forced pushed you loose the comments from the
diff view. (somewhat related to https://pagure.io/pagure/issue/751)
- It should be possible to display a few lines of code before or after
the diff to help having more context when making the review
Things that would be really nice to have
- Have a way to suggest changes directly while reviewing PRs
Some unrelated to PRs improvement:
- Being able to rename, move projects
- Being able to move a ticket between projects
(https://pagure.io/pagure/issue/737)
- Full Text search projects, users, groups
- Code search (https://pagure.io/pagure/issue/539)
- Support GPG signing commit (https://pagure.io/pagure/issue/751)
- Be able to select which event you want to send on the webhook, ie
everything or nothing
A lot of these a not necessary things we *really* *really* need to have, but they would make using Pagure much better in my opinion.
Yeah, I agree, pagure needs a better code reviewing UI
On Wed, 2020-01-29 at 15:56 +0100, Clement Verna wrote:
On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza jlanda@fedoraproject.org wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
It depends on the use case, doing development work projects hosted on pagure.io is not great in my opinion. In particular working with pull requests.
In terms of issue trackers, it is missing the ability to visualize issues in a board for example. Again this my opinion and maybe these are maybe not *really* *really* needed.
I think it depends on the size and scope of your project a bit. I do find Pagure.io a pretty good host of the projects I have there, as they're fairly small. But then, an open source (non-enterprise edition) Gitlab instance would work fine for them too.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
I personally don't think we can release Fedora without people across the project doing heroics and a crazy amount of hours which seems to have become a norm rather than an exception.
When that happens it doesn't normally involve Pagure much, though. And I don't think even an amazing git forge would actually go a long way to solving the main issues there.
On Wed, 29 Jan 2020 at 16:56, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2020-01-29 at 15:56 +0100, Clement Verna wrote:
On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza <
jlanda@fedoraproject.org>
wrote:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then
look at
the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
It depends on the use case, doing development work projects hosted on pagure.io is not great in my opinion. In particular working with pull requests.
In terms of issue trackers, it is missing the ability to visualize issues in a board for example. Again this my opinion and maybe these are maybe not *really* *really* needed.
I think it depends on the size and scope of your project a bit. I do find Pagure.io a pretty good host of the projects I have there, as they're fairly small. But then, an open source (non-enterprise edition) Gitlab instance would work fine for them too.
Yes I agree with you, Pagure does a good job with small size project. It is also easy deploy and self host. And as I mentioned earlier in this thread my main real complain with Pagure is that we have to invest time to develop it and maintain it. I would be very happy to use it, if it was developed and maintained by someone else :-)
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
I personally don't think we can release Fedora without people across the project doing heroics and a crazy amount of hours which seems to have become a norm rather than an exception.
When that happens it doesn't normally involve Pagure much, though. And I don't think even an amazing git forge would actually go a long way to solving the main issues there.
It is not about the git forge itself it is about how and on what we spend the little resources we have. If as a community we are all happy to invest this time on developing and maintaining a git forge that's all fine with me. But as said earlier we have not invested much in Pagure for more than a year, that allowed us to put a lot of effort and focus on Bodhi to add support for rawhide including people being able to use side-tag in rawhide now. Should we continue like that and feature freeze Pagure ? or do we invest in Pagure instead of other work that need to be done ? Do we switch to another forge, knowing that it will require a LOT of initial effort to migrate ? I honestly don't know what is the correct answer :-)
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Julen Landa Alustiza jlanda@fedoraproject.org writes:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
We don't have per-branch default assignees, which is actually a pretty big problem in Fedora (especially with EPEL packages).
Thanks, --Robbie
On Wed, Jan 29, 2020 at 12:52:53PM -0500, Robbie Harwood wrote:
Julen Landa Alustiza jlanda@fedoraproject.org writes:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
We don't have per-branch default assignees, which is actually a pretty big problem in Fedora (especially with EPEL packages).
I'd counter-argue that we don't need one considering bugzilla doesn't support a per-version assignee. So we need an assignee for Fedora and one for Fedora EPEL, going the level lower (F31, F30, F29, epel8, epel7...) does not bring anything since we wouldn't be able to sync this to bugzilla.
And the Fedora vs Fedora EPEL overrides/assignee is being worked on so we can move it off fedscm-requests where it is today to src.fp.o.
Pierre
Dne 29. 01. 20 v 23:22 Pierre-Yves Chibon napsal(a):
On Wed, Jan 29, 2020 at 12:52:53PM -0500, Robbie Harwood wrote:
Julen Landa Alustiza jlanda@fedoraproject.org writes:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
We don't have per-branch default assignees, which is actually a pretty big problem in Fedora (especially with EPEL packages).
I'd counter-argue that we don't need one considering bugzilla doesn't support a per-version assignee. So we need an assignee for Fedora and one for Fedora EPEL, going the level lower (F31, F30, F29, epel8, epel7...) does not bring anything since we wouldn't be able to sync this to bugzilla.
I mostly agree. However, retired packages, such as [1], should then be owned just by orphan after the years since their retirement. This used to work during PkgDB days, it does not work anymore.
Vít
[1] https://src.fedoraproject.org/rpms/rubygem-sqlite3-ruby
And the Fedora vs Fedora EPEL overrides/assignee is being worked on so we can move it off fedscm-requests where it is today to src.fp.o.
Pierre
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Thu, Jan 30, 2020 at 10:40:05AM +0100, Vít Ondruch wrote:
Dne 29. 01. 20 v 23:22 Pierre-Yves Chibon napsal(a):
On Wed, Jan 29, 2020 at 12:52:53PM -0500, Robbie Harwood wrote:
Julen Landa Alustiza [1]jlanda@fedoraproject.org writes:
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options.
Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them.
Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :)
We don't have per-branch default assignees, which is actually a pretty big problem in Fedora (especially with EPEL packages).
I'd counter-argue that we don't need one considering bugzilla doesn't support a per-version assignee. So we need an assignee for Fedora and one for Fedora EPEL, going the level lower (F31, F30, F29, epel8, epel7...) does not bring anything since we wouldn't be able to sync this to bugzilla.
I mostly agree. However, retired packages, such as [1], should then be owned just by orphan after the years since their retirement. This used to work during PkgDB days, it does not work anymore.
I'm traveling right now so I can't track it down, but the issue for this is that basically the script that syncs status from src.fp.o to bugzilla has been broken for a while. We fixed this just last december and started running the new script early this year, so this should be fixed now. If the issue persist, it's likely something that is going on with someone's FAS email not mapping to a bugzilla account. Having access to the logs of the cron job (runs twice a day), I can easily check this when I get back to a more stable working station.
Could you open an infra ticket to track this, so we don't forget about it?
Thanks, Pierre
On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar iucar@fedoraproject.org wrote:
On Wed, 29 Jan 2020 at 00:08, Leigh Griffin lgriffin@redhat.com wrote:
On Tue, Jan 28, 2020, 22:06 Iñaki Ucar iucar@fedoraproject.org wrote:
On Tue, 28 Jan 2020 at 20:58, Leigh Griffin lgriffin@redhat.com
wrote:
This thread is serving as a source of requirements (although it has
meandered dramatically away from that)
When I first read the post, my thought was: wow, what a convoluted and abstruse way of saying "we want to abandon Pagure". Probably this wasn't your intent, but that's what I got. And given the reactions, other people too.
The linked blog to the ODF is very explicit that Pagure is one of the 3
forge options we are considering. I can't stress enough that it's a viable choice and ultimately what we opt for will come down to an analysis driven by the requirements gathered. I'm unsure how the blog has been interpreted any other way but hopefully this clears it up.
The ODF is very explicit in the problem statement, and it specifically and clearly says that:
- Pagure does not align with CPE.
Correct and it's why we said this line, which you might have missed: "While we can make exceptions to the mission statement, we first need to know why we should consider a specific exception."
- CPE is not gonna commit a development team to Pagure.
CPE has not committed a team to it in over a year, we do state that as a driving factor to why we want to engage in this conversation but your assumption here is based on a particular outcome that sees Pagure not chosen. If Pagure is chosen, we will commit a team. We are very clear on that.
- The feature gap is big and growing, and basically Pagure is gonna
die because of this (and the document goes on saying that you're not trying to solve the feature gap).
Pagure is a standalone community project. Our choice is not killing Pagure and irrespective of the decision we make I personally hope it stays strong and grows. Stating the feature gap is big and growing is factual, with no committed team we are behind on it.
Then the ODF lists Pagure as a solution. How am I supposed to interpret the above?
This is why we are opening it to be very explicit that for the past year we have not focused on Pagure but we now need to make a decision going forward. If Pagure is the choice we staff it accordingly and de-priortise other initiatives and include it within our scope going forward. That is why Pagure is listed as a choice and it is why the ODF is laid out like that.
If you (and others) elaborate on how you use Pagure (and other forges)
and what you value from your day to day usage, we will take that on board and use it to drive our decision making.
Asking for requirements for a *forge* is pointless. A forge doesn't have requirements. What you do with a forge has requirements.
Tell me what you do and how you interact with a forge? That's the point of this exercise.
As others have already pointed out, Pagure is being used at the very least for 3 distinct use cases: to maintain rpm packages, to maintain upstream projects, and as an issue tracker. And they all have distinct requirements.
And we wish to hear all 3 as ultimately CPE become the owner of the solution that satisfies those requirements.
Only that, as it happens, Pagure has grown to cover their necessities with more or less success, which doesn't necessarily mean that a forge is the best solution for all of them (as, again, others have pointed out already). But the ODF only lists forges as solutions.
And if the requirements are stated we can have an open conversation about what does suit it. I get that things have organically grown around a forge that may / may not be the best fit for it now, lets examine that as a conversation when we know how people are using it. This topic is focused on what git forge the CPE team will choose based on requirements gathered but if there is a means to address a requirement gap by another tool that is not a forge, then that's a really good outcome of the conversation.
So solutions for what? What are we talking about here? Requirements for src.fp.org? Requirements for things that are in pagure.io? All? Other?
Iñaki _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, 29 Jan 2020 at 16:23, Leigh Griffin lgriffin@redhat.com wrote:
On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar iucar@fedoraproject.org wrote:
On Wed, 29 Jan 2020 at 00:08, Leigh Griffin lgriffin@redhat.com wrote:
On Tue, Jan 28, 2020, 22:06 Iñaki Ucar iucar@fedoraproject.org wrote:
On Tue, 28 Jan 2020 at 20:58, Leigh Griffin lgriffin@redhat.com wrote:
This thread is serving as a source of requirements (although it has meandered dramatically away from that)
When I first read the post, my thought was: wow, what a convoluted and abstruse way of saying "we want to abandon Pagure". Probably this wasn't your intent, but that's what I got. And given the reactions, other people too.
The linked blog to the ODF is very explicit that Pagure is one of the 3 forge options we are considering. I can't stress enough that it's a viable choice and ultimately what we opt for will come down to an analysis driven by the requirements gathered. I'm unsure how the blog has been interpreted any other way but hopefully this clears it up.
The ODF is very explicit in the problem statement, and it specifically and clearly says that:
- Pagure does not align with CPE.
Correct and it's why we said this line, which you might have missed: "While we can make exceptions to the mission statement, we first need to know why we should consider a specific exception."
I didn't miss it, I was obviously cherry-picking, but the point was to argue why this thread "meandered dramatically away from" the initial purpose: if that was my initial feeling at first reading, probably that was the case for others.
CPE has not committed a team to it in over a year, we do state that as a driving factor to why we want to engage in this conversation but your assumption here is based on a particular outcome that sees Pagure not chosen. If Pagure is chosen, we will commit a team. We are very clear on that.
It wasn't so clear to me, but good to know.
Tell me what you do and how you interact with a forge? That's the point of this exercise.
Those with the most complex workflows would provide most value here. I only maintain a few simple packages at src.fp, and most of my work is in Copr.
However, I would say that integration with FAS should be a requirement. Owning the development of the specific tool (whether a forge or not) is not a must, in principle, but it's a good thing IMO. Please correct me if I'm wrong, but that was one of the drivers e.g. to develop Copr instead of going for OBS.
Iñaki
On Wed, Jan 29, 2020, 17:19 Iñaki Ucar iucar@fedoraproject.org wrote:
On Wed, 29 Jan 2020 at 16:23, Leigh Griffin lgriffin@redhat.com wrote:
On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar iucar@fedoraproject.org
wrote:
On Wed, 29 Jan 2020 at 00:08, Leigh Griffin lgriffin@redhat.com
wrote:
On Tue, Jan 28, 2020, 22:06 Iñaki Ucar iucar@fedoraproject.org
wrote:
On Tue, 28 Jan 2020 at 20:58, Leigh Griffin lgriffin@redhat.com
wrote:
This thread is serving as a source of requirements (although it
has meandered dramatically away from that)
When I first read the post, my thought was: wow, what a convoluted
and
abstruse way of saying "we want to abandon Pagure". Probably this wasn't your intent, but that's what I got. And given the reactions, other people too.
The linked blog to the ODF is very explicit that Pagure is one of the
3 forge options we are considering. I can't stress enough that it's a viable choice and ultimately what we opt for will come down to an analysis driven by the requirements gathered. I'm unsure how the blog has been interpreted any other way but hopefully this clears it up.
The ODF is very explicit in the problem statement, and it specifically and clearly says that:
- Pagure does not align with CPE.
Correct and it's why we said this line, which you might have missed: "While we can make exceptions to the mission statement, we first need to
know why we should consider a specific exception."
I didn't miss it, I was obviously cherry-picking
It gives a very different view when considered in balance Vs a selective quote. That's why I replied on the off chance someone is driving by the thread and skips the key points in the post.
, but the point was to
argue why this thread "meandered dramatically away from" the initial purpose: if that was my initial feeling at first reading, probably that was the case for others.
CPE has not committed a team to it in over a year, we do state that as a
driving factor to why we want to engage in this conversation but your assumption here is based on a particular outcome that sees Pagure not chosen. If Pagure is chosen, we will commit a team. We are very clear on that.
It wasn't so clear to me, but good to know.
Glad I could clarify it, I'm happy to update the original ODF document if it makes it clearer for others.
Tell me what you do and how you interact with a forge? That's the point
of this exercise.
Those with the most complex workflows would provide most value here. I only maintain a few simple packages at src.fp, and most of my work is in Copr.
I suspect that a bulk of our users are similar to you. Given that you are engaged on the thread (thank you!) what is your day to day needs? What features are part of your usage and interaction? What's missing or what would you like to see added? Your voice here can help represent that group and is most welcome.
However, I would say that integration with FAS should be a requirement. Owning the development of the specific tool (whether a forge or not) is not a must, in principle, but it's a good thing IMO. Please correct me if I'm wrong, but that was one of the drivers e.g. to develop Copr instead of going for OBS.
Iñaki _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, 29 Jan 2020 at 23:23, Leigh Griffin lgriffin@redhat.com wrote:
I suspect that a bulk of our users are similar to you. Given that you are engaged on the thread (thank you!) what is your day to day needs? What features are part of your usage and interaction? What's missing or what would you like to see added? Your voice here can help represent that group and is most welcome.
I'd say that if you manage to accommodate the more complicated workflows, the basic one is covered. Beyond that, I really like the table that is displayed in src.fp.o for every package, because in a single glance you can tell which one is the stable version and the version in testing for every release. I really like the links to Koji, Bodhi... integrated just above the table. And I really really like the Fedora Packages app, but it seems to be dead.
In summary, package maintainance has many pieces (dist-git, builders, update system, bugzilla, QA, CI...), and a "control panel" like Fedora Packages is very useful, I think.
Iñaki
On Thu, Jan 30, 2020 at 6:40 AM Iñaki Ucar iucar@fedoraproject.org wrote:
On Wed, 29 Jan 2020 at 23:23, Leigh Griffin lgriffin@redhat.com wrote:
I suspect that a bulk of our users are similar to you. Given that you are engaged on the thread (thank you!) what is your day to day needs? What features are part of your usage and interaction? What's missing or what would you like to see added? Your voice here can help represent that group and is most welcome.
I'd say that if you manage to accommodate the more complicated workflows, the basic one is covered. Beyond that, I really like the table that is displayed in src.fp.o for every package, because in a single glance you can tell which one is the stable version and the version in testing for every release. I really like the links to Koji, Bodhi... integrated just above the table. And I really really like the Fedora Packages app, but it seems to be dead.
In summary, package maintainance has many pieces (dist-git, builders, update system, bugzilla, QA, CI...), and a "control panel" like Fedora Packages is very useful, I think.
The Packages app was being rewritten by Miroslav Suchy: https://github.com/xsuchy/fedora-packages-ng
I don't know if it's ready yet to replace the existing one, though.
On Thu, 30 Jan 2020 at 08:03, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jan 30, 2020 at 6:40 AM Iñaki Ucar iucar@fedoraproject.org wrote:
On Wed, 29 Jan 2020 at 23:23, Leigh Griffin lgriffin@redhat.com wrote:
I suspect that a bulk of our users are similar to you. Given that you are engaged on the thread (thank you!) what is your day to day needs? What features are part of your usage and interaction? What's missing or what would you like to see added? Your voice here can help represent that group and is most welcome.
I'd say that if you manage to accommodate the more complicated workflows, the basic one is covered. Beyond that, I really like the table that is displayed in src.fp.o for every package, because in a single glance you can tell which one is the stable version and the version in testing for every release. I really like the links to Koji, Bodhi... integrated just above the table. And I really really like the Fedora Packages app, but it seems to be dead.
In summary, package maintainance has many pieces (dist-git, builders, update system, bugzilla, QA, CI...), and a "control panel" like Fedora Packages is very useful, I think.
The Packages app was being rewritten by Miroslav Suchy: https://github.com/xsuchy/fedora-packages-ng
I don't know if it's ready yet to replace the existing one, though.
I don't know what the status of the replacement is, but when I go to Packages, 50% of what I look for is missing and 50% is just wrong. This is less than useless. Any prospective Fedora user won't even bother installing it if they can't find out whether their favourite application is available. We might as well just turn Packages off.
So if the rewrite can do basically anything, it's probably an improvement. I'm sorry to be so harsh to the existing app, but it's basically of negative benefit to Fedora right now.
On Fri, Jan 31, 2020 at 01:37:36AM -0500, Elliott Sales de Andrade wrote:
On Thu, 30 Jan 2020 at 08:03, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jan 30, 2020 at 6:40 AM Iñaki Ucar iucar@fedoraproject.org wrote:
On Wed, 29 Jan 2020 at 23:23, Leigh Griffin lgriffin@redhat.com wrote:
I suspect that a bulk of our users are similar to you. Given that you are engaged on the thread (thank you!) what is your day to day needs? What features are part of your usage and interaction? What's missing or what would you like to see added? Your voice here can help represent that group and is most welcome.
I'd say that if you manage to accommodate the more complicated workflows, the basic one is covered. Beyond that, I really like the table that is displayed in src.fp.o for every package, because in a single glance you can tell which one is the stable version and the version in testing for every release. I really like the links to Koji, Bodhi... integrated just above the table. And I really really like the Fedora Packages app, but it seems to be dead.
In summary, package maintainance has many pieces (dist-git, builders, update system, bugzilla, QA, CI...), and a "control panel" like Fedora Packages is very useful, I think.
The Packages app was being rewritten by Miroslav Suchy: https://github.com/xsuchy/fedora-packages-ng
I don't know if it's ready yet to replace the existing one, though.
I don't know what the status of the replacement is, but when I go to
Hopefully Miroslav can fill us in on that.
Packages, 50% of what I look for is missing and 50% is just wrong. This is less than useless. Any prospective Fedora user won't even bother installing it if they can't find out whether their favourite application is available. We might as well just turn Packages off.
Thats... much more harsh than I would agree with. I still use it and find some of its information helpfull.
kevin
On Mon, 3 Feb 2020 at 17:03, Kevin Fenzi kevin@scrye.com wrote:
Thats... much more harsh than I would agree with. I still use it and find some of its information helpfull.
Sadly it does seem to have got a lot worse recently... I noticed last weekend that a few of the packages I maintain (e.g. clide, colordiff, perl-App-ccdiff, whowatch) can no longer found.
I remember some tickets being created about this - I'll see if I can find them and comment there...
Rich
On Fri, 7 Feb 2020 at 21:50, Richard Fearn richardfearn@gmail.com wrote:
On Mon, 3 Feb 2020 at 17:03, Kevin Fenzi kevin@scrye.com wrote:
Thats... much more harsh than I would agree with. I still use it and find some of its information helpfull.
Sadly it does seem to have got a lot worse recently... I noticed last weekend that a few of the packages I maintain (e.g. clide, colordiff, perl-App-ccdiff, whowatch) can no longer found.
I remember some tickets being created about this - I'll see if I can find them and comment there...
Hi all,
The indexing of the packages app full text search database relies almost only on mdapi [0] to populate the informations. The indexing sends a lot of requests to mdapi (at least 80 000, 1 for each package and subpackages) that causes a lot of load on mdapi which in returns makes some of the requests timeout and fail. I have improved mdapi performance last year [1] but unfortunately since we have moved it to OpenShift, mdapi is using an NFS volume mount which is rather slow making the performance improvement not as significant.
So the current situation is that every time the indexing process run, it is a little bit of a lottery. Depending on how many requests to mdapi are failing it will get different results, so a package might suddenly disappear. There is also a bug that I did not investigate but sometimes a package has another package description.
All that to say that I think, the indexing process needs to be rewritten or fix to be less aggressive towards mdapi or to be able to handle failure. I think it would be nice to have full text search of packages as a different service providing a simple API so anyone interested can build something cool using this. I personally don't have the time to look at this, but if anyone is interested I am happy to answer questions or provide pointers about the current process.
Hope this was an useful explanation :-)
[0] - https://mdapi.fedoraproject.org/ [1] - https://communityblog.fedoraproject.org/speeding-up-mdapi/
Rich
-- Richard Fearn richardfearn@gmail.com _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Wed, Jan 22, 2020 at 5:00 am, Neal Gompa ngompa13@gmail.com wrote:
And there's this worry that GitLab will go the same path Transifex did. They have a ton of incentives to do so, and they already are starting to with the consideration of injecting nonfree JavaScript in all variants.
Terrifying. Do you have a reference for this?
I guess GitLab does not understand it would be throwing away all the efforts of GNOME, freedesktop.org, KDE, and Debian to migrate to it? I doubt any of these communities would be willing to continue using GitLab if this were to happen (even though another transition would be very painful for each community). We might even wind up in a bizarro world where Pagure becomes the new default forge for open source communities.
Michael
On Wed, Jan 22, 2020 at 10:46 AM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, Jan 22, 2020 at 5:00 am, Neal Gompa ngompa13@gmail.com wrote:
And there's this worry that GitLab will go the same path Transifex did. They have a ton of incentives to do so, and they already are starting to with the consideration of injecting nonfree JavaScript in all variants.
Terrifying. Do you have a reference for this?
Back in October, GitLab considered doing this[1]. The outcry from their corporate customers got them to reconsider... for now. They're still trying to figure out what to do here to implement that feature without as much pushback.
[1]: https://about.gitlab.com/blog/2019/10/10/update-free-software-and-telemetry/
I guess GitLab does not understand it would be throwing away all the efforts of GNOME, freedesktop.org, KDE, and Debian to migrate to it? I doubt any of these communities would be willing to continue using GitLab if this were to happen (even though another transition would be very painful for each community). We might even wind up in a bizarro world where Pagure becomes the new default forge for open source communities.
I don't know how many times we're going to have to learn the hard lesson that relying on open core software bites us in the end.
Am 22.01.20 um 11:00 schrieb Neal Gompa:
Yes, but neither of those communities actually have terribly special requirements. In fact, those communities either had *nothing* in terms of infrastructure (FreeDesktop/Xorg) or were willing to throw everything away for GitLab (GNOME). We would not fit in either bucket, which makes GitLab a very awkward fit for us.
I'm sure you are aware of it but Debian uses gitlab as well...
Felix
On Wed, Jan 22, 2020 at 5:21 PM Felix Schwarz fschwarz@fedoraproject.org wrote:
Am 22.01.20 um 11:00 schrieb Neal Gompa:
Yes, but neither of those communities actually have terribly special requirements. In fact, those communities either had *nothing* in terms of infrastructure (FreeDesktop/Xorg) or were willing to throw everything away for GitLab (GNOME). We would not fit in either bucket, which makes GitLab a very awkward fit for us.
I'm sure you are aware of it but Debian uses gitlab as well...
I am aware of Salsa. Salsa functions largely as a fancy code host, rather than something where they leverage more of its functionality. They do have GitLab CI, but it's only used on some code projects. The bulk of the projects that are packaging ones have no CI to speak of. All of the packaging test stuff works off uploads by DMs/DDs into the queue for ftpmasters, which is disconnected from the VCS entirely. Moreover, Debian does not mandate that packaging has a VCS or that if it does have a VCS that it has to be on Salsa. So overall, it's a very odd situation compared to others where usage of the system isn't even required (there are people hosting Debian projects and packaging on pagure.io!).
* Felix Schwarz:
Personally I guess github would attract most contributions for Fedora from new contributors but it is closed source so I'd prefer gitlab for Fedora.
I don't think Github allows disabling pull requests for projects. This means that a ptoential Fedora Github service would host content submitted by people who have to agreed to the FPCA https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement.
Maybe that alone is sufficient to rule out Github?
Thanks, Florian
On 22. 01. 20 11:21, Florian Weimer wrote:
- Felix Schwarz:
Personally I guess github would attract most contributions for Fedora from new contributors but it is closed source so I'd prefer gitlab for Fedora.
I don't think Github allows disabling pull requests for projects. This means that a ptoential Fedora Github service would host content submitted by people who have to agreed to the FPCA https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement.
Maybe that alone is sufficient to rule out Github?
We are not the first project to deal with this. Usually, i is sovled by pots. See for example:
https://github.com/python/cpython/pull/16012#issuecomment-530664428
* Miro Hrončok:
On 22. 01. 20 11:21, Florian Weimer wrote:
- Felix Schwarz:
Personally I guess github would attract most contributions for Fedora from new contributors but it is closed source so I'd prefer gitlab for Fedora.
I don't think Github allows disabling pull requests for projects. This means that a ptoential Fedora Github service would host content submitted by people who have to agreed to the FPCA https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement.
Maybe that alone is sufficient to rule out Github?
We are not the first project to deal with this. Usually, i is sovled by pots. See for example:
https://github.com/python/cpython/pull/16012#issuecomment-530664428
Does this really work?
This pull request still has the “CLA not signed” label:
https://github.com/python/cpython/pull/18111
But this is not shown clearly in the commit:
https://github.com/python/cpython/commit/d6fd38e2a47af1e75
The red X isn't a relevant indicator. This commit was merged and has it, too:
https://github.com/python/cpython/commit/0d5eac8c327251f8e
I don't know if the branch list (the “master” below the commit subject) is a reliable indicator.
This is why I think the bot-based approach needs some review. I also think it's quite rude. The whole FPCA thing feels strange these days. Hopefully there is a better way to make sure that contributions are intended as such.
Thanks, Florian
On 22. 01. 20 14:12, Florian Weimer wrote:
- Miro Hrončok:
On 22. 01. 20 11:21, Florian Weimer wrote:
- Felix Schwarz:
Personally I guess github would attract most contributions for Fedora from new contributors but it is closed source so I'd prefer gitlab for Fedora.
I don't think Github allows disabling pull requests for projects. This means that a ptoential Fedora Github service would host content submitted by people who have to agreed to the FPCA https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement.
Maybe that alone is sufficient to rule out Github?
We are not the first project to deal with this. Usually, i is sovled by pots. See for example:
https://github.com/python/cpython/pull/16012#issuecomment-530664428
Does this really work?
This pull request still has the “CLA not signed” label:
And is not merged.
But this is not shown clearly in the commit:
https://github.com/python/cpython/commit/d6fd38e2a47af1e75
The red X isn't a relevant indicator. This commit was merged and has it, too:
The red X doesn't mean “CLA not signed”, it means any CI has failed. CPython allows merges with some CI failed, they have a very complicated setup with lots of lots of CIs, buildbots and a "night watch" about his. Not relevant for this discussion.
I don't know if the branch list (the “master” below the commit subject) is a reliable indicator.
Of what? CPython frequently cherry-picks, so in this case, no, it probably isn't.
This is why I think the bot-based approach needs some review. I also think it's quite rude. The whole FPCA thing feels strange these days. Hopefully there is a better way to make sure that contributions are intended as such.
It is quite rude, yes. So is the PAgure settings to enforce Signed off by commits (especially for repos that don't describe what are you signing off).
This thing is not easy indeed.
* Miro Hrončok:
The red X isn't a relevant indicator. This commit was merged and has it, too:
The red X doesn't mean “CLA not signed”, it means any CI has failed. CPython allows merges with some CI failed, they have a very complicated setup with lots of lots of CIs, buildbots and a "night watch" about his. Not relevant for this discussion.
I don't know if the branch list (the “master” below the commit subject) is a reliable indicator.
Of what? CPython frequently cherry-picks, so in this case, no, it probably isn't.
The second commit (cited above) is on the master branch, though. Which is my point: this shared space *is* confusing if you think you need to control tightly who can publish under it.
Thanks, Florian
On Tuesday, 21 January 2020 17:34:37 CET Leigh Griffin wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
Quote:
At the same time, integrations that already exist in Pagure may need to be
created for another git forge, which is a cost as well. This also needs to be fully considered by the team as part of the requirement gathering.
We just got Release-monitoring integration in Pagure, how would that be implemented in a new forge? What man-hours are you ready to commit to this new forge that can't equally be equally be committed to Pagure? At least with Pagure, we have people who know the codebase, would it be that easy to do custom integration with Git{hub,lab}?
GitHub is also, as far as I know, not free; wouldn't that be in contradiction with Fedora mission-statement to use it over a free alternative?
Best regards,
Robert-André
Heya,
Currently we have two different pagure instances that hosts different use cases on them, and different use cases means different requirements, so first of all, about what use cases we are talking about?
we have src.fp.o for distgit, some pagure.io projects that hosts actual code development repos and some other repos that are used as trackers and documentation containers.
For all of them, I agree with mcatanzaro's requirements: #1 self hosted #2 open source
IMO, #1 could be a soft requirement, I would be fine with a service provided by an upstream first and open source friendly service provider if it allows us to dump out all our data on a easy way. Now git and github is the mainstream workflow, but previously was sourceforge and svn . We should be able to transfer our data from our current service to a N+1 or N+2 service without losing too much so we should be able to dump all our data on a supported way.
I have some more general requirements:
#3 privacy friendly. Nowadays js|cookie tracking is huge on the world wide web, I would prefer not being tracked on that way while using a fedora service. bodhi, koji or distgit does not inject any weird tracking javascript or cookies, I love that and since privacy concerns me I would like to continue on this way.
#4 Good integration with Fedora infra's core services. This include fas (and it's replacement) and fedora-messaging
#5 Easy to onboard and open to any community member, newcomers included. We should avoid the integration problems that we're having with teams.fp.o on this matter for example (see below)
This requirements are not just for our git forge, all the fedora services should satisfy with them.
Then, we should capture and analyze the different use cases individually. Different use cases, different requirements. They might fit all of them on the same solution or we could move some of them to a different one if the other solution fits better for that case.
So let start with distgit. Here we have a bunch of more requirements:
#packager.1: technical implementation of our packaking policies and the ability to evolve them as the policies evolve. This means at least support for system-wide commit users (provenpackagers), system-wide restricted branches, systemn-wide protected (non force pushable) refs, system-wide actors that can bypass all this limitations (releng).
This should cover orphaning and retaking process too. We lack but we should have ACL branches and admins to support different EPEL|Fedora maintainers on the same repo.
#packager.2: Integration with other options|services that we have on our packaking workflows. This could be done on the git repo or we could have a different packager control panel service (I love miro's mockups for example). This includes BZ, bodhi, koji, anitya, BZ overrides...
That's for now on distgit.
On pagure.io I identify two big groups of repositories: code repos for development of different projects and tracking repos that are mostly used for the ticket system and some documentation.
The later ones could fit on teams.fp.o if we can solve the big issues on it: the fas integration is not perfect, and is not open for contributions. Fixing [1] and [2] is a requirement for teams to fulfill the initial general requirements, so it would be a requirement for an hypothetical transfer of this kind of projects from pagure.io to teams.fp.o
As general requirements, I have two at least:
#tickets.1: ticket|issue system support for usual workflows: tickets, assignees, tags, states, priorities...
#tickets.2: some kind of documentation integration. We have some repos on this use case that are just docs + tickets. We could support them on a non git repo solution if we can integrate both docs and tickets on a unique UI.
And then we have the code repos.
I like the idea of having a unique place to host all the fedora related code projects and I would add a couple of requirements around the homepage about this in case we go with a solution that groups all those code repos on a single place:
#dev.1: An attractive homepage that shows where is the activity right now, where we need help, and where newcomers can start to contribute.
#dev.2: Good searching capabilities.
For the repo itself... this is where we probably diverge more since every single developer has her own workflows so she'll have their own personal requirements. Some of us could just work with a system that allows you to make basic git operations and some others will require complex interactive conflict resolving UIs.
On my case, I don't need too much:
#dev.3: git support. I'm fine with just ssh support, but https one could benefit newcomers onboarding process.
#dev.4: PR workflow support.
#dev.5: ticketing system
#dev.6: web ui to the code, branches etc.
And then I have a soft requirement on a actual pagure feature that I did not use it previously but it means a lot nowadays for me:
#dev.SOFT.1: allow project maintainer to rebase pull requests. This helps a lot both the PR author and the project maintainer, I love it, I use it a lot and I would like to continue using it on my fedora related contributions.
[1]: https://pagure.io/fedora-infrastructure/issue/7826 [2]: https://pagure.io/fedora-infrastructure/issue/7827
And that is for now.
Regards,
Le mardi 21 janvier 2020 à 16:34 +0000, Leigh Griffin a écrit :
Hi,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
Requirements:
1. the url to the archive (tar.xz, tar.bz2, etc) corresponding to various code states (commit/tag/release/fork…) should be regular and stable (ideally, identical to the current ones to avoid redoing all the automation that plugs in pagure today, redoing source declaration in specs, etc)
2. the git repos should be fully accessible over https (read and write) to allow the contributionsfrom environments where ssh is filtered for security reasons. It’s hard enough to nurture the contributor pool whithout infra that can not work with nowaday’s most common access protocol (contributors should do xxx means no contributors given the current project attractivity deficit)
Regards
First requirement: As a Fedora community member, I'm able to self-organize my personal and team work by creating projects and group 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.
As teams.fedoraproject.org was mentioned before, the fact teams.fp.o requires you to add each user in the project for them to be able to interact with a ticket made me given up with this tool for the translation platform migration to Weblate.
In the other hand, we created 38 repositories to contain documentation's translations. We created groups and did the whole setting easily. The Pagure mindset fits with the idea of autonomy and ability to personalize.
By the way, we are stuck with automation which relies on openshift. It took me days only to get access as reader to fedora docs openshift. I connected and got lost instantly, it's complex and since, we had no progress in months.
Moving to either GitLab or Github worries me as it may lower our ability to self organize and the empowerment from casual contributors to key member of the community.
Second requirement: As a Fedora community member, I am using tools respecting the values of my community so that my speech and my acts are consistent.
We already have difficulties in promoting open source, not using it ourselves lower our credibility.
Third requirement: The platform should provide ways to talk with fedora-messages, so that non-packaging activities are included in Fedora community statistics and rewards (badges).
Jean-Baptiste
On Tue, Jan 21, 2020 at 04:34:37PM +0000, Leigh Griffin wrote:
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on
Aleksandra's comment made me aware that for dist-git, we do not really need a git forge, it is just that the pagure git forge was used to implement a lot of workflows that pkgdb provided in the past.
I tried to write the requirements as user stories to make them easier to understand. What do you think?
- As a package maintainer, I can only commit to a dist-git repo, if I am in the Fedora packager group. - As a package maintainer, I can only commit to a dist-git repo, if I am a maintainer of the branch. - As a proven packager, I can commit to all dist-git repos that do not have special restrictions set by FESCo or are retired. - As a FESCO member, I can configure exceptions to disallow proven packager access to a dist-git repo. - 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 - As a dist-git repo admin, I cannot remove access to the repo from Fedora infra, Releng or proven packagers without FESCo approval. - As a package maintainer, I can easily orphan a dist-git repo or branch to show that it is not maintained anymore. - As a package maintainer, I can adopt any orphaned dist-git repo or branch. - As a package maintainer, I can easily unretire a retired dist-git repo or branch. - As a release engineer, I can easily approve unretire requests for a dist-git repo or branch. - As anybody, I can easily see the FAS usernames of maintainers for all branches of a dist-git repo. - As a non-releng member, I cannot remove any commits from any dist-git repo that were used to build a Fedora package. - As an external user, I can easily get a list of all orphaned or retired dist-git repos and branches. - As anybody, I can watch for issues (bugzillas) or PRs that are created for a dist-git repository. - As anybody, I can easily get a list of all dist-git repos that I am watching. - As anybody, I can easily get a list of all dist-git repos that a specific Fedora account has admin/commit access to. - As anybody, when looking at the dist-git repo it is clearly visible which branches are still maintained. - As anybody, when I look for a specific branch, EOL branches do not clutter my view. - As a package maintainer, I can easily request commit/admin access for a specific branch or dist-git repo.
Also since dist-git is a critical part of our infrastructure, there should probably also be some security-related requirements such as:
- As Fedora infra, I can easily audit that no git repo was accessed without authorization. - As Fedora infra/security response team, I have access to secure logs to analyse the impact of unauthorized access to all dist-git repos. - As anybody, the dist-git web page of a repo points me to Bugzilla to report issues for a repository.
I did not manage to read all other replies, so there might be some duplicates but it also seems to me that many of these items were not mentioned.
Kind regards Till
On Thu, Feb 6, 2020 at 4:14 PM Till Maas opensource@till.name wrote:
On Tue, Jan 21, 2020 at 04:34:37PM +0000, Leigh Griffin wrote:
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on
Aleksandra's comment made me aware that for dist-git, we do not really need a git forge, it is just that the pagure git forge was used to implement a lot of workflows that pkgdb provided in the past.
I tried to write the requirements as user stories to make them easier to understand. What do you think?
I think this is the most productive message on this thread so far. Thanks!
josh
- As a package maintainer, I can only commit to a dist-git repo, if I am in the Fedora packager group.
- As a package maintainer, I can only commit to a dist-git repo, if I am a maintainer of the branch.
- As a proven packager, I can commit to all dist-git repos that do not have special restrictions set by FESCo or are retired.
- As a FESCO member, I can configure exceptions to disallow proven packager access to a dist-git repo.
- 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
- As a dist-git repo admin, I cannot remove access to the repo from Fedora infra, Releng or proven packagers without FESCo approval.
- As a package maintainer, I can easily orphan a dist-git repo or branch to show that it is not maintained anymore.
- As a package maintainer, I can adopt any orphaned dist-git repo or branch.
- As a package maintainer, I can easily unretire a retired dist-git repo or branch.
- As a release engineer, I can easily approve unretire requests for a dist-git repo or branch.
- As anybody, I can easily see the FAS usernames of maintainers for all branches of a dist-git repo.
- As a non-releng member, I cannot remove any commits from any dist-git repo that were used to build a Fedora package.
- As an external user, I can easily get a list of all orphaned or retired dist-git repos and branches.
- As anybody, I can watch for issues (bugzillas) or PRs that are created for a dist-git repository.
- As anybody, I can easily get a list of all dist-git repos that I am watching.
- As anybody, I can easily get a list of all dist-git repos that a specific Fedora account has admin/commit access to.
- As anybody, when looking at the dist-git repo it is clearly visible which branches are still maintained.
- As anybody, when I look for a specific branch, EOL branches do not clutter my view.
- As a package maintainer, I can easily request commit/admin access for a specific branch or dist-git repo.
Also since dist-git is a critical part of our infrastructure, there should probably also be some security-related requirements such as:
- As Fedora infra, I can easily audit that no git repo was accessed without authorization.
- As Fedora infra/security response team, I have access to secure logs to analyse the impact of unauthorized access to all dist-git repos.
- As anybody, the dist-git web page of a repo points me to Bugzilla to report issues for a repository.
I did not manage to read all other replies, so there might be some duplicates but it also seems to me that many of these items were not mentioned.
Kind regards Till _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Thu, Feb 6, 2020, 21:14 Till Maas opensource@till.name wrote:
On Tue, Jan 21, 2020 at 04:34:37PM +0000, Leigh Griffin wrote:
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent
manner
on the future of a git forge solution which will be run by the CPE team
on
Aleksandra's comment made me aware that for dist-git, we do not really need a git forge, it is just that the pagure git forge was used to implement a lot of workflows that pkgdb provided in the past.
I tried to write the requirements as user stories to make them easier to understand. What do you think?
This is a really welcome contribution thank you!
- As a package maintainer, I can only commit to a dist-git repo, if I am in the Fedora packager group.
- As a package maintainer, I can only commit to a dist-git repo, if I am a maintainer of the branch.
- As a proven packager, I can commit to all dist-git repos that do not have special restrictions set by FESCo or are retired.
- As a FESCO member, I can configure exceptions to disallow proven packager access to a dist-git repo.
- 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
- As a dist-git repo admin, I cannot remove access to the repo from Fedora infra, Releng or proven packagers without FESCo approval.
- As a package maintainer, I can easily orphan a dist-git repo or branch to show that it is not maintained anymore.
- As a package maintainer, I can adopt any orphaned dist-git repo or branch.
- As a package maintainer, I can easily unretire a retired dist-git repo or branch.
- As a release engineer, I can easily approve unretire requests for a dist-git repo or branch.
- As anybody, I can easily see the FAS usernames of maintainers for all branches of a dist-git repo.
- As a non-releng member, I cannot remove any commits from any dist-git repo that were used to build a Fedora package.
- As an external user, I can easily get a list of all orphaned or retired dist-git repos and branches.
- As anybody, I can watch for issues (bugzillas) or PRs that are created for a dist-git repository.
- As anybody, I can easily get a list of all dist-git repos that I am watching.
- As anybody, I can easily get a list of all dist-git repos that a specific Fedora account has admin/commit access to.
- As anybody, when looking at the dist-git repo it is clearly visible which branches are still maintained.
- As anybody, when I look for a specific branch, EOL branches do not clutter my view.
- As a package maintainer, I can easily request commit/admin access for a specific branch or dist-git repo.
Also since dist-git is a critical part of our infrastructure, there should probably also be some security-related requirements such as:
- As Fedora infra, I can easily audit that no git repo was accessed without authorization.
- As Fedora infra/security response team, I have access to secure logs to analyse the impact of unauthorized access to all dist-git repos.
- As anybody, the dist-git web page of a repo points me to Bugzilla to report issues for a repository.
I did not manage to read all other replies, so there might be some duplicates but it also seems to me that many of these items were not mentioned.
Kind regards Till _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On 06/02/2020 22:13, Till Maas wrote:
On Tue, Jan 21, 2020 at 04:34:37PM +0000, Leigh Griffin wrote:
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on
Aleksandra's comment made me aware that for dist-git, we do not really need a git forge, it is just that the pagure git forge was used to implement a lot of workflows that pkgdb provided in the past.
I tried to write the requirements as user stories to make them easier to understand. What do you think?
- As a package maintainer, I can only commit to a dist-git repo, if I am in the Fedora packager group.
- As a package maintainer, I can only commit to a dist-git repo, if I am a maintainer of the branch.
- As a proven packager, I can commit to all dist-git repos that do not have special restrictions set by FESCo or are retired.
- As a FESCO member, I can configure exceptions to disallow proven packager access to a dist-git repo.
- 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
- As a dist-git repo admin, I cannot remove access to the repo from Fedora infra, Releng or proven packagers without FESCo approval.
- As a package maintainer, I can easily orphan a dist-git repo or branch to show that it is not maintained anymore.
- As a package maintainer, I can adopt any orphaned dist-git repo or branch.
- As a package maintainer, I can easily unretire a retired dist-git repo or branch.
- As a release engineer, I can easily approve unretire requests for a dist-git repo or branch.
- As anybody, I can easily see the FAS usernames of maintainers for all branches of a dist-git repo.
- As a non-releng member, I cannot remove any commits from any dist-git repo that were used to build a Fedora package.
- As an external user, I can easily get a list of all orphaned or retired dist-git repos and branches.
- As anybody, I can watch for issues (bugzillas) or PRs that are created for a dist-git repository.
- As anybody, I can easily get a list of all dist-git repos that I am watching.
- As anybody, I can easily get a list of all dist-git repos that a specific Fedora account has admin/commit access to.
- As anybody, when looking at the dist-git repo it is clearly visible which branches are still maintained.
- As anybody, when I look for a specific branch, EOL branches do not clutter my view.
- As a package maintainer, I can easily request commit/admin access for a specific branch or dist-git repo.
I add one more requirement based on my own workflow: - As fedora user, I want to easily create pull requests to any dist-git repo.
Michal
Also since dist-git is a critical part of our infrastructure, there should probably also be some security-related requirements such as:
- As Fedora infra, I can easily audit that no git repo was accessed without authorization.
- As Fedora infra/security response team, I have access to secure logs to analyse the impact of unauthorized access to all dist-git repos.
- As anybody, the dist-git web page of a repo points me to Bugzilla to report issues for a repository.
I did not manage to read all other replies, so there might be some duplicates but it also seems to me that many of these items were not mentioned.
Kind regards Till _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Fri, 7 Feb 2020 at 03:32, Michal Konecny mkonecny@redhat.com wrote:
On 06/02/2020 22:13, Till Maas wrote: As a package maintainer, I can easily request commit/admin access for
a specific branch or dist-git repo.
I add one more requirement based on my own workflow:
- As fedora user, I want to easily create pull requests to any dist-git
repo.
I think that is the one that was why we went with a 'git forge' in the first place. It was a requirement for the previous move that anyone with a fedora account could create a pull request which could be looked at dealt with by either a package maintainer or a proven packager.
A second one was that having an ability to merge and test pulls in an automated fashion
On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin lgriffin@redhat.com wrote:
Hey Everyone,
On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/
We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure.
Thanks in advance, Leigh
As QA, we don't have many git forge requirements. But this would be really great to have: * Be able to create several polls in a single ticket. This would allow us to vote on blocker/freeze-exception status of proposed bugs.
If we can't have that, we can work around it using a ticket bot, which would require at least the following: * API to read tickets in a structured format * API to add comments and edit the ticket description (ideally also adjust ticket tags, milestones or some other properties) * a webhook support to get notified of ticket changes or access to a message bus
And to add some more to the wishlist: * good integration to Fedora core services (the account system, messaging) * open source * be able to ping or CC someone using @name or similar * be able to cross-reference projects using projectB#123 or similar * be able to move tickets across projects