[Pkg-mythtv-maintainers] Bug#448893: Bug#448893: ivtv-utils will need to be upgraded in stable for "etch-and-a-half"

[dann frazier]

On Sun, Nov 04, 2007 at 06:09:21PM +0000, Ian Campbell wrote:
> 
> On Fri, 2007-11-02 at 08:01 -0400, Marc Sherman wrote:
> > Ian Campbell wrote:
> > > 
> > > What do I actually need to do? Prepare and upload a 1.0.3-1etch1 built
> > > against etch?
> > 
> > I'm not 100% sure. You should probably sync up with Dann Frazier; he 
> > seems to be running the show.
> 
> Thanks Marc.
> 
> Hi Dann,

hey Ian!

> What do you need from me for this etch-and-a-half kernel update? Is it
> as simple as preparing ivtv 1.0.3-2etch1 (-1 is currently in unstable
> but I hope -2 is about to go in soon) and asking my sponsor to upload to
> TPU or somewhere?

Well, nothing.. yet. We are planning to put 2.6.23 into sid before we
start a branch for etch 1/2. And, as this is new territory for us,
there are still a lot of unanswered questions.

The most important thing is that we do not risk breaking 2.6.18. Any
changes that affect 2.6.18 would only be accepted under the normal SRM
policies. In other words, if the SRMs wouldn't approve it for a point
release, we won't approve it for etch 1/2. Updating to a new upstream
release falls under this category.

What exactly that means for out-of-tree modules is a good question -
this probably needs to be looked at on a case-by-case basis. First
off, its not a requirement that hardware support for etch 1/2 be
on-par with etch. That is, just because we have ivtv for 2.6.18
doesn't mean we *have* to have it for 2.6.23. Obviously, having it
would be better than not, but since its still there for 2.6.18 we
won't consider it a regression. [I use mythtv/ivtv on etch myself, so
I'd certainly like to see it there :)]

For kernel-patch packages (at least the ones I've messed with), its
pretty straightforward to have separate patches for different kernel
versions, so it should be relatively simple to show that adding
support for 2.6.23 does not break 2.6.18 users.

For modules, my immediate thought is to find the first option below
that works:

 1) Does the existing version work with 2.6.23 as-is?
 2) Can support for 2.6.23 be easily added to the existing version in
    such a way that you can demonstrate low-risk of regressions for
    2.6.18? By this I mean the changes are small and easy to review,
    and perhaps are #ifdef'd to avoid changing behavior on 2.6.18.
 3) If we really need a new upstream version of the module, can you
    include the source to both modules such that the "old" version is
    used for 2.6.18, and the new for 2.6.23?
 4) As a last resort, we could consider adding a second package,
    e.g. ivtv-source-2.6.23. I don't really like this idea
    much because it seems pretty confusing for users. But, if prebuilt
    ivtv-modules packages are provided by one of the linux-modules-
    congolmeration packages, we can perhaps hide these details from
    them.

Anyway, I'm glad to see people already considering the impact of this,
thanks!

-- 
dann frazier