On Tue, Jan 21, 2020 at 10:02 PM Leigh Griffin <lgrif...@redhat.com> wrote: > > > > On Tue, Jan 21, 2020, 20:02 Fabio Valentini <decatho...@gmail.com> wrote: >> >> On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin <lgrif...@redhat.com> wrote: >> > >> > >> > >> > On Tue, Jan 21, 2020, 17:17 Fabio Valentini <decatho...@gmail.com> wrote: >> >> >> >> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgrif...@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 >> >> > >> >> > lgrif...@redhat.com >> >> > M: +353877545162 IM: lgriffin >> >> > >> >> > @redhatjobs redhatjobs @redhatjobs >> >> > _______________________________________________ >> >> > devel mailing list -- devel@lists.fedoraproject.org >> >> > To unsubscribe send an email to devel-le...@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-le...@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-le...@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-le...@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-le...@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-le...@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
