On Tue, Jan 21, 2020 at 3:01 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin <lgriffin@xxxxxxxxxx> wrote: > > > > > > > > On Tue, Jan 21, 2020, 17:17 Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > >> > >> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin@xxxxxxxxxx> 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
