Mythbuntu LTS plan

Matt Zimmerman mdz at ubuntu.com
Mon Jul 23 22:30:07 UTC 2012


It looks like you've gotten feedback from several folks by email, and we
reviewed at the meeting today to confirm that this proposal is approved.

On Fri, Jun 29, 2012 at 03:44:08PM -0500, Mario Limonciello wrote:
> Hi Kees,
> 
> The proposal is as it was originally (
> https://lists.ubuntu.com/archives/technical-board/2012-May/001258.html ),
> but there have been some clarifications in the thread for Colin and
> Stephane's questions.
> 
> Basically:
> 
> 1) Starting with 12.04, LTS only for Mythbuntu releases via ISO image.
> 2) We'll participate in LTS point releases, specifically for the new HW
> support coming at point releases.
> 3) We'll still participate in transitions and try to keep up with major
> bugs that are raised in the interim releases, prioritizing work on fixing
> things in LTS when possible.
> 4) We won't activate LTS->LTS upgrades until the first point release like
> Ubuntu does.
> 5) Users can still manually change upgrade options to interim releases and
> if they hit upgrade bugs we'll fix before next LTS, hopefully sooner
> depending upon priority.
> 
> And then we'll review how things went after T.
> 
> On Fri, Jun 29, 2012 at 3:19 PM, Kees Cook <kees at ubuntu.com> wrote:
> 
> > Hi Mario,
> >
> > Can you summarize the current plan? (Or point me to the proposal again,
> > if unchanged?) It wasn't clear to me as this thread grew if anything
> > about the proposal had changed.
> >
> > Thanks!
> >
> > -Kees
> >
> > On Fri, Jun 29, 2012 at 02:57:33PM -0500, Mario Limonciello wrote:
> > > Tech Board:
> > >
> > > Could we get a vote on approval for this?  We do have some things we'll
> > > need to get ready for the point release, so I'd like to make sure
> > everyone
> > > is in agreement on this plan.
> > >
> > > On Thu, May 31, 2012 at 9:42 AM, Mario Limonciello <superm1 at ubuntu.com
> > >wrote:
> > >
> > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > Mario Limonciello
> > > superm1 at gmail.com
> >
> > > --
> > > technical-board mailing list
> > > technical-board at lists.ubuntu.com
> > > https://lists.ubuntu.com/mailman/listinfo/technical-board
> >
> > --
> > Kees Cook
> >
> 
> 
> 
> -- 
> Mario Limonciello
> superm1 at gmail.com

> -- 
> technical-board mailing list
> technical-board at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board


-- 
 - mdz



More information about the technical-board mailing list