Re: Let's Discuss Interim Releases (and a Rolling Release)

[Thierry Carrez]

Rick Spencer wrote:
> = tl;dr =
> Ubuntu has an amazing opportunity in the next 7-8 months to deliver a
> Phone OS that will be widely adopted by users and industry while also
> putting into place the foundation for a truly converged OS.
> 
> To succeed at this we will need both velocity and agility. Therefore, I
> am starting a discussion about dropping non-LTS releases and move to a
> rolling release plus LTS releases right now.
> [snip]

I'm a bit late to the party, but here are my 2c:

The post is enthusiastic, but this is not a win-win: it's basically a
trade-off, and while there are numerous benefits, you shouldn't ignore
the drawbacks.

On the benefits side, there is, as Colin pointed out, the idea of
"reducing engineering effort so that it can be diverted towards other
things". It also allows to unleash shiny new things faster to a
potentially larger group of users, which could align well with the
"let's rewrite significant parts of the foundations ourselves" strategy.

I don't really buy the "avoids waiting 6 months if you miss the boat"
argument. You're replacing a 6-month cadence with a 2-year cadence, and
those missing the LTS boat will have to wait *2 years*. Like Ted pointed
out, LTS becomes your deadline. LTS becomes your release. You just turn
6-month-lived ubuntu-under-development into a 2-year-lived, hopefully
more stable and usable, 2-year-lived ubuntu-under-development.

On the drawbacks side, you lose the benefit of exercising the release
processes on non-LTS, "interim" releases. Rehearsing how to do it and
improving iteratively every 6 months has some value.

More importantly, you lose most of the benefits of the cadence that
sabdfl was praising not so long ago. Giving a fast rhythm allows you to
focus your development community and upstream communities on common
goals, and lets you have a breathing pulse overall (the 6-month physical
UDS helped in that respect as well). It encourages your developer
community to deliver more on a smaller period of time. You can enforce
deadlines internally within Canonical, but for everyone else the
artificial cadence was everything you had.

So it's a trade-off. You gain some and lose some. Depending on your
agenda and your position in the Ubuntu community, you'll have a
different opinion on this, and consensus will be a bit hard to find.

Regards,

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Ritchie]

On 3/5/13 4:21 PM, Steve Langasek wrote:

On Tue, Mar 05, 2013 at 02:10:55AM -0800, Scott Ritchie wrote:

apt should never do that, and that would be a major bug that we should fix.
Do you have a bug reference for this behavior in apt (preferably with a
reproducer case)?



This reminded me of this older bug from Karmic-Lucid era, which I'm
not sure ever got fixed since we just worked around it in
update-manager:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/571999


Ok.  Does that mean there's no bug filed for the case of apt looking at
recommends on the wrong version of the package?



Yes, I was misremembering the exact circumstances of the linked bug.


In this case apt is looking at a stale cache package rather than the
to-be-installed package.


That's not an accurate characterization of what's happening here.  The error
message shown in the log is from dpkg, not from apt:

  Selecting previously deselected package wine1.2.
  dpkg: regarding .../wine1.2_1.1.42-0ubuntu4_amd64.deb containing wine1.2:
   wine1.2 conflicts with wine (<< 1.2)
wine (version 1.1.42-0ubuntu4) is present and unpacked but not configured.

So in fact, it's dpkg that's detecting phantom conflicts with
previously-installed versions of packages that have since been removed.
I've updated the bug report accordingly.



Thanks


I suspect that bug has since been fixed, as I haven't heard anything about
this kind of failure recently.



It was a pretty rare edge case then, so I wouldn't necessarily count on 
it just because it hasn't cropped back up.



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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Steve Langasek]

On Tue, Mar 05, 2013 at 02:10:55AM -0800, Scott Ritchie wrote:
> >apt should never do that, and that would be a major bug that we should fix.
> >Do you have a bug reference for this behavior in apt (preferably with a
> >reproducer case)?

> This reminded me of this older bug from Karmic-Lucid era, which I'm
> not sure ever got fixed since we just worked around it in
> update-manager:
> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/571999

Ok.  Does that mean there's no bug filed for the case of apt looking at
recommends on the wrong version of the package?

> In this case apt is looking at a stale cache package rather than the
> to-be-installed package.

That's not an accurate characterization of what's happening here.  The error
message shown in the log is from dpkg, not from apt:

 Selecting previously deselected package wine1.2.
 dpkg: regarding .../wine1.2_1.1.42-0ubuntu4_amd64.deb containing wine1.2:
  wine1.2 conflicts with wine (<< 1.2)
   wine (version 1.1.42-0ubuntu4) is present and unpacked but not configured.

So in fact, it's dpkg that's detecting phantom conflicts with
previously-installed versions of packages that have since been removed. 
I've updated the bug report accordingly.

I suspect that bug has since been fixed, as I haven't heard anything about
this kind of failure recently.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Elizabeth Krumbach]

On Thu, Feb 28, 2013 at 7:31 AM, Rick Spencer
 wrote:
> Therefore, I think we should keep LTS releases, but starting now, stop doing
> interim releases and start a rolling release.
>
> More clearly, I think we should:
> * Stop making interim releases.
> * Keep doing daily quality and keep improving our daily quality.
> * Take a monthly snapshot of the development release, which we support only
> until the next snapshot
>
> That means users could choose:
> * The LTS release
> * The rolling release updated daily or as frequently as desired
> * The rolling release updated at least monthly

Translations and documentation are currently very closely tied to the
6 month release cycle. Are there any thoughts on how this would work
in a rolling release model? (there are probably other teams too, but
these spring to mind immediately)

I think having some expectations of what we would want to release each
monthly with regard to localization and documentation and getting
these teams involved in the discussion is important before any
decisions are made.

-- 
Elizabeth Krumbach // Lyz // pleia2
http://www.princessleia.com

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Ritchie]

On 3/4/13 12:46 PM, Steve Langasek wrote:

On Mon, Mar 04, 2013 at 12:42:30PM -0800, Scott Ritchie wrote:

On 3/3/13 4:54 PM, Colin Watson wrote:

On Sat, Mar 02, 2013 at 11:36:45AM +0100, Nicolas Delvaux wrote:

On Fri, 2013-03-02 at 09:32 +, Colin Watson wrote:

I'm surprised, because when I hunt around for people talking about
their experiences running raring I've generally found them favourably
contrasting its stability with that of prior development releases.
Indeed I hear that one group (the French loco, was it?) started
referring to it as "boring", which IMO is an excellent result. :-)



For example, in the last few hours, French testers have complained about
packages such as Skype or Wine that were removed by a dist-upgrade.



I would be happy to debug such things given the output of 'apt-get -o
Debug::pkgProblemResolver=true dist-upgrade'.  (The last such example I
saw turned out to be due to raring-proposed being erroneously enabled,
and disabling it fixed the problem.)



Likely one of:
https://bugs.launchpad.net/ubuntu/+source/winetricks/+bug/1123710
https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/954029



In this case I suspect I need to SRU the fix to 12.10 because apt
will in some cases look at the recommends of the currently installed
package rather than the to-be-upgraded-to package when doing
resolution.


apt should never do that, and that would be a major bug that we should fix.
Do you have a bug reference for this behavior in apt (preferably with a
reproducer case)?





This reminded me of this older bug from Karmic-Lucid era, which I'm not 
sure ever got fixed since we just worked around it in update-manager:

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/571999

In this case apt is looking at a stale cache package rather than the 
to-be-installed package.



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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Steve Langasek]

On Mon, Mar 04, 2013 at 12:42:30PM -0800, Scott Ritchie wrote:
> On 3/3/13 4:54 PM, Colin Watson wrote:
> >On Sat, Mar 02, 2013 at 11:36:45AM +0100, Nicolas Delvaux wrote:
> >>On Fri, 2013-03-02 at 09:32 +, Colin Watson wrote:
> >>>I'm surprised, because when I hunt around for people talking about
> >>>their experiences running raring I've generally found them favourably
> >>>contrasting its stability with that of prior development releases.
> >>>Indeed I hear that one group (the French loco, was it?) started
> >>>referring to it as "boring", which IMO is an excellent result. :-)

> >>For example, in the last few hours, French testers have complained about
> >>packages such as Skype or Wine that were removed by a dist-upgrade.

> >I would be happy to debug such things given the output of 'apt-get -o
> >Debug::pkgProblemResolver=true dist-upgrade'.  (The last such example I
> >saw turned out to be due to raring-proposed being erroneously enabled,
> >and disabling it fixed the problem.)

> Likely one of:
> https://bugs.launchpad.net/ubuntu/+source/winetricks/+bug/1123710
> https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/954029

> In this case I suspect I need to SRU the fix to 12.10 because apt
> will in some cases look at the recommends of the currently installed
> package rather than the to-be-upgraded-to package when doing
> resolution.

apt should never do that, and that would be a major bug that we should fix. 
Do you have a bug reference for this behavior in apt (preferably with a
reproducer case)?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Ritchie]

On 3/3/13 4:54 PM, Colin Watson wrote:

On Sat, Mar 02, 2013 at 11:36:45AM +0100, Nicolas Delvaux wrote:

On Fri, 2013-03-02 at 09:32 +, Colin Watson wrote:

I'm surprised, because when I hunt around for people talking about
their experiences running raring I've generally found them favourably
contrasting its stability with that of prior development releases.
Indeed I hear that one group (the French loco, was it?) started
referring to it as "boring", which IMO is an excellent result. :-)


For example, in the last few hours, French testers have complained about
packages such as Skype or Wine that were removed by a dist-upgrade.


I would be happy to debug such things given the output of 'apt-get -o
Debug::pkgProblemResolver=true dist-upgrade'.  (The last such example I
saw turned out to be due to raring-proposed being erroneously enabled,
and disabling it fixed the problem.)



Likely one of:
https://bugs.launchpad.net/ubuntu/+source/winetricks/+bug/1123710
https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/954029

In this case I suspect I need to SRU the fix to 12.10 because apt will 
in some cases look at the recommends of the currently installed package 
rather than the to-be-upgraded-to package when doing resolution.


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

Re: Monthly snapshots Re: Let's Discuss Interim Releases (and a Rolling Release)

[Loïc Minier]

On Mon, Mar 04, 2013, Philipp Kern wrote:
> am Mon, Mar 04, 2013 at 11:42:03AM +0100 hast du folgendes geschrieben:
> > I'm not intimate with the costs needed on the archive side when opening
> > a new series, so can't go in details about these, but I suppose it
> > ranges from creating new buildd chroots, updating a bunch of scripts,
> > using a lot of disk space to publish a full copy of main + universe etc.
> 
> uh, shouldn't the latter just be entries in a tag database just
> like they are in Debian's dak?

Yeah I guess; I don't know the internals, I guess it's just one more
reference to the files as with the archive's pools/dists.

-- 
Loïc Minier

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

Re: Monthly snapshots Re: Let's Discuss Interim Releases (and a Rolling Release)

[Philipp Kern]

Loïc,

am Mon, Mar 04, 2013 at 11:42:03AM +0100 hast du folgendes geschrieben:
> I'm not intimate with the costs needed on the archive side when opening
> a new series, so can't go in details about these, but I suppose it
> ranges from creating new buildd chroots, updating a bunch of scripts,
> using a lot of disk space to publish a full copy of main + universe etc.

uh, shouldn't the latter just be entries in a tag database just
like they are in Debian's dak?

Kind regards
Philipp Kern


signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Bjoern Michaelsen]

Hi,

Rick Spencer wrote:
> ... rolling releases ...

As the LibreOffice maintainer I am very happy to hear this, for a set of
reasons, but since so many have already been covered, let me just focus on the
two most essential:
- while the upstream release plan was explicitly crafted to arrive with a good
  release before feature freeze in the upcoming Ubuntu release, such tight
  interlocking leaves little room for errors or corrections. Like with aircraft
  liftoff there is a decision point (V1) after which a new LibreOffice major
  release essentially has to go in, no matter what happens. The tight
  interlocking of schedules made this point essentially the UDS at the begin of
  the cycle and then allowed for no flexibility afterwards.
- The number of both supported Ubuntu releases and upstream releases (with
  backports in the PPA) made regression tracking and finding a pain. When you
  multiply one current upstream major, one stable upstream major and one 
upstream
  major we released an Ubuntu series with the number of supported Ubuntu
  releases, I think its easy to understand the problem.

Lets get rolling!

Best,

Bjoern

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

Re: Monthly snapshots Re: Let's Discuss Interim Releases (and a Rolling Release)

[Loïc Minier]

On Sat, Mar 02, 2013, Robert Collins wrote:
> > source.list changes from one monthly to the next.  Launchpad series are
> > in too many places and would be too expensive to create/update monthly
> 
> I'd like to challenge that. Currently LP series happen every 6 months.
> Monthly is only 6 times the frequency.

6 times the frequency is bad in itself, and the difference is more like
24 times the frequency (new series every LTS vs. every month).

I'm not intimate with the costs needed on the archive side when opening
a new series, so can't go in details about these, but I suppose it
ranges from creating new buildd chroots, updating a bunch of scripts,
using a lot of disk space to publish a full copy of main + universe etc.

There are other costs, such as more painful upgrades for users
(sources.list entries need to be updated and reviewed for each repo),
PPAs (you need to copy your packages to the new PPA series), and for
developers (a bunch of packages need to be updated: debootstrap,
pbuilder etc., release upgrade data + tool need to be updated etc.).

While each of these could be considered a design flaw that we ought to
fix or something that we need to optimize, it's a lot of places/things
to fix.

> > We need an easy and solid way to switch between monthly and rolling
> > though; a bit like the software-properties flags for update frequencies,
> > which updates to install etc.
> 
> We should also be sure to gather stats about how much use rolling vs
> monthly vs LTS gets, to see if there is actual non-trivial demand for
> one vs another (and deal with the 'default sticks' effect too).

+1 on stats; in fact whatever we implement we ought to revisit our
choice in some time to review how well it fared.

-- 
Loïc Minier

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Sat, Mar 02, 2013 at 11:36:45AM +0100, Nicolas Delvaux wrote:
> On Fri, 2013-03-02 at 09:32 +, Colin Watson wrote:
> > I'm surprised, because when I hunt around for people talking about
> > their experiences running raring I've generally found them favourably
> > contrasting its stability with that of prior development releases.
> > Indeed I hear that one group (the French loco, was it?) started
> > referring to it as "boring", which IMO is an excellent result. :-)
> 
> For example, in the last few hours, French testers have complained about
> packages such as Skype or Wine that were removed by a dist-upgrade.

I would be happy to debug such things given the output of 'apt-get -o
Debug::pkgProblemResolver=true dist-upgrade'.  (The last such example I
saw turned out to be due to raring-proposed being erroneously enabled,
and disabling it fixed the problem.)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Stefano Rivera]

> As an application developer I want a stable environment that isn't too
> far behind upstream. I don't want to deal with changing APIs when I'm
> working on a project.

I don't think you can expect that from a rolling release. Things will be
changing regularly.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 461 1230 C: +27 72 419 8559

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Nicolas Delvaux]

Hi everyone,

On Fri, 2013-03-02 at 09:32 +, Colin Watson wrote:

> I'm surprised, because when I hunt around for people talking about
> their experiences running raring I've generally found them favourably
> contrasting its stability with that of prior development releases.
> Indeed I hear that one group (the French loco, was it?) started
> referring to it as "boring", which IMO is an excellent result. :-)

For example, in the last few hours, French testers have complained about
packages such as Skype or Wine that were removed by a dist-upgrade.

To be honest, we find the current Raring boring mainly because there is
not much new things in it yet. Quantal was boring and stable to, until
all new features started to land after the feature freeze (and, in the
end, Quantal turned out to be the usual not-stable-until-2-month release).


About monthly "releases", I think this is a good idea.
You can do the best you can to enforce testing everywhere, it's just
impossible to cover everything. You can't guarantee that my computer
will still boot after an upgrade, this needs real world testing.

To manage that, big changes (new kernel major version, new X stack...)
could land in the rolling release just after the last snapshot, in order
to be more confident in the usability of the next snapshot.

The target audience of each version seems clear to me:
- LTS <- stable: for Average Joe
- Monthly <- should be safe: for advanced/enthusiasts users
- Rolling <- should be safe, but unexpected breakages are still
possible: for developers

Personally, I would be interested to run the rolling release on my home
computer and to run the monthly release at work (I'm a developer).

My 2 cents ;)
Nicolas

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 07:16:58PM +0100, Philip Muskovac wrote:
> Let me add that due to 
> https://bugs.launchpad.net/bugs/1077116
> (automoc4 crashes in qemu-virtualized armhf)
> Kubuntu doesn't have any *usable* armhf PPA builders right now as KDE 
> software 
> doesn't compile in qemu.

FWIW, a week or two ago I raised an escalation request with Linaro on
behalf of Canonical to have more time spent on maintaining qemu's user
mode (and I know the engineers at the other end are receptive to this).
Assuming this is accepted, I'll make sure this bug is on the list.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 10:34:25PM -0800, Tobin Davis wrote:
> On Fri, 2013-03-01 at 16:52 +, Colin Watson wrote:
> > Just using 'apt-get dist-upgrade' all the time, or something with closer
> > semantics to that, is better.
> 
> Oh, then you've fixed the issue where dist-upgrade removes packages due
> to unmet dependencies (aka pool churn)?

Yes, in the vast majority of cases:

  https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036043.html

This is a major part of what Rick is referring to in shorthand as "daily
quality", which has been a big push since 12.04.

> These are serious issues, and frankly I haven't seen any progress to
> indicate otherwise.

I'm surprised, because when I hunt around for people talking about their
experiences running raring I've generally found them favourably
contrasting its stability with that of prior development releases.
Indeed I hear that one group (the French loco, was it?) started
referring to it as "boring", which IMO is an excellent result. :-)

(One problem I've occasionally seen, and I debugged an instance of this
just yesterday, is that some people who've taken part in verifying SRUs
on earlier Ubuntu releases and who've then upgraded to raring still
sometimes have -proposed enabled.  In such cases people are NOT
insulated from what you refer to as "pool churn".  The right fix here is
just to disable raring-proposed, which is not intended for use by
humans.)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Tobin Davis]

On Fri, 2013-03-01 at 16:52 +, Colin Watson wrote:
> On Thu, Feb 28, 2013 at 12:12:34PM -0500, Barry Warsaw wrote:
> > Long gone are the days where a `apt-get upgrade` has broken my system
> > (knock on wood) and while I do inspect dist-upgrades a little more
> > carefully, they are usually pretty reliable too.
> 
> FWIW, I have come to believe that nobody should use 'apt-get upgrade' as
> a general rule.  In particular, since it tries its best to install as
> much as it can under the constraint that it never installs new packages
> or removes installed ones, it will carry merrily on without installing
> any new Recommends introduced by the upgrade set, and you will never
> hear about them again unless some other package starts recommending the
> same target packages.
> 
> Just using 'apt-get dist-upgrade' all the time, or something with closer
> semantics to that, is better.
> 
> -- 
> Colin Watson   [cjwat...@ubuntu.com]
> 

Oh, then you've fixed the issue where dist-upgrade removes packages due
to unmet dependencies (aka pool churn)?  dist-upgrade should only be
used within a release, not during development (your words a few years
ago).

I quit tracking the Ubuntu daily builds shortly after 12.04 release
(Canonical people know why).  Have the issues of missing dependencies
been resolved during library update induced pool churn?  Have the issues
of systems not booting due to lack of 3D driver support been addressed?

These are serious issues, and frankly I haven't seen any progress to
indicate otherwise.



Tobin Davis 

"One Architecture, One OS" also translates as "One Egg, One Basket".


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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 10:13:39PM +0100, Loïc Minier wrote:
> On Fri, Mar 01, 2013, Colin Watson wrote:
> > The latter option (publish immediately, symlink only after passing
> > tests) would be simpler to implement and is probably the most plausible
> > way to do this; after all if you don't publish them at all on cdimage
> > then you have to invent some new way to publish them to jenkins for
> > smoke-testing.  It would require something to check in on test results
> > every so often, but that probably isn't too hopelessly difficult.
> 
> In fact, we could maintain a /latest vs. a /current; /latest would
> always be updated, but /current (or /tested, /releasable etc.) would
> only be updated when the image passes tests.

Yes, that would make sense too.  Keeping /current but gatewaying it on
tests is probably the best option since people are very used to /current
by now, and only a small number of people would need to adapt to
/latest.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Security Support - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Martin Pitt]

Colin Watson [2013-03-01 16:49 +]:
> While I think monthly image releases make sense, I don't personally like
> the notion of monthly updates at all

FWIW, I fully agree, I was just contemplating how we would implement
it in the easiest possible manner should we have to do it at all. I
would really like hear about some significant user group who would
actually use those; if we create them proactively without much demand
we just have replaced a big release every 6 months with six smaller
releases every month, which feels like "we want a RR, but not really".

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Kaj Ailomaa]

On Thu, 28 Feb 2013 16:31:49 +0100, Rick Spencer  
 wrote:



= tl;dr =
Ubuntu has an amazing opportunity in the next 7-8 months to deliver a  
Phone

OS that will be widely adopted by users and industry while also putting
into place the foundation for a truly converged OS.

To succeed at this we will need both velocity and agility. Therefore, I  
am
starting a discussion about dropping non-LTS releases and move to a  
rolling

release plus LTS releases right now.



I think what the community is concerned about (flavors, devs and users) is  
stability, and the ability to influence the quality of the releases. There  
aught to many ways to achieve this. Here are three points I'd like to make  
on behalf of Ubuntu Studio


 * Have more than one layer, repo-wise, making sure a non-devel rolling  
release is less agressively updated. Particularly some system critical  
packages can cause a lot of pain, if they present regressions/bugs, such  
as the kernel, core system libs and graphics related things. A more  
experimental repo could be used for the developers, and act as a buffer  
for the "stable" repo. This is not news, Debian does something like this,  
and I suppose it is just a smart way to go about things.
 * Flavors will want to have some influence in what is accepted into a  
"stable"-ish rolling release repo. That may actually not be a big amount  
of packages in the end, if they are fine to publish, but I can't speak for  
all the flavors, or other interest holders. Ubuntu Studio is dependant on  
Xubuntu for the desktop, while itself mostly focused on multimedia  
packages, and possibly most of those packages aren't important for anyone  
but Ubuntu Studio and their kind of user base - as an example.
 * I've yet to understand the benefit of monthly shapshots. If Ubuntu  
wants monthly's, I could imagine other flavors wants their own custom  
snapshots. The ability to make custom releases, which are quite useful,  
especially for a live media. And, as has been stated, a user could turn  
off anything but security updates, so a snapshot does fill a purpose. A  
snapshot would then be a planned mini-release.


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

Re: Monthly snapshots Re: Let's Discuss Interim Releases (and a Rolling Release)

[Steve Langasek]

On Sat, Mar 02, 2013 at 08:17:15PM +1300, Robert Collins wrote:
> On 1 March 2013 06:52, Loïc Minier  wrote:

> > source.list changes from one monthly to the next.  Launchpad series are
> > in too many places and would be too expensive to create/update monthly
> > :-/

> I'd like to challenge that. Currently LP series happen every 6 months.
> Monthly is only 6 times the frequency.

Opening a new series has gotten easier over the years, but it's still a
non-negligible amount of work.  Doing this once a month would be moving us
in exactly the wrong direction.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: 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: Monthly snapshots Re: Let's Discuss Interim Releases (and a Rolling Release)

[Robert Collins]

On 1 March 2013 06:52, Loïc Minier  wrote:

> source.list changes from one monthly to the next.  Launchpad series are
> in too many places and would be too expensive to create/update monthly
> :-/

I'd like to challenge that. Currently LP series happen every 6 months.
Monthly is only 6 times the frequency.

> We need an easy and solid way to switch between monthly and rolling
> though; a bit like the software-properties flags for update frequencies,
> which updates to install etc.

We should also be sure to gather stats about how much use rolling vs
monthly vs LTS gets, to see if there is actual non-trivial demand for
one vs another (and deal with the 'default sticks' effect too).

-Rob

-- 
Robert Collins 
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: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

On Saturday, March 02, 2013 09:34:22 AM Dmitry Shachnev wrote:
top post fixed.
> On 3/2/13, Scott Kitterman  wrote:
> > Colin Watson  wrote:
> >>On Fri, Mar 01, 2013 at 07:37:34PM +0400, Dmitry Shachnev wrote:
> >>> We must decide whether the rolling branch is for users/enthusiasts or
> >>> for developers only. If the latter (it's what most of us like), we
> >>are
> >>> *not* switching to rolling release model. We are just dropping
> >>non-LTS
> >>> releases.
> >>
> >>If it's for developers only then I would account that a failure.  It is
> >>necessary to open it up rather more widely than that if we stop
> >>providing non-LTS releases.
> >>
> >>> In both cases, we should try to make it more stable than the current
> >>> raring is. My suggestions are:
> >>> 
> >>> - Auto-sync packages from Debian testing, not sid;
> >>
> >>Please no.  Now that we have -proposed to release migration, we're
> >>guarded against the worst excesses of unstable.  Past experience has
> >>suggested that the main effect of autosyncing from testing is to make
> >>it
> >>take longer for regressions to get fixed, or else make us spend more
> >>time chasing down regressions fixed in unstable but not in testing.
> >>
> >>> - Make -proposed → -release migration more clever (i.e. recursively
> >>> building all reverse dependencies, and running their autopkgtests, if
> >>> any) — not sure if it is already done;
> >>
> >>This is planned and partially implemented.  I'd hoped to finish it off
> >>a
> >>couple of months ago but got a bit stuck; it'll clearly need to happen.
> >>
> >>> - Create and use -experimental pocket (as suggested by Stefano) for
> >>> testing unstable changes and handling transitions;
> >>
> >>I can understand why people ask for this, but new pockets are very
> >>complex to create due to extensive hardcoding of pocket semantics in
> >>Launchpad; they aren't something we can do easily or flexibly.  Plus,
> >>if
> >>we create one new experimental pocket, what happens when different
> >>people's in-progress projects clash?  I foresee trouble with this
> >>strategy.
> >>
> >>I wonder whether we could petition for the Canonical-only restrictions
> >>on devirtualised PPAs to be lifted for people in ~ubuntu-dev as a
> >>consequence of this release plan, and what other changes that would
> >>take.
> >>
> >>> Also, if we are dropping non-LTS releases, we should make more use of
> >>> -backports. Some flavours ({K,L,X}ubuntu) may use it for providing
> >>the
> >>> latest stable versions of their desktops for LTS users, and other
> >>apps
> >>> that are not part of DE (from the USC top: Vlc, Clementine,
> >>Lightread)
> >>
> >>> should also be updated there. Core stuff like
> >>> GCC/Python/Glib/Gtk/kernel shouldn't be touched of course.
> >>
> >>Serious question: why is GTK+ materially different from the core KDE
> >>libraries, which typically seem to be updated (even if only by minor
> >>releases) as part of KDE version bumps?
> >>
> > I wouldn't backport a major release of KDE libs or Qt.  We tried
> > backporting Qt4 for Hardy and it didn't go well.  These libs are,  IMO,
> > used by far to many applications for backports of major versions to be
> > safe.  I'd be surprised to find I felt differently about gtk2/3 if I
> > looked into in detail.
>
> OK, if we can't backport full KDE / GNOME, we can at least backport
> some individual apps (that don't depend on new versions of libraries).
> I don't know about KDE, but in GNOME lots of apps look backportable
> (for example, there are already some parts of GNOME 3.7 in raring,
> which is based while core components are at 3.6).
> 
You certainly could, but that couldn't provide an equivalent user experience 
for users of the complete new release.  I don't know what the right answer is 
for how to achieve the goal, but I think LTS + flavor specific package updates 
is an attractive release model.

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: Let's Discuss Interim Releases (and a Rolling Release)

[Dmitry Shachnev]

I meant "there are already some apps from GNOME 3.7 in raring, while
core GNOME components are at 3.6".

--
Dmitry Shachnev

On 3/2/13, Dmitry Shachnev  wrote:
> OK, if we can't backport full KDE / GNOME, we can at least backport
> some individual apps (that don't depend on new versions of libraries).
> I don't know about KDE, but in GNOME lots of apps look backportable
> (for example, there are already some parts of GNOME 3.7 in raring,
> which is based while core components are at 3.6).
>
> --
> Dmitry Shachnev
>
> On 3/2/13, Scott Kitterman  wrote:
>> Colin Watson  wrote:
>>
>>>On Fri, Mar 01, 2013 at 07:37:34PM +0400, Dmitry Shachnev wrote:
 We must decide whether the rolling branch is for users/enthusiasts or
 for developers only. If the latter (it's what most of us like), we
>>>are
 *not* switching to rolling release model. We are just dropping
>>>non-LTS
 releases.
>>>
>>>If it's for developers only then I would account that a failure.  It is
>>>necessary to open it up rather more widely than that if we stop
>>>providing non-LTS releases.
>>>
 In both cases, we should try to make it more stable than the current
 raring is. My suggestions are:

 - Auto-sync packages from Debian testing, not sid;
>>>
>>>Please no.  Now that we have -proposed to release migration, we're
>>>guarded against the worst excesses of unstable.  Past experience has
>>>suggested that the main effect of autosyncing from testing is to make
>>>it
>>>take longer for regressions to get fixed, or else make us spend more
>>>time chasing down regressions fixed in unstable but not in testing.
>>>
 - Make -proposed → -release migration more clever (i.e. recursively
 building all reverse dependencies, and running their autopkgtests, if
 any) — not sure if it is already done;
>>>
>>>This is planned and partially implemented.  I'd hoped to finish it off
>>>a
>>>couple of months ago but got a bit stuck; it'll clearly need to happen.
>>>
 - Create and use -experimental pocket (as suggested by Stefano) for
 testing unstable changes and handling transitions;
>>>
>>>I can understand why people ask for this, but new pockets are very
>>>complex to create due to extensive hardcoding of pocket semantics in
>>>Launchpad; they aren't something we can do easily or flexibly.  Plus,
>>>if
>>>we create one new experimental pocket, what happens when different
>>>people's in-progress projects clash?  I foresee trouble with this
>>>strategy.
>>>
>>>I wonder whether we could petition for the Canonical-only restrictions
>>>on devirtualised PPAs to be lifted for people in ~ubuntu-dev as a
>>>consequence of this release plan, and what other changes that would
>>>take.
>>>
 Also, if we are dropping non-LTS releases, we should make more use of
 -backports. Some flavours ({K,L,X}ubuntu) may use it for providing
>>>the
 latest stable versions of their desktops for LTS users, and other
>>>apps
 that are not part of DE (from the USC top: Vlc, Clementine,
>>>Lightread)
 should also be updated there. Core stuff like
 GCC/Python/Glib/Gtk/kernel shouldn't be touched of course.
>>>
>>>Serious question: why is GTK+ materially different from the core KDE
>>>libraries, which typically seem to be updated (even if only by minor
>>>releases) as part of KDE version bumps?
>>
>> I wouldn't backport a major release of KDE libs or Qt.  We tried
>> backporting
>> Qt4 for Hardy and it didn't go well.  These libs are,  IMO, used by far
>> to
>> many applications for backports of major versions to be safe.  I'd be
>> surprised to find I felt differently about gtk2/3 if I looked into in
>> detail.
>>
>> 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: Let's Discuss Interim Releases (and a Rolling Release)

[Dmitry Shachnev]

OK, if we can't backport full KDE / GNOME, we can at least backport
some individual apps (that don't depend on new versions of libraries).
I don't know about KDE, but in GNOME lots of apps look backportable
(for example, there are already some parts of GNOME 3.7 in raring,
which is based while core components are at 3.6).

--
Dmitry Shachnev

On 3/2/13, Scott Kitterman  wrote:
> Colin Watson  wrote:
>
>>On Fri, Mar 01, 2013 at 07:37:34PM +0400, Dmitry Shachnev wrote:
>>> We must decide whether the rolling branch is for users/enthusiasts or
>>> for developers only. If the latter (it's what most of us like), we
>>are
>>> *not* switching to rolling release model. We are just dropping
>>non-LTS
>>> releases.
>>
>>If it's for developers only then I would account that a failure.  It is
>>necessary to open it up rather more widely than that if we stop
>>providing non-LTS releases.
>>
>>> In both cases, we should try to make it more stable than the current
>>> raring is. My suggestions are:
>>>
>>> - Auto-sync packages from Debian testing, not sid;
>>
>>Please no.  Now that we have -proposed to release migration, we're
>>guarded against the worst excesses of unstable.  Past experience has
>>suggested that the main effect of autosyncing from testing is to make
>>it
>>take longer for regressions to get fixed, or else make us spend more
>>time chasing down regressions fixed in unstable but not in testing.
>>
>>> - Make -proposed → -release migration more clever (i.e. recursively
>>> building all reverse dependencies, and running their autopkgtests, if
>>> any) — not sure if it is already done;
>>
>>This is planned and partially implemented.  I'd hoped to finish it off
>>a
>>couple of months ago but got a bit stuck; it'll clearly need to happen.
>>
>>> - Create and use -experimental pocket (as suggested by Stefano) for
>>> testing unstable changes and handling transitions;
>>
>>I can understand why people ask for this, but new pockets are very
>>complex to create due to extensive hardcoding of pocket semantics in
>>Launchpad; they aren't something we can do easily or flexibly.  Plus,
>>if
>>we create one new experimental pocket, what happens when different
>>people's in-progress projects clash?  I foresee trouble with this
>>strategy.
>>
>>I wonder whether we could petition for the Canonical-only restrictions
>>on devirtualised PPAs to be lifted for people in ~ubuntu-dev as a
>>consequence of this release plan, and what other changes that would
>>take.
>>
>>> Also, if we are dropping non-LTS releases, we should make more use of
>>> -backports. Some flavours ({K,L,X}ubuntu) may use it for providing
>>the
>>> latest stable versions of their desktops for LTS users, and other
>>apps
>>> that are not part of DE (from the USC top: Vlc, Clementine,
>>Lightread)
>>> should also be updated there. Core stuff like
>>> GCC/Python/Glib/Gtk/kernel shouldn't be touched of course.
>>
>>Serious question: why is GTK+ materially different from the core KDE
>>libraries, which typically seem to be updated (even if only by minor
>>releases) as part of KDE version bumps?
>
> I wouldn't backport a major release of KDE libs or Qt.  We tried backporting
> Qt4 for Hardy and it didn't go well.  These libs are,  IMO, used by far to
> many applications for backports of major versions to be safe.  I'd be
> surprised to find I felt differently about gtk2/3 if I looked into in
> detail.
>
> 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: Let's Discuss Interim Releases (and a Rolling Release)

[Florian Diesch]

Am Fri, 1 Mar 2013 15:12:38 +0200
schrieb Stefano Rivera :

> Ubuntu has a few packages Debian doesn't. Including a desktop
> environment that people seem to complain about a lot.

Unity would actually be one of the very few things that could keep me
with Ubuntu.

> Most developers want to be developing on the latest libraries.
> Essentially, developing on their target. For open source developers,
> that could mean the latest Gnome/KDE, but for everyone else probably
> wants a rock-solid desktop environment.

As an application developer I want a stable environment that isn't too
far behind upstream. I don't want to deal with changing APIs when I'm
working on a project.


-- 
Privacy Indicator
Unity appindicator to switch privacy settings



signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Alan Bell]

For the "monthly" option as I understand it this means once a month you 
get todays latest stuff. Next month you upgrade from last months latest 
stuff to todays latest stuff.
This is not really what I want, if I want to take a conservative 
attitude to life. What I want is to be the penguin at the back of the 
crowd when we jump into the water - if the first few in get eaten, that 
is fine because it won't be me. When I get in the water will be safe.

http://hellenicpolytheist.files.wordpress.com/2012/07/killer_whale_eating_penguins-jump-in-air.jpg

What I want is not a "monthly" release, but a "today - 1 month" daily 
repo. This would automatically be identical to the daily repository, but 
a month behind in time - unless something goes wrong and a release of a 
package is tagged as "this one eats penguins/breaks grub/X doesn't 
start" in which case that release of that package would be skipped in 
the "today - 1 month" repo. I am not worried about having frequent 
updates, I just want them to have been tested for the presence of large 
marine predators.


Alan.

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

On Friday, March 01, 2013 03:18:26 PM Steve Langasek wrote:
> On Fri, Mar 01, 2013 at 01:31:37AM -0500, Scott Kitterman wrote:
> > David Henningsson  wrote:
> > >On 03/01/2013 05:55 AM, Scott Kitterman wrote:
> > >> On Friday, March 01, 2013 05:50:35 AM Martin Pitt wrote:
> > >>> For those we'll need temporary staging areas which are not put into
> > >>> the RR yet until they get a sufficient amount of testing; these
> > >
> > >could
> > >
> > >>> be "topic PPAs" which interested people would enable and develop in,
> > >>> which get landed into the RR when everything is ready?
> > >> 
> > >> For people or teams that are largely or entirely !canonical, this only
> > >> works if all you care about is x86 (i386/amd64).  Anything for armhf
> > >> (or powerpc) would have to land untested since the PPAs that are
> > >> available for !canonical don't build these architectures.
> > >
> > >From what I've heard, that is already fixed, at least for armhf - see
> > >http://dev.launchpad.net/CommunityARMBuilds
> > 
> > Not really.   Look at the limits associated with that.  It's a miminally
> > useful small scale capability.
> > 
> > Also, since it's (AIUI) virtualized, packages built in one of these PPAs
> > aren't suitable for copy to the primary archive.
> > 
> > It's a step, but not a solution.
> 
> If being able to build everything in virtualized ppas with armhf support
> would help solve the release issues for Kubuntu, I believe there's room for
> giving Kubuntu a bigger chunk of time on the virtualized builders.
> 
> AIUI, there are several issues at present that would prevent Kubuntu staging
> its builds of the 6-month KDE releases in ppas:
> 
>  - Kubuntu's build requirements would exceed the advertised community usage
>limits for virtualized armhf ppas
>  - KDE doesn't build under current qemu due to qemu bugs
>  - Binaries can't be copied from virt ppas to the archive, so rebuilds would
> be required when promoting
>  - It's not clear if there's a ppa schema that would meet the Kubuntu
>community's needs, or what that schema would be
> 
> Does that sound accurate?
> 
> None of these issues seem insurmountable to me; if the Kubuntu devs decide
> this is the right way to go, I don't think it's out of reach.

First, a disclaimer: While we've been discussing this topic within the Kubuntu 
development team, there's certainly no consensus about exactly what our needs 
are and how we would want to move forward if a near-term decision to abandon 
the current development model for this new proposal were taken.  So this is my 
view, I'm sure others in kubuntu-dev will have different ones.

It does sound accurate as far as it goes.  There are two related, but distinct 
sets of issues:

1.  How to we land major new versions of the packages we focus on into a 
rolling release without significant disruption to the user experience.  With an 
appropriate PPA structure, this would be easily accommodated as a natural 
extension of our current processes.  We'd need to decide policy for when to 
move things from the staging PPA to the rolling archive and I'm concerned that 
waiting too long will compromise the amount of user testing we get and moving 
too soon will compromise the stability of rolling.  From a technical 
perspective, this is not difficult though.

2.  How do we deal with releasing Kubuntu.  I am of the opinion that having "a 
release with the current KDE shortly after it's out" is a significant part of 
Kubuntu's reason for existing.  LTS + Rolling just does not satisfy that.

As I've mentioned elsewhere in one of these subthreads with my ~ubuntu-
backporters lead hat firmly in place, delivering major new versions of KDE and 
required KDE support appliications is not an appropriate use of backports.

Ideally, I'd like to be able to have some way to continue to do a release of 
LTS + Kubuntu packages (KDE and a few related packages) as a Kubuntu release.  
I haven't come up with an ideal approach to do this, but it might be LTS + a 
version specific PPA.  It might be an LP derived distribution.  I really don't 
know how best to approach it.

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: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

On Friday, March 01, 2013 08:15:13 PM Evan Dandrea wrote:
> On Fri, Mar 1, 2013 at 5:36 AM, Scott Kitterman  
wrote:
> > No would be a good time to be discussing this change for after 14.04. 
> > Doing this mid LTS - LTS cycle is going to be problematic for a variety
> > of reasons. I we had a year to get ready, then we might be in a
> > reasonable place to decide on making a transition like this.
> 
> I emphatically disagree. We have been laying the foundation for
> exactly this sort of thing for years. You've already read about the
> extensive testing on jenkins.qa.ubuntu.com, britney, the phasing of
> updates, the wealth of data from errors.ubuntu.com, changes to
> update-manager, and many other supporting actors to this that are
> already in place today or not far off. If we need more than that, lets
> get off the mailing list and get it written, but lets do it while
> moving forward.
> 
> Many of these tools will need to be developed in motion. We wont know
> how effective they are and what improvements need to be made until
> we're running them with real data from the rolling release.

Personally, I prefer the approach where we figure out what kind of tires we 
need on the next car and plan for them when we buy the car over an approach 
where we try to change the tires while the car is in motion.

While a lot of work has been done, I think the discussion to date shows that 
this is no where near completely thought through at the requirements level, 
let alone a mature concept ready for implementation.

I think a reasonable path for moving forward is to plan for transition to a 
rolling model after 14.04.  That doesn't mean work needs to wait, just the we 
should demonstrably have all the bits in place needed to throw the switch and 
move to the new development model before the decision to do it is made, not 
after.

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: Let's Discuss Interim Releases (and a Rolling Release)

[Steve Langasek]

On Fri, Mar 01, 2013 at 01:31:37AM -0500, Scott Kitterman wrote:
> David Henningsson  wrote:

> >On 03/01/2013 05:55 AM, Scott Kitterman wrote:
> >> On Friday, March 01, 2013 05:50:35 AM Martin Pitt wrote:
> >>> For those we'll need temporary staging areas which are not put into
> >>> the RR yet until they get a sufficient amount of testing; these
> >could
> >>> be "topic PPAs" which interested people would enable and develop in,
> >>> which get landed into the RR when everything is ready?

> >> For people or teams that are largely or entirely !canonical, this only
> >> works if all you care about is x86 (i386/amd64).  Anything for armhf
> >> (or powerpc) would have to land untested since the PPAs that are
> >> available for !canonical don't build these architectures.

> >From what I've heard, that is already fixed, at least for armhf - see
> >http://dev.launchpad.net/CommunityARMBuilds

> Not really.   Look at the limits associated with that.  It's a miminally
> useful small scale capability.

> Also, since it's (AIUI) virtualized, packages built in one of these PPAs
> aren't suitable for copy to the primary archive.

> It's a step, but not a solution. 

If being able to build everything in virtualized ppas with armhf support
would help solve the release issues for Kubuntu, I believe there's room for
giving Kubuntu a bigger chunk of time on the virtualized builders.

AIUI, there are several issues at present that would prevent Kubuntu staging
its builds of the 6-month KDE releases in ppas:

 - Kubuntu's build requirements would exceed the advertised community usage
   limits for virtualized armhf ppas
 - KDE doesn't build under current qemu due to qemu bugs
 - Binaries can't be copied from virt ppas to the archive, so rebuilds would
   be required when promoting
 - It's not clear if there's a ppa schema that would meet the Kubuntu
   community's needs, or what that schema would be

Does that sound accurate?

None of these issues seem insurmountable to me; if the Kubuntu devs decide
this is the right way to go, I don't think it's out of reach.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

Dmitry Shachnev  wrote:

>On Fri, Mar 1, 2013 at 9:10 PM, Colin Watson 
>wrote:
>> ...
>>> - Create and use -experimental pocket (as suggested by Stefano) for
>>> testing unstable changes and handling transitions;
>>
>> I can understand why people ask for this, but new pockets are very
>> complex to create due to extensive hardcoding of pocket semantics in
>> Launchpad; they aren't something we can do easily or flexibly.
>
>We can just use a centralized PPA then (for example, the desktop team
>already stages their experimental packages in their PPA). The only
>problem will be with managing upload rights to that PPA.
>
>> ...
>> Serious question: why is GTK+ materially different from the core KDE
>> libraries, which typically seem to be updated (even if only by minor
>> releases) as part of KDE version bumps?
>
>Because updating Gtk+ can potentially break the Unity stack and some
>components of GNOME we are using in Ubuntu Desktop. Updating core KDE
>libraries can break only KDE apps, which are updated to a compatible
>version.

Please have a look at all the kdelibs reverse depends. Only a small fraction of 
its users are part of KDE. 

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: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

Colin Watson  wrote:

>On Fri, Mar 01, 2013 at 07:37:34PM +0400, Dmitry Shachnev wrote:
>> We must decide whether the rolling branch is for users/enthusiasts or
>> for developers only. If the latter (it's what most of us like), we
>are
>> *not* switching to rolling release model. We are just dropping
>non-LTS
>> releases.
>
>If it's for developers only then I would account that a failure.  It is
>necessary to open it up rather more widely than that if we stop
>providing non-LTS releases.
>
>> In both cases, we should try to make it more stable than the current
>> raring is. My suggestions are:
>> 
>> - Auto-sync packages from Debian testing, not sid;
>
>Please no.  Now that we have -proposed to release migration, we're
>guarded against the worst excesses of unstable.  Past experience has
>suggested that the main effect of autosyncing from testing is to make
>it
>take longer for regressions to get fixed, or else make us spend more
>time chasing down regressions fixed in unstable but not in testing.
>
>> - Make -proposed → -release migration more clever (i.e. recursively
>> building all reverse dependencies, and running their autopkgtests, if
>> any) — not sure if it is already done;
>
>This is planned and partially implemented.  I'd hoped to finish it off
>a
>couple of months ago but got a bit stuck; it'll clearly need to happen.
>
>> - Create and use -experimental pocket (as suggested by Stefano) for
>> testing unstable changes and handling transitions;
>
>I can understand why people ask for this, but new pockets are very
>complex to create due to extensive hardcoding of pocket semantics in
>Launchpad; they aren't something we can do easily or flexibly.  Plus,
>if
>we create one new experimental pocket, what happens when different
>people's in-progress projects clash?  I foresee trouble with this
>strategy.
>
>I wonder whether we could petition for the Canonical-only restrictions
>on devirtualised PPAs to be lifted for people in ~ubuntu-dev as a
>consequence of this release plan, and what other changes that would
>take.
>
>> Also, if we are dropping non-LTS releases, we should make more use of
>> -backports. Some flavours ({K,L,X}ubuntu) may use it for providing
>the
>> latest stable versions of their desktops for LTS users, and other
>apps
>> that are not part of DE (from the USC top: Vlc, Clementine,
>Lightread)
>> should also be updated there. Core stuff like
>> GCC/Python/Glib/Gtk/kernel shouldn't be touched of course.
>
>Serious question: why is GTK+ materially different from the core KDE
>libraries, which typically seem to be updated (even if only by minor
>releases) as part of KDE version bumps?

I wouldn't backport a major release of KDE libs or Qt.  We tried backporting 
Qt4 for Hardy and it didn't go well.  These libs are,  IMO, used by far to many 
applications for backports of major versions to be safe.  I'd be surprised to 
find I felt differently about gtk2/3 if I looked into in detail.

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: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

Dmitry Shachnev  wrote:

>On Fri, Mar 1, 2013 at 11:08 AM, Stefano Rivera 
>wrote:
>> Hi Scott (2013.03.01_06:55:18_+0200)
>>> > I fully agree, and this is not even limited to the kernel. There
>are
>>> > other kinds of "major transitions" like switching to a new X.org
>>> > server, preparing a new major Qt or GNOME release, new eglibc,
>etc. Or
>>> > we want to do a complex transition such as moving from ConsoleKit
>to
>>> > logind.
>>> >
>>> > For those we'll need temporary staging areas which are not put
>into
>>> > the RR yet until they get a sufficient amount of testing; these
>could
>>> > be "topic PPAs" which interested people would enable and develop
>in,
>>> > which get landed into the RR when everything is ready?
>>>
>>> For people or teams that are largely or entirely !canonical, this
>only works
>>> if all you care about is x86 (i386/amd64).  Anything for armhf (or
>powerpc)
>>> would have to land untested since the PPAs that are available for
>!canonical
>>> don't build these architectures.
>>
>> It feels like an -experimental pocket would be the best solution
>here.
>> Which we would try to keep small, but could stage major transitions
>in.
>>
>> SR
>
>We must decide whether the rolling branch is for users/enthusiasts or
>for developers only. If the latter (it's what most of us like), we are
>*not* switching to rolling release model. We are just dropping non-LTS
>releases.
>
>In both cases, we should try to make it more stable than the current
>raring is. My suggestions are:
>
>- Auto-sync packages from Debian testing, not sid;
>- Make -proposed → -release migration more clever (i.e. recursively
>building all reverse dependencies, and running their autopkgtests, if
>any) — not sure if it is already done;
>- Create and use -experimental pocket (as suggested by Stefano) for
>testing unstable changes and handling transitions;
>- Maybe it'll make sense to freeze the archive for a couple of days
>before every monthly snapshot (like we did for beta releases).
>
>Also, if we are dropping non-LTS releases, we should make more use of
>-backports. Some flavours ({K,L,X}ubuntu) may use it for providing the
>latest stable versions of their desktops for LTS users, and other apps
>that are not part of DE (from the USC top: Vlc, Clementine, Lightread)
>should also be updated there. Core stuff like
>GCC/Python/Glib/Gtk/kernel shouldn't be touched of course.

Backports aren't suitable for sustaining newer versions of things like KDE. The 
libs are too far broadly used to properly test.  I'd expect other DEs to be 
similar. 

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: Let's Discuss Interim Releases (and a Rolling Release)

[Loïc Minier]

On Fri, Mar 01, 2013, Steve Langasek wrote:
> Sounds familiar:
>   http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntu/

haha, I couldn't find were the /latest were; checked cdimage and it
didn't have them  :-)

-- 
Loïc Minier

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Steve Langasek]

On Fri, Mar 01, 2013 at 10:13:39PM +0100, Loïc Minier wrote:
> On Fri, Mar 01, 2013, Colin Watson wrote:
> > The latter option (publish immediately, symlink only after passing
> > tests) would be simpler to implement and is probably the most plausible
> > way to do this; after all if you don't publish them at all on cdimage
> > then you have to invent some new way to publish them to jenkins for
> > smoke-testing.  It would require something to check in on test results
> > every so often, but that probably isn't too hopelessly difficult.

> In fact, we could maintain a /latest vs. a /current; /latest would
> always be updated, but /current (or /tested, /releasable etc.) would
> only be updated when the image passes tests.

Sounds familiar:

  http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntu/

:-)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Loïc Minier]

On Fri, Mar 01, 2013, Colin Watson wrote:
> The latter option (publish immediately, symlink only after passing
> tests) would be simpler to implement and is probably the most plausible
> way to do this; after all if you don't publish them at all on cdimage
> then you have to invent some new way to publish them to jenkins for
> smoke-testing.  It would require something to check in on test results
> every so often, but that probably isn't too hopelessly difficult.

In fact, we could maintain a /latest vs. a /current; /latest would
always be updated, but /current (or /tested, /releasable etc.) would
only be updated when the image passes tests.

-- 
Loïc Minier

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Stefano Rivera]

Hi Colin (2013.03.01_19:10:04_+0200)
> I wonder whether we could petition for the Canonical-only restrictions
> on devirtualised PPAs to be lifted for people in ~ubuntu-dev as a
> consequence of this release plan, and what other changes that would
> take.

Presumably devirt PPAs would have to not throw away uploads? And we'd
need a list of all the devirt PPAs.

Of course, having separate PPAs for staging unrelated changes would be
fantastic. But if we are dependent on full upload history as a buildd
audit trail, then these PPAs need to be considered part of the Ubuntu
archive.

If we want end-users on our rolling release, then we don't really have
anywhere to put things that we'd like to dogfood on our developers, but
not the users. I was thinking of that too, when I proposed a new pocket.

I feel that if we are trying to totally change our release process,
we should consider restructuring pockets, rather than shoe-horning
everything into the existing structure. Or maybe it's going to take us a
while to figure out what we want and we shouldn't be making any hasty
changes...

And yes, of course, adding new pockets would be non-trivial.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 461 1230 C: +27 72 419 8559

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

Re: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Evan Dandrea]

On Fri, Mar 1, 2013 at 5:36 AM, Scott Kitterman  wrote:
> No would be a good time to be discussing this change for after 14.04.  Doing
> this mid LTS - LTS cycle is going to be problematic for a variety of reasons.
> I we had a year to get ready, then we might be in a reasonable place to decide
> on making a transition like this.

I emphatically disagree. We have been laying the foundation for
exactly this sort of thing for years. You've already read about the
extensive testing on jenkins.qa.ubuntu.com, britney, the phasing of
updates, the wealth of data from errors.ubuntu.com, changes to
update-manager, and many other supporting actors to this that are
already in place today or not far off. If we need more than that, lets
get off the mailing list and get it written, but lets do it while
moving forward.

Many of these tools will need to be developed in motion. We wont know
how effective they are and what improvements need to be made until
we're running them with real data from the rolling release.

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Philip Muskovac]

On Friday 01 March 2013 01:31:37 Scott Kitterman wrote:
> David Henningsson  wrote:
> >On 03/01/2013 05:55 AM, Scott Kitterman wrote:
> >> On Friday, March 01, 2013 05:50:35 AM Martin Pitt wrote:
> >>> For those we'll need temporary staging areas which are not put into
> >>> the RR yet until they get a sufficient amount of testing; these
> >
> >could
> >
> >>> be "topic PPAs" which interested people would enable and develop in,
> >>> which get landed into the RR when everything is ready?
> >> 
> >> For people or teams that are largely or entirely !canonical, this
> >
> >only works
> >
> >> if all you care about is x86 (i386/amd64).  Anything for armhf (or
> >
> >powerpc)
> >
> >> would have to land untested since the PPAs that are available for
> >
> >!canonical
> >
> >> don't build these architectures.
> > 
> > From what I've heard, that is already fixed, at least for armhf - see
> >
> >http://dev.launchpad.net/CommunityARMBuilds
> 
> Not really.   Look at the limits associated with that.  It's a miminally
> useful small scale capability.
> 
> Also, since it's (AIUI) virtualized, packages built in one of these PPAs
> aren't suitable for copy to the primary archive.
> 
> It's a step, but not a solution.
> 
> Scott K

Let me add that due to 
https://bugs.launchpad.net/bugs/1077116
(automoc4 crashes in qemu-virtualized armhf)
Kubuntu doesn't have any *usable* armhf PPA builders right now as KDE software 
doesn't compile in qemu.

The only way for us to get armhf binaries built is by using the archive 
builders. If we can't use those for development anymore we have a bit of a 
problem.

Philip Muskovac

signature.asc
Description: This is a digitally signed message part.
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 09:20:11PM +0400, Dmitry Shachnev wrote:
> On Fri, Mar 1, 2013 at 9:10 PM, Colin Watson  wrote:
> > Serious question: why is GTK+ materially different from the core KDE
> > libraries, which typically seem to be updated (even if only by minor
> > releases) as part of KDE version bumps?
> 
> Because updating Gtk+ can potentially break the Unity stack and some
> components of GNOME we are using in Ubuntu Desktop. Updating core KDE
> libraries can break only KDE apps, which are updated to a compatible
> version.

Taking a dispassionate neutral point of view, these seem like
essentially the same thing; both are confined to a subsystem, and I
suspect the number of packages involved is roughly similar.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 12:01:25PM -0500, Barry Warsaw wrote:
> On Mar 01, 2013, at 04:52 PM, Colin Watson wrote:
> >FWIW, I have come to believe that nobody should use 'apt-get upgrade' as
> >a general rule.  In particular, since it tries its best to install as
> >much as it can under the constraint that it never installs new packages
> >or removes installed ones, it will carry merrily on without installing
> >any new Recommends introduced by the upgrade set, and you will never
> >hear about them again unless some other package starts recommending the
> >same target packages.
> >
> >Just using 'apt-get dist-upgrade' all the time, or something with closer
> >semantics to that, is better.
> 
> I generally agree, but just as a point of clarification: `apt-get upgrade`
> will tell you when there are things its holding back, so with confirmation,
> it's a nice little reminder to look a little more closely before switching
> over to `apt-get dist-upgrade`.

The problem is that it *won't* tell you about Recommends, because
unsatisfied Recommends don't cause things to be held back.  It'll just
let you do the upgrade and forget about the new Recommends.  (Well,
there might be a "Recommended packages:" section somewhere in the middle
of the screed of output; I haven't checked.  But it's at best not
usually very obvious.)

> [*] A recent example was the removal of libreoffice-presenter-mode (or
> whatever it was called).  I love that package so I wanted a little more
> clarification about why it was being removed before I dist-upgraded.  Turns
> out the feature was being merged into the core package, so all was well, but
> I'm glad I verified it first.

Yep.  I think the update-manager change I implemented recently to permit
removals only when there's a matching Conflicts/Replaces/Provides set is
broadly the right heuristic for this, but I'm quite sure there's room
for more fine-tuning to encapsulate what experienced people do in a
sensible set of defaults.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 04:48:21PM +0200, Jonathan Carter (highvoltage) wrote:
> On 01/03/2013 15:12, Stefano Rivera wrote:
> >And we have to ask the question of what advantage Ubuntu is providing
> >over Debian, without 6-monthly releases.
> 
> I think for the hacker. for the enthusiast, for the people who like
> to build their own stuff whether for fun or profit... not that much
> really.
> 
> But I've come to peace a long time ago that I'm not in the Ubuntu
> target market. I think what Ubuntu provides over Debian, for the
> users who would find it useful is:
> 
>  * Longer support cycle (Ubuntu LTS is supported for 5 years,
>  Debian typically for around 3 years)
>  * Ability to purchase commercial support from Canonical
>  * Packages only in Ubuntu (Unity, etc) (fixable)
>  * Services tied in to Ubuntu using non-free products such as
>Ubuntu One and Landscape. (not trivial to get for Debian)
>  * Access to a larger repository of non-free software that is
>already properly packaged and integrated (in Debian we don't
>particularly care about that)

Also there are some things where the ability to get broad changes into
Ubuntu more quickly is really useful.  Look at Wookey's recent Debian
arm64 port announcement, for example: built on Ubuntu because it has
just been taking too long to get some easy patches into Debian, and the
nature of the beast is that even one missing patch to a core package can
be a serious blocker.

For multiarch and cross-building, we're way ahead of Debian right now,
and not because we've been hoarding patches.  I'm sure there are other
examples like that.

> What bothers me more than user loss is developer loss. It's a fact
> that Ubuntu as a community project is currently completely
> unsustainable. The community is just a thin layer on the work that
> Canonical is doing and if Canonical would dissappear (completely
> hypothetically), then I can't see how the project would carry on for
> long.
> 
> Ubuntu is /much/ more of a commercial project that happens to have a
> community rather than a community project with commercial backing,
> as it is often marketed by Canonical. It actually hurts a lot that
> Canonical people in leadership positions completely refuse to
> acknowledge this at all.

I suspect that many folks in Canonical would find it unpalatable to make
such an argument, because it would be very hard to avoid it sounding
like a criticism or a dismissal of the Ubuntu community outside
Canonical.  That would certainly be a consideration for me in any such
discussion.

Loss of developers is certainly a concern for me.  Stefano does have a
point that there's a chance that a rolling release model might help.  At
the moment we often see confusion among new developers asking how they
can get some big change into 12.10, or submitting patches against stable
releases and then having to round-trip to get them to submit against the
development release instead (which they don't use), etc.  The message
would be clearer, and I think more likely to fit what distribution
developers (as opposed to application developers) often naturally
assume, if we had LTS and rolling.  (Debian doesn't have nearly the same
problem with new developers trying to submit patches against stable.)

> >Dare I ask what happens when we approach the next LTS? Does the rolling
> >release freeze? From our current plans, I'd guess so.
> >Isn't that exactly what people who like rolling releases want to avoid?
> >The "debian-testing is frozen" problem?
> 
> It would be interesting to see what happens to 13.04 users, they
> wouldn't have an upgrade path to 14.04 if there are no releases in
> between. I guess they'll either have to be told "sorry, too bad" or
> 14.04 would have to be upgradeable from 12.04 and 13.04 (yikes).

Supporting upgrades from 13.04 is not that much extra work in addition
to supporting upgrades from 12.04.  The other way round is what's hard.

As for users of 13.04 being catapulted onto a rolling release without
notice: well, if Canonical withdraws funding for a 13.04 release, I
don't see much alternative to "sorry, too bad".  But at least those
users are people who signed up to a development release in the first
place, and either they're developers who will just stay on the
development release almost all the time anyway, or a rolling release
might be an improvement.  I'm more worried about the message to 12.10
users.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Alishams Hassam]

== TL;DR == 

Apologies for the improper post, but my gmail account didn't get the
entire thread. I'm not a dev, just a long time user (since Warty
[technically, since Hoary as Warty pissed me off for some reason I can't
remember]. I've also provided support/installed Ubuntu for several
hundred lay people and counting, as part of my previous
work/volunteering/fun with Free Geek Vancouver. I would *love* to see
Ubuntu go rolling, but carefully, and learning from distros like Arch
Linux - doing the best we can to avoid common pitfalls. 

== -vv --VeryVerbose ==

I personally can work around any problems with rolling releases and
that's why I love love love Arch Linux, but that's not for Reg Ular User
who wants things to *just work.* Reg wants to do her/his thing and the
O/S should stay out of the way. IMHO, these two aspects piss off Reg
(into a rage):

1. Older libs need to be supported
2. Reg Dolt User decides to wait 3.5 months between updates; Reg
shouldn't have the system break [or we need to find a way to avoid
this].

1. Some programs won't be supported when new libraries come out and the
distro updates. Say a dev writes a cool game in SFML 1.6 and Ubuntu
rolling decides to use 2.0 - uh oh, we have some sad users and a dev
that now has to port. It would be *very* cool if older libraries could
somehow be supported so this situation doesn't happen (even as just as
an optional install with a flag such as
--ipromisetocleanuponceitisnotneeded) - but hey, that's what a small
secondary partition with the LTS is for, though that's not
user-friendly ;)

2. I can see monthly releases being of value to Reg Dolt User who hates
doing updates all the time. They just do an apt-get dist-upgrade once a
month. Or better yet it a confirmation dialogue with a warning not to
turn the machine off for the next few hours [the only options being
accept or ignore]. It also nags them once a day to this until they do
so, with no option to turn off the nag screen. 

We should try to discourage people waiting 3.5 months between updates as
breakage is going to take lots of work to prevent.  Arch Linux has
*never* broken on me through it's own fault, though it has when I've
fucked up. Now if you're being a moron and decide to update only once
every 3.5 months on Arch, you will probably get some trouble (I
admittedly did this, unintentionally, on a box that gets used
infrequently). This is not an acceptable situation for the Ubuntu user
base, IMHO. I'm thinking here of a slightly passionate user who
considers them-self a 'power user' :p They will just get frustrated and
die.

~Zeroedout


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Thu, Feb 28, 2013 at 06:24:59PM -0500, Scott Kitterman wrote:
> Perhaps it would make sense to extend 12.10 support by 6 months to give 12.10 
> users a decent interval to upgrade.

Agreed.  I understand the desire to cut costs, but giving people zero
days to switch over after we didn't tell them our plans [1] in advance
of their installing 12.10 seems a bit much to me.  I think we would have
to eat the cost of supporting 12.10 for a bit longer as the price of not
being properly organised about this.

[1] And indeed AFAIK didn't have those plans; applying this to 13.04 is
a very recent proposal even within Canonical.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Thu, Feb 28, 2013 at 03:47:21PM -0800, Scott Ritchie wrote:
> Perhaps it might also be correct to not refer to the "rolling
> release" as a release at all, but simply the current development
> version.

People outside the project are going to call it a rolling release
anyway; I don't see much point trying to push against the wind on that
:-)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Debian Sync - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Thu, Feb 28, 2013 at 12:59:19PM -0800, Steve Langasek wrote:
> On Thu, Feb 28, 2013 at 03:11:27PM -0500, Jeremy Bicha wrote:
> > I think we need to train our britney to block on Debian or Ubuntu RC
> > bugs. Maybe this will also allow the Kubuntu developers to package the
> > KDE beta updates without needing to worry about those getting picked
> > up in the next (monthly?) update cycle.
> 
> It is fundamental to the model that has been implemented for $devel-proposed
> in Ubuntu that we *don't* block packages in -proposed for anything other
> than consistency and installability, because to do otherwise would
> dramatically increase the on-hands management required to keep -proposed
> from becoming a tangled logjam.  We don't want to reproduce that part of the
> Debian testing experience.

I agree with most of this (and perhaps this is something that only has a
visceral appeal if you've been a Debian release manager ...).

That said, the worst problem is the time delay.  I didn't make our
proposed-migration instance check RC bugs because it didn't seem
desperately useful since users wouldn't have a chance to file them.  But
developers often have some idea that something might be risky when they
upload it too, or perhaps realise shortly afterwards, and even without
introducing an artificial delay there's a window while everything
builds.

Perhaps it would be useful to check Ubuntu Critical-priority bugs
anyway, without a delay?  This would have two advantages:

 1) The process for handling "argh, my upload was broken" goes from
"find a member of ubuntu-release and get them to commit a block
hint" to "file a critical bug".

 2) There would be an incentive for the Critical priority to actually
mean something for Ubuntu.  We aren't a million miles away from it
being useful, but there's never been a real incentive to clean
things up all the way.

Debian RC bugs are trickier.  Firstly, you'd have to check versions too.
Secondly, RC bugs are often due to more than just the version of the
specific package they're filed against, so we'd end up with a lot of
exceptions.  I can see why it's tempting but I think there may be too
many problems on the flip side for it to be worth it.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Dmitry Shachnev]

On Fri, Mar 1, 2013 at 9:10 PM, Colin Watson  wrote:
> ...
>> - Create and use -experimental pocket (as suggested by Stefano) for
>> testing unstable changes and handling transitions;
>
> I can understand why people ask for this, but new pockets are very
> complex to create due to extensive hardcoding of pocket semantics in
> Launchpad; they aren't something we can do easily or flexibly.

We can just use a centralized PPA then (for example, the desktop team
already stages their experimental packages in their PPA). The only
problem will be with managing upload rights to that PPA.

> ...
> Serious question: why is GTK+ materially different from the core KDE
> libraries, which typically seem to be updated (even if only by minor
> releases) as part of KDE version bumps?

Because updating Gtk+ can potentially break the Unity stack and some
components of GNOME we are using in Ubuntu Desktop. Updating core KDE
libraries can break only KDE apps, which are updated to a compatible
version.

--
Dmitry Shachnev

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Thu, Feb 28, 2013 at 10:09:04PM -0500, Michael Hall wrote:
> On 02/28/2013 06:01 PM, Ted Gould wrote:
> > I hope that we will.  My biggest worry with the rolling release 
> > methodology is that there is no deadlines for people to work
> > towards except the LTS deadlines.  This will then encourage more
> > polishing and refining, with a rush to an even bigger deadline.  We
> > could all say "you should be more disciplined than that," which is
> > a truism, but one that seems to ignore human nature.  So I hope
> > that there will be deadlines for the monthly releases that people
> > can target, and use for their own milestones.
> 
> I think we can use the 3-month UDS cycles for this, try and break down
> work items so that can be done by the next UDS.

We already had a problem that it was difficult to plan work more complex
than the six-month release cycle granularity.  Requiring everything to
be on a three-month granularity makes this even worse.  Sure, you can
try to break down work items, but you often need to retain more context
than that and our current planning style is often not very good at
retaining state unless you approach it with a lot of discipline.

I would suggest that it should be standard practice to be able to plan
to carry projects over, and that people shouldn't be required to
re-discuss things again and again if a project is already in progress
and going well.  This isn't to say that we don't sometimes need
iterative discussion and course-corrections; but there are also many
projects that are essentially uncontroversial where it's a waste of time
to keep showing up and saying "yup, we've got this far, seems fine".

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 07:37:34PM +0400, Dmitry Shachnev wrote:
> We must decide whether the rolling branch is for users/enthusiasts or
> for developers only. If the latter (it's what most of us like), we are
> *not* switching to rolling release model. We are just dropping non-LTS
> releases.

If it's for developers only then I would account that a failure.  It is
necessary to open it up rather more widely than that if we stop
providing non-LTS releases.

> In both cases, we should try to make it more stable than the current
> raring is. My suggestions are:
> 
> - Auto-sync packages from Debian testing, not sid;

Please no.  Now that we have -proposed to release migration, we're
guarded against the worst excesses of unstable.  Past experience has
suggested that the main effect of autosyncing from testing is to make it
take longer for regressions to get fixed, or else make us spend more
time chasing down regressions fixed in unstable but not in testing.

> - Make -proposed → -release migration more clever (i.e. recursively
> building all reverse dependencies, and running their autopkgtests, if
> any) — not sure if it is already done;

This is planned and partially implemented.  I'd hoped to finish it off a
couple of months ago but got a bit stuck; it'll clearly need to happen.

> - Create and use -experimental pocket (as suggested by Stefano) for
> testing unstable changes and handling transitions;

I can understand why people ask for this, but new pockets are very
complex to create due to extensive hardcoding of pocket semantics in
Launchpad; they aren't something we can do easily or flexibly.  Plus, if
we create one new experimental pocket, what happens when different
people's in-progress projects clash?  I foresee trouble with this
strategy.

I wonder whether we could petition for the Canonical-only restrictions
on devirtualised PPAs to be lifted for people in ~ubuntu-dev as a
consequence of this release plan, and what other changes that would
take.

> Also, if we are dropping non-LTS releases, we should make more use of
> -backports. Some flavours ({K,L,X}ubuntu) may use it for providing the
> latest stable versions of their desktops for LTS users, and other apps
> that are not part of DE (from the USC top: Vlc, Clementine, Lightread)
> should also be updated there. Core stuff like
> GCC/Python/Glib/Gtk/kernel shouldn't be touched of course.

Serious question: why is GTK+ materially different from the core KDE
libraries, which typically seem to be updated (even if only by minor
releases) as part of KDE version bumps?

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 07:12:03AM +0100, David Henningsson wrote:
> As we now move to a rolling release schedule, when is the right time
> to do a wide-scale testing and report bugs? Without just being met
> with a "please check if it's fixed in the next version" message?

I think we should deal with this by improving the way we interact with
users on bug reports.  A constant stream of "please see if this is fixed
in the next version", with no explanation of how it might be fixed,
gives users the impression that we don't really have much idea what
we're doing and are just throwing things at the wall until they stick.
The strategy here is often more about finding reasons to close bugs so
that the statistics look better, rather than actively working with users
to find fixes.

A better approach is something more thoughtful like "The $foobar
subsystem was extensively overhauled in 3.10, and has been reported to
improve output frobbing on AMD systems.  Could you test to see if this
fixes your bug?"  That is, we should have actual reasons for asking for
retests and we should tell users what they are, rather than making them
spend time retesting just for the sake of it.  If we do that and do it
well, then bug reporting schedules matter much less.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Barry Warsaw]

On Mar 01, 2013, at 04:52 PM, Colin Watson wrote:

>On Thu, Feb 28, 2013 at 12:12:34PM -0500, Barry Warsaw wrote:
>> Long gone are the days where a `apt-get upgrade` has broken my system
>> (knock on wood) and while I do inspect dist-upgrades a little more
>> carefully, they are usually pretty reliable too.
>
>FWIW, I have come to believe that nobody should use 'apt-get upgrade' as
>a general rule.  In particular, since it tries its best to install as
>much as it can under the constraint that it never installs new packages
>or removes installed ones, it will carry merrily on without installing
>any new Recommends introduced by the upgrade set, and you will never
>hear about them again unless some other package starts recommending the
>same target packages.
>
>Just using 'apt-get dist-upgrade' all the time, or something with closer
>semantics to that, is better.

I generally agree, but just as a point of clarification: `apt-get upgrade`
will tell you when there are things its holding back, so with confirmation,
it's a nice little reminder to look a little more closely before switching
over to `apt-get dist-upgrade`.  Usually there's no difference that I can
tell, except under the circumstances you describe above, and there I like to
just look a little more closely.  I'm almost -- but not quite -- at the point
where I *don't* care anymore since quality has been reliably so much better,
but that wasn't always the case previously.  In very rare cases, such as where
I'm just a little suspicious about dist-upgrade's package removals[*], I'll do
a test upgrade in a VM with disk snapshotting first.

Cheers,
-Barry

[*] A recent example was the removal of libreoffice-presenter-mode (or
whatever it was called).  I love that package so I wanted a little more
clarification about why it was being removed before I dist-upgraded.  Turns
out the feature was being merged into the core package, so all was well, but
I'm glad I verified it first.

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 05:46:19AM +0100, Martin Pitt wrote:
> Loïc Minier [2013-02-28 18:18 +0100]:
[...]
> > >  * What is the purpose of these snapshots, i. e. who would use them?
> > >If all our published daily images are good enough to install, boot,
> > >and get you into a desktop, and we wouldn't do significantly more
> > >QA on the "monthly" ones anyway, what makes these images special?
> > 
> > We need to bless "good" installation media in some way
> 
> My point is, we should never even have bad installation media on
> cdimage. If they fail smoketests, they should not even be published,
> or at least not be pointed to with the /current symlink.

The latter option (publish immediately, symlink only after passing
tests) would be simpler to implement and is probably the most plausible
way to do this; after all if you don't publish them at all on cdimage
then you have to invent some new way to publish them to jenkins for
smoke-testing.  It would require something to check in on test results
every so often, but that probably isn't too hopelessly difficult.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Thu, Feb 28, 2013 at 12:12:34PM -0500, Barry Warsaw wrote:
> Long gone are the days where a `apt-get upgrade` has broken my system
> (knock on wood) and while I do inspect dist-upgrades a little more
> carefully, they are usually pretty reliable too.

FWIW, I have come to believe that nobody should use 'apt-get upgrade' as
a general rule.  In particular, since it tries its best to install as
much as it can under the constraint that it never installs new packages
or removes installed ones, it will carry merrily on without installing
any new Recommends introduced by the upgrade set, and you will never
hear about them again unless some other package starts recommending the
same target packages.

Just using 'apt-get dist-upgrade' all the time, or something with closer
semantics to that, is better.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Security Support - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 05:54:32AM +0100, Martin Pitt wrote:
> Loïc Minier [2013-02-28 18:27 +0100]:
> > New series are super expensive to create, need coordination in a bunch
> > of places etc. and it means we're using the release dist upgrade
> > mechanisms rather than updating packages.
> 
> It wouldn't need to be a full series in the Launchpad sense; we could
> use a pocket, which is much more lightweight.

Using existing ones is lightweight.  Creating entirely new ones is even
more heavyweight than creating new series, and very scary; their
semantics are hardcoded in a variety of ad-hoc ways all over the LP
codebase.

> E. g. "raring" would take the role of "monthly" while the raring-daily
> pocket would take the role of "rolling release"; this could even be
> raring-updates, we don't use this pocket right now and it's already
> there.

We have discussed using raring-updates, indeed.  Reconfigure
proposed-migration to copy into -updates, then bulk-copy to the release
pocket once a month just in time to prepare the monthly image release.

While I think monthly image releases make sense, I don't personally like
the notion of monthly updates at all; I think they're pretty artificial
and it would be better to do an excellent job of the rolling release
rather than dividing our attention between two similar things, and there
are some awkward chicken-and-egg implementation problems relating to how
monthly image releases are prepared.  But if we have to do them then the
above is the obvious sensible way to do it.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Jonathan Carter (highvoltage)]

On 01/03/2013 16:48, Jonathan Carter (highvoltage) wrote:

It would be interesting to see what happens to 13.04 users, they
wouldn't have an upgrade path to 14.04 if there are no releases in
between. I guess they'll either have to be told "sorry, too bad" or
14.04 would have to be upgradeable from 12.04 and 13.04 (yikes).


s/13.04/12.10/g (oops)

-Jonathan

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Dmitry Shachnev]

On Fri, Mar 1, 2013 at 11:08 AM, Stefano Rivera  wrote:
> Hi Scott (2013.03.01_06:55:18_+0200)
>> > I fully agree, and this is not even limited to the kernel. There are
>> > other kinds of "major transitions" like switching to a new X.org
>> > server, preparing a new major Qt or GNOME release, new eglibc, etc. Or
>> > we want to do a complex transition such as moving from ConsoleKit to
>> > logind.
>> >
>> > For those we'll need temporary staging areas which are not put into
>> > the RR yet until they get a sufficient amount of testing; these could
>> > be "topic PPAs" which interested people would enable and develop in,
>> > which get landed into the RR when everything is ready?
>>
>> For people or teams that are largely or entirely !canonical, this only works
>> if all you care about is x86 (i386/amd64).  Anything for armhf (or powerpc)
>> would have to land untested since the PPAs that are available for !canonical
>> don't build these architectures.
>
> It feels like an -experimental pocket would be the best solution here.
> Which we would try to keep small, but could stage major transitions in.
>
> SR

We must decide whether the rolling branch is for users/enthusiasts or
for developers only. If the latter (it's what most of us like), we are
*not* switching to rolling release model. We are just dropping non-LTS
releases.

In both cases, we should try to make it more stable than the current
raring is. My suggestions are:

- Auto-sync packages from Debian testing, not sid;
- Make -proposed → -release migration more clever (i.e. recursively
building all reverse dependencies, and running their autopkgtests, if
any) — not sure if it is already done;
- Create and use -experimental pocket (as suggested by Stefano) for
testing unstable changes and handling transitions;
- Maybe it'll make sense to freeze the archive for a couple of days
before every monthly snapshot (like we did for beta releases).

Also, if we are dropping non-LTS releases, we should make more use of
-backports. Some flavours ({K,L,X}ubuntu) may use it for providing the
latest stable versions of their desktops for LTS users, and other apps
that are not part of DE (from the USC top: Vlc, Clementine, Lightread)
should also be updated there. Core stuff like
GCC/Python/Glib/Gtk/kernel shouldn't be touched of course.

--
Dmitry Shachnev

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Barry Warsaw]

On Mar 01, 2013, at 03:12 PM, Stefano Rivera wrote:

>And we have to ask the question of what advantage Ubuntu is providing
>over Debian, without 6-monthly releases.

I suppose one other difference is that Ubuntu will still used time-based
releases (just on a different schedule) while Debian will still use
release-when-ready (i.e. unpredictable time of release).

I have no idea whether that's an important, workable, or advantageous
distinction though. ;)

Cheers,
-Barry

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Barry Warsaw]

On Mar 01, 2013, at 08:18 AM, Ted Gould wrote:

>The problem there being that UDS is only signing up for more work, not a
>point where the work has to be delivered :-)  Ubuntu has had, in the
>past, an issue where the run up for UDS involves making sure we mark
>everything as POSTPONED.

I don't think that's a bad thing. ;) I'm probably not alone in being pretty
ambitious in work I propose at UDSes, and over the course of a cycle, reality
hits and work items start to get postponed.  I hope shorter cycles will lead
to more realistic planning.

However, not everything will be captured in 3-month blueprints.  Some
transitions and larger scale changes just take a long time.  I knew for
example that some of the things I wanted to accomplish since the last LTS
would take 2 years to fully realize.  Cycle-linked blueprints aren't a good
way to track that work, IMO.

-Barry


signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Stefano Rivera]

Hi Jonathan (2013.03.01_16:48:21_+0200)
> What bothers me more than user loss is developer loss. It's a fact
> that Ubuntu as a community project is currently completely
> unsustainable.
...
> >If we are finding that our non-LTS releases aren't stable enough, and
> >people are using the LTSs, what makes us think we can get a significant
> >userbase onto a rolling release that's less polished than our existing
> >releases?
> 
> Would it be a goal to have users use the rolling releases? I can't
> remember seeing that mentioned before in my catching up of the list.

Hrm, that is another good argument in favour of a rolling release.
Having more users on our development release will make contributing to
Ubuntu significantly easier, and take the round-trip time between
submitting a patch and seeing the benefit from 6 months to 1 month / 1
day.

When the development release isn't something that only Ubuntu developers
run, then the barrier to new contributions goes down.

> I can see a benefit in having normal users on lts releases only. It
> will make packaging of 3rd party apps that go into repositories such
> as 'extras' a lot easier and faster.

Right, agreed. As long as 2 years isn't too old for those users.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 461 1230 C: +27 72 419 8559

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Jonathan Carter (highvoltage)]

Howdy Stefano

Well, firstly, it's nice to see some action on ubuntu-devel again :)
...

On 01/03/2013 15:12, Stefano Rivera wrote:

And we have to ask the question of what advantage Ubuntu is providing
over Debian, without 6-monthly releases.


I think for the hacker. for the enthusiast, for the people who like to 
build their own stuff whether for fun or profit... not that much really.


But I've come to peace a long time ago that I'm not in the Ubuntu target 
market. I think what Ubuntu provides over Debian, for the users who 
would find it useful is:


 * Longer support cycle (Ubuntu LTS is supported for 5 years,
 Debian typically for around 3 years)
 * Ability to purchase commercial support from Canonical
 * Packages only in Ubuntu (Unity, etc) (fixable)
 * Services tied in to Ubuntu using non-free products such as
   Ubuntu One and Landscape. (not trivial to get for Debian)
 * Access to a larger repository of non-free software that is
   already properly packaged and integrated (in Debian we don't
   particularly care about that)

There are probably more items, but I think that's the gist of it.

The 6 month release cycle was good for a while, but let's face it, it 
really hasn't been working recently. Most general users can't keep up 
with the upgrades and it ends up a lot of work to sometimes just get 
slightly newer versions of software. From my observations the pros of a 
6 month release cycle no longer outway the cons. I can't say that I 
think the current approach is a good one, but a change certainly seems 
required.


What bothers me more than user loss is developer loss. It's a fact that 
Ubuntu as a community project is currently completely unsustainable. The 
community is just a thin layer on the work that Canonical is doing and 
if Canonical would dissappear (completely hypothetically), then I can't 
see how the project would carry on for long.


Ubuntu is /much/ more of a commercial project that happens to have a 
community rather than a community project with commercial backing, as it 
is often marketed by Canonical. It actually hurts a lot that Canonical 
people in leadership positions completely refuse to acknowledge this at 
all. I don't think that that will help much in terms of solving the 
problem, and that's harder for me to accept than not being in Ubuntu's 
target market by a long shot.



Ubuntu has a few packages Debian doesn't. Including a desktop
environment that people seem to complain about a lot.
Of course, it would also be nice to see most of those in Debian
eventually. Ubuntu would benefit from that too.


I think this will pick up a bit after Jessie is opened up properly. I 
remember seeing a few messages a while back saying that a few libraries 
in Unity are being deprecated that should make it a /lot/ easier to 
package on other systems.



If we are finding that our non-LTS releases aren't stable enough, and
people are using the LTSs, what makes us think we can get a significant
userbase onto a rolling release that's less polished than our existing
releases?


Would it be a goal to have users use the rolling releases? I can't 
remember seeing that mentioned before in my catching up of the list.



Dare I ask what happens when we approach the next LTS? Does the rolling
release freeze? From our current plans, I'd guess so.
Isn't that exactly what people who like rolling releases want to avoid?
The "debian-testing is frozen" problem?


It would be interesting to see what happens to 13.04 users, they 
wouldn't have an upgrade path to 14.04 if there are no releases in 
between. I guess they'll either have to be told "sorry, too bad" or 
14.04 would have to be upgradeable from 12.04 and 13.04 (yikes).



I have a hard time seeing huge benefits for our users, from a rolling
release. I only see the benefits for developers like us, and a reduction
in stable-support manpower.


I can see a benefit in having normal users on lts releases only. It will 
make packaging of 3rd party apps that go into repositories such as 
'extras' a lot easier and faster. That's assuming that those wouldn't be 
available in the rolling release though. Otherwise it would probably be 
even worse than what we have now :)


-Jonathan

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Bhavani Shankar R]

On Fri, Mar 1, 2013 at 6:42 PM, Stefano Rivera  wrote:
> Hi Florian (2013.03.01_14:06:37_+0200)
>> > That means users could choose:
>> >  * The LTS release
>> >  * The rolling release updated daily or as frequently as desired
>> >  * The rolling release updated at least monthly
>>
>> Neither of those choices fits my needs. I want new versions more
>> often than every 2 years, but I can't affort the time of monthly
>> upgrades.
>
> And we have to ask the question of what advantage Ubuntu is providing
> over Debian, without 6-monthly releases.
>
> Ubuntu has a few packages Debian doesn't. Including a desktop
> environment that people seem to complain about a lot.
> Of course, it would also be nice to see most of those in Debian
> eventually. Ubuntu would benefit from that too.
>
> After that, you're left with commercial support and certified hardware.
> Commercial support is of course available for other distros too, and the
> hardware certification work will benefit other distros eventually, as
> the changes go upstream.
>
>
> Most developers want to be developing on the latest libraries.
> Essentially, developing on their target. For open source developers,
> that could mean the latest Gnome/KDE, but for everyone else probably
> wants a rock-solid desktop environment.
>

Again agreed on the above points.

>
> Dare I ask what happens when we approach the next LTS? Does the rolling
> release freeze? From our current plans, I'd guess so.
> Isn't that exactly what people who like rolling releases want to avoid?
> The "debian-testing is frozen" problem?


How about something like this, Since it has been going around that
there will be vUDS every three months, how about a freeze every 15
days before the UDS starts/RR gets pushed publicly to have a final
test on that particular RR update (though emphasis will be on daily
quality as far as I can understand from the discussion happening) and
have a freeze period of say around 2 months when the LTS is about to
get released for a more extensive testing scenario,  (with focus being
on the LTS release at that point rather than a RR update) which
effectively makes way for stable freeze rather than an unstable pocket
freeze. And in the case of an RR update also even if the pocket
freezes for some duration of time, we can always have a
proposed/experimental pocket open for development.

Just adding some weight on here.

> I have a hard time seeing huge benefits for our users, from a rolling
> release. I only see the benefits for developers like us, and a reduction
> in stable-support manpower.
>

I'm divided here. from the desktop point of view I agree that there
could not be some sizeable benefits, but from a server admin point of
view (which is actually what I do to earn my bread) we would always
like LTS releases because we would like our production environment to
be stable enough and less risky and updates coming in (every month
preferably) to keep our systems upto date and switching to a rolling
release with emphasis on quality would provide just that I believe.

Please correct me if I have gotten the scenario and any expectations wrong here.

Regards,


-- 
Bhavani Shankar
Ubuntu Developer   |  www.ubuntu.com
https://launchpad.net/~bhavi

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Ted Gould]

On Thu, 2013-02-28 at 19:03 -0500, Barry Warsaw wrote:

> On Feb 28, 2013, at 05:01 PM, Ted Gould wrote:
> >I hope that we will.  My biggest worry with the rolling release
> >methodology is that there is no deadlines for people to work towards
> >except the LTS deadlines.  This will then encourage more polishing and
> >refining, with a rush to an even bigger deadline.  We could all say "you
> >should be more disciplined than that," which is a truism, but one that
> >seems to ignore human nature.  So I hope that there will be deadlines
> >for the monthly releases that people can target, and use for their own
> >milestones.
> 
> +1 and I think the 3 month vUDSes will provide a nice cadence for that.


The problem there being that UDS is only signing up for more work, not a
point where the work has to be delivered :-)  Ubuntu has had, in the
past, an issue where the run up for UDS involves making sure we mark
everything as POSTPONED.

Ted



signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Stefano Rivera]

Hi Florian (2013.03.01_14:06:37_+0200)
> > That means users could choose:
> >  * The LTS release
> >  * The rolling release updated daily or as frequently as desired
> >  * The rolling release updated at least monthly
> 
> Neither of those choices fits my needs. I want new versions more
> often than every 2 years, but I can't affort the time of monthly
> upgrades. 

And we have to ask the question of what advantage Ubuntu is providing
over Debian, without 6-monthly releases.

Ubuntu has a few packages Debian doesn't. Including a desktop
environment that people seem to complain about a lot.
Of course, it would also be nice to see most of those in Debian
eventually. Ubuntu would benefit from that too.

After that, you're left with commercial support and certified hardware.
Commercial support is of course available for other distros too, and the
hardware certification work will benefit other distros eventually, as
the changes go upstream.


Most developers want to be developing on the latest libraries.
Essentially, developing on their target. For open source developers,
that could mean the latest Gnome/KDE, but for everyone else probably
wants a rock-solid desktop environment.

If we are finding that our non-LTS releases aren't stable enough, and
people are using the LTSs, what makes us think we can get a significant
userbase onto a rolling release that's less polished than our existing
releases?


Dare I ask what happens when we approach the next LTS? Does the rolling
release freeze? From our current plans, I'd guess so.
Isn't that exactly what people who like rolling releases want to avoid?
The "debian-testing is frozen" problem?

I have a hard time seeing huge benefits for our users, from a rolling
release. I only see the benefits for developers like us, and a reduction
in stable-support manpower.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 461 1230 C: +27 72 419 8559

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jonathan Riddell wrote on 28/02/13 16:49:
> 
> Along with no UDS this feels like a further move away from being a 
> community project for Ubuntu.
> 
> After much time lobbying KDE (and other upstreams) to move to 6 
> monthly releases that has been working nicely for some years but if
> we lose that cadance we will be in danger of losing a lot of what
> makes this work well.
> 
> ...

A six-monthly cadence may have been good compared with what KDE was
doing previously, I don't know. But that does not mean it is the best
approach in general.

The idea of synchronized cadences dates from the days when it was
assumed that a "distribution" was a scalable way to provide all the
software that millions of people would want to use -- from the kernel
all the way up to the Kairo game. That turned out not to be true.

And even if it had been true, the optimal release cycle for a game, a
magazine app, a Web browser trying to push the standards envelope, a
Twitter client trying to stay ahead of API changes, an office suite
aiming for compatibility with a recent proprietary office suite, a
utility for controlling a recently-released hardware device, and a
base operating system, are all likely to be different. Why would
anyone expect them to be the same? Especially on a mobile platform
where many apps are intended for brief lifetimes, such as an
exhibition, conference, festival, sporting event, or magazine issue.

- -- 
mpt

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

iEYEARECAAYFAlEwoPwACgkQ6PUxNfU6ecoupgCdHK2TZHnac/wtf6VpRiVqjwNK
B0UAn14dprWJ9fDNNM7mgyDRSnTje0Cj
=ih/s
-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: Let's Discuss Interim Releases (and a Rolling Release)

[Marco Trevisan]

Il giorno ven, 01/03/2013 alle 07.12 +0100, David Henningsson ha
scritto:
> When I was new to Ubuntu, the intuitive thing to do to help out was to 
> download a beta release, test it, and report bugs. That's what betas are 
> for, right? Well, I learned that if I did that, the developers were 
> triaging my bug report around final freeze, and after that there was no 
> possibility to change anything. I then tried reporting bugs much 
> earlier, all I would get was a report back two months later, telling me 
> to test a new version of the package. After a few cycles, I had learned 
> that the right time to do testing was around feature freeze; when it's 
> still easy to upload, but the upstream versions have stopped pouring in.
> 
> As we now move to a rolling release schedule, when is the right time to 
> do a wide-scale testing and report bugs? Without just being met with a 
> "please check if it's fixed in the next version" message?

As we're suggesting to move to a RR with Quality in mind, I think that
the right moment to report bugs is "as soon as you see them" and it's up
to the developers to fix them as soon as possible without big delays, as
the the timeframe to develop is now extended without any rush for FF or
UIF (at least, until next LTS) and most of features can be stopped for a
while until we don't have a stable and fixed build to work on.


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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Florian Diesch]

Am Thu, 28 Feb 2013 07:31:49 -0800
schrieb Rick Spencer :

> That means users could choose:
>  * The LTS release
>  * The rolling release updated daily or as frequently as desired
>  * The rolling release updated at least monthly

Neither of those choices fits my needs. I want new versions more
often than every 2 years, but I can't affort the time of monthly
upgrades. 

I really like the 6 month cycle, and it was one of the main reasons
why I switched to Ubuntu in 2004. It keeps a good balance between
bledimng edge and stable working environmemnt.

Beeing a developer myself I see the burden that this cycle is for the
developers. But beeing a user I see it as one of the main features of
Ubuntu. 



-- 
Privacy Indicator
Unity appindicator to switch privacy settings



signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Loïc Minier]

On Fri, Mar 01, 2013, Martin Pitt wrote:
> > https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots
> Can this be made public? At least to me it appears as a nonexisting
> page.

Link broke because it was renamed to comply with summit.u.c
expectations; it's now at:
https://blueprints.launchpad.net/ubuntu/+spec/client-1303-monthly-snapshots

-- 
Loïc Minier

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Kaj Ailomaa]

On Fri, 01 Mar 2013 09:18:11 +0100, Tarmo Alexander Sundström  
 wrote:


Actually this whole rolling release proposition starts to sound like...  
Debian :)


stable = LTS
testing = Rolling Release
unstable = staging area for dev work / raring-proposed




Seems like a logical solution to me. At least one would like to have a  
-proposed repo for new additions. For a rolling release, isn't every  
addition really a stable release update?


Even though we in the Ubuntu Studio team do not handle packaging for  
Ubuntu outside of our own custom packages (ubuntustudio-*), we'd be very  
much interested in doing QA for multimedia packages. If not for the whole  
spectrum of what's available, then at least for the most common and  
important ones.


We'd like to have the opportunity to stop an update, if we find a severe  
regression, and stop the package from being released until we are able to  
fix the bug by either patching it or syncing it with any of the upstream  
alternatives.


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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Oliver Grawert]

hi,
On Do, 2013-02-28 at 23:55 -0500, Scott Kitterman wrote:
> On Friday, March 01, 2013 05:50:35 AM Martin Pitt wrote:
> > David Henningsson [2013-02-28 21:49 +0100]:
> > > But still, a word of caution here. Every piece of code even remotely
> > > related to the hardware, not only the Linux kernel but also most of
> > > the plumbing layer, is quite difficult (or even impossible) to
> > > automate testing for. Even if we would set up robots in our lab
> > > looking at the screen for artifacts, talking into the microphone and
> > > so on, we wouldn't cover the world's hardware.
> > > 
> > > Hardware becomes increasingly complex, diverse, and so testing it
> > > takes a lot of time. You can't go test thousands of machines to see
> > > if their headphone outputs stopped working every single day.
> > > 
> > > Do we have a plan to deal with those types of bugs?
> > 
> > I fully agree, and this is not even limited to the kernel. There are
> > other kinds of "major transitions" like switching to a new X.org
> > server, preparing a new major Qt or GNOME release, new eglibc, etc. Or
> > we want to do a complex transition such as moving from ConsoleKit to
> > logind.
> > 
> > For those we'll need temporary staging areas which are not put into
> > the RR yet until they get a sufficient amount of testing; these could
> > be "topic PPAs" which interested people would enable and develop in,
> > which get landed into the RR when everything is ready?
> 
> For people or teams that are largely or entirely !canonical, this only works 
> if all you care about is x86 (i386/amd64).  Anything for armhf (or powerpc) 
> would have to land untested since the PPAs that are available for !canonical 
> don't build these architectures.
thats (at least for armhf) not true anymore since a while... you can
just request armhf builds to be enabled for your PPA...

ciao
oli


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Tarmo Alexander Sundström]

Actually this whole rolling release proposition starts to sound like... 
Debian :)


stable = LTS
testing = Rolling Release
unstable = staging area for dev work / raring-proposed


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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Bhavani Shankar R]

On Fri, Mar 1, 2013 at 12:38 PM, Stefano Rivera  wrote:
> Hi Scott (2013.03.01_06:55:18_+0200)
>> > I fully agree, and this is not even limited to the kernel. There are
>> > other kinds of "major transitions" like switching to a new X.org
>> > server, preparing a new major Qt or GNOME release, new eglibc, etc. Or
>> > we want to do a complex transition such as moving from ConsoleKit to
>> > logind.
>> >
>> > For those we'll need temporary staging areas which are not put into
>> > the RR yet until they get a sufficient amount of testing; these could
>> > be "topic PPAs" which interested people would enable and develop in,
>> > which get landed into the RR when everything is ready?
>>
>> For people or teams that are largely or entirely !canonical, this only works
>> if all you care about is x86 (i386/amd64).  Anything for armhf (or powerpc)
>> would have to land untested since the PPAs that are available for !canonical
>> don't build these architectures.
>
> It feels like an -experimental pocket would be the best solution here.
> Which we would try to keep small, but could stage major transitions in.
>

+1 here as it would allow some package transitions (esp with those
which have some impact) to be uploaded at a point where lets say a
freeze is defined and its nearby so that we can upload packages and
test them and then if its working fine, it gets moved into a much
stabler pocket by which this wouldn’t cause  a disturbance in the
release pocket.

Regards,

-- 
Bhavani Shankar
Ubuntu Developer   |  www.ubuntu.com
https://launchpad.net/~bhavi

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Stefano Rivera]

Hi Scott (2013.03.01_06:55:18_+0200)
> > I fully agree, and this is not even limited to the kernel. There are
> > other kinds of "major transitions" like switching to a new X.org
> > server, preparing a new major Qt or GNOME release, new eglibc, etc. Or
> > we want to do a complex transition such as moving from ConsoleKit to
> > logind.
> > 
> > For those we'll need temporary staging areas which are not put into
> > the RR yet until they get a sufficient amount of testing; these could
> > be "topic PPAs" which interested people would enable and develop in,
> > which get landed into the RR when everything is ready?
> 
> For people or teams that are largely or entirely !canonical, this only works 
> if all you care about is x86 (i386/amd64).  Anything for armhf (or powerpc) 
> would have to land untested since the PPAs that are available for !canonical 
> don't build these architectures.

It feels like an -experimental pocket would be the best solution here.
Which we would try to keep small, but could stage major transitions in.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 461 1230 C: +27 72 419 8559

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

William Grant  wrote:

>On 01/03/13 15:55, Scott Kitterman wrote:
>> For people or teams that are largely or entirely !canonical, this
>only works 
>> if all you care about is x86 (i386/amd64).  Anything for armhf (or
>powerpc) 
>> would have to land untested since the PPAs that are available for
>!canonical 
>> don't build these architectures.
>
>PPAs can build on armel/armhf nowadays, but the qemu-based builders
>still have issues with the occasional package, and the small number of
>builders means we have to place fairly strict limitations on their
>usage
>at present.
>
>See https://dev.launchpad.net/CommunityARMBuilds for details on the
>policy.
>
>We have no solution for !canonical PowerPC PPA builds today.
>
I don't think powerpc is a significant issue.  At least for the cases I worry 
about the resource constraints really limit the utility of the qemu armhf PPAs.

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: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

David Henningsson  wrote:

>On 03/01/2013 05:55 AM, Scott Kitterman wrote:
>> On Friday, March 01, 2013 05:50:35 AM Martin Pitt wrote:
>>> For those we'll need temporary staging areas which are not put into
>>> the RR yet until they get a sufficient amount of testing; these
>could
>>> be "topic PPAs" which interested people would enable and develop in,
>>> which get landed into the RR when everything is ready?
>>
>> For people or teams that are largely or entirely !canonical, this
>only works
>> if all you care about is x86 (i386/amd64).  Anything for armhf (or
>powerpc)
>> would have to land untested since the PPAs that are available for
>!canonical
>> don't build these architectures.
>
> From what I've heard, that is already fixed, at least for armhf - see
>http://dev.launchpad.net/CommunityARMBuilds

Not really.   Look at the limits associated with that.  It's a miminally useful 
small scale capability.

Also, since it's (AIUI) virtualized, packages built in one of these PPAs aren't 
suitable for copy to the primary archive. 

It's a step, but not a solution. 

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: Let's Discuss Interim Releases (and a Rolling Release)

[William Grant]

On 01/03/13 15:55, Scott Kitterman wrote:
> For people or teams that are largely or entirely !canonical, this only works 
> if all you care about is x86 (i386/amd64).  Anything for armhf (or powerpc) 
> would have to land untested since the PPAs that are available for !canonical 
> don't build these architectures.

PPAs can build on armel/armhf nowadays, but the qemu-based builders
still have issues with the occasional package, and the small number of
builders means we have to place fairly strict limitations on their usage
at present.

See https://dev.launchpad.net/CommunityARMBuilds for details on the policy.

We have no solution for !canonical PowerPC PPA builds today.

William



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: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Allison Randal]

On 02/28/2013 09:36 PM, Scott Kitterman wrote:
> On Friday, March 01, 2013 06:16:18 AM Martin Pitt wrote:
>>
>> +1 on that from me as well, unless it turns out in discussions that we
>> are doing 13.04 after all, and only drop 13.10.
> 
> Now would be a good time to be discussing this change for after 14.04.  Doing 
> this mid LTS - LTS cycle is going to be problematic for a variety of reasons. 
>  
> I we had a year to get ready, then we might be in a reasonable place to 
> decide 
> on making a transition like this.

Yes, I'd find the plan more believable with a year to manage an orderly
transition. Time to boost quality procedures, time to implement and test
parts of the plan and regroup if they don't go as anticipated. ("No plan
survives first contact with reality.")

Allison

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[David Henningsson]

On 02/28/2013 10:06 PM, Robbie Williamson wrote:

On 02/28/2013 02:49 PM, David Henningsson wrote:

On 02/28/2013 05:09 PM, Martin Pitt wrote:

   * Keep doing daily quality and keep improving our daily quality.


Big +1. I'm particularly looking forward to integrating our automatic
package tests with britney.


The QA work done in -proposed has increased the productivity for the
rest of us, no doubt about that.

But still, a word of caution here. Every piece of code even remotely
related to the hardware, not only the Linux kernel but also most of the
plumbing layer, is quite difficult (or even impossible) to automate
testing for. Even if we would set up robots in our lab looking at the
screen for artifacts, talking into the microphone and so on, we wouldn't
cover the world's hardware.

Hardware becomes increasingly complex, diverse, and so testing it takes
a lot of time. You can't go test thousands of machines to see if their
headphone outputs stopped working every single day.

Do we have a plan to deal with those types of bugs?


Maybe I'm missing something, but don't we have this problem *now*,
regardless of a rolling release or not?  The only way to reasonably
solve this is get hardware OEMs to participate, who can't even tolerate
our 6 month cadence and thus do so on the LTS...which isn't changing.


I think you do have a point there, but let me answer from a different 
perspective.


When I was new to Ubuntu, the intuitive thing to do to help out was to 
download a beta release, test it, and report bugs. That's what betas are 
for, right? Well, I learned that if I did that, the developers were 
triaging my bug report around final freeze, and after that there was no 
possibility to change anything. I then tried reporting bugs much 
earlier, all I would get was a report back two months later, telling me 
to test a new version of the package. After a few cycles, I had learned 
that the right time to do testing was around feature freeze; when it's 
still easy to upload, but the upstream versions have stopped pouring in.


As we now move to a rolling release schedule, when is the right time to 
do a wide-scale testing and report bugs? Without just being met with a 
"please check if it's fixed in the next version" message?


There is a difference between "daily quality" and "non-LTS release 
quality", and a wide-scale hardware testing is one of those things that 
make up the difference. This wide-scale hardware testing is not done by 
hardware OEMs, but by the community, at least for the larger part.


And; that wide-scale testing in turn benefits the kernel/X packages we 
backport into the LTS point releases.


That is not to say I'm against moving to a rolling release; from a poll 
on a Swedish news site [1] most of our users seem to like it (73% for, 
27% against), I'm just saying that this is a tricky problem we need to 
solve somehow, if we can.



--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] 
http://techworld.idg.se/2.2524/1.488083/darfor-kan-ubuntu-1404-bli-den-sista-pa-lang-tid


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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[David Henningsson]

On 03/01/2013 05:55 AM, Scott Kitterman wrote:

On Friday, March 01, 2013 05:50:35 AM Martin Pitt wrote:

For those we'll need temporary staging areas which are not put into
the RR yet until they get a sufficient amount of testing; these could
be "topic PPAs" which interested people would enable and develop in,
which get landed into the RR when everything is ready?


For people or teams that are largely or entirely !canonical, this only works
if all you care about is x86 (i386/amd64).  Anything for armhf (or powerpc)
would have to land untested since the PPAs that are available for !canonical
don't build these architectures.


From what I've heard, that is already fixed, at least for armhf - see
http://dev.launchpad.net/CommunityARMBuilds

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

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

Blueprint renaming doesn't notify subscribers (was: Re: Let's Discuss Interim Releases (and a Rolling Release))

[Micah Gersten]

On 02/28/2013 11:46 PM, Scott Kitterman wrote:
> On Friday, March 01, 2013 04:43:09 PM William Grant wrote:
>> On 01/03/13 15:46, Martin Pitt wrote:> Loïc Minier [2013-02-28 18:18 +0100]:
 I would think we should go over these questions at UDS next week;
 Steve Langasek has kindly prepared a blueprint from some discussion we
 had on this:
 https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots
>>> Can this be made public? At least to me it appears as a nonexisting
>>> page.
>> It's public, but has been renamed to
>> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-monthly-snapshots
> Thanks for clearing that up.  I don't recall this coming up for me before.  
> It 
> seems a bit odd that if one is subscribed to a spec, you don't get mail for a 
> rename.  Given LP's general habit of verbosity, it's a bit surprising 
> something like this doesn't get mail.
>
I expected it as well, so I filed
https://bugs.launchpad.net/bugs/1137102 since LP didn't send any mail
about it.

Micah

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

On Friday, March 01, 2013 04:43:09 PM William Grant wrote:
> On 01/03/13 15:46, Martin Pitt wrote:> Loïc Minier [2013-02-28 18:18 +0100]:
> >> I would think we should go over these questions at UDS next week;
> >> Steve Langasek has kindly prepared a blueprint from some discussion we
> >> had on this:
> >> https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots
> > 
> > Can this be made public? At least to me it appears as a nonexisting
> > page.
> 
> It's public, but has been renamed to
> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-monthly-snapshots

Thanks for clearing that up.  I don't recall this coming up for me before.  It 
seems a bit odd that if one is subscribed to a spec, you don't get mail for a 
rename.  Given LP's general habit of verbosity, it's a bit surprising 
something like this doesn't get mail.

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: Let's Discuss Interim Releases (and a Rolling Release)

[William Grant]

On 01/03/13 15:46, Martin Pitt wrote:> Loïc Minier [2013-02-28 18:18 +0100]:
>> I would think we should go over these questions at UDS next week;
>> Steve Langasek has kindly prepared a blueprint from some discussion we
>> had on this:
>> https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots
>
> Can this be made public? At least to me it appears as a nonexisting
> page.

It's public, but has been renamed to
https://blueprints.launchpad.net/ubuntu/+spec/client-1303-monthly-snapshots



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: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

On Friday, March 01, 2013 12:36:43 AM Scott Kitterman wrote:
> On Friday, March 01, 2013 06:16:18 AM Martin Pitt wrote:
> > Scott Kitterman [2013-02-28 18:24 -0500]:
> > > Perhaps it would make sense to extend 12.10 support by 6 months to give
> > > 12.10 users a decent interval to upgrade.
> > 
> > +1 on that from me as well, unless it turns out in discussions that we
> > are doing 13.04 after all, and only drop 13.10.
> 
> No would be a good time to be discussing this change for after 14.04.  Doing
> this mid LTS - LTS cycle is going to be problematic for a variety of
> reasons. If we had a year to get ready, then we might be in a reasonable
> place to decide on making a transition like this.
> 
> I think this is a substantially more complex (in terms of understanding all
> the implications, making sure they are thought through, and including things
> in the "plan" - not necessarily just in code) than the "No more source
> packages" spec or the archive reorganization spec.  How long have those
> taken?
> 
> Scott K

s/No/Now at the start of the first paragraph.

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: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

On Friday, March 01, 2013 06:16:18 AM Martin Pitt wrote:
> Scott Kitterman [2013-02-28 18:24 -0500]:
> > Perhaps it would make sense to extend 12.10 support by 6 months to give
> > 12.10 users a decent interval to upgrade.
> 
> +1 on that from me as well, unless it turns out in discussions that we
> are doing 13.04 after all, and only drop 13.10.

No would be a good time to be discussing this change for after 14.04.  Doing 
this mid LTS - LTS cycle is going to be problematic for a variety of reasons.  
I we had a year to get ready, then we might be in a reasonable place to decide 
on making a transition like this.

I think this is a substantially more complex (in terms of understanding all 
the implications, making sure they are thought through, and including things 
in the "plan" - not necessarily just in code) than the "No more source 
packages" spec or the archive reorganization spec.  How long have those taken?

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: Let's Discuss Interim Releases (and a Rolling Release)

[Martin Pitt]

Scott Kitterman [2013-02-28 23:55 -0500]:
> For people or teams that are largely or entirely !canonical, this only works 
> if all you care about is x86 (i386/amd64).  Anything for armhf (or powerpc) 
> would have to land untested since the PPAs that are available for !canonical 
> don't build these architectures.

That's a good point. Whenever the blueprint gets visible again this
should certainly be added as one of the necessary prerequisites.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

Re: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Martin Pitt]

Scott Kitterman [2013-02-28 18:24 -0500]:
> Perhaps it would make sense to extend 12.10 support by 6 months to give 12.10 
> users a decent interval to upgrade.

+1 on that from me as well, unless it turns out in discussions that we
are doing 13.04 after all, and only drop 13.10.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

Re: Debian Sync - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Micah Gersten]

On 02/28/2013 11:03 PM, Martin Pitt wrote:
> Micah Gersten [2013-02-28 13:33 -0600]:
>> Yes, but our britney doesn't delay migration to allow for testing of the
>> built packages or block based on RC bugs filed.
> Not on RC bugs, but we can still block them manually. Pinging any
> release team member about that works right now.
>
> What appears to be a crucial prerequisite for this is to integrate our
> autopkgtest results into britney, though.
Well, since we have only a small amount of people that can make a bug RC
(~500), maybe we should socialize a bit more that if there's an RC bug,
the triager should hop into #ubuntu-release and ask for a block to be
put in place.
>> Perhaps if we had our own version of unstable/testing in the rolling
>> release, we could approach that level of quality.
> We have the raring-proposed staging area, which is kind of like that?
No, raring-proposed is only for automatic testing, it's not meant to be
used by end users.  Some bugs don't surface until the software is run as
almost all test suites don't have total code coverage.  As more
autopkgtests are added, I'm sure the number of RC bugs that hit users
will decline, but until test suites in most major software are
comprehensive, having the human testing is quite valuable.

Micah

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

Re: Debian Sync - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Martin Pitt]

Micah Gersten [2013-02-28 13:33 -0600]:
> Yes, but our britney doesn't delay migration to allow for testing of the
> built packages or block based on RC bugs filed.

Not on RC bugs, but we can still block them manually. Pinging any
release team member about that works right now.

What appears to be a crucial prerequisite for this is to integrate our
autopkgtest results into britney, though.

> Perhaps if we had our own version of unstable/testing in the rolling
> release, we could approach that level of quality.

We have the raring-proposed staging area, which is kind of like that?

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

On Friday, March 01, 2013 05:50:35 AM Martin Pitt wrote:
> David Henningsson [2013-02-28 21:49 +0100]:
> > But still, a word of caution here. Every piece of code even remotely
> > related to the hardware, not only the Linux kernel but also most of
> > the plumbing layer, is quite difficult (or even impossible) to
> > automate testing for. Even if we would set up robots in our lab
> > looking at the screen for artifacts, talking into the microphone and
> > so on, we wouldn't cover the world's hardware.
> > 
> > Hardware becomes increasingly complex, diverse, and so testing it
> > takes a lot of time. You can't go test thousands of machines to see
> > if their headphone outputs stopped working every single day.
> > 
> > Do we have a plan to deal with those types of bugs?
> 
> I fully agree, and this is not even limited to the kernel. There are
> other kinds of "major transitions" like switching to a new X.org
> server, preparing a new major Qt or GNOME release, new eglibc, etc. Or
> we want to do a complex transition such as moving from ConsoleKit to
> logind.
> 
> For those we'll need temporary staging areas which are not put into
> the RR yet until they get a sufficient amount of testing; these could
> be "topic PPAs" which interested people would enable and develop in,
> which get landed into the RR when everything is ready?

For people or teams that are largely or entirely !canonical, this only works 
if all you care about is x86 (i386/amd64).  Anything for armhf (or powerpc) 
would have to land untested since the PPAs that are available for !canonical 
don't build these architectures.

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: Security Support - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Martin Pitt]

Loïc Minier [2013-02-28 18:27 +0100]:
> On Thu, Feb 28, 2013, Martin Pitt wrote:
> > So if the "last monthly" is supposed to actually be a kind of a
> > release, instead of just a blessed daily installation image, this
> > would mean that there would be a new series each month?
> 
> New series are super expensive to create, need coordination in a bunch
> of places etc. and it means we're using the release dist upgrade
> mechanisms rather than updating packages.

It wouldn't need to be a full series in the Launchpad sense; we could
use a pocket, which is much more lightweight. E. g. "raring" would
take the role of "monthly" while the raring-daily pocket would take
the role of "rolling release"; this could even be raring-updates, we
don't use this pocket right now and it's already there.

But it would be using the "dist-upgrade" mode of update-manager either
way, of course.

> At the very least it should be very easy to switch between using the
> monthly and going to the rolling release; software-properties UI for
> instance, or perhaps also a command-line tool.

Yeah, this would merely mean to enable or disable the pocket which
provides the delta between "last monthly" and "daily".

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Martin Pitt]

David Henningsson [2013-02-28 21:49 +0100]:
> But still, a word of caution here. Every piece of code even remotely
> related to the hardware, not only the Linux kernel but also most of
> the plumbing layer, is quite difficult (or even impossible) to
> automate testing for. Even if we would set up robots in our lab
> looking at the screen for artifacts, talking into the microphone and
> so on, we wouldn't cover the world's hardware.
> 
> Hardware becomes increasingly complex, diverse, and so testing it
> takes a lot of time. You can't go test thousands of machines to see
> if their headphone outputs stopped working every single day.
> 
> Do we have a plan to deal with those types of bugs?

I fully agree, and this is not even limited to the kernel. There are
other kinds of "major transitions" like switching to a new X.org
server, preparing a new major Qt or GNOME release, new eglibc, etc. Or
we want to do a complex transition such as moving from ConsoleKit to
logind.

For those we'll need temporary staging areas which are not put into
the RR yet until they get a sufficient amount of testing; these could
be "topic PPAs" which interested people would enable and develop in,
which get landed into the RR when everything is ready?

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Martin Pitt]

Loïc Minier [2013-02-28 18:18 +0100]:
> Trying to think in the spirit of rolling, let's try to keep things as
> releasable as possible every day!  :-) 

Indeed, I thought that was the whole point why we are doing a RR now.

> If we really have a bad issue
> the day we intend to take a snapshot, then we should:
> a) fix it ASAP and
> b) take the snapshot from the previous or next day.

Yes, agreed. I understood it as "on day X, take the latest
known-working daily".

> >  * What does "support" mean for the monthly snapshots? Hopefully not
> >security updates, SRUs, and backports? That would ruin pretty much
> >all the savings that we do from dropping the interim releases.
> 
> Some basic level of security would seem to be needed, but I fear running
> a SRU process would be way too heavy (and probably technically complex
> too).  (Backports seem of course unjustified for a month.)

Agreed about SRU/backports.

As for security, I think we need to make up our minds what that
monthly thing is -- merely a "known good installation media" from
which you keep upgrading, i. e. we only support a RR model, or a
complete "release" which is actually supported for a month. In that
case we basically haven't done anything fundamentally new, we just
shrank the 6 month release process to an one-month one.

> >  * What is the purpose of these snapshots, i. e. who would use them?
> >If all our published daily images are good enough to install, boot,
> >and get you into a desktop, and we wouldn't do significantly more
> >QA on the "monthly" ones anyway, what makes these images special?
> 
> We need to bless "good" installation media in some way

My point is, we should never even have bad installation media on
cdimage. If they fail smoketests, they should not even be published,
or at least not be pointed to with the /current symlink.

> also I expect the main difference is that people would update every
> month to a new version with medium sized changes rather than every
> day to small changes or every 6 months / 2 years to a version with
> insanely big changes.

OK, that seems to suggest that you actually want to do a full release,
not just a monthly installation image.

> I don't really know who would/should be sticking to the monthlies after
> installation versus using the rolling release though.  I'd certainly use
> the rolling release  :-)

I would be interested in hearing about an actual demand from this,
too. that people can already decide today how often they upgrade
(every day or once per week).

> I would think we should go over these questions at UDS next week;
> Steve Langasek has kindly prepared a blueprint from some discussion we
> had on this:
> https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots

Can this be made public? At least to me it appears as a nonexisting
page.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

Re: Security Support - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Martin Pitt]

Ted Gould [2013-02-28 16:52 -0600]:
> While I realize that the mechanism is yet undecided, but it is important
> that if we are doing release, and expect people to use them, that we do
> upgrade testing between those.  This isn't really more work than having
> a 6 monthly release, but we shouldn't let it drop through the cracks.

We already do daily upgrade testing from last release and last LTS
release, so switching "last release" to "last monthly milestone" is
straightforward, as it would still by and large be a release.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Michael Hall]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 02/28/2013 06:01 PM, Ted Gould wrote:
> On Thu, 2013-02-28 at 17:09 +0100, Martin Pitt wrote:
>>> More clearly, I think we should: * Stop making interim
>>> releases.
>> 
>> This entails also dropping freezes for the non-LTS cycles, or
>> would we still have freeze cycles during the monthly cadence?
> 
> I hope that we will.  My biggest worry with the rolling release 
> methodology is that there is no deadlines for people to work
> towards except the LTS deadlines.  This will then encourage more
> polishing and refining, with a rush to an even bigger deadline.  We
> could all say "you should be more disciplined than that," which is
> a truism, but one that seems to ignore human nature.  So I hope
> that there will be deadlines for the monthly releases that people
> can target, and use for their own milestones.
> 
> Ted
> 
> 
> 

I think we can use the 3-month UDS cycles for this, try and break down
work items so that can be done by the next UDS.

- --
Michael Hall
mhall...@ubuntu.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRMBvQAAoJEInUYcGJgfVyW/AQAJGLNjZTesdkOo38+QVJBz/U
cnn1Gqs5Cp76/6smWqqbmal/tWwbdCjE9aoBsTxJaI5r3P4QfSyuF2++BD/8w7or
jqoPrqiW2iQ0JXRcUL3op0cAbjdRG7zx1oZYu7TSPUclAgnVRJJWxHqlppUPK3kC
frReGnbyA++ZATsIVJUU3IJTr5IkkVt0lR5ZE3Wp2jVoa9i6i2Yn4z9a1QF2wx48
nWtQXj+HeJmo55C8qtK90FrAz6OSxwtkFQggTnnRR54pQ6h3mSwBoksEGGmKGDbM
Nx5BPBABCim7TGgeFhgIDegaYyo4M3v/iQ+Zi5hCn9X8+GHXk0BaUSsBlox32ciI
cemLVKBDLRGqZyTWXnuFzKJWRISTYBvGwLGThezjgK1boxHpvwd6YdFcThGtTBGt
Yfdv+XHHajgFb14JMZqON/6UfYiBh9ixzmkvkU4680DLSuHT4r0i6eQY4WTpUOhB
aB8l1+bwmhlvXLIgxm4AC767iINj8vHJ/Y5dC4LdLgLtQXKpU2Sruzp1MRUjzRuf
3B36NXsfSL536eUsEsiwhtVkxk+fOksJk52o8wCUEKHBkBzyQkaCN+8wEKIONqXq
n4yarb/wElItMM0mkJ9OWPP3kvHomz+5K7oR6DDgqXK+zIiYgbRCRtUkJE9z8uCg
Jll4XMMIM2YekVMhKNTb
=J/wH
-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: Let's Discuss Interim Releases (and a Rolling Release)

[Barry Warsaw]

On Feb 28, 2013, at 05:01 PM, Ted Gould wrote:

>I hope that we will.  My biggest worry with the rolling release
>methodology is that there is no deadlines for people to work towards
>except the LTS deadlines.  This will then encourage more polishing and
>refining, with a rush to an even bigger deadline.  We could all say "you
>should be more disciplined than that," which is a truism, but one that
>seems to ignore human nature.  So I hope that there will be deadlines
>for the monthly releases that people can target, and use for their own
>milestones.

+1 and I think the 3 month vUDSes will provide a nice cadence for that.

-Barry


signature.asc
Description: 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: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Ritchie]

On 2/28/13 12:44 PM, Scott Kitterman wrote:

About the term "Interim Releases":

There's no such thing in Ubuntu.  We have regular releases and LTS releases
and until some decision has been made, I think those are the appropriate
terms.  If this is actually a discussion, I think people should avoid
referring to our current releases as interim as that is a completely
inaccurate and prejudicial way to describe them.

Scott K



Perhaps it might also be correct to not refer to the "rolling release" 
as a release at all, but simply the current development version.


I'm going to propose we just have LTS releases and a current development 
version (perhaps with snapshots).


The development version wouldn't be "unsupported", per se, as our policy 
for any supported version is to first fix it in development.



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

Re: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Adam Conrad]

On Thu, Feb 28, 2013 at 06:24:59PM -0500, Scott Kitterman wrote:
> The proposal is silent on the upgrade path for 12.10 users?  Presumably 12.10 
> -> 14.04 LTS upgrades will be supported.  Unfortunately, support for 12.10 
> runs out at just about the same time 14.04 is supposed to be release.
> 
> Perhaps it would make sense to extend 12.10 support by 6 months to give 12.10 
> users a decent interval to upgrade.

This was the same proposal I'd put forth privately in earlier discussions
about this, yes.  Trying to do some crazy 12.10->snapshots->14.04 path is
madness, 12.04 and 12.10 are quite similar, so update-manager quirks and
packaging fixes needed for both to upgrade to 14.04 should be fairly
straightforward, and it just makes sense to give users that grace period
by extending 12.10 support by three to six months (three was the absolute
minimum in my mind, but anything up to six seems fair).

... Adam

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

12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Scott Kitterman]

The proposal is silent on the upgrade path for 12.10 users?  Presumably 12.10 
-> 14.04 LTS upgrades will be supported.  Unfortunately, support for 12.10 
runs out at just about the same time 14.04 is supposed to be release.

Perhaps it would make sense to extend 12.10 support by 6 months to give 12.10 
users a decent interval to upgrade.

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: Let's Discuss Interim Releases (and a Rolling Release)

[Ted Gould]

On Thu, 2013-02-28 at 17:09 +0100, Martin Pitt wrote:

> > More clearly, I think we should:
> >  * Stop making interim releases.
> 
> This entails also dropping freezes for the non-LTS cycles, or would we
> still have freeze cycles during the monthly cadence?


I hope that we will.  My biggest worry with the rolling release
methodology is that there is no deadlines for people to work towards
except the LTS deadlines.  This will then encourage more polishing and
refining, with a rush to an even bigger deadline.  We could all say "you
should be more disciplined than that," which is a truism, but one that
seems to ignore human nature.  So I hope that there will be deadlines
for the monthly releases that people can target, and use for their own
milestones.

Ted



signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Alberto Milone]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/13 19:03, Steve Langasek wrote:
> Yes, with my SRU hat I'm in complete agreement here.  Unverified
> SRUs for interim releases every time we do an SRU to an LTS are a
> constant source of frustration for me, and make it starkly clear
> that testers (and by extension, users) don't actually care about
> interim releases to the same degree that they do about the LTS.
> That makes interim release SRUs a pretty demotivating thing to work
> on for everyone involved, because it's a lot of extra work for
> little extra benefit.

A huge +1 from me on this.

- -- 
Alberto Milone
Software Engineer
Hardware Enablement Team
Professional and Engineering Services
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEv4JAACgkQFZJJ6Y6yavGsrQCgsQmim0uuB2VMSgusItIowwB5
01gAoM/2wOprZetFekRbF2tp80c1MLA1
=5Obv
-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: Let's Discuss Interim Releases (and a Rolling Release)

[Ted Gould]

On Thu, 2013-02-28 at 16:00 -0500, Scott Kitterman wrote:

> On Thursday, February 28, 2013 11:26:51 AM Rick Spencer wrote:
> > On Thu, Feb 28, 2013 at 11:17 AM, Allison Randal  wrote:
> > > I'm not entirely opposed to the idea that the Debian development model
> > > of 2-year "stable" releases with an ongoing "unstable" archive has been
> > > right all along. But frankly, if someone came to me with this proposal
> > > you've posted as a "startup" and asked me to invest in it, I'd say "You
> > > haven't demonstrated that this is technically feasible." and kick them
> > > back to the drawing board.
> > 
> > Oh? I would point to our last several years of improving Daily Quality and
> > at Raring as it is today. I think our track record for making a highly
> > usable development release is quite excellent.
> 
> The current approach to daily quality has never been tried when Debian wasn't 
> in freeze.  Declaring things good now based on the available data is like a 
> penguin on an iceberg as it floats north being convinced the data so far 
> proving he's riding on a stable, reliable platform.


And also when Unity and Compiz have only been receiving bug fix work,
not major feature development.  I think that we have improved daily
quality overall, but Raring itself is not enough data to say it is
equivalent to the six month releases.

Ted



signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel