On Wed, Jan 22, 2020 at 12:38 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 22. 01. 20 12:19, Neal Gompa wrote:>> 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. > > While I don't necessarily agree with the tone, I must agree the the Gerrit > experience for drive by contributors is one of the most horrible ones I had. Ok, I knew I would trigger a lot of wrong conversation if I mention it out in the open. So let me just reiterate the main points: 1) src.fedoraproject.org is not a Git Forge Implementation of src.fp.org via GitForge is the option which we used through Pagure, but there are other possibilities. @jlanda just posted an awesome summary on the features, some of them support my point. Proven packages for example is not a Git Forge concept. Or the question of the ownership of the Pull request: in Git Forge pull-request are defined by the branch in someone's personal forked repository. And no one else has access to manage it. In Code Review system (yes, like Gerrit) change requests belong to the project repository. Anyone is able to work on anyone else's pull request, for example rebase it, or take over the work if the original owner doesn't want to continue by some reason. 2) Being afraid of everything which is not GitHub is not a good reason to choose GitHub. It is a reason to look into how to make some integrations and ways out from GitHub possible for the end user. Things like mirroring, like allowing GitHub accounts in the Single Sign On system for sending patches and so on can help with that. 3) No matter what we choose, it would anger someone, and makes someone's life harder. I would prefer if we choose tools by alignment of the purpose, the problem which those tools are trying to solve, rather then by the "niceness". Because if we have a same purpose - we have a way to improve the "niceness", sometimes by just waiting, sometimes by contributing... But if we have different purposes in mind, then we are not going to get any improvements, because "we are not the target audience" and our features are always going to be out of priority and out of scope. > I even think sending patches over e-mail is probably better. I think that it would be more productive if you try to rationalize this opinion. I don't want to argue about the feeling you have, but I would be interested in comparing notes on what exactly "Gerrit workflow" means to you, and whether or not it is the same thing to me. > > 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... > > This has been reported a year ago, without a fix so far: > > During running tests, it's very hard to see what's happening > https://pagure.io/fedora-ci/general/issue/2 > > CI errors are undecipherable > https://pagure.io/fedora-ci/general/issue/43 > > CI errors happen far to often > https://pagure.io/fedora-ci/general/issue/44 > > > I've been trying to make those issues a priority when we adapted gating, but I > was outvoted at FESCo. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > 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 -- 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
