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. > > I don't see a real need for that. > If someone has a features and wrote the patches, those patches should > be submitted, reviewed, ... as usual and then pushed to master. > I'm being a bit naive or optimistic here, but I think that for most > cases the usefullness of a features is obvious and would certainly not > need any kind of votes. If the features has some negatives aspects then > of course, it's the usual work to balance things and make the best choice. > > Also, for technical matters, I don't believe in votes. Only he technical > merrits should count. > > 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 In my view we should just go with Chris's approach and stop debating this issue endlessly. 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
