On Wed, Jan 22, 2020 at 1:05 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák > <dan.cermak@xxxxxxxxxxxxxxxxxxx> wrote: > > > > Felix Schwarz <fschwarz@xxxxxxxxxxxxxxxxx> 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. -- 真実はいつも一つ！/ 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
