@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...

@HerraBRE @piggo sounds like KDE needs to use the template thing (that I hope is working) that tells people when they're making a github PR to not do that instead.

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.

@trini @HerraBRE yeah that would work, it would save me 5 minutes trying to submit my work upstream. I'll just keep using my fork of the project, whatever
Follow

@piggo @trini Telling people to not submit PRs is dumb.

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.)

ยท Web ยท 2 ยท 4 ยท 5
@HerraBRE @trini I'm just thinking how much better KDE could've been if they tried to be less obnoxious

@piggo @trini That goes for a lot of FOSS, tbh. Turns out being nice and welcoming is work and requires people investing.

@HerraBRE @piggo What part of "Thanks, but this isn't where we work, this is just a mirror, please look here to interact with our community" isn't nice and welcoming?

@trini @HerraBRE look at the process for submitting it: https://community.kde.org/Infrastructure/Github_Mirror

I just won't bother trying. I hardly think I'm alone

@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".

@trini @HerraBRE Now, tell me where's the problem with setting up a Gitlab for the project, or, if they're so obsessed with GPL, let's make a clone, so that people can submit their work in a civilized manner and not like cavemen? Trying to send an Android app change as a patch is just ridiculous. It's a problem that's already solved

@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?

@trini @piggo Why be on GitHub at all?

I didn't say you had to be on GitHub. I'm saying that if you are, it would be courteous to play well by the rules of that community.

When in Rome!

@trini @piggo (Oops previous reply was on the wrong sub-thread. Apologies, hope it still makes sense.)

@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.

@trini @piggo @HerraBRE the point of enabling drive-thru is to capture the potential of those contributors who are *not* interested in remaining long term members

you know that "with enough eyes, all bugs are shallow"? you're rejecting an awful lot eyes

@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.

@trini @hirojin @HerraBRE well, it's not a bugfix, it's a new plugin building on existing APIs. I'm not sure you can CI-test that beyond "it compiles". someone has to build the app, put it on their phone, and try it out - in any case

@piggo @hirojin @HerraBRE It compiles, and whatever other static analysis tests they do are one part of the CI pipeline. I would also hope/assume they've got emulators setup to do mock input and so forth.

@HerraBRE @piggo With my U-Boot hat on, yes, I want to hear what one of the Mailpile guys as to say.

@trini @piggo OK. Here's my take.

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. ๐Ÿ˜€

@HerraBRE

Sorry, but that's a load of crap. Projects put their stuff on MS GitHub because, for various reasons, many people think that place is where software lives. Anyone who's not using MS Github is labelled some sort of crank.

I've been involved in projects which chose not to be on there, and, without exception, the first, largest and loudest complaints were from Fossbros demanding that the project relocate there.

@trini @piggo

@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.

@HerraBRE

Because no.

Just because a project chooses to mirror its development sources to MS Github, that doesn't mean that that is where development takes place.

The image shared above in the thread is neither hostile nor offensive - it is simply stating, with politeness, that development takes place elsewhere.

There's no rudeness there, there's no belittling, of the sort usually deployed by Fossbros, it simply invites someone to join the project elsewhere.

I honestly don't see why you think this is "hostile" or "rude". If you can show where this is either, I'd be happy to change my opinion, but, as is, this is neither.

@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!

@piggo @HerraBRE I don't see how telling people where to go to read how you're supposed to work with the project is being obnoxious, sorry.

@piggo @trini @HerraBRE they're doing a lot of work to improve this, moving to Gitlab and making a better unified identity

@jalcine @trini @HerraBRE oh if that's the case i'm looking forward to it

@piggo @trini @HerraBRE I keep close attention to their moves as of late since all of their chatter moved from mailing lists to phabricator

@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.

Sign in to participate in the conversation
Mastodon

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.