Tag Archives: Rolling Release

Linux

Bryan Quigley: Rolling Release – w/ Upstream Stable Cadence, Upstream Beta Cadence, and Limited Delta Buffer

Leave a comment

Upstream Stable Cadence

We track upstreams, what they consider stable, we consider stable, we ship in rolling release under *conditions.

Upstream Beta Cadence

We track upstreams beta/rc repo, what they consider “almost stable”, we consider worth getting extremely easy user testing.  We try to ship in Rolling Release archive, but with different package names.  This will not work for everything.   Some upstreams don’t really have RC/beta releases, others might be too complicated to keep in repo.

For example, meta-packages for:  firefox-beta, linux-rcs, etc.
Goal would be to evaluate doing this with packages in main only.  Others, like all of Gnome, might need a different plan.

Data.  Lots of data.

We need data that we can get an idea of how stable a product is. Some combination of reported bugs, automatic bugs, weighted in different ways.
The data should be generated from both the beta  and stable releases.

We also need to better connect users of the beta releases to upstream, faster, when they have a problem.

“Limited Delta Buffer” (*conditions)

First – Big changes to stable release separated by 3 weeks initially.  New Kernel and new Xorg both want to get in?  Only 1 get’s in every 3 weeks.  In this case I would suggest letting the kernel go first, then three weeks later Xorg get’s in.   This limits the volatility of the rolling release by limiting updates from all coming at the same time.
Second – Data driven modifications to buffering time, who get’s in first, and what blocks what.    For a new kernel the data would come from that exact kernel in the beta package,   If we find that the kernel never breaks anything and is super stable, move it to just a one week buffer.
Third – refine if we consider upstream to be “wrong”.  Maybe Linux kernel rc3 and above is all we ship in beta package, etc.

Rationale: We need a new concept of a stable system for a Rolling Release.  It should take advantage of and contribute to upstreams own stabilization procedures (their “beta cadence”) while limiting the rate of change (delta) users of the rolling release need to deal with.   As for using ‘Months’, they are way to arbitrary.  Some months there will be nothing interesting, others we could have a new kernel, Xorg, Unity, and Gnome.

Obviously, this isn’t perfect and needs a bunch more refinement, I just wanted to get this out there before March 18th (the deadline for proposals).  Thanks for reading and please let me know what you think.

 

…read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Mark Shuttleworth: Let’s go faster while preserving what works best

Leave a comment
;-)

It’s been two weeks since Rick Spencer made the case for a rolling release approach in Ubuntu. Having a rolling release is one of the very top suggestions from the hardcore Ubuntu user community, and after years of it being mooted by all and sundry I thought it deserved the deep consideration that Rick and his team, who represent most of Canonical’s direct contributions to Ubuntu, brought to the analysis.

It’s obviously not helpful to have mass hysteria break out when ideas like this get floated, so I would like to thank everyone who calmly provided feedback on the proposal, and blow a fat raspberry at those of you who felt obliged to mount soapboxes and opine on The End Of the World As We Know It. Sensible people the world over will appreciate the dilemma at being asked to take user feedback seriously, and being accused of unilateralism when exploring options.

Change is warranted. If we want to deliver on our mission, we have to be willing to stare controversy in the face and do the right thing anyway, recognising that we won’t know if it’s the right thing until much later, and for most of the intervening time, friends and enemies alike will go various degrees of apoplectic. Our best defense against getting it wrong is to have a strong meritocracy, which I think we do. That means letting people like Rick, who have earned their leadership roles, explore controversial territory.

So, where do we stand? And where do I stand? What’s the next step?

What makes this conversation hard is the sheer scale of the Ubuntu ecosystem, all of which is profoundly affected by any change. Here are the things I think we need to optimise for, and the observations that I think we should structure our thinking around:

Releases are good discipline, cadence is valuable.

Releases, even interim releases, create value for parts of the Ubuntu ecosystem that are important. They allow us to get more widespread feedback on decisions made in that cycle – what’s working, what’s not working. Interestingly, in the analysis that played into Rick’s proposal, we found that very few institutional users depend on extended support of the interim releases. Those who care about support tend to use the LTS releases and LTS point releases.

Release management detracts from development time, and should be balanced against the amount of use that release gets.

While reaffirming our interest in releases, I think we established that the amount of time spend developing in a cycle versus spent doing release management is currently out of whack with the amount to which people actually DEPEND on that release management, for interim releases, on the desktop. On the server, we found that the interim releases are quite heavily used in the cloud, less so on physical metal.

Daily quality has raised the game dramatically for tip / trunk / devel users, and addresses the Rolling Release need.

There’s widespread support for the statement that ‘developers can and should use the daily development release’. …read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Joel Pickett: UDS-1303, Day One

Leave a comment

Now UDS-1303 Tuesday is through, I’d like to recap on a couple of the sessions I watched on Google+ Hangouts.

Rolling Release discussion (+1 maintenance beyond April)

Interesting discussion which included some of the System76 folks that basically said that the Ubuntu release schedule works fine for their clients. They ship the latest LTS, 12.04, and the current stable release, 12.10. They pointed out that each release of Ubuntu has been a clear improvement over the previous release (phew!), and were looking forward to the upcoming Raring Ringtail. Very compelling to hear straight from the OEM vendors – they have been shipping Ubuntu for the past fifteen (yes, that’s 15!) releases.

Rick Spencer outlined the idea to keep LTS releases and focus on daily quality with monthly pulses. I think this is an interesting concept in relation where Ubuntu is as a platform. If this idea had been discussed around the days that I started as an Ubuntu user (Intrepid Ibex era), the daily quality was just not there. It was more of a sentiment to encourage users not to use the development build until the later alpha snapshots, or even beta releases.

These days I’ve been using the Quantal and Raring dailies with minimal disruption, essentially my desktop and laptops feel like a normal (release) install. It’s just that updates are much more frequent and I’m using the latest available version of the software.

Loco discussion (LoCo community – what’s next?)

Another interesting discussion was the concept of approved and unapproved LoCo teams. I’m a member of the Australian LoCo, which is currently approved. As Jono stated in the session, I think there’s less of a need for approved LoCo teams now. The main benefit of being an approved LoCo is that, historically, LoCos would be sent CD’s/DVD’s, stickers and other Ubuntu merchandise around releases and conferences. This isn’t particularly sustainable to send a pack to all approved LoCos each release, and arguably more people are using other media like USBs to install Ubuntu.

The other concern was the labelling and divide of LoCo teams. It should be noted that being an unapproved team doesn’t make you any less important than an approved LoCo. At the end of the day, LoCos will be recognised for the work that they do, supported by Planet Ubuntu blog posts, pictures of events (release parties, conference talks, Ubuntu Hours, Ubuntu Global Jam sessions) and team reports.

Thoughts on the first online UDS

On the whole, I think it went quite fine. I think if the LTS release structure is continued, I think a physical week-long UDS would be appropriate at least once through the LTS cycle. It’s also a positive bonus that everything is logged and the sessions are available once the session ends for people that have missed the session. These short UDS place a focus on detailed discussion, though if anything is missed, we’ll be able to revisit it again at the next UDS in a few months or on ubuntu-devel.

It would have been nice for Mark Shuttleworth to comment …read more
Source: FULL ARTICLE at Planet Ubuntu