On Wed, Jan 22, 2020 at 2:21 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 22. 01. 20 14:03, Aleksandra Fedorova wrote: > > can we have the power, scalability and feature-richness of a platform > > like Gerrit, but (optionally) hidden under the hood so that there is a > > "simple mode" for people who just need a one-time contribution? > > I won't go there, becasue I don't think we need the power, scalability and > feature-richness of a platform like gerrit in the first place. > > 1. Not for dist git This is where we disagree heavily I guess. We do need scalability, especially if we consider moving from source tarballs to unpacked sources at some point. And I hope we do (which is a yet another discussion we need to have). In my previous life we hosted Gerrit server for the entire custom Linux distribution (syncing all OpenStack commits in "real-time") on a VM with 2Gb of RAM, which never had an issue. We do need feature richness in terms of central management of the repositories in src.fp.org: default policies, groups, users, permissions, CI labels, branching,.. We do need integration, which Gerrit provides through the stream of events. And we already have CI system (Zuul engine) which can integrate nicely with it. We do need features like topics, where pull-requests to different projects are linked together as an implementation of one larger cross-project feature. This is something Git Forges don't have as an object at all, as they treat individual projects as isolated custom playgrounds, each with a separate workflow. If we don't get these features from a platform, we are going to implement it on our own, through bots and external services. Which will not make the contributor life easier. See the k8s link above: when integrations are done by bots rather than by internal platform features, they are not going to look nice or easy. > 2. Not for ticketing projects on pagure.io > 3. Code projects on pagure.io can choose a platform that fits their needs Pagure.io story is different. -- Aleksandra Fedorova bookwar _______________________________________________ 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
