you don't merge back from the main tree to the feature branch.
but the point is that I don't believe that the people who created the commits that you are complaining about would have done any better if they were patches. there was nothing in the tool that prevented them from doing things better. there are lots of kernel developers who would have helped them develop things (and comment them) if they had asked, but they weren't willing to reveal things.
getting things in patches would have probably been _far_ worse, as there would probably just be one big patch for each program (that _is_ the common thing to do when companies fork programs and then release their changes)
Posted May 8, 2009 10:31 UTC (Fri) by nbd (subscriber, #14393)
[Link]
Really simple:
If the system lets you get away with having to do less changes to a package to get it working, then *of course* there are going to be fewer changes. People want to get stuff working, and make only the necessary changes.
Or are you really saying that build system and structure have *no* influence on the result? My experience says otherwise...
About making things public and involving kernel people: Yes, that would have helped for getting changes upstream, but it would not have helped to get the product out faster. The Kernel developer community is focusing on getting it done right, while their own development team has to focus on getting it done fast (or at all). Considering the amount of pressure on getting stuff to the market fast, there's only so much time you can spend on figuring out the right approach...
So how would getting things in patches have been far worse, if the patches themselves are under version control? Having patches under version control means that you have *at least* the same amount of information available that you have now, but with an extremely easy way of structuring things even more if you feel like it, which (using quilt) costs virtually no extra effort.