From legotown@aol.com Thu May 30 23:40:43 2013 Return-Path: X-Original-To: ros-users@code.ros.org Delivered-To: ros-users@code.ros.org Received: from omr-d06.mx.aol.com (omr-d06.mx.aol.com [205.188.109.203]) by code.ros.org (Postfix) with ESMTP id 9BD5525C5AA for ; Thu, 30 May 2013 23:40:42 -0700 (PDT) Received: from mtaout-mb03.r1000.mx.aol.com (mtaout-mb03.r1000.mx.aol.com [172.29.41.67]) by omr-d06.mx.aol.com (Outbound Mail Relay) with ESMTP id B0B107000008D for ; Fri, 31 May 2013 02:40:54 -0400 (EDT) Received: from [10.0.0.2] (c-50-136-243-7.hsd1.ca.comcast.net [50.136.243.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mb03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id F0DEAE0000C6 for ; Fri, 31 May 2013 02:40:53 -0400 (EDT) From: Austin Hendrix Content-Type: multipart/alternative; boundary="Apple-Mail=_5F90A47D-703F-4DB9-896E-BB61146AA186" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Thu, 30 May 2013 23:40:51 -0700 References: To: User discussions In-Reply-To: X-Mailer: Apple Mail (2.1503) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1369982454; bh=H+9NQssxcXCEPPbPE63XkW6V7zYh8pLgwrNjUM6w6RE=; h=From:To:Subject:Message-Id:Date:Mime-Version:Content-Type; b=qcSLWxGQmWiBYDp0vqJ8RATxY4fAMEQpZAXtaOcJeLqpraXKhbA4MsXzcuFJ9E0hT LPkH2TD+SJn4F+TOnefkirg2HiX7Bdv9kRpSncRT9ggLLFsOBW8foLgcmglV6p1RLv sEMO2ClwHV+o2cx3b1ei0ELa7T2Mp0BP5+94Vi1s= X-AOL-SCOLL-SCORE: 0:2:515060576:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294351a845f51ead X-AOL-IP: 50.136.243.7 Subject: Re: [ros-users] ROS Release Timeline X-BeenThere: ros-users@code.ros.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: User discussions List-Id: User discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 06:40:43 -0000 --Apple-Mail=_5F90A47D-703F-4DB9-896E-BB61146AA186 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 30, 2013, at 10:27 PM, Chad Rockey = wrote: > My vote is to only support the Ubuntu LTS releases. I can't recall a = use case where robot hardware absolutely required anything non-LTS = besides a backported kernel. Unfortunately, it looks like we didn't = poll which Ubuntu versions ROS users install on workstations and on = robots. I expect almost no one uses non-LTS on a robot, but it's likely = a good idea to issue another poll on Ubuntu usage. I disagree; I think we should have at least some support for every = Ubuntu release, even if only one or two versions of ROS support it. I = think it significantly lowers the barrier to entry if a new user can = install ROS on any Ubuntu machine they have handy. =46rom what I've seen on ROS Answers, people are using ROS with every = version of Ubuntu. I think it would be confusing and unfriendly to = support only certain versions of Ubuntu. >=20 > Another thought is that the version of ROS that releases alongside the = LTS should also become an LTS with slightly longer support. I'm not = sure that the entire 5 years is within the resources of our community, = but I'm sure those with long-term deliverables would appreciate at least = 3 years in order to have time to bridge Ubuntu LTS releases. Agreed; since I use the LTS releases for production, it would be good to = have the LTS version of ROS supported for the entire lifetime of the OS. >=20 > Therefore, my proposal (similar to Daniel's) is that every other 12 = month ROS release is an LTS, supported for 36 months; and the other = release is used for ROS staging and will bridge the two LTS releases. >=20 > =46rom Igloo on, that should look like: >=20 > Igloo LTS released exclusively with Ubuntu T LTS (Supported for 36 = months) >=20 > J Turtle Released on Ubuntu T (Supported for 24 months). Adds = Support for Ubuntu X LTS mid-cycle >=20 > K Turtle LTS released exclusively with Ubuntu X LTS (Supported for 36 = months) +1 I like the idea of ROS staging releases supporting most Ubuntu releases, = and a ROS stable release on top of the Ubuntu LTS. -Austin >=20 > ... >=20 > TL;DR: Poll Ubuntu Usage - More LTS >=20 >=20 > On Thu, May 30, 2013 at 4:46 PM, Tully Foote = wrote: > Hi Everyone,=20 >=20 > As a follow up to the survey we circulated last month I'd like to = start a discussion of what the best timeline for ROS releases would be. =20= >=20 > As a reminder of the survey results see: = https://docs.google.com/file/d/0BzNmzxy4pVGMZHd2b1BSWVlHVHM/edit >=20 > We've had many discussions here at OSRF about these results and have = come up with a few candidates which seem reasonable. I'll outline the = logic behind how we got to them and would like to hear what you think. >=20 > Starting out based on the survey. We had a majority of respondants = prefering a 12 month release cycle and a plurality of respondants = preferring a 24 month support period. These two number nicely allign = with our current practice of having two supported ROS distributions at a = time with one ROS distribution in development, however just with a = longer release cycle. This amount of parallel development is about all = that we think we can support as a community. So based on this I think = there's a relatively clear mandate to change the ROS release cycle to = every 12 months with 24 months of support, allowing 12 months of overlap = between releases for transition. =20 >=20 > We've put together a nice graphic see ros.svg >=20 > Unfortunately the problem is not quite as simple as the above graphic = shows as we need to build on top of other platforms. Ubuntu has = recently updated their planned release cycle to support LTS for 5 years, = but non-LTS releases for only 9 months while maintaining their 6 month = release cycle. See: https://wiki.ubuntu.com/Releases =20 >=20 > This can be seen in ubuntu.svg >=20 > This change for Ubuntu unfortunately makes our nice clean plan above = much harder as it is impossible to support a release for anywhere near = close to 24 months on non-LTS Ubuntu distros. =20 >=20 > We started out be assuming we'd release ROS in the spring to coincide = with the LTS Ubuntu Release. If we're planning a 1 year release cycle, = the quick answer is that for the intervening 6 month Ubuntu Release the = last ROS release is ported forward. This can be done with a minimal = effort by following the Ubuntu by about 1 month, enabling a ROS release = to be built against the current release and the upcoming pre-release = Ubuntu. (Based on past experiences prebuilds of Ubuntu releases are = available shortly after the previous release has come out.) With this = basic outline we can release ROS each spring and support two Ubuntu = distros each. =20 >=20 > In recognition of the fact that many users only use LTS on their = robots we then thought to add a backport of the ROS release with LTS+2 = to build on the LTS. However the fact that the LTS+2 release will also = be built on the LTS+3 makes supporting this spanning set very hard = because LTS+3 is usually the staging grounds for large changes to get = into the next LTS release. =20 >=20 > To see this see graphic ubuntu_ros.svg >=20 > To resolve this there are many options. We could consider dropping = support for LTS+3 to resolve the large spanning set. Another option is = to simply support the LTS Ubuntu Releases since the non LTS release = cycles are now so short, making our 24 month support cycle much easier. =20= >=20 >=20 > You will note in this process that we have decreased the matrix of ROS = vs Ubuntu packages. This is purposeful as we've identified supporting = the large matrix of ROS vs Ubuntu distros as a significant burden on the = community. Our sketch is laid out to support two major use cases, a = stable developer who wants to stick to the LTS Ubuntu release and the = cutting edge user who wants the latest version of ROS on the latest = Ubuntu distro. =20 >=20 > Besides the provided Debian package it is always easily possible to = build a ROS distribution from source. It only requires running a handful = of commands. A complete build of desktop-full takes about 3-4 hours of = compilation time on a recent Intel i7 machine. This is the workflow that = every non-Ubuntu user uses which has been continuously improved as we = have upgraded the core tools. >=20 > And the last consideration is when should we release Hydro, we have = close to half the packages for Hydro released and I know many of the = remaining packages which were in the initial groovy release are = preparing for the hydro release at the moment. =46rom the = considerations of synchronizing with Ubuntu LTS it seems like a good = target for Indigo Igloo will be April/May 2014 leaving us 11 months from = now. As a straw man for Hydro I'd propose July giving the Indigo cycle = 9 months following Hydro 7 months to ease us into the 12 month cycle.=20 >=20 > Please let us know your thoughts? >=20 > Tully >=20 >=20 > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >=20 >=20 > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users --Apple-Mail=_5F90A47D-703F-4DB9-896E-BB61146AA186 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 chadrockey@willowgarage.com> wrote:
My vote is to only support the Ubuntu LTS = releases.  I can't recall a use case where robot hardware = absolutely required anything non-LTS besides a backported kernel. =  Unfortunately, it looks like we didn't poll which Ubuntu versions = ROS users install on workstations and on robots.  I expect almost = no one uses non-LTS on a robot, but it's likely a good idea to issue = another poll on Ubuntu usage.

I = disagree; I think we should have at least some support for every Ubuntu = release, even if only one or two versions of ROS support it. I think it = significantly lowers the barrier to entry if a new user can install ROS = on any Ubuntu machine they have handy.

=46rom = what I've seen on ROS Answers, people are using ROS with every version = of Ubuntu. I think it would be confusing and unfriendly to support only = certain versions of Ubuntu.


Another thought is that the version of ROS = that releases alongside the LTS should also become an LTS with slightly = longer support.  I'm not sure that the entire 5 years is within the = resources of our community, but I'm sure those with long-term = deliverables would appreciate at least 3 years in order to have time to = bridge Ubuntu LTS = releases.

Agreed; since I use the = LTS releases for production, it would be good to have the LTS version of = ROS supported for the entire lifetime of the = OS.


Therefore, my proposal = (similar to Daniel's) is that every other 12 month ROS release is an = LTS, supported for 36 months; and the other release is used for ROS = staging and will bridge the two LTS releases.

=46rom Igloo on, that should = look like:

Igloo LTS = released exclusively with Ubuntu T LTS (Supported for 36 = months)

J Turtle Released = on Ubuntu T  (Supported for 24 months).  Adds Support for = Ubuntu X LTS mid-cycle

K Turtle LTS released = exclusively with Ubuntu X LTS (Supported for 36 = months)

+1

I like the idea of ROS staging releases supporting most Ubuntu = releases, and a ROS stable release on top of the Ubuntu = LTS.

-Austin


...

TL;DR: = Poll Ubuntu Usage - More LTS


On = Thu, May 30, 2013 at 4:46 PM, Tully Foote <tfoote@osrfoundation.org> wrote:
Hi Everyone,

As a follow up to the survey = we circulated last month I'd like to start a discussion of what the best = timeline for ROS releases would be.  

As a reminder of the survey = results see: https://docs.google.com/file/d/0BzNmzxy4pVGMZHd2b1BSWVlH= VHM/edit

We've had many discussions = here at OSRF about these results and have come up with a few candidates = which seem reasonable.  I'll outline the logic behind how we got to = them and would like to hear what you think.

Starting out based on the = survey.  We had a majority of respondants prefering a 12 month = release cycle and a plurality of respondants preferring a 24 month = support period.  These two number nicely allign with our current = practice of having two supported ROS distributions at a time with one = ROS distribution in development, however just with a longer release = cycle.  This amount of parallel development is about all that we = think we can support as a community.  So based on this I think = there's a relatively clear mandate to change the ROS release cycle to = every 12 months with 24 months of support, allowing 12 months of overlap = between releases for transition.  

We've put together a nice = graphic see ros.svg

Unfortunately the problem is = not quite as simple as the above graphic shows as we need to build on = top of other platforms.  Ubuntu has recently updated their planned = release cycle to support LTS for 5 years, but non-LTS releases for only = 9 months while maintaining their 6 month release cycle.  See: https://wiki.ubuntu.com/Releases =  

This can be seen in = ubuntu.svg

This change for Ubuntu = unfortunately makes our nice clean plan above much harder as it is = impossible to support a release for anywhere near close to 24 months on = non-LTS Ubuntu distros.  

We started out be assuming = we'd release ROS in the spring to coincide with the LTS Ubuntu Release. =  If we're planning a 1 year release cycle, the quick answer is that = for the intervening 6 month Ubuntu Release the last ROS release is = ported forward.  This can be done with a minimal effort by = following the Ubuntu by about 1 month, enabling a ROS release to be = built against the current release and the upcoming pre-release Ubuntu. = (Based on past experiences prebuilds of Ubuntu releases are available = shortly after the previous release has come out.) With this basic = outline we can release ROS each spring and support two Ubuntu distros = each.  

In recognition of the fact = that many users only use LTS on their robots we then thought to add a = backport of the ROS release with LTS+2 to build on the LTS. =  However the fact that the LTS+2 release will also be built on the = LTS+3 makes supporting this spanning set very hard because LTS+3 is = usually the staging grounds for large changes to get into the next LTS = release.  

To see this see graphic = ubuntu_ros.svg

To resolve this there are = many options.  We could consider dropping support for LTS+3 to = resolve the large spanning set.  Another option is to simply = support the LTS Ubuntu Releases since the non LTS release cycles are now = so short, making our 24 month support cycle much easier. =  


You will note in this process = that we have decreased the matrix of ROS vs Ubuntu packages.  This = is purposeful as we've identified supporting the large matrix of ROS vs = Ubuntu distros as a significant burden on the community.  Our = sketch is laid out to support two major use cases, a stable developer = who wants to stick to the LTS Ubuntu release and the cutting edge user = who wants the latest version of ROS on the latest Ubuntu distro. =  

Besides the provided Debian = package it is always easily possible to build a ROS distribution from = source. It only requires running a handful of commands.  A complete = build of desktop-full takes about 3-4 hours of compilation time on a = recent Intel i7 machine. This is the workflow that every non-Ubuntu user = uses which has been continuously improved as we have upgraded the core = tools.

And the last consideration is = when should we release Hydro, we have close to half the packages for = Hydro released and I know many of the remaining packages which were in = the initial groovy release are preparing for the hydro release at the = moment.  =46rom the considerations of synchronizing with Ubuntu LTS = it seems like a good target for Indigo Igloo will be April/May 2014 = leaving us 11 months from now.  As a straw man for Hydro I'd = propose July giving the Indigo cycle 9 months following Hydro 7 months = to ease us into the 12 month cycle.

Please let us know your = thoughts?

Tully

=
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users


_______________________________________________
ros-users mailing = list
ros-users@code.ros.org
https= ://code.ros.org/mailman/listinfo/ros-users

= --Apple-Mail=_5F90A47D-703F-4DB9-896E-BB61146AA186--