Linux 5.8-rc1
lore.kernel.org
lore.kernel.org
we have modified about 20% of all the files
in the kernel source repository
despite not really having any single thing that stands out
Fully admitting to ignorance here, but to me it seems that this problem is way to big to prevent bad actors from participating. I would love to hear thoughts to the contrary.
It's done by email
Certainly better than closed source Windows 10 and OSX.
How can you tell?
Magnitudes of more people use Windows and macOS than Linux* and they have yet to fail catastrophically.
* not counting servers and embedded
Parent post was updated to say "not counting servers and embedded", but dismissing smartphones -- literally the most popular type of personal computing device in the world -- this way seems to completely invalidate the point.
can know what -- that there isn't a backdoor? I can look at Linux source all day and not find the answer to that.
One dedicated person, can.
You answered your own question. :)
scripts/get_maintainer.pl
It'll output the appropriate subtree of maintainers who "own" the code in the kernel that the patch applies to. Then, you can email your patch to them. The maintainer will send the patch up the "tree" until (hopefully) it ends up in Linus' repo.
For the two patches I submitted, it took two months to get in the kernel.
These guys are veterans in maintaining the sub-systems and make sure code base is clean enough based on linus' guidelines.
The maintainers are organized like a tree, Linus never saw my tiny change (I assume) but the maintainer reviewed it carefully.
Looking at kernel.org, the last LTS was the 5.4.z series, so I'm curious when the next LTS branch will be cut to use these features in most distros.
The next company I joined is using RHEL's 2.6.32 in production, more than 10 years after its release.
I've been having pretty good luck at work just asking for kernel updates - though it helps that I'm willing to stare at oopses and kcore dumps and userspace regressions (they happen!) on the canary machines.
This one is frighteningly common in embedded stuff.
RHEL7 has another year[0] of support left (until August 30, 2021), and is based on kernel 3.10 [1], which was released in 2013 [2]
RHEL 8 is expected to see support through 2029, and is based on kernel 4.18, which was released in 2018.
Redhat does backport changes, but tends to avoid backporting feature changes.
If you want to be able to use "recent" features of software, you are probably not running running Redhat But, many companies prefer the stability of systems that have been battle tested, and so are perpetually years behind the bleeding edge in terms of features.
[0] https://access.redhat.com/support/policy/updates/errata/
[1] https://www.redhat.com/en/blog/what-latest-kernel-release-my...
I’m just personally not convinced we really win much with the trade off as a society :p
The majority of kernel hackers are paid to work on it.
My main project has 95 libraries and is nowhere near that massive.
But does anyone have opinions on what the most “impactful” linux releases ever was?
Andrew Morton (7):
updates
more updates
yet more updates
still more updates
even more updates
some more updates
updates
But why so offensively?
He raised good concerns
That said, that merge log is fairly useless. Whether it needs to be anything other than that, and who generally would see it and whether it's for the person writing it or someone else is something to be discussed, but even in the case it's mainly meant for the author to look back on, is it even succeeding in being useful in that job? I would agree that it appears pathetic, but probably pathetic in a low-cost doesn't really matter way.
[1]: https://euroquis.nl/blabla/2019/08/09/git-alligator.html
https://patchwork.freedesktop.org/series/73884/
With the current kernel development model these aren't recorded in the actual tree, though.
So the best use I've seen for the merge commits are bugtracker task IDs and such.
1. Create a bug fix on the main development branch. eg "master" or equivalent.
This ensures the bug is "resolved" for all new builds and future releases.
2. Apply the fix to the supported release branches. eg v3.12.x, v3.11.x, etc.
This ensures the bug is "resolved" for all new point releases created from those release branches. eg v3.12.1, v3.12.2, etc.
In practise though, does it work well?
I think it could be done a lot differently, and better, but any change requires huge amount of political changes. There's probably ... 2 or 3 teams that would need to approve of any process change, and no one wants to be the one to push changes like this ahead. It's "good enough", even though... we often collectively lose a non-trivial amount of time every week or two or three. We log that "wasted time" in a spreadsheet to make a point of it, but... no one is motivated enough the shepherd the required change process. The devops team would have to change a bunch of their scripts, and the process would need to be coordinated among multiple teams of varying sizes and skills. It is kinda disorganized and nightmarish with... I'm trying to count - there's maybe 20+ devs touching this. I suspect this was 'fine' 10 years ago with, say, 5-6 devs who would have dealt with it.
With the absolutely rarest exceptions all patch releases are done in the same manner as the regular ones, i.e. from the HEAD of master. History must be as linear, as possible.
So there are basically 2 general cases when you really need to share a commit. In the first, you find out in your branch there's something to be fixed, which you know I already fixed in mine, in the commit X. In this case it's better if I reorder commits in my branch so that X is the first one, create a new branch with X, which then is merged in a proper manner. You can rebase then.
Second case is when 2 people with different skill-sets or responsibilities must work on something that "from the above" looks like the same piece of functionality. Then, however hard you may try, it all turns up much messier and they will end up needing to share branches (so they cannot rebase them) with multiple commits. In this case I name one of them responsible for changes made within this task as a whole, so when the work is finished the second (3rd, 4th,...) person doesn't touch the branch(es) in question any more, and the first one might rebase and clean up it as needed.
More like most times when people look at logs they will only have the first line visible anyway.
Yes, however, -m does encourage people to make single line messages.
The character limits are a real thing in git culture. One could start here, with a question posed by an apparent skeptic:
https://stackoverflow.com/questions/2290016/git-commit-messa...
git log would definitely show the entire commit message, so I don't see why there would be almost no audience. git blame along with git show or git log -n1 would also allow you to see the rest of the commit message for a particular line in the codebase.
git log could show the entire commit message, but I can't remember the last time I saw any developer whose default format wasn't a single-line one. Presumably there are some people who do prefer to see the whole message every time, and maybe that includes you, but IME that's quite rare.
By default, it shows the entire message, and, in my experience, most people aren't going to change the default behavior in one specific case.
That is true, but I literally can't think of any developer I've worked with in many years who had not done something like that. The typical display in every GUI for git repos that I've come across in recent times is also geared to single-line display, though some of them are marginally better with at least indicating the presence of additional lines than git's own one-line display formats in the CLI.
YMMV, and apparently it does, based on your second paragraph.
That's a subjective preference. Maybe for some repos it's a good idea to allow or even require longer messages, but certainly not all.
For example, after seeing many different strategies for commit messages over the years, my own preference in many cases is now to permit only one-line commit messages, with a strict character limit, which include a reference to a suitable source such as a feature or bug ID where more details may be found. With git, this can be checked using a pre-commit hook.
The big advantage of this is that a `git log` or similar command with a single-line format can never then hide anything important. Assuming we're talking about an established project that does have things like a bug tracker and some sort of structured project documentation set up, I have found that any time I am tempted to write a longer commit message, there is usually a better place I could record that information, and if not then maybe it wasn't that important anyway.
YMMV, of course. As I said, it's a subjective preference, and no doubt there are many different ways a team might choose to use their tools.
* A few little subsystems and a start of a lot of MM patches. Subsystems affected by this patch series: squashfs, ocfs2, parisc, vfs. With mm subsystems: slab-generic, slub, debug, pagecache, gup, swap, memcg, pagemap, memory-failure, vmalloc, kasan"
* More mm/ work, plenty more to come. Subsystems affected by this patch series: slub, memcg, gup, kasan, pagealloc, hugetlb, vmscan, tools, mempolicy, memblock, hugetlbfs, thp, mmap, kconfig
* More MM work. 100ish more to go. Mike Rapoport's "mm: remove __ARCH_HAS_5LEVEL_HACK" series should fix the current ppc issue. Various other little subsystems"
* Various trees. Mainly those parts of MM whose linux-next dependents are now merged. I'm still sitting on ~160 patches which await merges from -next. Subsystems affected by this patch series: mm/proc, ipc, dynamic-debug, panic, lib, sysctl, mm/gup, mm/pagemap"
* a kernel-wide sweep of show_stack(); pagetable cleanups; abstract out accesses to mmap_sem - prep for mmap_sem scalability work; hch's user acess work. Subsystems affected by this patch series: debug, mm/pagemap, mm/maccess, mm/documentation.
* various hotfixes and minor things; hch's use_mm/unuse_mm clearnups. Subsystems affected by this patch series: mm/hugetlb, scripts, kcov, lib, nilfs, checkpatch, lib, mm/debug, ocfs2, lib, misc.
* A few fixes and stragglers. Subsystems affected by this patch series: mm/memory-failure, ocfs2, lib/lzo, misc
And of course there are hundreds of commit messages for the patches that describe what is really going on. That said, Andrew Morton works in a different way than every other maintainer so the merge commit messages in his case tend to be much less descriptive than everyone else's.
And even though it never ocured to me to check, yeah, I'd actually expect a higher quality standards of Linux kernel.
This could help in terms of preventing regressions by making further updates for example.
Especially when looking back through older code to see "what did we change since X date?", and/or "what changed between (say) the 3rd and 5th of July?".
That seems to be a fairly standard thing too (from my perspective).
Linux kernel commits are very detailed and high quality. The style can be a bit ad hoc, but the face of enforcement is Linus himself.
What you're looking at here is a throwaway piece of unnecessary text. Git offers the opportunity to include it, but it is generally left blank, because it adds no value. All of the interesting bits are included by incorporation.
In this case, Andrew Morton decided to have a bit of ironic fun with the throwaway text. Dismissals ensue!
So even though I said
> I have no idea of what constitutes this Morton's work and if he could've done better
I very much believe that he could have. For 2 reasons:
1. There are multiple people with huge, broad, non-specific merges in that list, and every single one of them, did, in fact do better than Andrew Morton.
2. I believe that consistency in logs is good, so even in the case somebody really, truly, actually cannot say more, than just "updates" about the changes he introduces (which I don't think is ever true, but let's assume it is), I think "updates|updates|updates|updates" would still be a mile better, than "updates|more updates|yet more updates|still more updates".
Not at all.
> it adds no value
It is used by Linus to check what's going on and see if there's anything he should check more closely (perhaps cross-checking the message with the diffstat); it is used by developers (now or in the future) and journalists to make themselves an idea of what is being merged; it may explain features that are in development and have preparatory work being merged; and so on.
So I'd say there's quite a bit of value there.
The merge commit message is the equivalent of forwarding an email to someone and adding your comment at the top:
"Really interesting, read this!"
"Hey, look what Joe said..."
"?"
If we take it as true that merge commits have no useful information by definition, shouldn't they have a blank commit message? Or a message of "merged branch X"? And why are we spending lines displaying them in the denser log formats?
They are useful because it shows very clearly when a branch and merge was done. Dates and times are useful. Knowing the parent of a branch is useful. Knowing when a branch was merged back in to another branch is useful.
I think the fundamental problem is that commands like merge and revert generate their own default commit message and don't bring up the editor so that further updates can be made.
At my job, I always will tell people that they need to include why they're reverting a commit in the commit message. I haven't really done anything about enforcing standards on merge commit messages, but perhaps including the cover letter or PR description in the merge commit would be a good start.
Those are mergers, and besides they care more about quality of the commits, than about the quality of commit messages.
It's one of the perks not having some superficial scrum master to satisfy.
But once the paper is published no one will ever look at the commits again
I don't think a Linux monoculture is good, but from the perspective of an individual or organisation choosing which OS to use, there's less and less reason to choose a BSD.
Keep doing it the hard way, trying something different and running your code on a different browser and OS. In the long run, Windows and the BSDs have done a lot to make Linux good, in the same way that Android and iOS push each other forward. I’m just hoping folks keep adopting Firefox.
Git and C
I am using Mercurial and Pascal. But they seem to be dying :(
Those are tertiary issues at most.
Features, quality, issues resolved etc.. is mostly what matters.