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