And before you start whining - again - about how you are fixing bugs, let me remind you about the build failures you had on big-endian machines because your patches had gotten ZERO testing outside your tree.
As far as I know, the Linux Foundation does not provide testing infrastructure to it’s developers. Instead, corporations are expected to use their massive amount of resources to test patches across a variety of cases before contributing them.
Yes, I think Kent is in the wrong here. Yes, I think Kent should find a sponsor or something to help him with testing and making his development more stable (stable in the sense of fewer changes over time, rather than stable as in reliable).
But, I kinda dislike how the Linux Foundation has a sort of… corporate centric development. It results in frictions with individual developers, as shown here.
Over all of the people Linus has chewed out over the years, I always wonder how many of them were independent developers with few resources trying to figure things out on their own. I’ve always considered trying to learn to contribute, but the Linux kernel is massive. Combined with the programming pieces I would have to learn, as well as the infrastructure and ecosystem (mailing list, patch system, etc), it feels like it would be really infeasible to get into without some kind of mentor or dedicated teacher.
Linus complains the author didn’t submit the patch to some places for public comments and testing BEFORE requesting a merge.
Although a reasonable expectation, I can’t find anything about this on the kernel.org docs for posting patches. They seem to imply that you just check and verify your patch before submitting it on the kernel mailing list, but that’s it. I didn’t see any mentions of mailing lists explicitly for feedbacks or other conventions.
As far as I know, the Linux Foundation does not provide testing infrastructure to it’s developers. Instead, corporations are expected to use their massive amount of resources to test patches across a variety of cases before contributing them.
Yes, I think Kent is in the wrong here. Yes, I think Kent should find a sponsor or something to help him with testing and making his development more stable (stable in the sense of fewer changes over time, rather than stable as in reliable).
But, I kinda dislike how the Linux Foundation has a sort of… corporate centric development. It results in frictions with individual developers, as shown here.
Over all of the people Linus has chewed out over the years, I always wonder how many of them were independent developers with few resources trying to figure things out on their own. I’ve always considered trying to learn to contribute, but the Linux kernel is massive. Combined with the programming pieces I would have to learn, as well as the infrastructure and ecosystem (mailing list, patch system, etc), it feels like it would be really infeasible to get into without some kind of mentor or dedicated teacher.
Testing infrastructure would help for sure, but it’s not necessarily the lack of infra that’s causing trouble.
Linus complains the author didn’t submit the patch to some places for public comments and testing BEFORE requesting a merge.
It sounds like he expects something like
Although a reasonable expectation, I can’t find anything about this on the kernel.org docs for posting patches. They seem to imply that you just check and verify your patch before submitting it on the kernel mailing list, but that’s it. I didn’t see any mentions of mailing lists explicitly for feedbacks or other conventions.