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 <[email protected]> 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 <[email protected] > > >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 < > > [email protected]>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 > > > >> [email protected] > > > >> > > > > > > > > > > > > > > > > -- > > > > Mario Limonciello > > > > [email protected] > > > > > > > > > > > > > > > > -- > > > Mario Limonciello > > > [email protected] > > > > > -- > > > technical-board mailing list > > > [email protected] > > > https://lists.ubuntu.com/mailman/listinfo/technical-board > > > > -- > > Kees Cook > > > > > > -- > Mario Limonciello > [email protected] -- Kees Cook -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
