On Wed, Nov 7, 2012 at 5:14 PM, Benjamin Drung <bdr...@ubuntu.com> wrote: > This is covered by point four of the "When" section: "Bugs which do not > fit under above categories, but (1) have an obviously safe patch and (2) > affect an application rather than critical infrastructure packages (like > X.org or the kernel)."
The words here give me impression like this. Ubuntu devs don't want to touch a risky bug at all (unless it's about security or data loss), regardless of how stupid and broken the functionality is. > The question is: How big is the patch to fix the misbehavior? A > regression has more weight than a bug fix in a stable system. It's > easier to live with a known issue than to suddenly get a regression by > installing the updates. You cannot estimate risks just by looking at the size, it's simple and naive. Understand and test. > We need to get the fix in the development version first. Then we can > look at the required changes for the stable version. Who is going to review new "rar" package? It's not that interesting from packaging's point of view since "rar"'s upstream is just a bunch of closed source binaries. > The fix for this bug is currently going through the SRU process. As someone and I said many times, it is *not* a root fix. It let SSD users waste several seconds for input method startup and gives little help to people with slow environments. > I agree and these kind of fixes are covered by the SRU policy. If IBus > 1.4.2 is just a bug-fix release of upstream's 1.4.x branch, a SRU update > should be doable. Just someone needs to prepare the update, do all the > paperwork (test cases, analyze the regression potential). It's indeed the case: https://github.com/ibus/ibus/commits/1.4.y -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
