4 ms·
Yikes. Mailing list development might work for Linus and the kernel team but the PR approach on GitHub is so much easier for developers to discover and use and
by gigatexal 4y ago
Yikes. Mailing list development might work for Linus and the kernel team but the PR approach on GitHub is so much easier for developers to discover and use and even for senior or more seasoned devs I’d rather do this in the open on a PR than in some mailing list. Ugh.
- meibo 4y agoYeah, I was reading this and thought "Have fun!": > I don't know much about it, but I'm going to dig into it in the near future (https://man.sr.ht/lists.sr.ht/ https://man.sr.ht/lists.sr.ht/). For now, those who want to contribute, I'll just add read/write permissions to the project.
- morpheuskafka 4y agoThere's a huge middle ground of running your own instance of Gitlab/etc. versus going to the mailing list style of development (even that could be a lot easier with a more readable web interface and web posting support).
- shp0ngle 4y agoI think the mailing list approach would work for giant projects that have many bullshit PRs and issues, and you want to deter the “hello please fix it on my pc” stuff. Not really for small projects where each PR is usually helpful. I have no idea what is kyoto and if it fits there.
- 015a 4y agoTo be honest; I think something the creator (?) commented elsewhere here is really apt: no one is born knowing how to use Github. We get used to what we're used to. I'm not asserting that as an argument for email, or PRs, but rather just that I'm certain there's people who feel, and are, extremely productive in vim, or collaborating over email, or programming in PHP, or whatever tech the younger people in the industry would claim is Yikes or Big Oof. Unless we're talking about Bitbucket. No one is productive in Bitbucket.
- xigoi 4y agoPersonally, it took me a long time to understand how pull requests work.