What project(s) did you experience those steps with? They can all make sense under varying circumstances, I'd be happy to take a look at some of them to bear them in mind (sometimes projects can be encouraged to move to more streamlined processes, even when it requires careful planning and a long time).
I understood the intent of it being just a local change and not submitted. You're right that submitting it would be a bit more involved, and other people would probably protest, since the prompt was added deliberately, so why not just keep it local?
> Subscribe to some mailing list (because free software is stone age)
Doing free software via e-mail is also fairly decentralized. In fact Linux was done via e-mail until (at least) 1998 - patches were mailed to Linus and it was patch and diff (in 1999 VA Linux and Red Hat IPO'd).
Debian was very e-mail oriented last time I checked, unless things changed in the past year or two.
There may be drawbacks to software via e-mail but there are benefits as well. It depends on various factors.
GitHub is nonfree but it's just a UI for git. If it disappears or goes in the chamberpot, everyone can go to GitLab or self host. At most people would lose the issues.
It also doesn't handle sensitive data(It's all public!) and it can't really change stuff easily without messing up the hashes and making it quickly noticeable. Although I suppose on a large project it could slip in commits nobody would notice.
I know that this is a tutorial and the software was chosen as an example, but the bit where they discover a modernised version with many additions but steam on ahead making their own fix without checking out if the new version solved their original problem was very realistic.
15 comments
[ 3.6 ms ] story [ 39.3 ms ] threadCheck whom to to report the changes.
Check how to write your commit message, with or without Changelog.
Subscribe to some mailing list (because free software is stone age)
Post your patches. You are told to sign your copyright papers.
Ask the clerk to send you the copyright papers.
Fill out the assignment request, what you did.
Wait for the assignment PDF.
Print the PDF after you've received it, sign it, scan it, send it back. In most countries via snail mail.
Wait a week or two.
Check the change requests and reviews from the mailing list. People are picky, esp. free software people.
Rebase rebase rebase.
If you are lucky you are in after some time, and your code doesn't belong too you anymore.
Doing free software via e-mail is also fairly decentralized. In fact Linux was done via e-mail until (at least) 1998 - patches were mailed to Linus and it was patch and diff (in 1999 VA Linux and Red Hat IPO'd).
Debian was very e-mail oriented last time I checked, unless things changed in the past year or two.
There may be drawbacks to software via e-mail but there are benefits as well. It depends on various factors.
https://github.com/hboetes/mg/pulls
although it seems the author didn't do that either
Make a GitHub pull request
Fix whatever the project owner doesn't like in said PR
Done
GitHub makes FOSS no longer stone age.
Until GH or Microsoft does dislikes the project and kills it, with all the PRs, bug reports, etc.
Email makes things safer.
It also doesn't handle sensitive data(It's all public!) and it can't really change stuff easily without messing up the hashes and making it quickly noticeable. Although I suppose on a large project it could slip in commits nobody would notice.
Even the actions bot is open source!