reflecting on first UDS session on "rolling releases"

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

reflecting on first UDS session on "rolling releases"

Allison Randal-3
There were a few things that concerned me in today's session on cadence
of rolling releases:

http://summit.ubuntu.com/uds-1303/meeting/21683/community-1303-rolling-release/

But, the biggest was at the very end when System76 said that two years
is too long between releases for their customers, but that they were
willing to at least *try* the new rolling releases. The reply was that
the rolling releases weren't expected to be stable enough to deliver to
customers. This surprised me, since "stability" is exactly the purpose
of rolling releases.

If the "rolling releases" really aren't intended for end-users, then we
should just drop the fiction, say the change is from a 6-month cadence
to a 2-year cadence, and be done with it.

Yes, it has all the problems we've come to know-and-hate with stale
applications. So, either allow SRU exceptions for more applications like
we do for Firefox, or start really supporting Backports for the LTS.

It's a waste of everyone's time and effort to rework the whole project
around talk of "rolling releases" when it's really just the same old
development release on a slower schedule. (Remember how we used to call
monthly images alphas and betas? That was ages ago, like 4 whole months.)

Allison

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Michael Hall
On 03/05/2013 06:49 PM, Allison Randal wrote:

> There were a few things that concerned me in today's session on cadence
> of rolling releases:
>
> http://summit.ubuntu.com/uds-1303/meeting/21683/community-1303-rolling-release/
>
> But, the biggest was at the very end when System76 said that two years
> is too long between releases for their customers, but that they were
> willing to at least *try* the new rolling releases. The reply was that
> the rolling releases weren't expected to be stable enough to deliver to
> customers. This surprised me, since "stability" is exactly the purpose
> of rolling releases.
>
> If the "rolling releases" really aren't intended for end-users, then we
> should just drop the fiction, say the change is from a 6-month cadence
> to a 2-year cadence, and be done with it.
>
> Yes, it has all the problems we've come to know-and-hate with stale
> applications. So, either allow SRU exceptions for more applications like
> we do for Firefox, or start really supporting Backports for the LTS.
>
> It's a waste of everyone's time and effort to rework the whole project
> around talk of "rolling releases" when it's really just the same old
> development release on a slower schedule. (Remember how we used to call
> monthly images alphas and betas? That was ages ago, like 4 whole months.)
>
> Allison
>

I think different segments of the community have different ideas of what
"stable" means:

Distro devs & power users: "stable" == "things don't break"

App devs, OEMS, NTEU: "stable" == "things don't change"


I think what we're going for in a rolling release is a release where
things change, but don't break.  While an LTS release is one where
things neither change nor break.

--
Michael Hall
[hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Scott Kitterman-3
On Tuesday, March 05, 2013 07:41:23 PM Michael Hall wrote:

> On 03/05/2013 06:49 PM, Allison Randal wrote:
> > There were a few things that concerned me in today's session on cadence
> > of rolling releases:
> >
> > http://summit.ubuntu.com/uds-1303/meeting/21683/community-1303-rolling-rel
> > ease/
> >
> > But, the biggest was at the very end when System76 said that two years
> > is too long between releases for their customers, but that they were
> > willing to at least *try* the new rolling releases. The reply was that
> > the rolling releases weren't expected to be stable enough to deliver to
> > customers. This surprised me, since "stability" is exactly the purpose
> > of rolling releases.
> >
> > If the "rolling releases" really aren't intended for end-users, then we
> > should just drop the fiction, say the change is from a 6-month cadence
> > to a 2-year cadence, and be done with it.
> >
> > Yes, it has all the problems we've come to know-and-hate with stale
> > applications. So, either allow SRU exceptions for more applications like
> > we do for Firefox, or start really supporting Backports for the LTS.
> >
> > It's a waste of everyone's time and effort to rework the whole project
> > around talk of "rolling releases" when it's really just the same old
> > development release on a slower schedule. (Remember how we used to call
> > monthly images alphas and betas? That was ages ago, like 4 whole months.)
> >
> > Allison
>
> I think different segments of the community have different ideas of what
> "stable" means:
>
> Distro devs & power users: "stable" == "things don't break"
>
> App devs, OEMS, NTEU: "stable" == "things don't change"
>
>
> I think what we're going for in a rolling release is a release where
> things change, but don't break.  While an LTS release is one where
> things neither change nor break.

Things are going to break.  I think the goal is for the development release
(AKA rolling) to be stable enough that breakage is rare and not beyond the
ability of advanced users to recover their systems.  I don't think it's a
release in any normal sense of the word.

We also break things in stable releases sometimes too, but we attempt to
provide a very low risk of this and a no regressions policy that causes any
regressions post-release to be a very high priority to address.

Both are going to change, it's a matter of what kinds of change are
appropriate to be applied with what level of risk.

Scott K

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Allison Randal-3
In reply to this post by Michael Hall
On 03/05/2013 04:41 PM, Michael Hall wrote:

>
> I think different segments of the community have different ideas of what
> "stable" means:
>
> Distro devs & power users: "stable" == "things don't break"
>
> App devs, OEMS, NTEU: "stable" == "things don't change"
>
>
> I think what we're going for in a rolling release is a release where
> things change, but don't break.  While an LTS release is one where
> things neither change nor break.

It wasn't stated as "you might prefer the LTS, many OEMs do". It was
stated as "you shouldn't deliver the rolling release to customers". And,
really, that does seem to fit the discussion threads. It doesn't sound
like it's possible to deliver a user experience in the rolling scenario
that would be high-enough quality for System76 to ship directly to
customers (and many of theirs are power users). Even people who are
totally on board with "rolling releases" are still calling it the
"development release".

Allison

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Robert Collins
In reply to this post by Allison Randal-3
On 6 March 2013 12:49, Allison Randal <[hidden email]> wrote:

> There were a few things that concerned me in today's session on cadence
> of rolling releases:
>
> http://summit.ubuntu.com/uds-1303/meeting/21683/community-1303-rolling-release/
>
> But, the biggest was at the very end when System76 said that two years
> is too long between releases for their customers, but that they were
> willing to at least *try* the new rolling releases. The reply was that
> the rolling releases weren't expected to be stable enough to deliver to
> customers. This surprised me, since "stability" is exactly the purpose
> of rolling releases.

It surprises me too. Google are doing regular updates - daily -
http://googlechromereleases.blogspot.com/ - so it is clearly doable.
Now it is true that Chromebooks have a vastly smaller surface area
than Ubuntu main, but surface area isn't the key with rolling release
stability.

IMNSHO The key with rolling release stability is making each change
small enough to validate properly. Thousand line updates are hard to
validate properly. Ten's of thousands of lines even less so. And we're
very dependent on upstream making sensible changes too.

With bzr we ran for some years with monthly releases and eventually -
largely to fit in with Ubuntu schedules - switched to 6 monthly. I
thought at the time that was a mistake, and I still do - the result of
a slower release schedule was more pressure to break compatibility in
each release (because the benefits of backwards compat were relatively
lower, as noone was expected to be depending on behaviour in interim
releases).

Launchpad got itself out of the doldrums by moving away from monthly
releases - with batched up QA and relatively large risky migrations -
to daily (multiple times a day now) releases, with every change
[intended to be] backwards compatible and safe to do incrementally. It
is slightly higher overhead on each change, but more than offset by
the ability to stop mid-arc and head in a different direction safely,
and rapid feedback about the suitability of changes (because you can
learn as you go rather than once you are finished).

tl;dr - you don't need a massive engineering team to do high quality
low breakage continual deployment. What you need is some supporting
automation and care and attention to detail on each change you *do*
make.

> If the "rolling releases" really aren't intended for end-users, then we
> should just drop the fiction, say the change is from a 6-month cadence
> to a 2-year cadence, and be done with it.

Agreed.

> Yes, it has all the problems we've come to know-and-hate with stale
> applications. So, either allow SRU exceptions for more applications like
> we do for Firefox, or start really supporting Backports for the LTS.
>
> It's a waste of everyone's time and effort to rework the whole project
> around talk of "rolling releases" when it's really just the same old
> development release on a slower schedule. (Remember how we used to call
> monthly images alphas and betas? That was ages ago, like 4 whole months.)

I think Adam's suggestion of treating all our uploads as things to do
phased exposure too, and using automatic signs - crashes and
exceptions from a small part of the userbase - to trigger a halt to
propogation, or even an automated reversal - a very good one.

A rolling release that isn't actually *always releasable* isn't a
rolling release.

Just saying.

-Rob


--
Robert Collins <[hidden email]>
Distinguished Technologist
HP Cloud Services

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Barry Warsaw-2
On Mar 06, 2013, at 02:31 PM, Robert Collins wrote:

>A rolling release that isn't actually *always releasable* isn't a
>rolling release.

In a different forum, some folks were advocating for never actually doing what
we'd traditionally call "a release" ever (of an upstream package).  There'd be
no such thing as an artificially version numbered tarball-like thing.  You'd
just point to whatever git branch and revision and/or tag you cared about, and
that would be it.

Try to imagine a world (or a distro) where everything just rolls along and is
always "releasable" because it always passes whatever automated tests and
gatekeepers are in place.  Crazy, huh?

-Barry

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Scott Kitterman-3
On Tuesday, March 05, 2013 10:14:05 PM Barry Warsaw wrote:

> On Mar 06, 2013, at 02:31 PM, Robert Collins wrote:
> >A rolling release that isn't actually *always releasable* isn't a
> >rolling release.
>
> In a different forum, some folks were advocating for never actually doing
> what we'd traditionally call "a release" ever (of an upstream package).
> There'd be no such thing as an artificially version numbered tarball-like
> thing.  You'd just point to whatever git branch and revision and/or tag you
> cared about, and that would be it.
>
> Try to imagine a world (or a distro) where everything just rolls along and
> is always "releasable" because it always passes whatever automated tests
> and gatekeepers are in place.  Crazy, huh?

What percentage of code in the default install is covered by automated tests?

For a relatively small project, such approaches are conceivable.  For
something the size of an installed Ubuntu (pick your favorite flavor) system, I
think we're a long ways away from being sufficiently instrumented with tests.

Scott K

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Robert Park
In reply to this post by Allison Randal-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13-03-05 03:49 PM, Allison Randal wrote:
> If the "rolling releases" really aren't intended for end-users,
> then we should just drop the fiction, say the change is from a
> 6-month cadence to a 2-year cadence, and be done with it.

That's how I've been interpreting this all along... 2-year release
cadence, and the current dev release is simply declared "rolling"
without any real changes. I don't see any issues with this: it's a
huge reduction in SRU burden while allowing more developer time to be
spent developing things.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJRNrxFAAoJEMnVpoCaWglE8LEQAKjjxWHj6vyWiteXxMJ36gWu
AzQjZ3L/OkAwE9N0Pr7pb3fSBTLx5+wIz7aMoRRkaSd4NpWUSLIeRmePCuGDdrHG
ZpNDdPWfJEHigEFIsTWCIMFzkJrpfFpQ7QD6Dqwfu/6EDeH38FBvsK6/AtIzRkry
Seh7/70muYqZRsZpapp6wvYOpExqOeaZ3CYzorfW84JQ9p1pCUonzCBT3ZjbLzpQ
vK9mGpdzQQAtftQ098kqH2QUIKXsYc6J0ayvFti8f76CcPw4AAhkAbLHEijEZkNn
4FM9YN8qdHyDg7fIF4LE9BpLdrqCv8uaFe9VmCw5dL57GMF4K7YNZZH5g5ikHjy1
9rPbrsd97T6u25oNa5r2otTZNilK4tqUijg+yUvlKZ6Khr845aPHed4sF3UVKCMu
sgZ3nRY6xeqCgUYVKM6ZPHbRmLYnYeE1BdzmTTko7Jv3eFsYHJsEeUp/4lMGupQd
P8ky43H9v0z//Ry5iWZZyQhV4WAJjw9H72M2WZNFHdi4UHNJK1Ny6s0iDyaqFlA4
DHUQCC8HjWZNmpdjYZURt3N4yGKkCQRDC+jViI1oxqvBg9GRGAqeOKzbxlcOipKS
WTs3Qc0yOmcWLdHqFvBkXLVB3FMCrLHgX4pT7sVh6jbdaspypKVCGKQepI09ZBoc
9ybxhyXxcroA6fiqrGA/
=ecem
-----END PGP SIGNATURE-----

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Jono Bacon-3
In reply to this post by Scott Kitterman-3
On Tue, Mar 5, 2013 at 7:43 PM, Scott Kitterman <[hidden email]> wrote:
> What percentage of code in the default install is covered by automated tests?

I am not sure, maybe the QA team can weigh in on this.

> For a relatively small project, such approaches are conceivable.  For
> something the size of an installed Ubuntu (pick your favorite flavor) system, I
> think we're a long ways away from being sufficiently instrumented with tests.

I agree: I think automated testing is going to be essential here to
*assure* quality across the system. I think we would need ensure that
we have good test coverage across the core components.

   Jono

--
Jono Bacon
Ubuntu Community Manager
www.ubuntu.com / www.jonobacon.org
www.identi.ca/jonobacon www.twitter.com/jonobacon

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Scott Kitterman-3
On Tuesday, March 05, 2013 08:07:36 PM Jono Bacon wrote:
> On Tue, Mar 5, 2013 at 7:43 PM, Scott Kitterman <[hidden email]>
wrote:

> > What percentage of code in the default install is covered by automated
> > tests?
> I am not sure, maybe the QA team can weigh in on this.
>
> > For a relatively small project, such approaches are conceivable.  For
> > something the size of an installed Ubuntu (pick your favorite flavor)
> > system, I think we're a long ways away from being sufficiently
> > instrumented with tests.
> I agree: I think automated testing is going to be essential here to
> *assure* quality across the system. I think we would need ensure that
> we have good test coverage across the core components.

I agree.  My main point is that such things are pre-requisites to a new
release model.  We don't have them, so we should get them before we change to
something we're not ready to support.

Scott K

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Jono Bacon-3
On Tue, Mar 5, 2013 at 8:13 PM, Scott Kitterman <[hidden email]> wrote:
> I agree.  My main point is that such things are pre-requisites to a new
> release model.  We don't have them, so we should get them before we change to
> something we're not ready to support.

My feeling here is that new processes and models need to have a level
of assurance that it is going to work. I am not averse to taking
risks, but there needs to be (a) a reasonable amount of reward to
justify the risks, and (b) enough assurance to ensure that the change
is not reckless. Of course the challenge in a community such as ours
is that we all have different definitions of risk and assurance - I
think the trick in this discussion is finding a good middle ground of
what is considered acceptable risk and requisite assurances.

   Jono

--
Jono Bacon
Ubuntu Community Manager
www.ubuntu.com / www.jonobacon.org
www.identi.ca/jonobacon www.twitter.com/jonobacon

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Robert Collins
In reply to this post by Scott Kitterman-3
On 6 March 2013 17:13, Scott Kitterman <[hidden email]> wrote:

> On Tuesday, March 05, 2013 08:07:36 PM Jono Bacon wrote:
>> On Tue, Mar 5, 2013 at 7:43 PM, Scott Kitterman <[hidden email]>
> wrote:
>> > What percentage of code in the default install is covered by automated
>> > tests?
>> I am not sure, maybe the QA team can weigh in on this.
>>
>> > For a relatively small project, such approaches are conceivable.  For
>> > something the size of an installed Ubuntu (pick your favorite flavor)
>> > system, I think we're a long ways away from being sufficiently
>> > instrumented with tests.
>> I agree: I think automated testing is going to be essential here to
>> *assure* quality across the system. I think we would need ensure that
>> we have good test coverage across the core components.
>
> I agree.  My main point is that such things are pre-requisites to a new
> release model.  We don't have them, so we should get them before we change to
> something we're not ready to support.

I don't see them as strict pre-requisites. Its like this: if you have
500% coverage you can still ship broken code. (100% coverage is not
complete coverage, because all (open source) coverage tools todate can
at most report branch coverage, not domain and range coverage (though
a http://en.wikipedia.org/wiki/Symbolic_execution based coverage
analysis would be pretty close). Once you have complete coverage all
you know is that you have claimed that your code should do what it
does, *not* that that is correct: you can still violate the
expectations of third party libraries and that leads to bugs.

What not enough tests *actually* means is that individual developers
making changes need to think harder. While there is a safety barrier
of 'noone really uses this' there is no driver for contributors to pay
attention to detail : they can fix any issue by another upload.
Exactly what conclusion to draw from that I'm not sure; will leave it
as an exercise for the reader.

-Rob

--
Robert Collins <[hidden email]>
Distinguished Technologist
HP Cloud Services

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Scott Kitterman-3
Robert Collins <[hidden email]> wrote:

>On 6 March 2013 17:13, Scott Kitterman <[hidden email]> wrote:
>> On Tuesday, March 05, 2013 08:07:36 PM Jono Bacon wrote:
>>> On Tue, Mar 5, 2013 at 7:43 PM, Scott Kitterman
><[hidden email]>
>> wrote:
>>> > What percentage of code in the default install is covered by
>automated
>>> > tests?
>>> I am not sure, maybe the QA team can weigh in on this.
>>>
>>> > For a relatively small project, such approaches are conceivable.
>For
>>> > something the size of an installed Ubuntu (pick your favorite
>flavor)
>>> > system, I think we're a long ways away from being sufficiently
>>> > instrumented with tests.
>>> I agree: I think automated testing is going to be essential here to
>>> *assure* quality across the system. I think we would need ensure
>that
>>> we have good test coverage across the core components.
>>
>> I agree.  My main point is that such things are pre-requisites to a
>new
>> release model.  We don't have them, so we should get them before we
>change to
>> something we're not ready to support.
>
>I don't see them as strict pre-requisites. Its like this: if you have
>500% coverage you can still ship broken code. (100% coverage is not
>complete coverage, because all (open source) coverage tools todate can
>at most report branch coverage, not domain and range coverage (though
>a http://en.wikipedia.org/wiki/Symbolic_execution based coverage
>analysis would be pretty close). Once you have complete coverage all
>you know is that you have claimed that your code should do what it
>does, *not* that that is correct: you can still violate the
>expectations of third party libraries and that leads to bugs.
>
>What not enough tests *actually* means is that individual developers
>making changes need to think harder. While there is a safety barrier
>of 'noone really uses this' there is no driver for contributors to pay
>attention to detail : they can fix any issue by another upload.
>Exactly what conclusion to draw from that I'm not sure; will leave it
>as an exercise for the reader.

As long as we're integrating externally developed code, we're at the mercy of upstream practices.  While Canonical has done a lot of work around upstream code it develops, that in no way translates across the archive.

If we can't fully guarantee functionality then code has to be landed somewhere and tested before it should be exposed to end users.

We have made a lot of progress on development release stability, but a few months of successwhile Debian is in freeze aren't enough to know where we are on the quality continuum yet.

Scott K



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Jonathan Carter (highvoltage)
In reply to this post by Allison Randal-3
Hi Allison

On 06/03/2013 01:49, Allison Randal wrote:
> There were a few things that concerned me in today's session on cadence
> of rolling releases:

Sad not to have made it, I had to be out at that moment. Thanks for the
summary!

> But, the biggest was at the very end when System76 said that two years
> is too long between releases for their customers, but that they were
> willing to at least *try* the new rolling releases. The reply was that
> the rolling releases weren't expected to be stable enough to deliver to
> customers. This surprised me, since "stability" is exactly the purpose
> of rolling releases.

I think that it would be a good idea to be armed with more information
before making big decisions like this, information that is out there but
possibly not properly harvested yet. Like, "Why is two years between
releases too long?". From my experience with a wide selection of
different kind of users, it comes down to this:

  * Hardware enablement
   * New Linux kernel
   * New Xorg (and friends) stack
  * Latest software
   * Desktop environment
   * Firefox/Thunderbird
   * LibreOffice
   * ... and some other popular ones but the list isn't that long

As far as I understand, a really good effort is already put into the
hardware enablement part in LTS. So hypothetically, if a dozen or so
packages were well updated and available somewhere for LTS, what would
be the gap that's left for users to find it useful and stick with it?

> If the "rolling releases" really aren't intended for end-users, then we
> should just drop the fiction, say the change is from a 6-month cadence
> to a 2-year cadence, and be done with it.

Sure this is anecdotal, but it covers 100+ 'normal' end users I've come
across, but for a large number of them, they /fear/ updates. Not like a
casual developer fear of "oh, this might blow up and I might have to fix
it", but a more primal, real level of fear of "Oh f**k. This might not
work and then I'm without my computer and then I'm totally screwed and I
won't know what to do!" kind of fear.

Also, is a monthly release intended to be less work than a 6-monthly
release? Because last I checked there wasn't enough manpower to pull off
a 6 month release without any very harsh bugs.

Basically, I agree that a rolling model for end users is fiction at this
stage, but I'm willing to trust the people coming up with the plan and
if they have some brilliant ideas around it then I'll certainly back it.

> Yes, it has all the problems we've come to know-and-hate with stale
> applications. So, either allow SRU exceptions for more applications like
> we do for Firefox, or start really supporting Backports for the LTS.

+1

> It's a waste of everyone's time and effort to rework the whole project
> around talk of "rolling releases" when it's really just the same old
> development release on a slower schedule. (Remember how we used to call
> monthly images alphas and betas? That was ages ago, like 4 whole months.)

IMHO it should really be worked on as "a proposal" rather than something
"that's happening now". Some people have asked me what I think of "the
rolling release proposal", but afaik there isn't really any real
proposal yet, it's all being actively worked on. It's hard to agree or
disagree with something that doesn't really exist yet. At this stage
it's all really just discussion and I think it's more healthy to assume
that things will continue working as they did before until the plan is
more formalized, rather than everyone jumping to their own conclusions
and working in different directions which would probably very negatively
affect a 13.04 release, if it should happen (which does indeed look more
and more unlikely).

But that's just me, I like to think that I'm reasonable and pragmatic,
but perhaps I'm just getting old and too guarded.

-Jonathan

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Allison Randal-3
In reply to this post by Robert Park
On 03/05/2013 07:47 PM, Robert Bruce Park wrote:
>
> That's how I've been interpreting this all along... 2-year release
> cadence, and the current dev release is simply declared "rolling"
> without any real changes. I don't see any issues with this: it's a
> huge reduction in SRU burden while allowing more developer time to be
> spent developing things.

I don't have a problem with a 2-year cadence either. It's a sound
engineering plan.

The risk comes in building up a lot of hoopla about rolling releases
being a stable replacement for the 6-month cadence, not investing the
resources required to really develop/support rolling releases "right
now", and then failing to deliver anything remotely close to the
stability of the prior 6-month releases. It's better to under-promise
and succeed beyond expectations, than to over-promise and appear to fail.

It's easy enough to declare a 2-year cadence, and say that rolling
releases are an idea we'll be working on and plan to have solid after
the 14.04 release. That leaves time and space to do things right, and
only announce they're ready when they really are ready.


This still leaves the question of how best to support OEMs like
System76, and the Flavors. But I think jonathan is on the right track
with LTS + key package sets (or 13.04 + key package sets, if that's
declared the "final" 6-month release).

Allison

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Matthew Paul Thomas
In reply to this post by Michael Hall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Hall wrote on 06/03/13 00:41:

>
> On 03/05/2013 06:49 PM, Allison Randal wrote:
>>
>> There were a few things that concerned me in today's session on
>> cadence of rolling releases:
>>
>> http://summit.ubuntu.com/uds-1303/meeting/21683/community-1303-rolling-release/
>>
>>
>>
But, the biggest was at the very end when System76 said that two
>> years is too long between releases for their customers, but that
>> they were willing to at least *try* the new rolling releases. The
>> reply was that the rolling releases weren't expected to be stable
>> enough to deliver to customers. This surprised me, since
>> "stability" is exactly the purpose of rolling releases.

This was the argument System76's Carl Richell gave against two-yearly
releases: "I don't think Windows or OS X or Chrome OS are going to
release in such a long time. And I'd also look at 11.04, for instance.
If we installed 11.04 on our computers, and used it for a week, is
that how we would want Ubuntu represented commercially? Because that
would be the result of a two-year release cycle."
<http://www.youtube.com/watch?v=4FN_S9PoMC8#t=1m24s>

I don't understand the first part of that argument. Windows 7 and 8
were, actually, both released two years after the previous version. OS
X had 18-to-24-month releases for over a decade, switching to yearly
releases only with 10.7 and 10.8. And Chrome OS has little UI or APIs
of its own, so (I assume) it has less difficulty in keeping "stable"
in any sense of the word.

The second part of the argument is that if 11.04 had been an LTS, with
the new model it would still be the latest Ubuntu release today, and
11.04 was awful. But that is unfair. 11.04 was awful precisely because
we (well, not me, but others;-) thought it was important to land Unity
as early as possible to prepare it for 12.04 LTS a year later. If we
had been doing two-yearly releases only, it would not, I hope, have
landed in that state.

>> If the "rolling releases" really aren't intended for end-users,
>> then we should just drop the fiction, say the change is from a
>> 6-month cadence to a 2-year cadence, and be done with it.

There are three parts to Rick's proposal:
1.  dropping non-LTS releases
2.  making the development version a "rolling release" stable enough
    for enthusiast use
3.  introducing monthly snapshots.

But any one of those could be done without doing the others. I have
seen no argument that any of them would depend on either of the others.

> ...
>
> I think different segments of the community have different ideas
> of what "stable" means:
>
> Distro devs & power users: "stable" == "things don't break"

Possibly more precisely: "crashes and other errors don't happen".

> App devs, OEMS, NTEU: "stable" == "things don't change"
>
> ...

Each of those are different, too.

App developers: "stable" == "APIs don't change".

OEMs: "stable" == "hardware compatibility doesn't break".

Non-technical end users: "stable" == "buttons don't move around".

Naturally there is some overlap in what those groups care about. And
there is some overlap in how we control those different types of
stability. But as with the word "support", the word "stable" has just
too many meanings in software discussions to be useful without a
modifier. It's not hard to be precise: use terms like "reliable",
"API-stable", "compatible", and "familiar".

- --
mpt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlE3UIcACgkQ6PUxNfU6ecoTvQCgi38Z7I2j79CfIAvdOerxPWyM
x6oAoI65nYY6s4S2xy59ARXcrVXkDue3
=/VrT
-----END PGP SIGNATURE-----

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Rodney Dawes-5
In reply to this post by Allison Randal-3
On Tue, 2013-03-05 at 17:06 -0800, Allison Randal wrote:

> On 03/05/2013 04:41 PM, Michael Hall wrote:
> >
> > I think different segments of the community have different ideas of what
> > "stable" means:
> >
> > Distro devs & power users: "stable" == "things don't break"
> >
> > App devs, OEMS, NTEU: "stable" == "things don't change"
> >
> >
> > I think what we're going for in a rolling release is a release where
> > things change, but don't break.  While an LTS release is one where
> > things neither change nor break.
>
> It wasn't stated as "you might prefer the LTS, many OEMs do". It was
> stated as "you shouldn't deliver the rolling release to customers". And,
> really, that does seem to fit the discussion threads. It doesn't sound
> like it's possible to deliver a user experience in the rolling scenario
> that would be high-enough quality for System76 to ship directly to
> customers (and many of theirs are power users). Even people who are
> totally on board with "rolling releases" are still calling it the
> "development release".

I think the problem is the use of the word "release" for the rolling
archive.
It's not a release. It's a constantly changing archive, where we have
some
automated testing to try to prevent things breaking. Also, there is a
history
of Ubuntu's 6-monthly releases being perceived as stable, when they
weren't
necessarily. After LTS was introduced, they started becoming more of the
"shake things up a bit in between LTS" releases that we have now, and
while
generally stable as in "things mostly don't break" they have had some
rather
large changes in them from the previous version.

OEMs wouldn't ship rawhide, Firefox nightlies, Windows beta, etc… to
their
users, so why would they do it with Ubuntu?

As far as what Ubuntu OEMs ship to users, System76 seems to be the
exception
more than the rule.

If I were building hardware and shipping it with an OS on it, I'd ship
the
LTS and/or LTS point releases with HWE stack, rather than interim
releases,
and certainly not the rolling archive. With the rolling archive, they
could
ship hardware that works fine one day, and a kernel regression or
something
could slip in unnoticed, and then all their customers with that hardware
might
have a system that won't boot after installing updates the next day.
It's
just a bad plan all around to go that route. I understand they want to
ship
the new shiny, as early and often as possible, but I don't think it's a
feasible plan to do so. If there are certain things they think must get
shipped
to customers, then maybe it wouldn't be a bad idea for them to work more
with
the OEM team at Canonical to get things done, similar to how Dell and
other
OEMs do.



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Scott Kitterman-3
On Wednesday, March 06, 2013 09:59:14 AM Rodney Dawes wrote:

> On Tue, 2013-03-05 at 17:06 -0800, Allison Randal wrote:
> > On 03/05/2013 04:41 PM, Michael Hall wrote:
> > > I think different segments of the community have different ideas of what
> > > "stable" means:
> > >
> > > Distro devs & power users: "stable" == "things don't break"
> > >
> > > App devs, OEMS, NTEU: "stable" == "things don't change"
> > >
> > >
> > > I think what we're going for in a rolling release is a release where
> > > things change, but don't break.  While an LTS release is one where
> > > things neither change nor break.
> >
> > It wasn't stated as "you might prefer the LTS, many OEMs do". It was
> > stated as "you shouldn't deliver the rolling release to customers". And,
> > really, that does seem to fit the discussion threads. It doesn't sound
> > like it's possible to deliver a user experience in the rolling scenario
> > that would be high-enough quality for System76 to ship directly to
> > customers (and many of theirs are power users). Even people who are
> > totally on board with "rolling releases" are still calling it the
> > "development release".
>
> I think the problem is the use of the word "release" for the rolling
> archive.
> It's not a release. It's a constantly changing archive, where we have
> some
> automated testing to try to prevent things breaking. Also, there is a
> history
> of Ubuntu's 6-monthly releases being perceived as stable, when they
> weren't
> necessarily. After LTS was introduced, they started becoming more of the
> "shake things up a bit in between LTS" releases that we have now, and
> while
> generally stable as in "things mostly don't break" they have had some
> rather
> large changes in them from the previous version.
>
> OEMs wouldn't ship rawhide, Firefox nightlies, Windows beta, etc… to
> their
> users, so why would they do it with Ubuntu?
>
> As far as what Ubuntu OEMs ship to users, System76 seems to be the
> exception
> more than the rule.
>
> If I were building hardware and shipping it with an OS on it, I'd ship
> the
> LTS and/or LTS point releases with HWE stack, rather than interim
> releases,
> and certainly not the rolling archive. With the rolling archive, they
> could
> ship hardware that works fine one day, and a kernel regression or
> something
> could slip in unnoticed, and then all their customers with that hardware
> might
> have a system that won't boot after installing updates the next day.
> It's
> just a bad plan all around to go that route. I understand they want to
> ship
> the new shiny, as early and often as possible, but I don't think it's a
> feasible plan to do so. If there are certain things they think must get
> shipped
> to customers, then maybe it wouldn't be a bad idea for them to work more
> with
> the OEM team at Canonical to get things done, similar to how Dell and
> other
> OEMs do.

I'm sure it wouldn't be a bad idea for Canonical to have a new customer for
OEM services.

I just checked and ZaReason (who also doesn't pay Canonical OEM services)
offers both Ubuntu 12.04 and 12.10.  They also offer Kubuntu and Edubuntu 12.04.  

I don't know how many companies are shipping Ubuntu flavors based off of the
public distribution, but of the two I know of, both offer the current release.

Scott K

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Jonathan Carter (highvoltage)
In reply to this post by Matthew Paul Thomas
On 06/03/2013 16:19, Matthew Paul Thomas wrote:
> There are three parts to Rick's proposal:
> 1.  dropping non-LTS releases
> 2.  making the development version a "rolling release" stable enough
>      for enthusiast use
> 3.  introducing monthly snapshots.

Thanks for that. Apologies if it's been posted before and I somehow
missed it, but is there a wiki page or something with the proposal as it
exists today?

-Jonathan

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: reflecting on first UDS session on "rolling releases"

Allison Randal-3
On 03/06/2013 07:13 AM, Jonathan Carter (highvoltage) wrote:
> On 06/03/2013 16:19, Matthew Paul Thomas wrote:
>> There are three parts to Rick's proposal:
>> 1.  dropping non-LTS releases
>> 2.  making the development version a "rolling release" stable enough
>>      for enthusiast use
>> 3.  introducing monthly snapshots.

As the conversation runs on, these "enthusiasts" appear to be a smaller
and smaller subset of the Ubuntu user base. So, we're investing enormous
engineering effort in a small subset of users, and very little
engineering effort in the user experience of the "majority" of users on
the LTS.

Also remember that, as the idea currently stands, the tiny set of
"enthusiasts" are the only people who will get updated versions of
applications. The majority of users will have a stale experience, and no
reasonable alternative.

> Thanks for that. Apologies if it's been posted before and I somehow
> missed it, but is there a wiki page or something with the proposal as it
> exists today?

Not yet. The idea is still in rapid flux on the mailing list and in UDS
sessions. I anticipate a draft proposal on wiki.ubuntu.com in a week-ish
after UDS.

Allison

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
123