Mythbuntu LTS plan

Mario Limonciello superm1 at
Wed May 30 17:20:08 UTC 2012

Thanks for the feedback Stephane and Colin.

On 05/28/2012 04:09 PM, Colin Watson wrote:
> (Speaking for myself alone) I have some qualms, mainly around whether
> you're going to be able to get good testing in the development release
> of things like Mythbuntu-specific installer changes if you stop testing
> the non-LTS images; but overall your rationale seems sound enough and I
> don't see why you shouldn't try this out.
> Do you intend to keep building dailies?  I think you might suffer some
> bitrot otherwise.
> Do you think we could review how this has gone after T?
Well I'm a little bit torn about building dailies.  I would prefer not 
to be wasting Canonical's resources for something that will be 
infrequently tested.  Now if we can leverage some sort of automatic test 
suite for the ISO image rather than only hand testing, I can see more 
value in this.  Alternatively, can ubuntu-defaults-builder be extended 
to do one off ISO builds for flavours too?  Then at least it would be 
possible to at least do ISO builds throughout development on demand as 
parts of the transitions happen.

On 05/28/2012 04:31 PM, Stéphane Graber wrote:
> Hi Mario,
> I can certainly see how that makes sense for Mythbuntu and I'm sure
> it'll be an interesting experiment.
> Just a few questions on top of Colin's:
> What's your plan regarding the usual work on the Mythbuntu related
> packages between LTS releases, are you planning on doing the usual
> merges/syncs/transitions and general FTBFS/NBS fixing even though you
> won't release images or are you planning to try and do it all in one
> shot before an LTS?
The current plan is to still keep up with the regular archive churn.  
With the python3 transition there have been a few things that have been 
looked at so far, but more to come.
> To respect the "fix things in development before you fix them in stable"
> rule, you'll have to do your bugfixes first in the current development
> release, then backport the bugfix to your LTS release.
> In some case this will likely mean working on two quite different fixes
> as things can change quite a bit during the two years between LTSes, are
> you comfortable with doing that?
> Are you also planning on uploading such bugfixes to intermediate release
> should there be demand for it (from outside Mythbuntu)?
At least with the tools that a lot of our users complain about bugs, we 
generally don't change the code base too drastically from release to 
release.  So hopefully I don't eat my words after we finish the python3 
transition (most of our tools are python), but I think this shouldn't be 
too big a deal to do fixes in development with the intention of bringing 
them back to the LTS after.

If there are users clamouring for bugfixes in the intermediate releases 
though, I'm happy to fix them there, we just need to make sure we're 
messaging that they won't be seeing them in ISO images for a while.  I 
expect there should be a significant drop in the number of people in 
these intermediate releases considering we're trying to guide the 
population to LTS.

> I'm also wondering whether you're planning on following and fixing
> reported bugs for anyone who's specifically upgrading from your latest
> LTS release to the following non-LTS release or plan on just dealing
> with all the upgrade bugs when working on the next LTS?
I think this will be a case by case basis.  Some of these bugs will 
certainly affect the next LTS so the sooner they're fixed the better.  
Others will just be kicked into a lower priority bucket.  Fortunately a 
majority of the "upgrade" related bugs end up being distro wide.  The 
bugs that we've seen specific to us on upgrade are usually pulling in 
unity on upgrade or a bad conflicts/replaces with other flavours.  Those 
are pretty straightforward, and certainly need to be fixed.
> And one last thought, though not really a big deal, as you won't have
> people upgrading from the latest non-LTS to the LTS, are you planning on
> allowing LTS-to-LTS upgrades at release time or also wait till the first
> point release to enable these (like Ubuntu does)?
I would prefer to wait until the first point release to enable this.  
It's an unnecessary complexity if we need to deviate from the Ubuntu 
plan of first point release.  We historically have a hard time testing 
people upgrading between releases because they like stable boxes, so the 
more time we can have to gather feedback and fix things the better in my 

Mario Limonciello
superm1 at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the technical-board mailing list