On Mon, Dec 1, 2014 at 6:17 PM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > 1) A problem is identified. > 2) Profile the problem and show where it might be happening. > 3) Some amount on fixing the problem is done. > 4) Find that the problem isn't there and there is no quick fix. > 5) Throw away that solution and implement another one. > 6) Deal with flame wars about any and all changes during this from people > the problem doesn't occur to. > > Projects which use words like "we" before 3 or 4 usually never get to 3 or 4 > due to the amount of "why is your problem now my work?" response from > everyone from developers to random people on the lists. > > Currently you are at 1, and you have tried to jump to 3 with the Arch > solution. You need to profile the Arch solution to see if it really works or > if it only works if you run an X11/twm and nothing fancier than Mosaic from > 1997. [Or without X11 at all.. that is the usual way to get a large power > improvement on a laptop.] Question: Shouldn't the evaluation and fix be targeted at Rawhide first, and then see about "backporting" demonstrated fixes to Fedora 21? For all we know now, these could be significant new features. Or alternatively a lot of work may have to be repeated if it turns out the problems don't occur, or the solutions are radically different, if Wayland is being used instead of X11. Further, the sample size is two models. Identifying a common source problem probably means looking at more hardware. -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
