Mythbuntu LTS plan

Mario Limonciello superm1 at ubuntu.com
Thu May 31 14:42:37 UTC 2012


Oh and yes I would like to review how well this has worked when we get
through the next LTS too.

On Wed, May 30, 2012 at 12:20 PM, Mario Limonciello <superm1 at ubuntu.com>wrote:

>  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 opinion.
>
>
>
> --
> Mario Limonciello
> superm1 at ubuntu.com
>



-- 
Mario Limonciello
superm1 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20120531/e9dd9234/attachment.html>


More information about the technical-board mailing list