Paragon Looks To Mainline Their NTFS Read-Write Driver To The Mainline Linux Kernel

[oiaohm]

I don't know what your definition of "sign off" here is, but if you mean approving a certain merge/pull request (i.e. the result of applying a specific patch) then Github/Gitlab support this fine. Its easily possible to assign specific reviewers for specific merge/pull requests.

Not at all

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

Section 11-13 out of the processes the Linux kernel runs by. Sign off does not mean approved to merge in Linux kernel procedures. Its extra meta data process. First person to sign off is the person who wrote the patch or modify the patch.

Concept of assign reviewer that is not the Linux kernel works section 13. Anyone who wishes to review can review a patch and resubmit patch to mailing list with a Reviewed-by: statement.

None of these different sign off means the patch will be merged.

Where I work we also have custom webhooks to deal with more complicated "signing" capabilities also because of legal reasons (we use Github Enterprise at work).

The reality is the Linux kernel has more complex sign off processes. Assigning specific reviewers is commonly not part of the Linux kernel process. Instead open playing field for any reviewer who wants to review the code to add a reviewed by sign off is in the Linux kernel process.

If you host your own Gitlab instance it can be as durable as you want it to be. Gitlab uses postgres as a database, which is the most durable open source ACID database The only other persistence that Gitlab stores is git repos, which is obviously as durable as git. I seriously doubt storing emails is more durable than a ACID database which has had decades of proven stability.

That not durable in the way you need. You are needing a solution that is allowing multi instances spread out globally that functionally can remain close enough synced. Postgesql and git don't give you this note I said close enough synced as in not perfectly synced. This is what the mailing lists with all the different mirrors and the like give.

Git repos for the way the Linux kernel mailing list need to operate to get around different filters is far to strict. Remember lag tolerance. Mailing list archives can insert newly arrived messages into the archive before entries that had already arrived because those have been delayed in transport somewhere.

I think the point is that the Linux maintainers need to get out of the mindset of thinking in terms of mailing lists. Its outdated and primitive, there were reasons why to use them in the past but the whole process is painful manual and obtrusive.

This is you not looking at mailing list and seeing what it has going for it. There is really a need for another format other than git for storing gitlab information equal to what the Linux kernel mailing list do that is tolerant like a mailing list to allow multi instances of gitlab to be running slightly out of sync with each other.

This is not a easy problem.

This is a non issue. I am pretty sure coding a simple web API is easy for any Linux maintainer and will pay itself off massively in time saved.

That is a very big mistake in presume. LInux kernel developers generally don't work with web API at all. Just take a close look at kernel.org and work out that all the web based stuff you are seeing is the documentation team creation that is basically 1 person out of the complete Linux kernel developers. Yes the developer doing the documentation work is well and truly overworked.

[QUOTE=mdedetrich;n1201485]Also I am pretty sure there isn't going to be a problem for anyone in the world to access a website. Github is accessible in places like China for example (hilariously China tried to ban Github but failed when there was a massive outcry of developers being unable to do their work).

https://en.wikipedia.org/wiki/Censorship_of_GitHub#MITM_attack

China has not given up filtering Github neither has other countries. So isn't going to be a problem is really putting you head in sand with current state of play. Projects on github can be not accessable to different users around the world.

Current state of play requires a solution more durable than what a single hosted location can provide. Git of Linux gets mirrored and the mailing lists get archived in many different countries and if maintainer thinks someone who should have responded with the email system around mailing lists has not responded they can email them directly.

This is all about creating as many routes to connect to individual contributors/reviews as possible. Mailing list archives don't require database servers and have tolerance to be slightly out of sync. Tolerance to be slightly out of sync is required to deal with global filtering.

Also its not hard to set up multiple domains to post to some hosted Gitlab instance (or heck even raw IP's can work).

LKML the Linux kernel mailing list is already hosted on multi domains on multi different servers round the world including inside china. Email archive 4 hour+ tolerance for lag is great.

Some hosted github instance is not going to cut it. You need multi instances of something like gitlab able to remain somewhat in sync when countries deciding to cause communication disruptions. Preferable with something with mailing list archive level of out of sync tolerance.

Thing here the Linux kernel mailing lists show you don't need 100 percent perfect sync for all the information about kernel development as long the information in the mailing lists into sync in few days. As in email messages in mailing list if they are delayed by 2 to 3 days getting to developers the effect to Linux kernel productivity is minor. This gives time to work around any forms of country filtering or the possibility that the country just quits doing it.

This is a way higher bar to get over. I would like to see a gitlab like item with this level of tolerance to disruptions. Its really easy to overlook that the git and mailing list Linux kernel development is using is highly tolerant to government disruptions. There is a old saying don't throw the baby out with the bath water. There is something really good about the Linux kernel development setup that alternatives do need to be equal to and that is the tolerance level to disruption it has .

[danmcgrew]

The Register (which referenced and acknowledged Michael Larabel's contribution to this subject) was less than underwhelmed by this fiasco.

From one of the 92 comments (a/o morning of 19 August), which got 139 up-votes--

“...That maintenance burden is FAR FAR more difficult than the initial code-drop is. You have to understand all the code, change it often, make sure it stays secure and bug-free, deal with support from users who now have NTFS 5.1 and why are they getting corruption now when they didn't on 5.0, and so on...”

“... A dump-and-run is a common output from a company that doesn't WANT to maintain it any more, or deal with the user's complaining that it's unmaintained, or has a bug they haven't fixed...”

from

"Linux kernel maintainers tear Paragon a new one after firm submits read-write NTFS driver in 27,000 lines of code"
"How exactly do you expect someone to review this monstrosity?''

Tue 18 Aug 2020 // 14:27 UTC

https://www.theregister.com/2020/08/18/paragon_tries_to_contribute_ntfs/

[starshipeleven]

The Register (which referenced and acknowledged Michael Larabel's contribution to this subject) was less than underwhelmed by this fiasco.

It was actually pretty neutral and factual, citing both sides of the coin fairly. Yeah the title is clickbait, but that's how it is in the news businness. The Register isn't a shit site. Why are you always stirring the pot to incite rage?

I don't love Paragon, but there is no reason to jump at their throat like that.

That said, now we are a few days later and the person said he will do as asked by Sterba, https://lore.kernel.org/linux-fsdeve...-software.com/

also he addressed other concerns about code quality and ability to pass kernel automated filesystem testing tools, which is decent so far https://lore.kernel.org/linux-fsdeve...-software.com/

And also said that the plan was to provide opensource mkfs and hopefully also fsck too if there is interest in this project. https://lore.kernel.org/linux-fsdeve...-software.com/
We plan to publish our mkfs.ntfs utility as the open source as well (and possibly fschk.ntfs - after mkfs).

and there is a kernel developer that said he will review the contribution once it is following contribution rules https://lore.kernel.org/linux-fsdeve...z6ddp6gl@pali/

From one of the 92 comments (a/o morning of 19 August), which got 139 up-votes--

Which is obviously more rage-filled bullshit nonsense. Why are you so angry at things.

[Awesomeness]

Has GitLab solved the problems which made Linus refuse to accept pull requests from GitHub?

Linus is a terrible human being and his opinions are garbage.

[Awesomeness]

And yet the kernel is pretty usable, wouldn't you say?

Not really that's why it needs 3rd party software for hardware configuration. Manually crawling through kernel parameters etc. is no doable for regular users.

[Awesomeness]

Why is it stupid?

Arrive in this century and you'll understand.

[starshipeleven]

Arrive in this century and you'll understand.

Let me rephrase.
What is the difference between using the GUI of a mail application and the GUI of a web site to see text messages?
You are doing 99% of the work with git anyway (or a git GUI).

[skeevy420]

Let me rephrase.
What is the difference between using the GUI of a mail application and the GUI of a web site to see text messages?
You are doing 99% of the work with git anyway (or a git GUI).

The extra 2GB of ram being used by the web browser.

[oiaohm]

Let me rephrase.
What is the difference between using the GUI of a mail application and the GUI of a web site to see text messages?
You are doing 99% of the work with git anyway (or a git GUI).

The biggest problem is Federation and having disruption tolerance. Mailing lists do Federation with disruption tolerance really simply. They come from be BBS days where disruptions was insanely common.

https://gitlab.com/gitlab-org/gitlab/-/issues/6468

Gitlab is still trying to get the finer points of Federation worked out.

Web site you still have to log in to say who you are. Email solution you sign who you are and it done.

The reality is for something like Gitlab to be able to replace the Linux kernel mailing list system you will need Federation to work with disruption tollerance. You will need means for a user to be able to change between federated servers and still be identify as them as well.

One day we may have something good enough to replace the Linux kernel mailing list solution. But as of today I know of nothing good enough yet.

Yes it possible that we could have gitlab make something that is more disruption tolerant than a mailing list in future but it does not have that feature yet.

Think about this we are still using car wheel base designs that are over 100 years old because the design works not that we cannot do better. The reality is the Linux kernel mailing lists works around a problem that needs to be solved in the alterative on offer.

Awesomeness has a real big baby and bath water problem. As in wanting to get rid of having to deal with mailing lists and not seeing in the bath water of mailing lists there is a baby of simple federation and disruption tolerance. So replacement need to keep the baby of that feature basically.