Pending SRU Request; What to do?

Mario Limonciello superm1 at
Mon Nov 19 08:25:15 GMT 2007

Hi Everyone,

Shortly after 7.10's release, during UDS I started to read a few forum
posts for people upgrading from 7.04 regarding their Hauppauge PVR-350
video output not working anymore.  The PVR-350's are not that common,
due to more inexpensive cards that perform similar functions available
from Hauppauge.  Also, even those using the cards don't typically use
the video output because it is limited to very specific timings and

Incidentally, IVTV was merged into kernel 2.6.21 with the current
PVR-350 video output API deprecated and scheduled to change.  For
2.6.22, this actually happened.  This was overlooked as there were no
testers during the 7.10 cycle using the PVR-350 for video output.

I tracked down the appropriate patch at the end of UDS, built it on a
PPA and had people who had contacted me with troubles test it out. 
After verifying it worked, I filed an SRU [1] for it with hopes of
clearing it so that future users would not have to hunt down the PPA.

When I returned from UDS, I verified it didn't break non pvr-350 IVTV
output by using it on two of my own machines running mythtv.

Now this was 3 weeks ago today that the bug was filed.  I had asked
Steve Langesek and Martin Pitt both in separate instances to ack the SRU. 

Quoting pitti from IRC:

<pitti> superm1: I did look at it, see
<ubotu> Launchpad bug 158562 in mythtv "PVR-350 Video output fails"
[Low,In progress]
<pitti> superm1: isn't there an actual *patch* which fixes the problem?
<superm1> pitti, the driver was rewritten to fix the problem
<superm1> pitti, which is what that patch is
<superm1> because it changed upstream ivtv
<pitti> right, but with that we don't know how many new problems it created
<pitti> i. e. we break mythtv for some people to fix it for others
<superm1> well none, because its only used for ivtv video output
<superm1> video input is a completely different subsystem
<superm1> and isn't that the point of the sru, to get further testing?
<pitti> the point of -proposed uploads is *not* to get initial testing
of questionable changes
<pitti> i. e. if changes are questionable they are not eligible for SRU
in the first place
<superm1> its not initial testing though
<pitti> as I said, if I get confirmation from the (former) MOTU SRU team
that this is wanted, I'm ok with it
<pitti> but I am not going to take responsibility for this


Now this brings me to address multiple problems with this:

(1) There is a worry about this patch inadvertently affecting other systems.
Referencing the SRU page on [2]


      A *patch* applicable to the stable version of the package. If
      preparing a patch is likely to be time-consuming, it may be
      preferable to discuss the first three items before preparing a
      patch. The patch must be as small and unintrusive as possible.

Well sure, this patch looks big, its a 66.7K debdiff.  This needs to be
taken beyond face value.  The API *changed, *meaning that a lot of the
function calls needed to be rewritten.  It's almost a blessing that myth
doesn't crash when trying to make the old calls in the first place for
those trying to use pvr-350 video output.  Now look a little closer at
the affected files:

    $ cat mythtv-ivtv-sru.debdiff | grep ^---
    --- mythtv-0.20.2/debian/changelog
    --- mythtv-0.20.2.orig/libs/libmythtv/videoout_ivtv.h
    --- mythtv-0.20.2.orig/libs/libmythtv/videodev2_myth.h
    --- mythtv-0.20.2.orig/libs/libmythtv/ivtv_myth.h
    --- mythtv-0.20.2.orig/libs/libmythtv/videoout_ivtv.cpp

There are a total of 4 files that are changed, with the majority of
changes in the 3 IVTV video output files.  The 4th file,
videodev2_myth.h is adding additional support for V4L2 calls.  Every
single line removal is matched with a line addition of the same line  or
increased support.  Existing calls to this file are consequently unaffected.

(2) Breadth of testing and number of regression possibilities
Referencing the SRU page on [2]

    A *discussion* of the regression potential of the patch and how
    users could get inadvertedly effected.

As I've tried to elaborate throughout all of this, there is very little
chance for regression here.  Users that want to use the PVR-350 video
output are not able to currently.  Users not using it won't be
affected.  I've already referred several people from the forums and IRC
to the PPA whom have been successful using the package.  I've tested it
myself on my machines to make sure nothing breaks.

(3) pitti is referencing asking the *former* MOTU SRU team.
Referencing the SRU page on [2]

    * Any MOTU can decide that particular issue is good candidate for
    SRU and can prepare the update package for <release>-proposed
    * The sponsor of the upload is responsible for testing the update,
    although responsibility for follow up thereafter may be negotiated
    between the sponsor and contributor.

Does this not mean the responsibility falls directly on the MOTU?  I
don't see how pitti would be taking responsibility for said problem.

Earlier this year, the MOTU SRU process was reviewed, with a
determination of the MOTU's role as well as the archive admin's role [3].
Here is a snipped from the meeting notes:


      The *motu*-sru team is not used.


      Archive admins don't check anything more than the version number
      when going to -proposed.

The MOTU SRU team isn't used at all.  Referencing their use seems like
an unnecessary burden here.  Also why are archive admins stepping up and
doing so much administrative work in reviewing all of the changes so in
depth in the first place?  My impression (especially after that meeting)
was that an Archive Admin had a much more clerical role instead.

Beyond my desires to get this SRU accepted, it appears that there is
still confusion here.  Would some other archive admins perhaps like to
give some input on where they see their role in community driven packages? 



Mario Limonciello
superm1 at

-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : 

More information about the ubuntu-devel mailing list