<div dir="ltr"><div>Dear Bryan and all!<br><br>I think that the greatest problem nowadays is that reported bugs are not fixed and/or even triaged.<br>I have asked for support on <a href="http://community.ubuntu.com">community.ubuntu.com</a> (<a href="https://community.ubuntu.com/t/improving-bug-visibility/2626">https://community.ubuntu.com/t/improving-bug-visibility/2626</a>). But bug visibility is still low.<br>Sometimes I think to stop reporting bugs, but I want to make Ubuntu better. So I'll continue (<a href="https://bugs.launchpad.net/~nrbrtx">https://bugs.launchpad.net/~nrbrtx</a>).<br><br>As conclusion I can say the following - if "Monthly Update Cadence Proposal" will help to fix cosmetic (non-security, non-critical) bugs inside (or before) LTS lifecycle, than it would be really great. LTS must be stable and user-friendly.<br><br></div><div><br>With best regards,<br>Norbert.<div> <br></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 1, 2018 at 3:07 AM, Bryan Quigley <span dir="ltr"><<a href="mailto:bryan.quigley@canonical.com" target="_blank">bryan.quigley@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Instead of releasing a version of Ubuntu every 6 months, we release<br>
select core components of Ubuntu every month.  Updates to core<br>
components would need to be staggered so that no closely coupled<br>
components would see a major release within the same month.<br>
<br>
We'd provide a newsletter every month before the core components land<br>
and provide possible plans for the next 2 months.<br>
<br>
There would be at least one additional place (PPA) to test every core<br>
component update before it gets to -proposed.<br>
<br>
My hypothesis is that this will help create stability and make the<br>
monthly releases predictable enough that we will get more users than<br>
we currently have on our non-LTS releases.<br>
<br>
It would be possible to try this process for 18.10.  If it shows<br>
itself to be an improvement, we can keep doing it indefinitely.  If<br>
not, we can call it a failed experiment and release 18.10.<br>
<br>
I wrote a good bit more about this proposal, including a possible list<br>
of some core components and how the schedule would have worked for the<br>
past year - <a href="https://bryanquigley.com/pages/papers/ubuntu-monthly-update-cadence.html" rel="noreferrer" target="_blank">https://bryanquigley.com/<wbr>pages/papers/ubuntu-monthly-<wbr>update-cadence.html</a><br>
<br>
Thanks a bunch!<br>
<span class="HOEnZb"><font color="#888888">Bryan<br>
<br>
--<br>
Ubuntu-devel-discuss mailing list<br>
<a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com">Ubuntu-devel-discuss@lists.<wbr>ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/ubuntu-devel-<wbr>discuss</a><br>
</font></span></blockquote></div><br></div>