On 2014-10-15 03:48 AM, Martin Pitt wrote: > Hello all, > > Steve Langasek [2014-10-14 13:24 -0700]: >>> I don't agree with the "highly limited in impact", but I do agree with >>> the compromise of putting the udev rule into kubuntu-default-settings. >>> While this isn't an appropriate long-term solution (i. e. it >>> definitively shouldn't be done that way in Utopic or at least not in >>> V), I don't know of a more appropriate place for an SRU. >> >> Note that this change is already present in utopic. Are you asking the >> Kubuntu team to revert this? > > Oh, you mean Utopic's kubuntu-default-settings already has that rule? > I understood it like we changed the kernel default scheduler in > utopic. #1378789 does not explain the fix in utopic, nor does it have > a package upload that closes the bug. I suppose this is a case where > the SRU is being done on a fresh "synthetic" bug instead of the real > bug report, and so it doesn't have all the relevant information. > > Anyway, now is not the time to change utopic's kernel default.
For the record, I disagree with the principle that a desktop environment should alter the scheduler settings, contrary to expected defaults or configuration set by the system administrator. Balloo relies on a specific scheduler to operate properly, which is quite unfortunate. While I'm not thrilled about a SRU to kubuntu-default-settings for trusty, I see no other viable option to solve this issue at the moment. Like others have mentioned, I also would like to see a minimum of regression testing be performed before this goes approved. I'd like a measurable way of determining if changing the scheduler does in fact solve the issue, without greatly penalizing Kubuntu users who submit their system to other disk i/o, such as large file operations, or the use of virtual machines. Marc. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board