Mythbuntu LTS plan

[Kees Cook]

Great, thanks.

This all seems fine to me. +1

-Kees

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
-- 
Kees Cook