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

Reply via email to