Richard, let me first express my gratitude for your efforts. Richard Purdie wrote: > Following the procedure includes listening to feedback and acting on it. > In the case I suspect we're talking about the commit was premature and a > consensus was not reached.
Sorry, disagree here. Unless you define consensus as a unanimous decision. This POV is out there with some people, sometimes in the form of "I feel free to veto and block just about anything, but I will gladly override negative feedback for my own commits". I don't share the "You have to have a unanimous decision" POV especially if the veto is IMHO obviously out there for the sole reason to stall changes indefinitely (and keep the breakage for others, which it seems some people would like to spin as Angstrom-hunting, which is of course, bull). Let's also not forget, this was a non-core change and did not even need an RFC. I strongly object to the notion that the feedback given until the commit in question wasn't taken into account. I feel it's quite a stunt to even suggest otherwise, especially since there's ample and public evidence to the contrary. I'm not saying that suggestions made *after* the commit couldn't and shouldn't have improved on the solution (instead of reverting). I do agree with Frans that there are still very many fuzzy areas as to what is permittable in OE and what not. I also agree with Frans that it's becoming increasingly difficult to "move OE forward", whatever that means for the individual. And yes, I see the conflict between fixing those two things. Both effects greatly decrease the fun to hack on OE, though, and has given OE a very slerotic feeling on my end lately. I fully understand Frans' feeling of "whatever you do in OE, you'll likely get burned". Frans, I hope I did not paraphrase your sentiments incorrectly. Feel free to correct me if I did. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
