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

[anth]

Why don't Linux kernel devs not use GitLab like normal people? Sending patches to mailing lists is stupid.

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

[oiaohm]

Why don't Linux kernel devs not use GitLab like normal people? Sending patches to mailing lists is stupid.

Number one Normal people there is no such thing. Linux kernel developers class using a mailing lists as normal.

Gitlab and Github both have major limitations when it comes to multi maintainer problem.

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html

Read though this carefully when submitting patches you are meant to submit patches to maintainers of particular sections of the Linux kernel.

Gitlab and Github both in fact lack the means to process submitted patches and give them to the right party to sign off.

There is also the requirement for traceability on those submitting patches.

I agree submitting patches to the Linux kernel could be made simpler. Problem is none of the existing tools including gitlab or github are really designed todo the kernel workflow of signoff, scripts/checkpatch.pl and so on. There is a coding project in it self to make a GUI that makes submitting to the Linux kernel straight forwards follow steps and tells you this is wrong don't submit yet.

[mdedetrich]

Number one Normal people there is no such thing. Linux kernel developers class using a mailing lists as normal.

Gitlab and Github both have major limitations when it comes to multi maintainer problem.

https://www.kernel.org/doc/html/v4.1...g-patches.html

Read though this carefully when submitting patches you are meant to submit patches to maintainers of particular sections of the Linux kernel.

Gitlab and Github both in fact lack the means to process submitted patches and give them to the right party to sign off.

There is also the requirement for traceability on those submitting patches.

I agree submitting patches to the Linux kernel could be made simpler. Problem is none of the existing tools including gitlab or github are really designed todo the kernel workflow of signoff, scripts/checkpatch.pl and so on. There is a coding project in it self to make a GUI that makes submitting to the Linux kernel straight forwards follow steps and tells you this is wrong don't submit yet.

Huh, this is all bullocks.

Gitlab and Github can handle multiple maintainers fine. You can easily assign specific people to review a pull/merge request. Furthermore both services allow you to enforce people to sign their commits with GPG keys for traceability/security.

Also both services have API's that allow you to add additional checks that trigger when creating a pull/merge request which can be programatically defined to do anything. Gitlab is also completely open source so you can customize it as you wish (for someone like Linux maintainers I would recommend gitlab).

[microcode]

I had to register a new email address but in many free emails, SMTP can be enabled only after paying money...

Literally what free mail provider doesn't have free authenticated SMTP?

[Kepsz]

Literally what free mail provider doesn't have free authenticated SMTP?

I think Protonmail was one of them. I didn't remeber the other one. At the end, Zohomail was the solution.

[starshipeleven]

Why don't Linux kernel devs not use GitLab like normal people? Sending patches to mailing lists is stupid.

Why is it stupid?

[oiaohm]

Gitlab and Github can handle multiple maintainers fine. You can easily assign specific people to review a pull/merge request

Not if you read though the way the Linux kernel works.

Gitlab and Github both in fact lack the means to process submitted patches and give them to the right party to sign off.

I said sign off here. This is not the maintainer. The maintainer mailing list gets the patch and lets say it relates to something AMD/Intel you could have a Intel/AMD developer watching the list resend patch back to the mailing list signed by them as fine. So there is more in the Linux kernel system than just a pull and merge request.

Linux kernel is different that you have multiple maintainers and reviewers working together in way that reviewers self opt in and out of reviewing. Both Gitlab and Github are not designed for this model. Please note the review sign does not mean the patch will be merged.

Multi maintainer problem with the Linux kernel is something more creative. Linux kernel mode you have maintainers that can do pull/merge request and each of the maintainers have their pool of reviewers some are human some are bots. The reviewer structure does not have strong formal controls.

To give something to the right party for sign off at times requires you to email a patch to a legal department or equal. Yes this could be that the party that needs to sign off happens to be somewhere like china and the great firewall is being ass blocking access to website yet email gets though.

Mailing lists seam horrible but they turn out to be quite durable. Remember if you are running a email server and you take it off line for less than 4 hours all your email gets though because servers will cache and wait. Email system is designed to cope with quite a percentage of disruption.

Gitlib and github are lacking in mailing list integration and you need the means to email. Lot of ways this means Linux maintainers really do need a fully functional desktop client with email if not email something else as communication durable.

Also both services have API's that allow you to add additional checks that trigger when creating a pull/merge request which can be programatically defined to do anything.

This is true but someone has to code the addons to suite the Linux kernel workflow and the communication issues of operating globally this means a web only interface is not good enough. Email for getting messages around globally works decently well.

Of course I can understand people wanting more web based interface. But there are operational things on the maintainers side that have to be addressed like the all important how do I get a patch to a party to reviewer who happens to be in a location that being a jackass with firewalls and other things with the most dependability and least effort.

A project management system that can handling the Linux kernel processes and annoying issues caused by world wide operation in a user-friendly way is one hell of a challenge that I would love to see someone successfully pull off.

[k1e0x]

Microsoft is a giant and they couldn't finish it, wow, now I'm thinking Btrfs takes so long not because it was badly mismanaged, or was it..?

Sort of.. when btrfs was very new they added too many features and too much code too quickly.. (They wanted feature parity with ZFS even tho ZFS had a 10 year head start? not sure) beyond that filesystems are very hard and often even large companies fail at these kinds of software projects. (Microsoft failed WinFS as example)

With BTRFS it's really a wonder it works at all.. considering the problems they had. So Kudos to them getting the project back under control and moving forward.

[mdedetrich]

Not if you read though the way the Linux kernel works.

Gitlab and Github both in fact lack the means to process submitted patches and give them to the right party to sign off.

I said sign off here. This is not the maintainer. The maintainer mailing list gets the patch and lets say it relates to something AMD/Intel you could have a Intel/AMD developer watching the list resend patch back to the mailing list signed by them as fine. So there is more in the Linux kernel system than just a pull and merge request.

Linux kernel is different that you have multiple maintainers and reviewers working together in way that reviewers self opt in and out of reviewing. Both Gitlab and Github are not designed for this model. Please note the review sign does not mean the patch will be merged.

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.

Both of these services have had these fine grained abilities for a while.

To give something to the right party for sign off at times requires you to email a patch to a legal department or equal. Yes this could be that the party that needs to sign off happens to be somewhere like china and the great firewall is being ass blocking access to website yet email gets though.

Again, none of this is impossible to do on Github/Gitlab. 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).

Mailing lists seam horrible but they turn out to be quite durable. Remember if you are running a email server and you take it off line for less than 4 hours all your email gets though because servers will cache and wait. Email system is designed to cope with quite a percentage of disruption.

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 (see https://docs.gitlab.com/omnibus/settings/database.html). 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.

Gitlib and github are lacking in mailing list integration and you need the means to email. Lot of ways this means Linux maintainers really do need a fully functional desktop client with email if not email something else as communication durable.

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 true but someone has to code the addons to suite the Linux kernel workflow and the communication issues of operating globally this means a web only interface is not good enough. Email for getting messages around globally works decently well.

Of course I can understand people wanting more web based interface. But there are operational things on the maintainers side that have to be addressed like the all important how do I get a patch to a party to reviewer who happens to be in a location that being a jackass with firewalls and other things with the most dependability and least effort.

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.

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). Also its not hard to set up multiple domains to post to some hosted Gitlab instance (or heck even raw IP's can work).

[dovla091]

Yes, more important thing are to focus on changing words master/slave, blacklist, etc...