[ Linux-kernel added back into the cc, because I actually think this is
On Tue, 21 Dec 2004, Jesper Juhl wrote:
> Should I just stop attemting to make these trivial cleanups/fixes/whatever
patches? are they more noice than gain? am I being a pain to more skilled
people on lkml or can you all live with my, sometimes quite ignorant,
I do try to learn from the feedback I get, and I like to think that my
patches are gradually getting a bit better, but if I'm more of a bother
than a help I might as well stop.
To me, the biggest thing with small patches is not necessarily the patch
itself. I think that much more important than the patch is the fact that
people get used to the notion that they can change the kernel - not just
on an intellectual level ("I understand that the GPL means that I have the
right to change my kernel"), but on a more practical level ("Hey, I did
that small change").
And whether it ends up being the right thing or not, that's how everybody
starts out. It's simply not possible to "get into" the kernel without
starting out small, and making mistakes. So I very much encourage it...
So please don't stop. Yes, those trivial patches _are_ a bother. Damn,
they are _horrible_. But at the same time, the devil is in the detail, and
they are needed in the long run. Both the patches themselves, and the
people that grew up on them.
I think Linus's quote largely reflects my opinion/experience. A new comer's changes won't always be good or right, but get in there and try things out!
It gives you exposure to code, the dev loop, general idea of how things work. Then one can take on bigger and bigger challenges.
We all gotta start somewhere.
Note that it was rejected because I sent it into the wrong branch (we do use master these days) and so I even had to resubmit it https://github.com/rust-lang/rust/pull/4308
I'm about to send in my 972nd PR now. The Rust book is 520 pages; that was the second version, the first of which was ~300 pages. Quite a big difference from +34/-2. I'm at +142,087/-166,524 lines to the main repo now, and #12 overall contributor.
Yes, not everyone who sends in a small patch will become a core contributor. But some will. It's a numbers game.
From this POV btw Github does a terrible job not telling maintainers: "merging this PR will result in the following PRs being no longer mergeable". Most of the times the list would be empty, making the merging of small PRs a lot more a non brainer.
I wonder if this may be similar to the "won't hire jr. developers" tragedy of the commons that many companies are party to: the economy as a whole would benefit from investing in jr. developers (by providing an environment in which they can advance to sr. developers), but for each company individually, there is risk in training someone up in a year or two only to have them leave and become a "mid-level developer" at another company.
I get the same idea as with the first Gordon Ramsey Kitchen-fixing programmes. Apparently, people said it was insane how he dared to swear on TV. But basically, he notices things are very wrong, makes sure he gets to the bottom of the mess, and hammers the ugly message very publicly into some owner who lost any connection with reality. If the cost is some swearing, that's the least of the problem. The failing businesses get fixed at least as much on a sociological level as on a cooking level.
Linus does the same. A big software project's problems are more sociological than technical in nature. Sometimes, the ugly message has to get trough, an another famous rant is born. But most of the time, work gets done, probably with a reasonable amount of smiles.
I still enjoy watching the Fox version (and his new show, 24 Hours), but I appreciate those original seasons much more.
People are complicated. He needn't be either a saint or a demon.
Spot on. I'd hate to be on the receiving side, but look at what we've all gotten from this effort - in a Machiavellian sense it really has been the correct choice.
I have not heard of Linus taking credit for other people's work, or him getting into a fistfight at a conference or feeling up women's asses.
Stop trying to paint progress as a bad thing.
> I think the trivial patches are among the most important ones - exactly because they are the "entry" patches for every new developer.
I have been running a fairly successful open source project and this is not exactly my experience. I guess about 70% of pull request I get is simple spell, grammar, white spaces and the likes. Some time folks send this in wholesale because they want their personal favorite verbiage. It takes enormous amount of time to go through each line and each file to make sure something else is not sipping in. However, more importantly, rarely I have seen these text fixers to send any real code fixes. Vast majority of them are just one offs.
My thesis is that there are lots of folks out there just trying to brag to be "contributor" for popular open source projects and they just move on from one project to next rarely taking time to settle down in any individual project. This might be not be the case for Linux kernel but might be the case for other smaller projects.
>My thesis is that there are lots of folks out there just trying to brag to be "contributor" for popular open source projects
Do you have an example of this? All I could find in your top 3 repos was one pull request updating the readme and its only 8 lines.
This is an enormous exaggeration.
- downcasing some http headers in an example (because they wouldn't match unless downcased, which I spent hours figuring out)
- replacing a regex search with a string search (because it made the method 30x faster and it was on the critical path of a weird edge case)
- allowing the user to prevent some harmless automatic stats being loaded in a postgres library on connect (because it broke cockroachdb, which uses the same wire protocol)
- quoting the urls in some generated CSS (because in base64 "//" is sometimes a valid encoding and our CSS preprocessor implemented line comments)
Now, I left a description for all of these that explained the problem, but without context they'd just look like I was collecting "contributor" labels.
E.g. look at 22-52 days old denied PRs on the HTML spec: https://github.com/whatwg/html/pulls?q=is%3Apr+is%3Aclosed
That's an entirely different thing to "serious" small fixes that actually clean up small problems in docs and such.
a) ignore it
b) file a bug/shout on irc
c) do a pull request.
I much prefer c over b, and both over a. Every little bit helps, and it's improving the current state. I've hardly seen people doing extensive (as in hard to review) commits that looked like busywork to get an 'I commited' badge of honor (is that a thing?) in any repo.
And I also do that all the time, if I find some thing that's quicker to fix via PR than even find the external bug tracker or the irc channel? Everybody wins.
I'm not justifying them, but there is quite a difference.
> When I was reading the documentation, my 4-year-old
> niece wanted to see what I was doing. After telling her,
> she noticed that something was very wrong and asked
> me to fix it. Instead, I helped her fix it herself.
One of the things I'm most proud of as a dev is a tiny contribution to the Nim standard library. It's a single commit and very simple, but made the PostgreSQL adapter consistent with the other RBDMSs' adapters. At the time, I'd been using Nim for only a couple of days, but that didn't stop me from being able to contribute in a meaningful way.
I'm amused and humbled that despite all of the work I've done over the past decade, it's quite likely that a seven-line change that I did mostly in ignorance will be the thing that impacts the most people going forward.
Here's the change, if you're curious: https://github.com/nim-lang/Nim/pull/6381/commits/921cc53e40...
My most popular open source project, by the numbers, is a ~40 line Rack middleware I wrote when jetlagged at 2am. ~29MM downloads all-time, 984 github stars.
I think about that all the time.
FTFY. There's a non-zero amount of time investment required to submit kernel patches (learning enough git, using the mailinglist, responding to questions, submitting revisions, etc)
---1.9 Ext4 file system parameters
+++1.9 Ext4 file system parameters
(Sadly, at age 53, I probably cannot get away with trying to make letters happy or otherwise be "cute", or I might well be inspired to try to do some kernel dev in the near future.)
1.9 Ext4 file system parameters
1.9 Ext4 file system parameters
One of the reasons I fell in love with OpenBSD was the commitment to correctness throughout the entire system. This is a lot harder with Linux because they only control the kernel and not the entire distribution.
Growing up, at my grandparents house, we had a communal old Mac (running OS 7 or 8, and BeOS for a while). Being a curious kid, I would often watch my uncle play Civilization II, and I would play myself. One day, I went to observe what he was playing, and instead it was programing in FutureBASIC. It sparked my interest, and he taught me the basics. This became a lifelong hobby, and I went from learning FutureBASIC from him, to then discovering a whole world of information online, learning REALBasic and PHP next, and C, Objective-C, and more. As a teenager, I made Mac apps and websites, and eventually when the iPhone came out, mobile apps. This gave me disposable income in high school (from selling shareware) and funded my one-way ticket and move to Silicon Valley.
A simple gesture like that, that sparks the right interest, can give someone an entirely different life and career.
From date in mail list (https://lkml.org/lkml/2014/11/24/407) seems like  should be appended.
I hope you're still hacking on it and other projects, Maisa Roponen... Now 8 year old!
It's so not a part of the adult lifestyle anymore that suddenly being confronted with it affects those sensitive to it deeply.
Christmas culture and thematics seems to target this dynamic.
Think of it as the equivalent of picking up a small piece of litter on the street, and throwing it into the nearby trash can.
This would then lead to a kernel patch and they would feel incredibly happy about for as long as they remembered it (little kids love to help in any way).
Maisa in this case probably learnt that there are grown-up text things like books on the computer, and it is a big thing if things do not line up and a letter is "sad". It is important to computers and people using computers.
And then to fix it for other people so that their "s" is not sad you write a letter with a computer and explain how they can fix it.
It might be interesting to hear her own memories of this, if she still remembers the episode.