On 28 February 2018 at 20:31, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > On Wed, Feb 28, 2018 at 9:22 PM, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> (c) try to send patches upstream that help your project - at least >> for merge purposes >> >> Note that (c) can be a huge deal, but it requires that you make sure >> your patches make sense in the context of upstream, not just in your >> own context. > > So far as I've been told, it takes many many months for Luc to get a > response on things he sends upstream, then gets some stylistic > feedback, fixes it, resubmits, and then has to wait another couple of > months. For this reason, people get fed up and are then inclined to > diverge. This is a bummer, as it'd be preferable to have quick review > cycles and thus continuous merging. I think it is somewhat more complex than that. Firstly some changes are directional - e.g. SSA implementation, or the debate about pseudo value size versus a pseudo OP code. And sometimes these changes can block other changes. In my view a solution can be found if people look at things more from a technical standpoint and avoid hurling personal abuse / insults. Also if a technical change is blocking other changes then submitters can perhaps omit the controversial change and move forward with the rest - but there has been a lack of flexibility in my opinion. Secondly Sparse lacks a robust test framework that can be used to verify the output - I do not mean that just for the traditional use case of Sparse as a code checker - but as a basis for code generation. This is something I am hoping to address by contributing a working LLVM backend and test cases. Having a robust test framework will enable more rapid changes as it will give confidence that a change does not break things. There is also a lack of reviewers - so that is I guess a bandwidth issue. But on the whole it is better to not skip the review and hurry with changes - especially due to above. Sometimes changes are quite large and it is hard to verify that they don't break things. I certainly found a number of changes in the last year that broke things - and several revisions were needed to fix issues - and in some cases I have not yet merged those changes. Again this makes applying large series of changes very hard. In my case I have not had issues - I got good responses on all the problems I reported. Although I haven't submitted patches yet I hope to start soon. Regards Dibyendu -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
