On 25 February 2018 at 20:59, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Sun, Feb 25, 2018 at 06:38:45PM +0000, Dibyendu Majumdar wrote: >> On 25 February 2018 at 17:49, Luc Van Oostenryck >> <luc.vanoostenryck@xxxxxxxxx> wrote: >> >> I am not sure why above is the 'right thing'. There does not appear to >> >> be a definition or process to identify fixes or changes that people >> >> need urgently - and if I recall correctly you previously objected to >> >> having such a process when I suggested it. >> > >> > I don't remember we ever had a discussion about this. >> > It's true though, that I don't believe in very strict procedures >> > (though, I'm sure they are very good things in a lot of situations). >> > I think we must adapt our decisions to the reality with all its >> > complexity and unpredictability. >> > >> >> Here is the quote from previous discussion: >> >> >> 4. My suggestion would that for enhancements a simple majority voting >> >> should be adopted to ensure that features go in because Sparse users >> >> want them. > > Here above you was talking about 'fixes or changes people need urgently' > while this suggestion was about simple enhancements. > My objection was about using majority voting to take techncal decisions. > Voting can be used in two ways: a) to express need for a particular fix or feature b) to express approval for a change. Even technical merit is sometimes subjective - my solution is better than yours etc. - voting can help get opinions from others to decide the best way forward. >> > During these months I explained several times: >> > 1) that I tried the pseudo-size approach, even before Linus >> > suggested the OP_ARG/OP_PUSH approach, and that I abandoned >> > it because I saw several problems with it. >> >> From what I recall you tried adding a type to PSEUDO_VAL which didn't >> work. I don't think you tried the solution adopted by Chris. >> >> Here is your attempt: >> >> https://marc.info/?l=linux-sparse&m=148924738913671&w=2 > > I had tried a pseudo-size approach before. > I never posted it because of several issues I saw. > The PSEUDO_VAL approach came later. It looked better at first > but just after I posted it, I realized it couldn't work. > Then Linus proposed the OP_ARG way which became OP_PUSH. > As you know very well, it was easy, low impact, implemented and > tested within hours by me and tested soon after by yourself. > >> In my view we should just go with Chris's approach and stop debating >> this issue endlessly. > > The pseudo-size approach (the one I did or Chris' version, they're > essentially the same patch) have issues with CSE and with casts, > maybe others too. It's impact is not understood. It's not tested. > I think that is fine. We can test it and fix issues. I already tested it in my repo and did not find any issues - although I appear to have missed the bug you found. The way forward is to have it available and test it. If Chris can move the change to sparse-next branch then the objection to having this on HEAD / master is solved. Thanks and 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
