Thinking about SRU

[Rodney Dawes]

On Thu, 2012-11-08 at 15:42 -0600, Ma Xiaojun wrote:
> On Thu, Nov 8, 2012 at 1:55 PM, Clint Byrum <clint at ubuntu.com> wrote:
> > 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.
> 
> What you said is all right. I guess contributors generally don't throw
> a patch and leave. But I wonder whether Ubuntu developer generally
> ask.
> For me, I don't mind if the whole process being slow, say, spanning 6
> months to fix a simple bug.
> What I mind is that probably fixable bugs being marked WONTFIX prematurely.
> 
> Another annoying situation is that fix only goes to future release and
> the origin bug marked as FIXED. Though it's anyway a positive movement
> for Ubuntu, it hides the fact that the Ubuntu series that the bug
> raised is still broken. I don't know what's the best thing to do in
> this case.

Probably upgrade. Unless it's a supported package on a supported
release; it's very unlikely that the fix will get back-ported to the
older version. Some fixes are particularly problematic, because they
require very large unrelated changes to be included as well, because
upstream may have changed significantly from previous releases.


> > 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.
> 
> Repeat, you can ask if you don't understand. I think that's fair for both sides.

And the SRU team will reject anything that they can't reliably test for.
It's your job to provide the information that is documented as required
on the wiki, not the SRU team's job to keep asking people to provide
that info.


> > 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.
> 
> Probably a bad example, I don't know whether multiverse is part of Ubuntu.
> (non-free is not part of Debian?)

Multiverse is unsupported, and binary-only packages are extremely hard
to assess potential regressions for. Even packages in Universe are not
a good example, as most of them are not supported. However, getting SRUs
for things is really not all that difficult.

The best way to get SRUs done for packages you care about, that other
people aren't doing SRUs for, is to prepare them yourself. You will
likely get your bugs fixed, and learn a lot more about the SRU process
in doing so, and it will make Ubuntu better for yourself, and everyone
else as well.