On Thu, Feb 22, 2018 at 2:28 PM, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > Hey Chris & Sparse ML, > > I've seen that Luc (CC'd) has a boat load of well tested patches, and > is also actively working on new features and improvements. Meanwhile > the sparse master branch on kernel.org seems like a bit of an > afterthought. What would it take to enable Luc to really take the > reins and start merging his stuff upstream and pulling things forward? Sorry for the late response I have been super busy in the last two weeks. I am actually agree to not apply Luc's patch unless it is git pull request. A little bit about the history, Luc has a lot of patches. He does not want his patch to be apply as other orders. I have try different ways to satisfy Luc. So the current method is that, I don't apply Luc's patch as "git am". I wait for Luc to send me git pull request. If I am not complete happy about it. Luc will address my concern and resend a new pull request. That is why I have to ask Luc if it is OK I apply the two patch you care directly, out of order. Normally I can't directly apply Luc patch. Even though there is a lot of them flowing on the mailing list. To answer your question. It is actually very easy. Just send me small easy to pull branches base on master. Don't contain patches that I already Nack. I usually want to make things cleaner, do things in a more long term organized way. I exercise my Nack very carefully, only a few times. Usually for a good reason. The current situation is a bit sad. Luc's stable branch is actually not pullable from master. 1)has conflict. 2) It contain patches I am not comfortable with. I am looking forward to merge Luc's pull request to reduce the gap between master and Luc's stable branch. Otherwise it effectively create a fork, which is bad for sparse. As I said, small series can be pull cleanly from master works the best. Chris -- 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
