On Sun, Nov 12, 2017 at 7:10 PM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > No Chris. > We spend a full month discussing about how you was willing to > accept a solution to finally accept my solution and claiming > it was what you meant since the beginning. I have no idea what you are talking about any more. I recall there are two very serious bugs, one is the ptrlist iteration while modify. There other one is the wine deadloop bug. Both this two bus hold up the release. You can also blame me for hold up the release too if that means you feel better. > > The first part of the series: pre-llvm-fixes is 16 patches. > These patches have been submittted in March, 8 months ago. > Is it normal to take 8 months to review 16 patches? Luc, per our email exchange you know that one of the very important pull email was lost. And you said you believe and I don't need how show you the screen shot but I did any way. Why do you pretend you all the sudden forget about this issue and roll back the time line to 8 month? Just to make me look bad? If that is what you want. You win. Can we go back to get a solution to get the patch merged start from your llvm-fix series? I can not partial merge the branch. I do have issue with the OP_PUSH. That hold up the pull. You have been very abusive to me on email. That makes me not want to reply to you. Basically feeding the trolls. > > This is most probably your worst error. > Months ago, Linus gave you an advice. He said: > Particularly with somebody like Luc, who sends > involved patch series for core stuff and knows > what he is doing, I think Chris could just do > git merges, and lower the maintenance overhead > a lot. Come on, what Linus mean was I should use git merge rather than apply patches. You take it out of context of comparing applying patch vs git merge. You insert your own interpretation that I should not try to provide feed back and fix up with your branch. I usually tolerate small disagreement on the patches in the pull request, just suck it up. The OP_PUSH is too big a change for that. If I merge it then revert it in the later part of the branch. It is kind of ugly. So I want to know what is the option I have here to resolve this issue? > > You choose to not listen to this advice. It's your right, > of course but choices have consequences. Yes, you can abuse me and justify forking sparse. >> Why do you keep refusing to make any change >> to your pull request. > > I refuse to make frivolous changes 8 months after a series > been submitted, like you asked last week. > I'm very reluctant to make non-bug related changes 8 months > after a series have been submitted. > > The issue with SETVAL having no type have been discussed on > the mailing list in March, there were several patches, several > ideas and opinions. Some patches were dropped but a working > solution emerged. This solution was developped, integrated > with all the others changes, *tested* and was satisfying > to the person involved. > Who didn't participated in these discussions? Come on. You are CC on the SETVAL patch. Others comments on it. You ever did. Why? I join late to the discussion but you are the one did not finish it. Also why you did not review my other code changes? I might be late to do it. But I do think careful about your changes. > You already proposed this some times ago, at least twice IIRC, > and I said that I would be fine with this. Then for the OP_PUSH I think that is a much better solutions. Because until now you fail to express why SETVAL.size patch is technically inferior to your OP_PUSH. I have evidence to show otherwise. If you think the only problem of SETVAL.size is not complete, why don't admit that? I can provide the rest of the change make it complete. It take a rebase to cleanly drop OP_PUSH. It would be best if you can provide a pull point that does not have OP_PUSH. If I do it, it will means I rebase or revert your patches. With your blessing, I will go ahead and do it. > But you must also understand that, given the limited time you > have to accept patches, I have serious doubt about this. You can keep your doubt. It is free. Give me your blessing of me droping OP_PUSH I will show you the code. > If you want to maintain a project, you need to work reasonably > with the developpers. Taking 24 months to take a good series > without having even really reviewed it is not what I call > working reasonably well with devs. > Same here with the 8 months old LLVM series. Good. 8 months old. I am doing nothing in that 8 month. Not applying one single patch and not releasing one single bits. Thank you. Can we going back to find a solutions to merge the bits quicker? Give me your blessing I can do the dirty work. Make you the condensing one that review and throw rock on my branch for reviews. I well come that. > Isn't that a bit easy? > I've been very very patient with you, I have spent a lot > of time and energy trying to improve sparse, mainly fixing > bugs. Look at the activity of the last 8 years and look at > the activity of the last 12 months. Improving sparse, this > is my agenda. And you, what have you helped exactly here? I am very much appreciate your work and help on sparse. If that is not very clear to you. I repeat it here. I am very much appreciate your help. Thank you. What I am helping you? If you say nothing then I am fine with that. >> For example, if you drop the unresolved OP_PUSH patches >> from the series. I can pull your llvm-fix now. >> Do you want to do that? Or that is not an option for you? > > It's an option but: > 1) You must understand that this represent work. > Since, you have so limited time, you could: > - be efficient > - respect people's time & work. > 2) The actual solution is working and tested. > Removing the OP_PUSH would be a regression. The OP_PUSH is too much a issue apply the revert it. Especially it haven't merge yet. Need to go, To be continue. 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
