Thinking about SRU

[Clint Byrum]

Excerpts from Ma Xiaojun's message of 2012-11-07 16:40:43 -0800:
> On Wed, Nov 7, 2012 at 5:14 PM, Benjamin Drung <bdrung at 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.
> 

This is the nature of a stable release. "Better the devil we know." This
is the reason why we ask for simple, easy to understand patches, or
require an extremely detailed testing plan if the patches are larger
than that. We don't want to just throw in upstream's latest awesomeness
without understanding how it might impact Ubuntu users. If there were
more resources available to backport and test these fixes, then we
would probably open it up to a wider selection of bugs. But as it stands,
the resources are too limited even for the current policy. The queues
for precise and quantal SRU reviews have been multiple-weeks long for
some eimte now.

> > 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.
> 

This is a resource issue, not a complexity issue.

I am an SRU team member, and one of our duties is to check that the
patch makes sense and actually does what its documentation says it
does. Even doing a lightweight skim over patches of languages I'm not
super comfortable with is something that scales logarithmically. The
more lines in the patch, the more I need to scan around in the files
and understand how each change impacts the whole program.

So, while I agree you can't estimate the risk just by counting lines
added/removed, you *can* estimate how long it will take to review it.

> > 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.
> 

Rar, and any other binary-only package (really anything in multiverse)
is not a good example. The bulk of the packages in Ubuntu are open source.