Re: Mythbuntu LTS plan
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 k...@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 supe...@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 supe...@ubuntu.comwrote: 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
Re: Mythbuntu LTS plan
2012/5/9 Mario Limonciello supe...@ubuntu.com: What does the tech board think of this proposal? I have nothing further to add other than it sounds like an interesting experiment, so a +1 from me. -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Mythbuntu LTS plan
On 07/03/2012 11:17 AM, Martin Pitt wrote: Mario Limonciello [2012-06-29 15:44 -0500]: 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. This trades a stream of continuous maintenance against a rather large hump of catching up with development every two years. But the total amount of effort of the latter should still be smaller, so if that approach works for you I see no reason not to try it. So +1 from me as well. Thanks! Martin +1 here too. Hoping this will work fine for you and we'll review after T. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Mythbuntu LTS plan
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 supe...@ubuntu.comwrote: 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 supe...@ubuntu.com -- Mario Limonciello supe...@gmail.com -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Mythbuntu LTS plan
On 05/09/2012 01:20 PM, Mario Limonciello wrote: Hi Tech Board, Kate Steward recommended that I should reach out to the tech board on behalf of the Mythbuntu team to help get agreement around the plan we want to follow for our releases going forward. I believe we're a bit different than the rest of the Ubuntu based flavors in that our users demand much less churn with their setups as they are generally HTPCs. We have done some analysis and consequently found that a majority of our user base gravitate toward LTS releases. We currently provide PPA's with stable builds of upstream fixes and new releases across an intersection of Ubuntu releases as dictated by our PPA page (www.mythbuntu.org/repos http://www.mythbuntu.org/repos). Upstream has integrated (opt in) statistics for usage, and LTS dominates (OS tab of http://smolt.mythtv.org/static/stats/stats.html). So with all of that said, our team all agrees that it makes more sense to only ship ISO images of LTS releases. We can continue to provide packages that work with the archive and misc transitions as the archive evolves during interim releases. But not creating ISO images at the new interim releases, we would help cater to what our users are asking for while being able to reduce our effort with every cycle in fixing every problem related to the ISO creation. We'd still like to spin updated point releases of the LTS releases, but no new features would be introduced during those point releases. That way we can still provide updates for the users introducing new hardware that they need the support from backported kernels and software stack versions. So we'll still be signed up for testing those respins, it should be a lot less effort than all the bugs that get introduced with interim releases and need to be fixed constantly throughout the cycle. What does the tech board think of this proposal? Thanks, -- Mario Limonciello supe...@gmail.com mailto:supe...@gmail.com 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? 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)? 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? 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)? -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
