Re: Follow Up from Let's Discuss Interim Releases

[Vincent Ladeuil]

 Clint Byrum cl...@ubuntu.com writes:

 I actually think this is already how many server/cloud users use Ubuntu
 right now anyway. Run the LTS as your core, encapsulate your custom apps
 in containers/virtualenvs/rvms/etc.

Indeed. And this goes both ways: you can run a precise container on
raring as well as a raring container on precise.

Can we make this smooth enough that an app developer can ship a precise
version on raring to enjoy API stability in the container while still
running on newer versions until the newer LTS can be targeted directly ?
Or instead, deliver raring containers for precise with more testing.
Will it be simpler for app devs than just targeting all releases in a
PPA ? Both probably apply to different workflows/team sizes.

The same issue remains though, who test what ?

To me, the real question is identifying the various testing populations
and relate them to each release, whether you use a dev release or an LTS
with additional PPAs or not is directly related to the amount of testing
received/expected/accepted. 

After releasing bazaar for some years, I encountered a weird conclusion:
whoever uses bazaar (across all releases) is really running a revision
that was the tip of the trunk. Bug fixes on stable releases have been
minor. In the end, I wasn't testing before releasing, I was releasing
what has already been tested (across releases thanks for CI). I
perfectly realize that one package is not an OS, but there are some
similarities.

For any software, whatever is released *has* been tested. The question is:
how does that relate to me ? How close from my use cases/hardware were
those tests ? 

What this really means, IMHO, is that the back of the crowd attitude,
while understandable (and accepted) is just waiting to see if others die
in flames, but most of the time, they just dive happily in the water
(getting fresher and more fish ;).

Nevertheless, +1 on btrfs to rollback a broken upgrade ;)

   Vincent


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Thierry Carrez]

Robert Collins wrote:
 On 11 March 2013 23:12, Thierry Carrez t...@ubuntu.com wrote:
 Robert Collins wrote:
 
 A - an archive that we place a high friction change process on,
 intended to eliminate regressions [the SRU]
 B - a logical name that users can associate with a /large/ bundle of
 changes. One can say 'Unity in Raring is fantastic' only because
 Raring is a thing.
 C - A set of APIs that work well together and which we commit to keep
 working for the duration of the release (except where it is infeasible
 [e.g. due to facebook dropping their support for the server side of an
 API].
 D - A mostly unchanging environment. No surprises.
 [...]

 Today, it's also [E] an install media.
 
 I don't agree here. There is [E] an install media in the 'what is a
 release', but 'has unchanging install media' is not an important thing
 in any user story I have seen so far. Dailies *from the released
 archive* are fine *today*, if we chose to publish them. AFAICT there
 are no use cases or user expectations to fail that are tied to how
 often install media are updated vs the already covered aspects.

I'm not saying you can't use dailies to care for getting an install
media. You were listing what, technically, a release means today. I'm
just saying that as of today, releases also mean a reference install
media.

 About LTS mode ('keep my behaviour unchanged') I suspect every n years
 you'll have to create another LTS mode. For people who want their
 behaviour unchanged but from a reasonably modern starting point. How do
 you handle that ?
 
 It is just a combination of options - feature flag values, so you
 could name each LTS combination 'precise' etc.
 
 Or you could take a less orchestrated approach and just allow saying
 'give me the default behaviour new installs had on date'. Then
 deprecation of support for a given thing is directly tied into that,
 and the UI can show people who are lagging warnings without needing to
 translate codenames.

I'm not sure I understand how this configuration would work,
especially with security updates. I'm probably missing something, so
let's have an example. Let's say I install Ubuntu on January 1st, 2014
and set it to LTS mode. I get Gnucash 2.5. Alice does the same on
February 1st, 2014 and grabs Gnucash 2.6. Bob does the same on March
1st, 2014, gets Gnucash 3.0, which introduces a very large behavior
change. In May, a vulnerability is discovered that affects all versions
up to 3.0.1. The security team has to backport the fix to 2.{5,6} and
3.0 because all those LTS users expectation is that they will get keep
me secure with my behavior unchanged mode ?

Or are you saying that Gnucash 3.0, like all other packages in the
archive, should have a config option that says compatibility=2.x that
would preserve any past behavior, letting the security team happily only
patch Gnucash 3.0 ?

 With a well-oiled release process, the cost is not high. And keeping
 that logical name to describe a point in time has benefits: reference
 install media, time-based cycle to focus development community, media
 attention, LTS mode starting point, easy way to describe a set of APIs
 and everything else you have in [B] above.

 If you think of a release not in term of upgrade and maintenance but
 in terms of a development milestone and a breathing rhythm, I think the
 benefits outweigh the costs. And it's certainly compatible with the rest
 of your proposal.
 
 I don't understand what you mean by 'point in time' here. Could you
 expand on that?

I mean keeping the association between a name and a period in time.
Raring is the development cycle that started in November 2013 and ends
in April 2014.

Then you can anchor a number of things to that artificial rhythm you
created: sets of API versions for your API deprecation policy, reference
install media if you still want them, common community development
cycle, etc.

My point is that there is value in having a cadence, and the cost of
special-casing a few dates is not that high to pay.

-- 
Thierry Carrez (ttx)
Ubuntu core developer

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Robert Collins]

On 12 March 2013 23:07, Thierry Carrez t...@ubuntu.com wrote:
 I'm not saying you can't use dailies to care for getting an install
 media. You were listing what, technically, a release means today. I'm
 just saying that as of today, releases also mean a reference install
 media.

Ack.


 I'm not sure I understand how this configuration would work,
 especially with security updates. I'm probably missing something, so
 let's have an example. Let's say I install Ubuntu on January 1st, 2014
 and set it to LTS mode. I get Gnucash 2.5. Alice does the same on
 February 1st, 2014 and grabs Gnucash 2.6. Bob does the same on March
 1st, 2014, gets Gnucash 3.0, which introduces a very large behavior
 change. In May, a vulnerability is discovered that affects all versions
 up to 3.0.1. The security team has to backport the fix to 2.{5,6} and
 3.0 because all those LTS users expectation is that they will get keep
 me secure with my behavior unchanged mode ?

So, if gnucash is supported - that is, if its part of the APIs and
behaviour we have *committed* to preserving, that 3.0 upload wouldn't
happen *until* we had figured out how to preserve behaviour for the
users that had started on 2.x.

If gnucash isn't supported, if its just in universe, then the security
team isn't on the hook, and we would just have uploaded 3.0.1 with the
fix.

So lets assume it is supported: There are two broad avenues to
preserving the behaviour it had with the 3.0 introduction.
a) versioned installs. We do a little transition dance and end up with
gnucash2 and gnucash as separate packages. In this approach nearly no,
or even no code changes are needed to gnucash, but we pay a
maintenance cost indefinitely.
b) feature flags. We (or upstream) restore (or keep in the first place
- much easier to do it that way) the 2.x behaviour when this 'large
change' is coming in 3. The default is the latest upstream behaviour,
but a user/system wide config can easily tell gnucash to revert to the
2.x behaviour. In this approach we only have one package, and we just
update it with the security release.

 Or are you saying that Gnucash 3.0, like all other packages in the
 archive, should have a config option that says compatibility=2.x that
 would preserve any past behavior, letting the security team happily only
 patch Gnucash 3.0 ?

Not *all other packages*. *all packages that are supported*. There is
a hugely long tail of packages. It doesn't make sense to me that we
pay an overhead premium to provide no-regression behaviour on packages
used by 0.01% of the userbase. Such users can band together and
request that we provide no-regression behaviour in a few ways: they
can contribute the fixes themselves to upstream; they can contribute
them to us, or they can hire a proxy to do that.

Providing totally seamless behaviour across versions isn't /hard/ - it
is straight forward engineering most of the time, the real issue is
deciding that:
 - it is worth doing
 - who is going to do it.

 I don't understand what you mean by 'point in time' here. Could you
 expand on that?

 I mean keeping the association between a name and a period in time.
 Raring is the development cycle that started in November 2013 and ends
 in April 2014.

 Then you can anchor a number of things to that artificial rhythm you
 created: sets of API versions for your API deprecation policy, reference
 install media if you still want them, common community development
 cycle, etc.

Sure, thanks for clarifying. I was thinking database PITR, which is a
very different thing :).

 My point is that there is value in having a cadence, and the cost of
 special-casing a few dates is not that high to pay.

It depends a *great* deal on the implications of that special casing.
LEAN teaches that your cycle time - the time it takes do your
plan-execute-learn-plan loop is the big definer for your agility -
your ability to respond to changing needs from your users. 6 months is
a very long interval for responding in a software project delivering
products for the cloud. 4-6 weeks would be a much better interval, I
think. But thats a different discussion :).

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Cloud Services

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Otus]

On Fri, Mar 8, 2013 at 6:51 AM, Robert Bruce Park
robert.p...@canonical.com wrote:
 Although I feel quite strongly about my support for the rolling
 release model, if it is rejected, we can't continue as we used to. We
 simply do not have the resources to support more than two releases at
 a time. I'd prefer to only have to support LTS+rolling, but LTS+one
 interim at a time would be an acceptable second best.

If you need/wish to cut down the number of supported releases all the
way down to two at a time (from current ~5) there are really only two
options:

1. Cut LTS support from 5 to 4 years, do not offer support for the
rolling dev version.
2. Cut LTS support from 5 to ~2 years, support a single release
(rolling or non-LTS) in addition.

Either way the LTS release, which OEMs and (some) ISVs presumably
depend on, would need a shorter support period. Two years of LTS
support seems completely untenable, so that only really leaves one
path forward, if two releases are indeed the maximum that can be
supported. It comes down to simply cutting all non-LTS releases and
shaving a year off LTS support.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Thierry Carrez]

Robert Collins wrote:
 On 12 March 2013 23:07, Thierry Carrez t...@ubuntu.com wrote:
 I'm not sure I understand how this configuration would work,
 especially with security updates. I'm probably missing something, so
 let's have an example. Let's say I install Ubuntu on January 1st, 2014
 and set it to LTS mode. I get Gnucash 2.5. Alice does the same on
 February 1st, 2014 and grabs Gnucash 2.6. Bob does the same on March
 1st, 2014, gets Gnucash 3.0, which introduces a very large behavior
 change. In May, a vulnerability is discovered that affects all versions
 up to 3.0.1. The security team has to backport the fix to 2.{5,6} and
 3.0 because all those LTS users expectation is that they will get keep
 me secure with my behavior unchanged mode ?
 
 So, if gnucash is supported - that is, if its part of the APIs and
 behaviour we have *committed* to preserving, that 3.0 upload wouldn't
 happen *until* we had figured out how to preserve behaviour for the
 users that had started on 2.x.
 
 If gnucash isn't supported, if its just in universe, then the security
 team isn't on the hook, and we would just have uploaded 3.0.1 with the
 fix.
 
 So lets assume it is supported: There are two broad avenues to
 preserving the behaviour it had with the 3.0 introduction.
 a) versioned installs. We do a little transition dance and end up with
 gnucash2 and gnucash as separate packages. In this approach nearly no,
 or even no code changes are needed to gnucash, but we pay a
 maintenance cost indefinitely.
 b) feature flags. We (or upstream) restore (or keep in the first place
 - much easier to do it that way) the 2.x behaviour when this 'large
 change' is coming in 3. The default is the latest upstream behaviour,
 but a user/system wide config can easily tell gnucash to revert to the
 2.x behaviour. In this approach we only have one package, and we just
 update it with the security release.

Understood. IMHO that LTS mode would significantly reduce the benefits
compared to the current LTS. Current LTS promises to keep
you secure with a behavior mostly unchanged. It gives you unchanged
behavior for 99% of the packages in the archive, perfect security
support for main, and best-effort-but-still-good security support for
everything else.

It looks like to avoid turning it into a maintenance nightmare, your
LTS mode would have to significantly reduce the scope of supported
packages: only a very limited set of packages would both be preserving
behavior *and* be security-supported. Everything else would have to drop
one or the other (most likely deciding to abandon preserving behavior).

Not saying that means this is unreasonable, just detailing how your LTS
mode differs from what LTS currently provides :)

-- 
Thierry Carrez (ttx)
Ubuntu core developer

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Phillip Susi]

On 3/9/2013 6:45 AM, Otus wrote:

On Fri, Mar 8, 2013 at 6:51 AM, Robert Bruce Park
robert.p...@canonical.com wrote:

Although I feel quite strongly about my support for the rolling
release model, if it is rejected, we can't continue as we used to. We
simply do not have the resources to support more than two releases at
a time. I'd prefer to only have to support LTS+rolling, but LTS+one
interim at a time would be an acceptable second best.


If you need/wish to cut down the number of supported releases all the
way down to two at a time (from current ~5) there are really only two
options:


I am pretty sure he meant all supported LTS count as one, and the goal 
is to not have more than one non LTS supported.




--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Dmitrijs Ledkovs]

On 12 March 2013 17:23, Phillip Susi ps...@ubuntu.com wrote:
 On 3/9/2013 6:45 AM, Otus wrote:

 On Fri, Mar 8, 2013 at 6:51 AM, Robert Bruce Park
 robert.p...@canonical.com wrote:

 Although I feel quite strongly about my support for the rolling
 release model, if it is rejected, we can't continue as we used to. We
 simply do not have the resources to support more than two releases at
 a time. I'd prefer to only have to support LTS+rolling, but LTS+one
 interim at a time would be an acceptable second best.


 If you need/wish to cut down the number of supported releases all the
 way down to two at a time (from current ~5) there are really only two
 options:


 I am pretty sure he meant all supported LTS count as one, and the goal is to
 not have more than one non LTS supported.


LTS releases must overlap to allow for upgrades. Plus the benefit of
LTS is its longer support, e.g. even reaching beyond the next two LTS
release.

Regards,

Dmitrijs.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Robert Collins]

On 13 March 2013 03:57, Thierry Carrez t...@ubuntu.com wrote:
 Robert Collins wrote:


 Understood. IMHO that LTS mode would significantly reduce the benefits
 compared to the current LTS. Current LTS promises to keep
 you secure with a behavior mostly unchanged. It gives you unchanged
 behavior for 99% of the packages in the archive, perfect security
 support for main, and best-effort-but-still-good security support for
 everything else.

I think that is overselling the current LTS. I would say it gives you
approximately no security support for 90% of the archive. Many smaller
projects don't issue CVEs when they have a defect, and the only way
you have security support is if you get a new release. The SRU process
is excruciatingly slow [by choice, it is an engineering tradeoff].

 It looks like to avoid turning it into a maintenance nightmare, your
 LTS mode would have to significantly reduce the scope of supported
 packages: only a very limited set of packages would both be preserving
 behavior *and* be security-supported. Everything else would have to drop
 one or the other (most likely deciding to abandon preserving behavior).

The thing about having a user base of millions of users is that those
incompatibilities become a massive force multiplier for packages used
by any significant % of the user base. Folk that proxy for large user
bases will naturally want to minimise the cost of accomodating such
changes - and the LTS cycle allows them to reduce repeated
incompatible changes to the same thing, by folding them all together.
However for distinct incompatible changes, the LTS cycle only serves
to bundle them together, making the time to adjust to a release larger
and slower (which provides backpressure on the frequency of releases,
but the further apart the releases are the greater the bundled
changes it is a vicious cycle).

And yet preserving behaviour over and above what upstream does is an
extraordinary thing to do. Backported security fixes are work upstream
didn't do, for instance.

Assertion: Generally speaking upstreams expect folk to upgrade every
time they release. And they are surprised and unhappy when folk don't
*and* they get bug reports from users running old releases. This isn't
just the web space - even old plumbing tools like gcc and automake
care about this (and you can tell, *because* they talk about backward
compat... if they didn't expect immediate upgrades and [transient]
skewed user populations, backwards compat becomes much less
important).

The /normal/ thing upstreams expect is that they do a release that is
compatible, with *perhaps* a small number of documented
incompatabilities, and users upgrade near immediately.

So I'm not suggesting more or less work, I'm suggesting that we *take
the work where it belongs* - in upstream, *when* the incompatible
change is being made.

Old: (N incompatible changes upstream, then M backported security
fixes for 5 years) per LTS
New: (N would-have-been-incompatible changes enhanced to be compatible
via a config option).

If N is larger than 3M(*) then it is a wash. If N is  3M, then this
is clearly more efficient, and will also most folk that run trunk of
such projects have an easier time.

*) 3M because (LTS 2 years apart, 5 year life - 2 LTS's, + 1 current
release under Mark's 7 month support proposal)

 Not saying that means this is unreasonable, just detailing how your LTS
 mode differs from what LTS currently provides :)

Yeah - it is good to spell it out.
-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Cloud Services

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Thierry Carrez]

Thierry Carrez wrote:
 Robert Collins wrote:
  - Move the concept of using 'a release of Ubuntu' to using 'a
 configuration' - LTS is 'keep my behaviour unchanged', interim
 releases are 'give me new features when they are production quality'
 and 'development edition' is 'give me new stuff as soon as it enters
 the archive'.
 
 About LTS mode ('keep my behaviour unchanged') I suspect every n years
 you'll have to create another LTS mode. For people who want their
 behaviour unchanged but from a reasonably modern starting point. How do
 you handle that ?

Elaborating on that, LTS mode is actually keep me secure with my
behaviour unchanged. That means backporting security fixes to the
behavior unchanged state. If you don't want to drive your security
team crazy, you'll need a limited set of discrete states. That's another
role releases (as milestones) fill for you.

-- 
Thierry Carrez (ttx)


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2013-03-11 03:12:45 -0700:
 Robert Collins wrote:
  One thing I think has been missing from the discussion so far has been
  in reviewing our *definition* of a release. There was some mention of
  defining what Ubuntu is - how big the surface area we maintain, vs app
  developers maintain and deliver /on/.
  
  I'd like to decompose 'Release' though. Technically, it means a number
  of things today:
  A - an archive that we place a high friction change process on,
  intended to eliminate regressions [the SRU]
  B - a logical name that users can associate with a /large/ bundle of
  changes. One can say 'Unity in Raring is fantastic' only because
  Raring is a thing.
  C - A set of APIs that work well together and which we commit to keep
  working for the duration of the release (except where it is infeasible
  [e.g. due to facebook dropping their support for the server side of an
  API].
  D - A mostly unchanging environment. No surprises.
  [...]
 
 Today, it's also [E] an install media.
 

Not sure that is any different than B. I installed using raring install
media. Or I failed to install using raring install media. If you plan
for a changing core, the install media is just a vehicle to get on the
crazy train.

  So, here is an alternative approach to solving these four things while
  still integrating upstream changes etc.
  
  tl;dr version:
   - Identify a really small set of APIs to support, and set LTS
  timeframes on them. Examples - boot configuration, networking,
  graphics, etc.
   - For new APIs set timeframes that reflect their maturity (and
  support them for that timeframe).
   - Support those APIs for that timeframe irrespective of upstream -
  but in selecting them discuss that with upstream.
   - Use feature flags to decouple 'new code release' from 'new
  behaviour' for the platform itself - Unity, indicators etc.
   - For key upstream applications (e.g. using data from popcon) make
  sure we allow co-installability of multiple versions. (libreoffice may
  be an example of this).
   - Move the concept of using 'a release of Ubuntu' to using 'a
  configuration' - LTS is 'keep my behaviour unchanged', interim
  releases are 'give me new features when they are production quality'
  and 'development edition' is 'give me new stuff as soon as it enters
  the archive'.
 
 About LTS mode ('keep my behaviour unchanged') I suspect every n years
 you'll have to create another LTS mode. For people who want their
 behaviour unchanged but from a reasonably modern starting point. How do
 you handle that ?
 

I believe what Robert was advocating was just a configuration that does
not move behavior forward. So each LTS is a configuration that does not
move forward.  The LTS cut today is not special from the one cut tomorrow.

   - Stop doing fixed releases altogether.
 
 Once we adopt the rest of your proposal, what would be the added cost of
 actually still doing releases, that could serve as reference points in
 time and install media ?
 

As you stated in your follow up, the more frozen states there are,
the more states the security team has to ensure work with the new
configuration/patched software.

 With a well-oiled release process, the cost is not high. And keeping
 that logical name to describe a point in time has benefits: reference
 install media, time-based cycle to focus development community, media
 attention, LTS mode starting point, easy way to describe a set of APIs
 and everything else you have in [B] above.
 
 If you think of a release not in term of upgrade and maintenance but
 in terms of a development milestone and a breathing rhythm, I think the
 benefits outweigh the costs. And it's certainly compatible with the rest
 of your proposal.
 

I see those benefits too. I think the cost of backporting fixes is what
has grown too high in proportion to the other costs. So if one can keep
moving the majority of software forward, and only have to backport fixes
to a minimal core, then releases of that core still do make sense.

I actually think this is already how many server/cloud users use Ubuntu
right now anyway. Run the LTS as your core, encapsulate your custom apps
in containers/virtualenvs/rvms/etc.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Robert Collins]

On 11 March 2013 23:25, Thierry Carrez t...@ubuntu.com wrote:
 Thierry Carrez wrote:
 Robert Collins wrote:
  - Move the concept of using 'a release of Ubuntu' to using 'a
 configuration' - LTS is 'keep my behaviour unchanged', interim
 releases are 'give me new features when they are production quality'
 and 'development edition' is 'give me new stuff as soon as it enters
 the archive'.

 About LTS mode ('keep my behaviour unchanged') I suspect every n years
 you'll have to create another LTS mode. For people who want their
 behaviour unchanged but from a reasonably modern starting point. How do
 you handle that ?

 Elaborating on that, LTS mode is actually keep me secure with my
 behaviour unchanged. That means backporting security fixes to the
 behavior unchanged state. If you don't want to drive your security
 team crazy, you'll need a limited set of discrete states. That's another
 role releases (as milestones) fill for you.

I think you misunderstood the definition of configurations. Its not a
discrete state for the security team to care for. It is solely an
option in the various programs which have user visible behaviour that
was all of
a) changed upstream during the LTS lifetime
b) something we thought users might depend on so preserved via a
configuration flag
c) in a supported [core] package

This is a much smaller surface area than full copies of packages which
the security team deals with today. Obviously there is increased risk
of *accidental* behaviour alteration as a trade off.

-Rob


-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Cloud Services

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Robert Collins]

On 11 March 2013 23:12, Thierry Carrez t...@ubuntu.com wrote:
 Robert Collins wrote:

 A - an archive that we place a high friction change process on,
 intended to eliminate regressions [the SRU]
 B - a logical name that users can associate with a /large/ bundle of
 changes. One can say 'Unity in Raring is fantastic' only because
 Raring is a thing.
 C - A set of APIs that work well together and which we commit to keep
 working for the duration of the release (except where it is infeasible
 [e.g. due to facebook dropping their support for the server side of an
 API].
 D - A mostly unchanging environment. No surprises.
 [...]

 Today, it's also [E] an install media.

I don't agree here. There is [E] an install media in the 'what is a
release', but 'has unchanging install media' is not an important thing
in any user story I have seen so far. Dailies *from the released
archive* are fine *today*, if we chose to publish them. AFAICT there
are no use cases or user expectations to fail that are tied to how
often install media are updated vs the already covered aspects.



 About LTS mode ('keep my behaviour unchanged') I suspect every n years
 you'll have to create another LTS mode. For people who want their
 behaviour unchanged but from a reasonably modern starting point. How do
 you handle that ?

It is just a combination of options - feature flag values, so you
could name each LTS combination 'precise' etc.

Or you could take a less orchestrated approach and just allow saying
'give me the default behaviour new installs had on date'. Then
deprecation of support for a given thing is directly tied into that,
and the UI can show people who are lagging warnings without needing to
translate codenames.

  - Stop doing fixed releases altogether.

 Once we adopt the rest of your proposal, what would be the added cost of
 actually still doing releases, that could serve as reference points in
 time and install media ?

In my proposal you would not do reference points in time in the sense
of a distinct series with frozen packages. So it is a question that
doesn't apply. Install media should churn out daily (or more often if
there is a need).

 With a well-oiled release process, the cost is not high. And keeping
 that logical name to describe a point in time has benefits: reference
 install media, time-based cycle to focus development community, media
 attention, LTS mode starting point, easy way to describe a set of APIs
 and everything else you have in [B] above.

 If you think of a release not in term of upgrade and maintenance but
 in terms of a development milestone and a breathing rhythm, I think the
 benefits outweigh the costs. And it's certainly compatible with the rest
 of your proposal.

I don't understand what you mean by 'point in time' here. Could you
expand on that?

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Cloud Services

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Chow Loong Jin]

On 10/03/2013 09:35, Scott Kitterman wrote:
 [...]
 There's still the requirement to keep things in sync.  That's what I was
 referring to.  Also, for many common targets for SRUs/late bug fixes that are 
 actively maintained, the packages in the development release would quickly 
 diverge and so you'd still have to do two sets of patches.  Except for 
 reduced 
 QA requirements, it doesn't seem to offer much over release and SRU and I'm 
 not 
 sure reduced QA is actually a feature.

I don't really see an issue with having to maintain two sets of patches, really.
If we're going to have a rolling release as well as make stable releases,
maintaining two sets of patches for the SRUable changes is a minimum, and
something we should stick to.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Scott Kitterman]

Chow Loong Jin hyper...@ubuntu.com wrote:

On 10/03/2013 09:35, Scott Kitterman wrote:
 [...]
 There's still the requirement to keep things in sync.  That's what I
was
 referring to.  Also, for many common targets for SRUs/late bug fixes
that are 
 actively maintained, the packages in the development release would
quickly 
 diverge and so you'd still have to do two sets of patches.  Except
for reduced 
 QA requirements, it doesn't seem to offer much over release and SRU
and I'm not 
 sure reduced QA is actually a feature.

I don't really see an issue with having to maintain two sets of
patches, really.
If we're going to have a rolling release as well as make stable
releases,
maintaining two sets of patches for the SRUable changes is a minimum,
and
something we should stick to.

First, I find the term rolling 'release' to be off the mark. It's not a release 
at all. It's the development series made more usable. 

You're correct that once the development series is branched and there is both a 
development series and a stabilization branch on it's way to becoming a release 
it's pretty inevitable that two sets of changes will be needed.   There will 
need to be process and structure around this so that checks are in place to 
make sure that changes to one branch are not lost to the other.

I'm not claiming this is any kind of a deal breaker. I do think it's an 
essential part of any proposed restructuring of our development process that 
the proposal describe how we would do an actual release and I haven't seen it 
yet.

Scott K



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Scott Kitterman]

On Thursday, March 07, 2013 05:19:35 PM Rick Spencer wrote:
...
 1. Move to a rolling release similar to what I proposed in the
 original straw man.
...

One thing I have not seen described (or possibly I missed it - there's been a 
lot of traffic on this topic) is how the transition from It's rolling to 
We're getting ready to release an LTS would happen?  

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Phillip Susi]

On 03/09/2013 12:29 PM, Scott Kitterman wrote:

One thing I have not seen described (or possibly I missed it - there's been a
lot of traffic on this topic) is how the transition from It's rolling to
We're getting ready to release an LTS would happen?


Yes, there hasn't been much discussion on that yet.  I see two possible 
options:


1)  In the say, 3 months leading up to LTS, we impose a freeze.  This 
would be basically what debian does, where they freeze testing, fix 
bugs, then finally release that as the new stable release. Then after 
the stable release, we open a new archive for the next development 
release.  The down side to this is that for that time, new development 
stops.


2)  Rather than upload to raring, then freeze, then release raring as 
stable, change the model slightly so we have uploads going to the 
unstable release.  Then say, 3 months prior to the deadline for the 
new stable release, we open a new archive for that release, and copy the 
unstable release to it.  Then bugs would be fixed in the stable release, 
while new development can continue concurrently in unstable.




--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Scott Kitterman]

On Saturday, March 09, 2013 02:56:55 PM Phillip Susi wrote:
 On 03/09/2013 12:29 PM, Scott Kitterman wrote:
  One thing I have not seen described (or possibly I missed it - there's
  been a lot of traffic on this topic) is how the transition from It's
  rolling to We're getting ready to release an LTS would happen?
 
 Yes, there hasn't been much discussion on that yet.  I see two possible
 options:
 
 1)  In the say, 3 months leading up to LTS, we impose a freeze.  This
 would be basically what debian does, where they freeze testing, fix
 bugs, then finally release that as the new stable release. Then after
 the stable release, we open a new archive for the next development
 release.  The down side to this is that for that time, new development
 stops.
 
 2)  Rather than upload to raring, then freeze, then release raring as
 stable, change the model slightly so we have uploads going to the
 unstable release.  Then say, 3 months prior to the deadline for the
 new stable release, we open a new archive for that release, and copy the
 unstable release to it.  Then bugs would be fixed in the stable release,
 while new development can continue concurrently in unstable.

Your option two seems somewhat similar to the situation we end up with now 
when just after release, we don't have a development series and SRUs are 
uploaded to the current release and later forward copied to the development 
version when it's ready.  This can be a pretty labor intensive, error prone 
process.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Philip Muskovac]

On Saturday 09 March 2013 14:56:55 Phillip Susi wrote:
 On 03/09/2013 12:29 PM, Scott Kitterman wrote:
  One thing I have not seen described (or possibly I missed it - there's
  been a lot of traffic on this topic) is how the transition from It's
  rolling to We're getting ready to release an LTS would happen?
 
 Yes, there hasn't been much discussion on that yet.  I see two possible
 options:
 
 1)  In the say, 3 months leading up to LTS, we impose a freeze.  This
 would be basically what debian does, where they freeze testing, fix
 bugs, then finally release that as the new stable release. Then after
 the stable release, we open a new archive for the next development
 release.  The down side to this is that for that time, new development
 stops.
 
 2)  Rather than upload to raring, then freeze, then release raring as
 stable, change the model slightly so we have uploads going to the
 unstable release.  Then say, 3 months prior to the deadline for the
 new stable release, we open a new archive for that release, and copy the
 unstable release to it.  Then bugs would be fixed in the stable release,
 while new development can continue concurrently in unstable.

The *good* side of being frozen and stopping development, is that you actually 
force people to stop developing and instead concentrate on testing and fixing 
bugs. The moment you open a new development branch developer attention will 
turn to that instead of stabilizing the LTS.

(Sure, people will focus on the LTS too, but it won't be the same as when 
that's the only thing you can concentrate on)

Philip

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Robert Collins]

On 8 March 2013 14:19, Rick Spencer rick.spen...@canonical.com wrote:
 Hi all,

 There has been a lot of discussion and impact around the strawman
 proposal for changing our release cadence that I sent last Thursday.
 There was a misconception that the proposal was a decision that I was
 masking as a call for discussion. I want to reassure everyone that I
 really did mean it as a discussion. I feel passionately that we need
 to change and innovate in this area, but a change like this cannot
 succeed, or in fact be made, without discussion in the community and
 proper governance.

FWIW it was clearly a proposal, not a fait accompli being announced,
at least for me :).

 Discussion of this topic on the mailing list and at UDS this week was
 wide ranging. There were a lot of divergent opinions and ideas. The
 discussion seems to have resulted in roughly three different forms of
 proposals.

 1. Move to a rolling release similar to what I proposed in the
 original straw man.
 2. Continue to release interim releases but only support them until
 roughly the next interim release 6 months later.
 3. Dramatically increase the rate of our releases to, say, once per month.

 I've attempted to capture the essence of these proposals (and
 associated sub-proposals) along with a structure for points and
 counterpoints in wiki format to support honing and organizing. They
 are currently stubs, so will need detailed content and continued
 honing, but the wiki format invites collaboration on that honing.

 See:
 https://wiki.ubuntu.com/ReleaseCadence
 https://wiki.ubuntu.com/ReleaseCadence/RollingRelease
 https://wiki.ubuntu.com/ReleaseCadence/SixMonthInterimRelease
 https://wiki.ubuntu.com/ReleaseCadence/TrueMonthlyReleases

 I'd like to invite everyone who is interested to get their input into
 these pages by March 18th (or thereabouts). Then I'd like to work with
 interested people to select what we consider the best proposal to take
 to the technical board for guidance.

 Part of the straw man proposal was to convert 13.04 into a Rolling
 Release in order to allow us to go faster on the converged OS starting
 immediately. Given the work that is left to achieve a proper proposal
 for the tech board, I don't foresee such a proposal being completed in
 time to make such a radical change to 13.04.

One thing I think has been missing from the discussion so far has been
in reviewing our *definition* of a release. There was some mention of
defining what Ubuntu is - how big the surface area we maintain, vs app
developers maintain and deliver /on/.

I'd like to decompose 'Release' though. Technically, it means a number
of things today:
A - an archive that we place a high friction change process on,
intended to eliminate regressions [the SRU]
B - a logical name that users can associate with a /large/ bundle of
changes. One can say 'Unity in Raring is fantastic' only because
Raring is a thing.
C - A set of APIs that work well together and which we commit to keep
working for the duration of the release (except where it is infeasible
[e.g. due to facebook dropping their support for the server side of an
API].
D - A mostly unchanging environment. No surprises.

We've got good reasons to want to achieve those four things:
A - We don't want millions of users to have something that worked
break because we changed something badly. Breaking folks environments
is a good way to encourage them to move elsewhere.

B - We have 20K pieces of software, 2K in main, all changing all the
time.Talking about individual versions of everything is tedious, for
all that it is accurate.

C - We want to get app developers vendors - both individuals and
aggregators like steam - to target Ubuntu, so that more folk can
benefit from a free and open platform. I broadly model app vendors as
minimaxers (for both pro bono and commercial vendors): for the least
investment, get the most gain from from building and supporting an app
on a platform. Each new platform needs a minimum reach to be worth
porting / rewriting on, and the harder it is to build the app there,
the larger the reach required for it to be worth it.
Crucially, the faster APIs change, the wider the reach needed by the
platform for supporting it to be worth it. (Revenue = total users *
per-user-revenue, *or* good-done = total users * benefit per user) /
effort.
APIs don't need to be unchanging, they just need to be
unchanging-enough that working with them is worth it.

D - Since we are optimised for producing releases, we want to minimise
the cost of supporting each release: the more it changes, the more we
(and others) have to revise documentation, screenshots, manuals,
wrapper scripts, and the more we run the risk of causing a regression.

Now, I think it is axiomatic that we need to keep achieving the four things:
 - reliability for our users.
 - clarity of communication about what upstream software is available
and its versions
 - good APIs that work together well and are stable enough to be

Re: Follow Up from Let's Discuss Interim Releases

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/09/2013 03:09 PM, Scott Kitterman wrote:
 2)  Rather than upload to raring, then freeze, then release
 raring as stable, change the model slightly so we have uploads
 going to the unstable release.  Then say, 3 months prior to the
 deadline for the new stable release, we open a new archive for
 that release, and copy the unstable release to it.  Then bugs
 would be fixed in the stable release, while new development can
 continue concurrently in unstable.
 
 Your option two seems somewhat similar to the situation we end up
 with now when just after release, we don't have a development
 series and SRUs are uploaded to the current release and later
 forward copied to the development version when it's ready.  This
 can be a pretty labor intensive, error prone process.

No.  Under that option there would never be a time where we don't have
a development release.  It would always exist and, I propose, be named
simply unstable.  Bugs found during the freeze would be first fixed
in unstable, and the fix backported to stable, just as we do now with
SRUs, though with more relaxed requirements since it wouldn't be a
stable release yet.


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

iQEcBAEBAgAGBQJRO+JdAAoJEJrBOlT6nu75a2gH/0ROFH4nfzlf/0HGYoU+Pcis
90igBLdBKahOwKrdHufXlJhnv+Wj9rUC1zQzHjTnAO3sfgl8npXJa7ktVwikg6+z
t+2odjghSydm0g7JKScUmRbtjsd5Iwi7lNqh0W9iRG01ljxPyffAdMMtLgYR+Z5i
LdlE/4JcJMigDuq6LLfH1uPhQcfyIi5XszezoC0ffp8hup+eaEL2LHybxKXIMP+h
jT0O9H7HpcZEaDFBfWAlH1+/w7Wyn2sKjXxaWmJaBkNATSCqbOZ/OXyTJOevYf8f
AYf3g15bBD9cyXwPzsdDuLM5Vn7WmKbBiotZcInAcNyC2JytQZhVhRRUVoGYxDI=
=j7Ak
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/09/2013 03:32 PM, Philip Muskovac wrote:
 The *good* side of being frozen and stopping development, is that
 you actually force people to stop developing and instead
 concentrate on testing and fixing bugs. The moment you open a new
 development branch developer attention will turn to that instead of
 stabilizing the LTS.

Trying to force people to do something they do not want is never a
good idea.  It also isn't an either-or situation.  You don't choose
between new development and bug fixing.  You fix bugs when they are
reported, and when there aren't any that need fixing, you can continue
with new development.  If you can't work on new development, and don't
have known bugs to fix, then you are wasting time with nothing to do.


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

iQEcBAEBAgAGBQJRO+MvAAoJEJrBOlT6nu75DuUIAJg+E0H9jzgBGXhfjNVQX40m
ZuET/e1oVYvIQNI4cRErNnqnN2J+nea9Sl8JNE7sVRTbUd7kOeV2LmSMkkrCCBfR
yZPxoub1sz5PLiE3Is0lcJgbq5U3STEHp4OwM36ts9v7SBjuqvvWsgPLVR7D16AK
KWCPZI/rX0bW5YSy1zQHyCogNncAXVZQf+Z7fP9UOY6NGwKG5+CSbhob+lzak9fY
h29sd5a0VYe4IuSqpU3wCOYw600FL/9MqbzUvNSEoeX/0QT/IdGp94T2pgwcGVCy
mXNTA0Fyf5JMBEx2/JmFAitiQHpywyUGDYYTqCVCbvTo5Uu260Wy72z1BvhRk/Y=
=eAlY
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Scott Kitterman]

On Saturday, March 09, 2013 08:31:09 PM Phillip Susi wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 03/09/2013 03:09 PM, Scott Kitterman wrote:
  2)  Rather than upload to raring, then freeze, then release
  raring as stable, change the model slightly so we have uploads
  going to the unstable release.  Then say, 3 months prior to the
  deadline for the new stable release, we open a new archive for
  that release, and copy the unstable release to it.  Then bugs
  would be fixed in the stable release, while new development can
  continue concurrently in unstable.
  
  Your option two seems somewhat similar to the situation we end up
  with now when just after release, we don't have a development
  series and SRUs are uploaded to the current release and later
  forward copied to the development version when it's ready.  This
  can be a pretty labor intensive, error prone process.
 
 No.  Under that option there would never be a time where we don't have
 a development release.  It would always exist and, I propose, be named
 simply unstable.  Bugs found during the freeze would be first fixed
 in unstable, and the fix backported to stable, just as we do now with
 SRUs, though with more relaxed requirements since it wouldn't be a
 stable release yet.

There's still the requirement to keep things in sync.  That's what I was 
referring to.  Also, for many common targets for SRUs/late bug fixes that are 
actively maintained, the packages in the development release would quickly 
diverge and so you'd still have to do two sets of patches.  Except for reduced 
QA requirements, it doesn't seem to offer much over release and SRU and I'm not 
sure reduced QA is actually a feature.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/09/2013 08:35 PM, Scott Kitterman wrote:
 There's still the requirement to keep things in sync.  That's what
 I was referring to.  Also, for many common targets for SRUs/late
 bug fixes that are actively maintained, the packages in the
 development release would quickly diverge and so you'd still have
 to do two sets of patches.  Except for reduced QA requirements, it
 doesn't seem to offer much over release and SRU and I'm not sure
 reduced QA is actually a feature.

Yes, they would diverge, and you would have to upload two fixes, just
like what we do now with SRUs.  Where it differs from the current
release and SRU is that we have a longer period of feature freeze /
bug fix time before the final release, but without it holding up
ongoing development.


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

iQEcBAEBAgAGBQJRO+ZXAAoJEJrBOlT6nu75PxwH/14Xk5ZlZq8grqDt3MAS2rqt
iGokrjjT5Kvag1TxMmcBEnqRnEBw4GlUNR+wTNnuxTrwGyUxkSH/Z4t40ztP35wY
qe1nIX5OZqHCt+wrWhs9K432RQfpb9cey4vezi8cB8fk0CEznSW0Tn4YaARXrW6A
YDcwWDSiHg9F2T11uUsoldcwJQRzf7yUzPZGyRVBgmVTc+KKmKuT+umb8v8SUpwJ
TYOVKw7AA2GwHX/xHettMY/mJrrJkJF2QuH2MZviJZGwha1W3oOpG9hWjOKFL06j
n2w5PmAE/xoerx9cKlYlohvc1/F1SKUui0Pvo4S5903DDSE6WG913+21zVW7sLc=
=ixzH
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Cesare Falco]

1. Move to a rolling release similar to what I proposed in the
 original straw man.
 2. Continue to release interim releases but only support them until
 roughly the next interim release 6 months later.
 3. Dramatically increase the rate of our releases to, say, once per month.

 I think there's another proposal worth considering IMHO, quoting Alex
Chiang's e-mail:

Let's figure out how to decouple and disentangle our apps from
our platform.

I understand the main issue is that nearly nobody offers packages for
Ubuntu upstream, anyway the idea of splitting the distro into, say,
ubuntu-sys and ubuntu-apps with different devel cycles is both new and
intriguing.

My 2 cents.

Cesare.
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Jo-Erlend Schinstad]

I'd like to add a few points to this that I feel haven't got much
attention. Before I do, however, I'd like to explain that while I have used
Ubuntu for a long time and paid attention to the development process, there
are so many things that know very little about. For that reason, I don't
really want to go into the pro et contra of the interim vs rolling releases
from a technical point of view, but rather from an observers point of view.

It's about the enthusiasts. Not the curious, but the ones who have been
using Ubuntu for a very long time and are decidedly into it. In the past,
these are the kinds of people who have begun installing Ubuntu from a late
alpha or early beta stage. They've been committed to filing bugs and are
willing to experience some breakages, but want their systems to be fairly
usable. To these people, the pre-releases have been the highlight of the
season. However, in the early stages of development, things have been too
confused for them to get involved and in the late stages, developers have
been too busy getting things in place for the release. That means they've
always been limited to a status of perpetual observers or testers at best.
Every six months, there'll be a couple of weeks when people feel they're in
the game, but that also means most of the time, they won't. If you want to
learn something, you need to practice and then repeat.

One benefit I see from the rolling releases idea, is the possibility for
developers to take a bug, announce that it's now being worked on, and
enable people to tag along for the ride all the way from bug report to
release. Of course, this means there has to actually be a release. A
monthly snapshop can act to this purpose. The curious will install the
rolling release at a snapshot and then install updates at regular
intervalls along the way. But they are aware that things might break and
are willing and able to fix or perform a work-around for those cases. Using
btrfs might be helpful in that regard, since it could give them the ability
to easily undo an upgrade. I see that as a prerequisite for a rolling
release in either case, because you have to expect some people to suffer
horribly from time to time. Bugs exist. If people can reboot and revert,
it's not such a big deal if something _does_ break horribly. A boot menu
option to pretend today didn't happen would allow more people to join in
early.

In many cases, insightful people will be able to make an educated guess as
to how difficult it will be to fix a bug. So label it properly before the
work starts, write an introduction containing languages used and what the
work is expected to look like, when it's estimated to arrive in rolling,
etc and allow people to subscribe to these events. When applicable,
schedule bug specific meetings so that hangarounds can ask questions,
become more enlightened and discuss among themselves. At the end, you'll
have a well documented, real-life development story for people to study.
With a library of these, journalists and technical writers will be able to
use these as starting points for articles or even chapters of a book. The
curious monthly-upgraders will be more cutting edge while the dedicated
enthusiasts will have a chance to be a bigger part of the process. This
enables bragging rights, particularly if there's a chance of getting your
name in the release notes. Some bugs might also be useable in school
projects, such as backporting a bug to the most recent LTS.

If this sounds horribly naive, it's because it is and I am. But from
experience, I think the naive perspective can often be quite useful. I hope
this was, and I thank you for your time and attention.

Jo-Erlend Schinstad
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Rick Spencer]

As others pointed out no change is the default choice. However, if
someone wants to capture our current release cadence and support model
to the wiki, I don't see why there would be any objection to that.

Cheers, Rick

On Thu, Mar 7, 2013 at 7:15 PM, Scott Kitterman ubu...@kitterman.com wrote:
 Rick Spencer rick.spen...@canonical.com wrote:

Hi all,

There has been a lot of discussion and impact around the strawman
proposal for changing our release cadence that I sent last Thursday.
There was a misconception that the proposal was a decision that I was
masking as a call for discussion. I want to reassure everyone that I
really did mean it as a discussion. I feel passionately that we need
to change and innovate in this area, but a change like this cannot
succeed, or in fact be made, without discussion in the community and
proper governance.

Discussion of this topic on the mailing list and at UDS this week was
wide ranging. There were a lot of divergent opinions and ideas. The
discussion seems to have resulted in roughly three different forms of
proposals.

1. Move to a rolling release similar to what I proposed in the
original straw man.
2. Continue to release interim releases but only support them until
roughly the next interim release 6 months later.
3. Dramatically increase the rate of our releases to, say, once per
month.

I've attempted to capture the essence of these proposals (and
associated sub-proposals) along with a structure for points and
counterpoints in wiki format to support honing and organizing. They
are currently stubs, so will need detailed content and continued
honing, but the wiki format invites collaboration on that honing.

See:
https://wiki.ubuntu.com/ReleaseCadence
https://wiki.ubuntu.com/ReleaseCadence/RollingRelease
https://wiki.ubuntu.com/ReleaseCadence/SixMonthInterimRelease
https://wiki.ubuntu.com/ReleaseCadence/TrueMonthlyReleases

I'd like to invite everyone who is interested to get their input into
these pages by March 18th (or thereabouts). Then I'd like to work with
interested people to select what we consider the best proposal to take
to the technical board for guidance.

Part of the straw man proposal was to convert 13.04 into a Rolling
Release in order to allow us to go faster on the converged OS starting
immediately. Given the work that is left to achieve a proper proposal
for the tech board, I don't foresee such a proposal being completed in
time to make such a radical change to 13.04.

 Maintaining the current cadence should also be one of the options.

 Scott K


 --
 ubuntu-devel mailing list
 ubuntu-devel@lists.ubuntu.com
 Modify settings or unsubscribe at: 
 https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Scott Kitterman]

Rick Spencer rick.spen...@canonical.com wrote:

Hi all,

There has been a lot of discussion and impact around the strawman
proposal for changing our release cadence that I sent last Thursday.
There was a misconception that the proposal was a decision that I was
masking as a call for discussion. I want to reassure everyone that I
really did mean it as a discussion. I feel passionately that we need
to change and innovate in this area, but a change like this cannot
succeed, or in fact be made, without discussion in the community and
proper governance.

Discussion of this topic on the mailing list and at UDS this week was
wide ranging. There were a lot of divergent opinions and ideas. The
discussion seems to have resulted in roughly three different forms of
proposals.

1. Move to a rolling release similar to what I proposed in the
original straw man.
2. Continue to release interim releases but only support them until
roughly the next interim release 6 months later.
3. Dramatically increase the rate of our releases to, say, once per
month.

I've attempted to capture the essence of these proposals (and
associated sub-proposals) along with a structure for points and
counterpoints in wiki format to support honing and organizing. They
are currently stubs, so will need detailed content and continued
honing, but the wiki format invites collaboration on that honing.

See:
https://wiki.ubuntu.com/ReleaseCadence
https://wiki.ubuntu.com/ReleaseCadence/RollingRelease
https://wiki.ubuntu.com/ReleaseCadence/SixMonthInterimRelease
https://wiki.ubuntu.com/ReleaseCadence/TrueMonthlyReleases

I'd like to invite everyone who is interested to get their input into
these pages by March 18th (or thereabouts). Then I'd like to work with
interested people to select what we consider the best proposal to take
to the technical board for guidance.

Part of the straw man proposal was to convert 13.04 into a Rolling
Release in order to allow us to go faster on the converged OS starting
immediately. Given the work that is left to achieve a proper proposal
for the tech board, I don't foresee such a proposal being completed in
time to make such a radical change to 13.04.

Maintaining the current cadence should also be one of the options. 

Scott K


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Allison Randal]

On 03/07/2013 07:15 PM, Scott Kitterman wrote:
 
 Maintaining the current cadence should also be one of the options. 

That would be the default if no proposal was submitted to the TB or no
proposal approved by the TB.

Or, do you mean there's value in writing up the advantages of the
current cadence in parallel to the other options, for a clearer
comparison? I can see that.

Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Scott Kitterman]

On Thursday, March 07, 2013 08:01:37 PM Allison Randal wrote:
 On 03/07/2013 07:15 PM, Scott Kitterman wrote:
  Maintaining the current cadence should also be one of the options.
 
 That would be the default if no proposal was submitted to the TB or no
 proposal approved by the TB.
 
 Or, do you mean there's value in writing up the advantages of the
 current cadence in parallel to the other options, for a clearer
 comparison? I can see that.

Yes.  If options are going to be presented to the TB, stick with what we have 
should be one of them.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Robert Bruce Park]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13-03-07 07:15 PM, Scott Kitterman wrote:
 Rick Spencer rick.spen...@canonical.com wrote:
 https://wiki.ubuntu.com/ReleaseCadence/SixMonthInterimRelease
 
 Maintaining the current cadence should also be one of the options.
 
I disagree, the current cadence (along with the current support
periods and the current SRU process) is totally unsustainable.

There is a *ton* of effort currently being put into supporting totally
irrelevant interim releases.

Staying at a six-month cadence is already one of the options, but the
proposal greatly reduces maintenance burden by reducing support
periods for interim releases. This allows most people to continue on
with their happy status quo, while reducing the obligatory SRU
nightmare for releases that nobody uses.

Although I feel quite strongly about my support for the rolling
release model, if it is rejected, we can't continue as we used to. We
simply do not have the resources to support more than two releases at
a time. I'd prefer to only have to support LTS+rolling, but LTS+one
interim at a time would be an acceptable second best.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJROW5ZAAoJEMnVpoCaWglEeEMP/0nT5GIlUXNgjYRqI2gDzrJI
m8Z9xVwsat46TFiVc9Xw7d/WCNUUWExqJQlo6ALOQrWOHMEV8y0vAZUOtF1ogGrI
VsYVqbAvNzGfP3ToLixLnZRFKgth68Q+MggT4H0XOJh2mgV8lOBEt+Njdg4PUYZs
03Cjy49UTYcbzsmh9q1+cK8yloFdSgBfm2lhk2F0FIwVuha0IXjv4P3iHer6eDg4
dCqulFTxdIZQnGfdSKTkqVpFdF838JIUi1lbYMGrQwxEaaf/PjpJbE6tDVp8xXsP
G8lZ+tT2GvBeZw3XuSu6XCo/p0LXtpwQGCOOOIj4FGRQX7h2R2l1LKNcGDm5E4Vn
tksI3z26qAHPdZYEqdHkNkjg6xJdd/JdVS35bYNGbKCXdeHG9WoHlbi6SpvNX1lw
mBlqks1exyoSAFBinpsJSsJPGD/7CA0vvrj7T90hqy3e0h1RirkgZx3n6beaqydh
2JT2VAocy3qpMYjx+qXtwuOi9dakPcm7B29gHu/pOAto07o6rpeop35gLTgn5GBM
h2HxtliEPCoFoSl5B2UJF7hPU+q8owRH8NzY7S8pXkvl836gb+6vNUVsNC+nRfSZ
SWEOiVz4gfhNbqr4iViF63/A9pLJA3imuoHaRLlxYMrl+GZE7x20HZAJK/Go9OLV
7TmKxgOZNfqieSINi5Lq
=ThC8
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Jono Bacon]

On Thu, Mar 7, 2013 at 8:12 PM, Scott Kitterman ubu...@kitterman.com wrote:
 On Thursday, March 07, 2013 08:01:37 PM Allison Randal wrote:
 On 03/07/2013 07:15 PM, Scott Kitterman wrote:
  Maintaining the current cadence should also be one of the options.

 That would be the default if no proposal was submitted to the TB or no
 proposal approved by the TB.

 Or, do you mean there's value in writing up the advantages of the
 current cadence in parallel to the other options, for a clearer
 comparison? I can see that.

 Yes.  If options are going to be presented to the TB, stick with what we have
 should be one of them.

I presume that if there is no proposed change, there would be no
proposal to take to the TB, hence leaving off the current way of
working as an option. :-)

   Jono

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

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Follow Up from Let's Discuss Interim Releases

[Paul Sladen]

On Thu, 7 Mar 2013, Jono Bacon wrote:
 I presume that if there is no proposed change, there would be no
 proposal to take to the TB,

The status-quo has both merits and demerits.  It is necessary to
evaluate those as thoughly as the rest, to adequately explore the
problem, and available solution space(s).

Without doing that most basic of academic basework, any presumed
improvement is likely to be flawed in proposition and implementation.

It would be like running a study without a control group baseline to
evaluate results against;  or more frankly, like expecting a perfect
outcome when urinating in an area of high atomspheric pressure.

Thusly Jono, I respectfully disagree: the donkey work should be done.

-Paul


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel