> >>- We're dealing with the symptom, not the cause. Almost always a bad idea. > > > >I very much prefer to have a fix for a symptom than no fix at all, which is the > >realistic alternative in this case. > > > >So, I think we should merge the patch and if someone finds the root cause > >at one point in future, then we can just use the *right* approach instead of > >the present one. > > > >The problem is real and people in the field are affected by it, so if you don't > >have a working alternative patch, please just let go. > > I'm not denying that the problem is real. What I am concerned about > is finding a real solution, not just putting a sticky plaster over > the wound. It seems to me to be much wiser to deal with the issue > properly now instead of doing extra work later to diagnose what > might be a harder to reproduce symptom of the same problem. I'd > happily put the time in now myself, but I simply don't have the time > this week. > > Would it be possible to apply the patch, adding some sort of new tag > that can be used to say "This needs further attention", perhaps > including an enduring reference to this conversation. Later, the > 'real' fix could include another special tag that says "Proper fix > for the symptom addressed in commit 5e94f810"? WARN_ON() whenever patch triggers? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
