@piggo That's a really bad experience.
If they can write a bot to close PRs, they could with a bit more effort probably write a bot that copies the PR over to wherever they want it and post a link.
Admittedly, it would be more effort. But if someone writes it, I'm sure a bunch of projects that want to leave GitHub would use it...
It sucks all around as I know this will surprise no one, github makes it not at all easy to disable PR support even if you have just a mirror of your repository there.
It's better than wasting peoples' time, but it's still a really shit workaround.
The PR can be pulled from any git client and could easily be imported into their preferred repo. This could be automated.
If they've already got a bot that automatically comments and closes PRs, they've already done the hard parts, but they chose to be hostile and unhelpful instead of doing it properly.
(Or, nobody thought of doing what I just suggested.)
@piggo @HerraBRE You aren't alone. But if you're going to submit a non-trivial change and also can't be bothered to work with the community review and testing infrastructure you're just pushing the testing effort off on to someone else. Frankly I think it speaks towards "github mirrors are bad as github isn't friendly towards projects that don't want to go all-in on github".
@piggo @HerraBRE And if the majority of contributors and reviewers are already happy with mailing lists and patches? Or whatever else they're using (the KDE stuff looks a little home-grown, but they've been at it for ages too so I'm sure it works for them) why set up a whole bunch of new stuff, especially if it's to bring in people that aren't joining the project to become a long term member and share that burden?
@HerraBRE @piggo We, like KDE, the Linux Kernel and a number of other projects setup mirrors on github on the grounds of "Hey, free high availability fast clones sounds like a good thing". It was about 6 months ago I think that github added a post-receive hook (that projects can't tweak) telling people to make a PR now. I suppose the take away is that github isn't good for read-only mirrors anymore, which is a bit of a shame. But I suppose it was also a bit of an oddity to start with.
@hirojin @piggo @HerraBRE It depends on the depth of the bug being fixed too. Over here, we had a drive-by fix of a register offset for Pi. And yeah, it was trivial enough that I wish there was an easy way to re-direct it to the regular process. The one off there was that I tagged the Pi custodian and he was happy enough to do the leg work. There's other SoCs that I could see and understand the custodian just putting it low on their TODO list. 1/2
@hirojin @HerraBRE And the big problem is that all of our review flow depends on things going the normal process so all of the other volunteers know to look for things to review and apply. I've seen a few other projects discuss if they have enough bandwidth to review things from both "traditional" and "drive-by PRs", and they don't. I don't mean to pick on @piggo here but their PR looks like something non-trivial. It really should get put in the KDE CI loop and tested and reviewed regularly.
By being on Github, you are implicitly supporting Github's workflows. Not everyone will take the time to read about why you are different and special, and you can't expect them to.
By the time they see the warning that their PR won't be looked at, they've already made the effort to contribute and submit a PR - and only then do they find out they made a mistake.
This is an entirely predictable course of events. Blaming the contributor for this IS hostile.
@HerraBRE @piggo I don't see closing / telling people not to do it as blame. If someone sends me a patch directly, I don't take it, I say hey, thanks (quickly review it for huge obvious problems) and then direct them to the mailing list. Especially for mirror accounts, no one is getting an email when someone opens a PR so the alternative is silence which is worse I think.
@trini It's hostile to set people up for failure.
Maybe you think the these mirrors are worth the frustration (easy, since the frustrated people aren't core members of the team). But being collateral damage isn't exactly a nice feeling. IMO @piggo 's reaction was 100% normal and expected.
Maybe that wasn't the intention, but once it's clear that is the end result, declining to fix it means accepting hostility towards newcomers.
Anyway, I've said my piece, I'll stop now. 😀
@dgold I hear a lot of name calling and ranting, but ... which part of what I said was in your opinion incorrect?
I'm saying that IF you are on GitHub, it makes sense to play by the rules. When in Rome, etc.
If you're not on GitHub, you're not on GitHub. That's fine. If you resent being pressured into using GH, that's also unrelated. If you think that resentment justifies doing a shit job and being rude to new contributors... well you do you I guess.
@dgold Because they know people are wasting their time, and they continue to allow it to happen when they could easily do better.
I'm glad you've now changed your mind, that's great!
@HerraBRE @piggo There's a handful of bots that projects that mirror stuff only to github use to try and mitigate github being annoying and _telling_ people to make a PR now with some hooks that AFAICT you can't turn off. And you're assuming there's some other place for that PR to go. I know in my case there is not, we don't take PRs from most people, we take patches.
Generalistic and moderated instance. All opinions are welcome, but hate speeches are prohibited. Users who don't respect rules will be silenced or suspended, depending on the violation severity.