Oh and yes I would like to review how well this has worked when we get through the next LTS too.<br><br><div class="gmail_quote">On Wed, May 30, 2012 at 12:20 PM, Mario Limonciello <span dir="ltr"><<a href="mailto:superm1@ubuntu.com" target="_blank">superm1@ubuntu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Thanks for the feedback Stephane and Colin.<div class="im"><br>
<br>
On 05/28/2012 04:09 PM, Colin Watson wrote:
<blockquote type="cite">
<pre></pre>
<pre>(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?
</pre>
</blockquote></div>
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.<div class="im"><br>
<br>
On 05/28/2012 04:31 PM, Stéphane Graber wrote:
<blockquote type="cite"><br>
<pre>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?</pre>
</blockquote></div>
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.<div class="im"><br>
<blockquote type="cite">
<pre>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)?
</pre>
</blockquote></div>
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.<br>
<br>
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.<div class="im"><br>
<br>
<blockquote type="cite">
<pre>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?</pre>
</blockquote></div>
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.<div class="im"><br>
<blockquote type="cite">
<pre>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)?
</pre>
</blockquote></div>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
<div>-- <br>
<font size="-2" face="Helvetica, Arial, sans-serif"><font color="#999999">Mario Limonciello</font><br>
<font color="#666666"><a href="mailto:superm1@ubuntu.com" target="_blank">superm1@ubuntu.com</a></font></font>
</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Mario Limonciello<br><a href="mailto:superm1@gmail.com" target="_blank">superm1@gmail.com</a><br>