On Wed, Jan 22, 2020 at 6:06 AM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > On Wed, Jan 22, 2020 at 9:48 AM Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > >> > >> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngompa13@xxxxxxxxx> 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... -- 真実はいつも一つ！/ 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
