From d.stonier@gmail.com Thu May 30 19:51:37 2013 Return-Path: X-Original-To: ros-users@code.ros.org Delivered-To: ros-users@code.ros.org Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by code.ros.org (Postfix) with ESMTPS id 5F73025C5E6 for ; Thu, 30 May 2013 19:51:37 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x14so2575466ief.40 for ; Thu, 30 May 2013 19:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=DmqI5AEwwTQyoKGo6MkVE0e+ny+F3nmmbVphpG1fX+M=; b=r1gex4l9OBa+faAVL/ArZQENisgBDROffDaFM7Ie6HCXnOT5FthmRUgHWsNlPxf4zs I0SZ+QHRfy1k6O2Cj3zVZuKGmbyPUMv9eh1BO/b2GYeP5Q9efsz9axBEcRlOKXmVn96u SvE/0Z3wHtJcj5qstEsbM49FUcAW9O/EIhpt6QgnYWrEhWJAamkHOjXiHR0YFBASljos nFmgzKVUh1SOALlqqfZzUqP6zQIW0GEeWcN844ao9E+zoBI1/ul0jplNL3DqwoXGEvPa u+OCLOaSfT5sSgvizmgMLtBLieqQqqPQPwuFlbAXOfywJIlBNQPqoPokDa5IqvdXBDP3 Q79w== MIME-Version: 1.0 X-Received: by 10.43.106.202 with SMTP id dv10mr4174088icc.37.1369968712707; Thu, 30 May 2013 19:51:52 -0700 (PDT) Received: by 10.64.236.116 with HTTP; Thu, 30 May 2013 19:51:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 May 2013 11:51:52 +0900 Message-ID: From: Daniel Stonier To: User discussions Content-Type: multipart/alternative; boundary=20cf3022403979789504ddfab2cf 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 02:51:37 -0000 --20cf3022403979789504ddfab2cf Content-Type: text/plain; charset=UTF-8 On 31 May 2013 11:43, Daniel Stonier wrote: > > > > On 31 May 2013 08:46, Tully Foote 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/0BzNmzxy4pVGMZHd2b1BSWVlHVHM/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. >> * >> > > > Took a perusal of the svg's to really sort out the puzzle of words above! > > I think groovy was what we would consider a 'staging ground' release for > large changes. We had a vested interest in pursuing groovy for some of our > use cases, but for the use cases where we are interested in using Ubuntu > LTS releases, we probably wouldn't have missed groovy much at all. So I'm > not sure there may be enough interest to warrant investing the effort to > support big staging releases on LTS. > > I notice what you've drawn in ubuntu_ros.svg coincides with this thinking > - i.e. > > i-turtle: LTS, LTS+1 > j-turtle: LTS+2, LTS+3 <- Staging Release > k-turtle: NLTS, NLTS+1 (Next LTS) > Just realise that this would imply i-turtle and k-turtle have support for 24months, and j-turtle only 12months. That would be fine, though you could also extend support for j-turtle into the first year of NLTS by which time you would hope it had smoothed out the bumps. > > We usually have an interest at Yujin in pursuing both use cases - the > latest *and* the stable (dependant on the project) and I think we could > work with that quite happily. It also provides a mechanism for ros to > introduce potentially disruptive changes (i.e. in LTS+2, LTS+3 releases) > and get real feedback without disrupting the part of the community that > needs to be stable. > > Cheers, > Daniel. > > * >> >> 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. From 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 >> >> > > > -- > Phone : +82-10-5400-3296 (010-5400-3296) > Home: http://snorriheim.dnsdojo.com/ > Yujin R&D: http://rnd.yujinrobot.com/ > > -- Phone : +82-10-5400-3296 (010-5400-3296) Home: http://snorriheim.dnsdojo.com/ Yujin R&D: http://rnd.yujinrobot.com/ --20cf3022403979789504ddfab2cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 31 May 2013 11:43, Daniel Stonier <d.stonier@gmail.com&g= t; wrote:



On 31 May 2013 08:= 46, Tully Foote <tfoote@osrfoundation.org> wrote:

Hi Everyone,


As a follow up to the surve= y we circulated last month I'd like to start a discussion of what the b= est timeline for ROS releases would be. =C2=A0


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


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


Starting out based on the s= urvey. =C2=A0We had a majority of respondants prefering a 12 month release = cycle and a plurality of respondants preferring a 24 month support period. = =C2=A0These two number nicely allign with our current practice of having tw= o supported ROS distributions at a time with one ROS distribution in develo= pment, however just with a longer release cycle. =C2=A0This amount of paral= lel development is about all that we think we can support as a community. = =C2=A0So based on this I think there's a relatively clear mandate to ch= ange the ROS release cycle to every 12 months with 24 months of support, al= lowing 12 months of overlap between releases for transition. =C2=A0<= /p>

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


Unfortunately the problem i= s not quite as simple as the above graphic shows as we need to build on top= of other platforms. =C2=A0Ubuntu has recently updated their planned releas= e cycle to support LTS for 5 years, but non-LTS releases for only 9 months = while maintaining their 6 month release cycle. =C2=A0See: https://wiki.ubuntu.com/Relea= ses =C2=A0


This can be seen in ubuntu.= svg


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


We started out be assuming = we'd release ROS in the spring to coincide with the LTS Ubuntu Release.= =C2=A0If we're planning a 1 year release cycle, the quick answer is th= at for the intervening 6 month Ubuntu Release the last ROS release is porte= d forward. =C2=A0This can be done with a minimal effort by following the Ub= untu by about 1 month, enabling a ROS release to be built against the curre= nt release and the upcoming pre-release Ubuntu. (Based on past experiences = prebuilds of Ubuntu releases are available shortly after the previous relea= se has come out.) With this basic outline we can release ROS each spring an= d support two Ubuntu distros each. =C2=A0


In recognition of the fact = that many users only use LTS on their robots we then thought to add a backp= ort of the ROS release with LTS+2 to build on the LTS. =C2=A0However the fa= ct 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 fo= r large changes to get into the next LTS release.



Took a peru= sal of the svg's to really sort out the puzzle of words above!

I think groovy was what we would consider a 'staging g= round' release for large changes. We had a vested interest in pursuing = groovy for some of our use cases, but for the use cases where we are intere= sted in using Ubuntu LTS releases, we probably wouldn't have missed gro= ovy much at all. So I'm not sure there may be enough interest to warran= t investing the effort to support big staging releases on LTS.

I notice what you've drawn in ubuntu_ros.svg coinci= des with this thinking - i.e.

i-turtle: LTS, = LTS+1
j-turtle: LTS+2, LTS+3 =C2=A0 <- Staging Release
k-turtle: NLTS, NLTS+1 (Next LTS)

Just realise that this would imply i-turtle= and k-turtle have support for 24months, and j-turtle only 12months. That w= ould be fine, though you could also extend support for j-turtle into the fi= rst year of NLTS by which time you would hope it had smoothed out the bumps= .

=C2=A0
=

We usually have an interest at Yujin in pursuing both use cases = - the latest and the stable (dependant on the project) and I think w= e could work with that quite happily. It also provides a mechanism for ros = to introduce potentially disruptive changes (i.e. in LTS+2, LTS+3 releases)= and get real feedback without disrupting the part of the community that ne= eds to be stable.

Cheers,
Daniel.


To see this see graphic ubu= ntu_ros.svg


To resolve this there are m= any options. =C2=A0We could consider dropping support for LTS+3 to resolve = the large spanning set. =C2=A0Another option is to simply support the LTS U= buntu Releases since the non LTS release cycles are now so short, making ou= r 24 month support cycle much easier. =C2=A0



You will note in this proce= ss that we have decreased the matrix of ROS vs Ubuntu packages. =C2=A0This = is purposeful as we've identified supporting the large matrix of ROS vs= Ubuntu distros as a significant burden on the community. =C2=A0Our 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 la= test version of ROS on the latest Ubuntu distro. =C2=A0


Besides the provided Debian= package it is always easily possible to build a ROS distribution from sour= ce. It only requires running a handful of commands. =C2=A0A 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 Hyd= ro released and I know many of the remaining packages which were in the ini= tial groovy release are preparing for the hydro release at the moment. =C2= =A0From 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 f= rom now. =C2=A0As a straw man for Hydro I'd propose July giving the Ind= igo cycle 9 months following Hydro 7 months to ease us into the 12 month cy= cle.


Please let us know your tho= ughts?


Tully



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




--
Phone : +82-10-5400-3296 (010-= 5400-3296)
Home: http://snorriheim.dnsdojo.com/



--
Phone : +82-= 10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
--20cf3022403979789504ddfab2cf--