Pending SRU Request; What to do?

[Martin Pitt]

Hi Mario,

first, thanks a lot for this excellent summary of the situation.

Mario Limonciello [2007-11-19  2:25 -0600]:
> 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.

Ah, this is a piece of information that I missed. It is just
surprising that nobody complained about this during the development
cycle.

> <pitti> but I am not going to take responsibility for this

I might be overly cautious about it, indeed. It's because I review all
the SRUs for main, where we have very strict standards and policy of
what to accept. This naturally reflects to my judging of universe as
well.

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

So the ivtv backend specifically applies to the pvr-350, and no other
hardware? If we get testing confirmation on some other hardware which
also uses this driver I would have a much better conscience when
accepting this.

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

If that is true, then the SRU is appropriate.

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

Right, it's not official policy any more, but since this is not a
'standard' SRU, I wanted to get some more opinions.

>     * Any MOTU can decide that particular issue is good candidate for
>     SRU and can prepare the update package for <release>-proposed

I object to this bit of the current MOTU SRU policy since it toally
lacks peer review and acknowledgement. I raised this to the TB a week
ago, but did not get an answer yet. But redesigning the MOTU SRU
policy is a separate discussion, of course.

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

If my role for MOTU SRU is merely an archive monkey, then I wouldn't.
But since we currently do not have any peer review in MOTU SRU I
review the universe SRUs anyway to check them for sanity and errors,
and thus I think I do have some implicit responsibility.

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

I said that with my ubuntu-sru hat on, not with ubuntu-archive. In
principle you are right, we shouldn't need to do any in-depth review,
but *someone* should. Changing stable releases without *any* peer
review feels very wrong to me. At the moment I just (ab?)used my
archive admin hat to get a more in-depth discussion about non-obvious
SRUs like this one.

I hope that the outcome of the TB discussion is a sanitation of the
current MOTU SRU processs and reintroduction of peer review, so that
the burden of review is taken off my shoulders and put back to the
MOTUs.

Thank you,

Martin

-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20071119/f0b8b6e7/attachment.pgp