Linus challenges Paragon and criticizes GitHub for mergers

Linus Torvalds is known to he is very fussy about the procedures and standards that those who help develop the Linux kernel must follow. And, he is not usually very kind to those who are not up to the task. Let us remember that in the past he withdrew from his role for a time to rethink the way he related to other people.

This time, it was Paragon Software, the company behind the NTFS3 driver, who incurred his dislike.  Announced for version 5.15 of the Linux kernel, it will improve support for the native Windows file system.

Version control systems (MCS)

For this story to be understood, we are going to explain some details that not everyone has to know.

Developers of very complex software projects use version control software (Usually operated by an external provider in the cloud) This software allows you to track who, when and what makes changes.

If you are not part of the project members, you can make a fork, that is, copy the project files to your own repository and, in it, make your own modifications. If you like the result you can suggest to the administrator of the original project to incorporate them, by calling pull request.

Controller release

Last year, Paragon Software aHe announced the release of the controller code, which he previously marketed, also committing to take care of the maintenance and updatingn. This is good news as it is much better than the one we were currently using.

According to the company itself

The current version works with normal / compressed / spacious files and supports acl, NTFS journal playback. Most of the code was in the linux-next branch since August 13, but there are some patches, which were in the linux-next branch only for a couple of days. Hopefully it's okay - no regression was detected in the tests. '

After Paragon's announcement, the NTFS3 driver had to go through many rounds of revision to improve the quality of the code and make it comply with the coding standards of the rest of the kernel.

It seems that he finally made it.

And so we come to the mother of the sheep.

Linus subtracts Paragon

In order to include the driver in kernel version 5.15, Linus Torvalds asked Paragon Software to do the Pull request of which we spoke above. The company did it, but not in the way Torvalds likes.

The Finn's first observation was that the pull request should have been signed.

In a perfect world, this would be a PGP signature that could trace directly to you through the chain of trust, but I have never required it.

Second, he complained that the pull request it had been done from the web interface of the service, which produces a lot of junk code.

Github is a perfectly good hosting site, and it does a number of other things well too, but mergers isn't one of those things.

He also protested lack of sufficient information.

For the creator of Linux "Linux kernel merges must be done properly." And added: «That means proper commit messages with information about what is being merged and * why * something is being merged. But it also means proper information about authorship and committer, etc. All of which GitHub totally messes up. '

Linus Torvalds knows what he's talking about, he was the creator of Git, the software on which services like GitHub are based, now owned by Microsoft. And, curiously, it was due to disagreement with another service

I never really wanted to make a version control program as I hated them all… Then BitKeeper came along and it really changed the way I look at them. BK got most of it right and having a local copy of the repository and distributed merge was very important. The great thing about distributed origin control is that it makes one of the main problems with MCSs go away - the politics around "who can make changes."

BK showed that this can be avoided by giving everyone their own repository. But BK also had its own problems; there were some technical decisions that caused problems (renaming was painful), but the biggest drawback was the fact that, since it was not open source, there were many people who did not want to use it. So even though we ended up having several kernel maintainers using BK - it was free to use for open source projects - it never got massive. So it helped the kernel development, but it wasn't perfect.

So at some point I decided that I couldn't keep using BK, but I really didn't want to go back to the bad old pre-BK days. Sadly, at the time, while there were a few other SCVs that more or less tried to get the thing distributed, none of them did remotely well. I had performance requirements that weren't even remotely satisfied by what was available, and I was also concerned with the integrity of the code and the entire workflow, so I ended up deciding to write my own.