date:20130301

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: Avoiding fragmentation with a rolling release

On Fri, Mar 01, 2013, Martin Pitt wrote:
 I don't think that's feasible with a RR model. We don't even control
 most of the APIs that are in Ubuntu even.
 
 As Matthew Paul Thomas and others pointed out, we primarily want to
 recommend the LTS releases on the download page and for most users, so
 that's certainly what ISVs should target, too?

I don't think we can make any commitment against all of Ubuntu or all of
main, but we could pick a subset by product and commit to some level of
API and ABI support for this subset.  e.g. this blessed set of core
libraries would be guaranteed to be included in the next LTS, this
blessed set of Unity APis would be available in the Touch and Desktop
releases, this blessed set of KDE APIs would be available in the next
release etc.

This would be a prerequisite to releasing standalone SDKs that people
could run on other GNU/Linux distros and eventually perhaps even from
Windows and OSX as to target Ubuntu.

This should probably be a new thread though  :-)

-- 
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)

2013-03-01 Thread 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: Avoiding fragmentation with a rolling release

2013-03-01 Thread Matthew Paul Thomas

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Langasek wrote on 01/03/13 01:44:
 
 On Thu, Feb 28, 2013 at 02:05:35PM -0800, Alex Chiang wrote: ...
 
 If you want to avoid the daily grind, press the close button
 when update-manager fires. Or set the 'check for updates'
 frequency to monthly. I think the intended audience for monthly
 images could handle that workflow.
 
 Except we really, really don't want users doing that.  When 
 update-manager fires because there's a critical security update,
 and failing to apply it means their machine will in short order
 become part of a botnet with the best-designed UI the world has
 ever seen, we really don't want the user's first instinct to be to
 postpone the update.
 
 ...

Certainly we don't want people to instinctively dismiss the dialog.
The recent redesign has aimed at getting consent more often.

But changing the updates frequency instead is a valid option, because
Software Sources has two update frequency settings.
https://wiki.ubuntu.com/SoftwareUpdates#settings

When there are security updates:, defaulting to Display immediately.

And When there are other updates:, defaulting to Display weekly.

You can change the latter right now to Display every two weeks,
without delaying your exposure to security updates at all.

As I understand the purpose of monthly snapshots so far, we could
achieve the same effect simply by adding a Display monthly item to
that second menu.

However, currently when there are security updates, Software Updater
assumes that you will want to install any available non-security
updates at the same time, to minimize interruption. Minimizing
bandwidth use from update churn is not a problem we optimize for at
the moment (except for warning you when you're on mobile broadband).
But we could add a setting for that if necessary.

- -- 
mpt

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

iEYEARECAAYFAlEwiREACgkQ6PUxNfU6ecq9sQCeMJfFmmq4W8r1T6ihLc0VIzio
1j0Ani8BmblJn8jwPhsfERVmKmY2X0+4
=jeJp
-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)

2013-03-01 Thread 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)

2013-03-01 Thread 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)

2013-03-01 Thread 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)

2013-03-01 Thread 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)

2013-03-01 Thread 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)

2013-03-01 Thread Dmitry Shachnev

On Fri, Mar 1, 2013 at 11:08 AM, Stefano Rivera stefa...@ubuntu.com 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)

2013-03-01 Thread 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)

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: Ubuntu Developer Summits Now Online and Every Three Months

2013-03-01 Thread Iain Lane

Hi,

On Tue, Feb 26, 2013 at 10:31:04AM -0800, Jono Bacon wrote:
 […]  we decided that we couldn’t wait until May to run this new
 format for UDS, so the first online UDS will be taking place next week from
 5th - 6th March 2013 from 4pm UTC - 10pm UTC […]

FYI, for those of you who haven't noticed yet (since I didn't see it
elsewhere in mail), it seems from [0] that the times have changed to
14:00 - 22:00 UTC.

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]

[0]
http://fridge.ubuntu.com/2013/02/26/ubuntu-developer-summits-now-online-and-every-three-months/


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)

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)

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: Avoiding fragmentation with a rolling release

On Fri, Mar 01, 2013 at 11:13:27AM -0500, Michael Hall wrote:
 On 02/28/2013 11:19 PM, Scott Kitterman wrote:
  Rolling can't both have stable APIs and be the development platform.  You 
  need to pick one.
 
 They APIs don't have to be static, they just have to be backwards
 compatible.  Most projects already strive for some amount of backwards
 compatibility, even as they add on to their API.

This would be something we could say for APIs we control.  But, given
the breadth of interfaces in Ubuntu and how few of them actually
originate from the Ubuntu project directly (and I think this is a good
thing!), assurances here would seem to be little more than fine words.

-- 
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: Avoiding fragmentation with a rolling release

On Thu, Feb 28, 2013 at 05:15:38PM -0600, Mario Limonciello wrote:
 What about a rolling static base instead?  Do a unionfs (or similar) on top
 of it.  Deliver an encompassing image from month to month.  Turn off apt as
 a mechanism to deliver updates.  But allow it to be turned back on.  Even
 if you don't install anything on top of it, then every month a new static
 base comes up and updates it.  If you decide to do daily updates on top,
 some of them might be in next month's new static base already, so that
 would need to be handled gracefully.

IMO the point of this rolling release strategy is to reduce engineering
effort so that it can be diverted towards other things.  In that light,
I'm sceptical about fundamentally replacing the entire upgrade strategy
for the desktop as an initial requirement for making any of it work.
Sure, some kind of image-based updates will likely be required for phone
clients and such, and I expect that eventually we'd want to converge
that with the desktop; but this is at the very least several months down
the line, probably more.

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

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

LTS point releases (12.04.1 , 12.04.2 , etc.) and semi-rolling

2013-03-01 Thread Omar B .

LTS point releases (12.04.1 , 12.04.2 , etc.) and semi-rolling release

I totally agree with how the foundations are getting in place for a rolling
model. Obstacles like the daily quality and even the fixed 6 month UDS which
also was a kind of obstacle have all been addressed and updated to accommodate
the new times ahead.
I believe most people will be very happy sticking to the LTS and its
point/support releases (12.04.1, 2, etc.). Proof of that were all the great
amount of changes and improvements introduced recently in the latest 12.04.2 in
order to address important things like UEFI/secure-boot and the Steam launch.
http://news.softpedia.com/news/Ubuntu-12-04-2-LTS-Officially-Released-Features-New-Linux-Kernel-329713.shtml

Most people thought they would be forced to update to 12.10 for this, but were
pleasantly surprised when the LTS received the attention it deserves, which
most interim releases have usually taken away.

However to avoid fragmentation or too many normal users using the rolling
development because they can't wait 2 years, I propose more attention to these
LTS point/support releases.
More Unity features backported from the R.D.R. and of course as much up to date
software as possible.
Anyway there are many different models for a RR:
http://en.wikipedia.org/wiki/Rolling_release
But some of the most popular for users and devs, with more stability and
precitbility over full-rolling are the semi/half-rolling, like LMDE and Chakra:
http://chakra-linux.org/wiki/index.php?title=Half-Rolling_Release_Model
Both also release snapshots, so is easy to evaluate right now the positives,
what fits with Ubuntu's new vision and what can be improved.
-Omar B. --
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)

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)

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)

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: Avoiding fragmentation with a rolling release

On Fri, Mar 01, 2013 at 05:40:26PM +, Colin Watson wrote:

   The monthly snapshots would be for users who want the fresh 
   software, but don't want to manage the daily grind of updating to 
   ensure that their system is secure. The way I think of it is that 
   we support 2 cadences for updates, daily and monthly.

  As above, that seems like something we'd want to discourage. Even so,
  it is already possible in R, without snapshots. It takes two clicks:

  1. When Software Updater appears, expand Details of updates.

  2. Uncheck the checkbox next to Other updates, leaving Security
  updates checked. (These groupings appear only if any of the updates
  are security updates.)

 This is a good point.  (It has no real-world testing, because we have
 never had a release where we applied changes both in the release pocket
 and in -security; we have only had releases where we applied changes
 only in the release pocket, and releases where we applied changes in
 both -security and -updates.  That said, I agree that this argument
 holds up theoretically, and thus we could do this without the complexity
 of staging everything in -updates.)

Two clicks sounds simple, but it wouldn't be very obvious to users who are
meaning to track the monthly that they should be un-selecting other
updates.  Is there a good way for us to pre-unselect this for users who are
opting in to the monthly updates?

Also, Colin, I think one of the reasons we thought we needed a separate
-updates pocket and to keep the release pocket stable between monthlies was
for installability of extra software downloaded at install time.  I don't
see that changing selections in update-manager helps with this at all; if
we're still going to have to use -updates to ensure this kind of
consistency, I don't see any benefit to tweaks at the update-manager level
rather than at the apt sources.list level.

 Another possibility that AFAIK has not been discussed is to use the new
 phased updates facility; we could set the Phased-Update-Percentage to 0
 until we want to roll something out.

Unless you mean to have users who follow the rolling release ignore the
Phased-Update-Percentage, I'm not sure how this would help.  And using
Phased-Update-Percentage that way feels dodgy to me.

-- 
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: Avoiding fragmentation with a rolling release

On Fri, Mar 01, 2013 at 10:55:14AM +, Matthew Paul Thomas wrote:

 Certainly we don't want people to instinctively dismiss the dialog.
 The recent redesign has aimed at getting consent more often.

 But changing the updates frequency instead is a valid option, because
 Software Sources has two update frequency settings.
 https://wiki.ubuntu.com/SoftwareUpdates#settings

 When there are security updates:, defaulting to Display immediately.

 And When there are other updates:, defaulting to Display weekly.

 You can change the latter right now to Display every two weeks,
 without delaying your exposure to security updates at all.

 As I understand the purpose of monthly snapshots so far, we could
 achieve the same effect simply by adding a Display monthly item to
 that second menu.

Display monthly wouldn't guarantee that users who update monthly are
updating to the *same* set of monthly packages.  Displaying the prompt
monthly, even if the user consistently acted on it as soon as they saw it,
would cause inevitable drift over time; we would therefore not be able to
provide security support for these users, because the security pocket would
be updated with packages built for the previous monthly snapshot and the
user has (for example) monthly + 5 days installed.

So in that case I don't see any advantage to trying to provide security
updates against the monthlies at all, and we should just pull users forward
to current rolling with each security update.

-- 
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)

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)

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)

Dmitry Shachnev mity...@ubuntu.com wrote:

On Fri, Mar 1, 2013 at 11:08 AM, Stefano Rivera stefa...@ubuntu.com
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)

Colin Watson cjwat...@ubuntu.com 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)

Dmitry Shachnev mity...@ubuntu.com wrote:

On Fri, Mar 1, 2013 at 9:10 PM, Colin Watson cjwat...@ubuntu.com
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)

On Fri, Mar 01, 2013 at 01:31:37AM -0500, Scott Kitterman wrote:
 David Henningsson david.hennings...@canonical.com 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: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)

On Friday, March 01, 2013 08:15:13 PM Evan Dandrea wrote:
 On Fri, Mar 1, 2013 at 5:36 AM, Scott Kitterman ubu...@kitterman.com 
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)