[Pkg-mythtv-maintainers] Committed 0.7.0-1

[Ian Campbell]

Hi Mark,

Your reply didn't make it to me for some reason (via the list of private
mail) so I am cutting and pasting from the archive. Please could you CC
me on responses for the time being. Cheers.

> Trunk/debian/control still talks about the 0.6.x branch and kernel version 
> 2.6.16 :-(

Damn. Fix committed. Thanks.

>  I have filed an RC bug (#382780) to stop this release entering testing
> > until the 2.6.17 kernel propagates.
> 
> I've used that in the past and it should have the desired effect. Although I 
> have mainly used it to keep svn/ beta versions of packages out of testing.

I buggered it up and didn't use a version pseudo-header so one of the
release managers closed it -- I'll reopen once it is uploaded...

> > Before I started the 0.7.x work I branched the current trunk into
> > branches/0.6.x so we still have a route to update those packages in
> > testing if we need to. I doubt that will be necessary though.
> 
> That might not be as simple as it sounds.
> 
> I have done similar using unstable and experimental but not testing and 
> unstable.
> 
> From my example earlier we kept the released version under branches/ and 
> uploaded it and any changes to unstable, which then flowed through to 
> testing. We kept the beta versions of the software under trunk/ and released 
> into experimental.  That way the two were kept different and the software 
> under experimental had a 'higher' version number than that in 
> unstable/testing.  But because experimental doesn't flow into testing we 
> could unload fixes to the released version under branches and upload into 
> unstable/testing without worrying about experimental.
> 
> Now in the case of ivtv, we have 0.6.x in testing and if we upload 0.7.x to 
> unstable (blocked by a rc bug) then the two will coexist and won't overwrite 
> each other.  But if we wish to incorporate a fix into the 0.6.x package we 
> can't release into unstable (without an epoc) as 0.7.x > 0.6.x, and Debian 
> won't let us release directly to testing.

Hmm you may be right. What is the usage policy for testing proposed
updates? Presumably it is only for bug fixes during the freeze or
something. That wouldn't be so bad since I don't propose to upload new
upstream versions but only to correct any serious packaging errors etc. 

If 2.6.17 goes into testing before Etch then we can allow 0.7.x to
propagate. I don't know what the kernel team's plan is about kernel
versions for Etch...

> Also as these are independent, shouldn't we actually be packaging them 
> separately like you have done with ivtv0.[2,3,4,6] at hellion.

Since the plan upstream was to get them merged soon I didn't think it
was worth the effort. See bug #380155.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380155

> > Also, do you use the IVTV framebuffer output? I have some preliminary
> > packages of the ivtv X driver -- would you be willing to sponsor those?
> > Even if not I'd like to use the pkg-mythtv svn to maintain them so
> > unless you object I will check them into pkg-mythtv/xf86-video-ivtv
> > sometime soon.
> 
> I don't use it but happy to host under pkg-mythtv.

Thanks.

Cheers,
Ian.

-- 
Ian Campbell

Screw up your courage!  You've screwed up everything else.