On Wed, Jan 22, 2020 at 12:20 PM Neal Gompa <ngomp...@gmail.com> wrote: > > On Wed, Jan 22, 2020 at 6:06 AM Aleksandra Fedorova <al...@bookwar.info> > wrote: > > > > On Wed, Jan 22, 2020 at 9:48 AM Clement Verna <cve...@fedoraproject.org> > > wrote: > > > > > > > > > > > > On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro <mcatanz...@gnome.org> > > > wrote: > > >> > > >> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngomp...@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 _______________________________________________ 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
