I claimed in a thread today, that projects using GitHub as a mirror, but refusing to process pull requests were being unnecessarily hostile to newcomers. This could be automated.

I decided to check my claim. Hilarity.

Turns out if you append the six characters ".patch" to the URL of the pull request, GitHub serves up a plain-text patch formatted as an mbox format file.

The man-page for `git send-email` specifies that as it's first preferred input format...

So, yeah:

ยท Web ยท 6 ยท 16 ยท 25

@HerraBRE Well that's cool. I mean so as long as GitHub maintains that feature, but definitely cool for now.

@cstanhope Yeah, this could totally disappear tomorrow. Such is the nature of SaaS.

But for now, it's very low hanging fruit for building bridges.

@HerraBRE to me one of the best perks of the mailing-list-centric flow is precisely *because* it makes it so much easier to accept patches from a variety of sources. let casual contributors send patches from GitHub, core contributors can email the mailing list for discussion, others can link to a small .patch in an IRC channel; it all ends up in the same place in the end.

@technomancy @HerraBRE Yeah, I think it's kind of unfortunate that projects have to make a choice between mirroring to Github (with all of the exposure that provides) and working the way they want to work. OTOH, I see the point about this being easy to automate. It seems like it wouldn't be that hard to write a bot to forward a pull request to a mailing list as a patch.

@djmoch @technomancy Especially not when you consider that these projects ALREADY have bots that close the PRs and tell people they're "doing it wrong."

@HerraBRE @technomancy I'm trying to interpret that move as generously as they can, and I think the counterargument would be that if they didn't clarify their usual development process to newcomers, then those newcomers might never find out. There's a lot of value to participating in mailing lists and they'd be missing out on if they just throw PR's over the fence.

@djmoch @technomancy I think a lot - probably most - of the systemic "hostility" in FOSS is accidental. But it still sucks when people encounter it.

This is an example of that dynamic. The system sets people up for failure, in spite of good intentions from those who created it.

@HerraBRE @technomancy Some of it is genuine too. :)

I think Github could do a better job as well. Someone in your previous dialog mentioned that Github makes it nearly impossible to turn PR's off. I actually haven't found a way to do it at all. It'd be an easy feature that would send people to the README and save them the aggravation.

@djmoch @HerraBRE @technomancy You think this discussion is timely. I'm punting on putting things on GitHub largely because of maintenance but also because I do want to encourage the use of Git as a tool and not some "magic" that's procured by GitHub (someone I mentored thought sadly that GitHub made Git).

@jalcine @HerraBRE @technomancy Yeah, I've moved to self-hosting recently. I have a Github account, but now use it just to contribute to other projects.

@jalcine @djmoch @HerraBRE @technomancy

I've archived or deleted almost everything I ever had on MS Github; anything I still have an interest in I moved to a self-hosted gitea.

The FOSS community made a massive unforced error by standardising on one shitty platform run by shitty people.

@dgold @HerraBRE @technomancy @djmoch Oh one of my good friends got chased out by the former CEO and they tried to cover it all up - you don't have to tell me twice about their mismanagement.

@dgold @HerraBRE @jalcine @technomancy Agreed. It's weird to see a closed-source platform become the poster child of the opens source community.

@djmoch @dgold @jalcine @technomancy Not so weird, when you consider how much of Open Source these days is businesses sponsoring the creation of open dev tools and platforms used to build closed proprietary products just like GitHub.

GitHub was never as popular with folks who prefer the term Free Software...

I use it grudgingly. I'm weirdly more comfortable making devs, who know enough to manage their risks, use a closed platform than I would be publishing non-free code to innocent end users.

@kirschwipfel Correct. There are many ways to skin this cat. People just need to decide it's worth doing.

@HerraBRE that's handy. However is there any way to convince GitHub's infrastructure to email this out? The main problem we have with this sort of thing is you need and end-point for a web-hook which means having a server somewhere and someone to configure and maintain it.

@stsquad I don't know!

I agree that would be handy, I suspect GH don't do it for the usual corporate SaaS silo reasons, but I'm just wildly guessing.

My comment here was in the context of projects that have already written bots that interact with GitHub and auto-close the PRs.

@HerraBRE ahh ok. The #qemu project has a mirror on github but so far all we've managed is a comment in the project description and the occasional manual comment by one of the admins when someone submits them.

@stsquad If someone reads the email notifications and helps out folks that get confused, that can be enough. All depends how it's done, right?

It's extra work, but being welcoming to new contributors always is.

@HerraBRE sure and we try our best. It's less of a problem on PRs (who at least tend to come from someone familiar with code) than it is with bug reports. If you just copy and paste a form response pointing to our bug reporting guidelines that can come across as snarky but crafting an individual response to everyone saying thanks but you missed some vital information can get quite wearing.

@HerraBRE A point of using emails is code review. While I don't like this UI, I observed a maintainer on a project that preferred this way of collaborating and the mutt-based workflow. Mutt was the code review tool.

Pull requests on GitHub are often also noisy, with commits containing "useful" auto-generated titles like "Updated" and no further info. Or email address in the .patch may be wrong "george@Georges-MacBook-Pro.local".

Were I running a project based around code reviews in mutt over a mailing list, I might not want to manually import PRs, or assume that I should just blast the commit onto the mail address for review.

GitHub can be a nice read-only mirror; some people don't care about its so-called "community" aspects.

Not advocating for or against using Git web UIs (proprietary or not), just offering a different PoV here. I wouldn't easily call it hostility.

As an example: There are some projects where I have admin privileges and where an external issue tracker is in 10yr+ use, so we disabled the GitHub one; no way to do it with PRs, however. So the existing community is forced to look at a tool it has no interest in (and, because of copyright assignment policy towards a free software organisation, maybe even cannot accept). No hostility to user intended; merely result of an existing way the community operated since before Subversion transition and way before Git transition.

Sign in to participate in the conversation

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.