+1 on supporting more than just the LTS release.
Then again, supporting means two things: making sure the code compiles and
building packages. As we increase support for more distros/OSes, we receive
a lot of compatibility fixes from the community (I am thinking about
Homebrew that is constantly up to date with packages) and that means the
code usually compiles fine on a bunch of Ubuntu releases.
For building packages, it's just a matter of resources: if the ROS
community had more funding, we could build for more Ubuntu releases or even
Linux distros.
If we go out of sync with Ubuntu with longer release cycles, I also think
those decisions (about LTS, support and so on) should be made on a per
release basis because:
- Hydro will be fairly incremental but solid and we don't know yet when it
will be released (hence we don't know when Indigo will be released and
whether it will have a lot of new stuff)
- Ubuntu might switch to a rolling release (it's been debated several times
already since 12.10)
- who knows what will be the most popular OS for Indigo ? (sure most likely
Ubuntu, but ROS finally runs on Windows and also on more Linux distros
these days)
So I think we should make a decision about Hydro (release date, which
Ubuntu distros to support and so on), but not try to come up with rules
that we will apply next, in a year most likely, when the landscape might be
very different.
And just to heat up the debate, we could also have a rolling release :)
Like we used to have actually around C/D-turtle (that was "unstable" right
?).
On Fri, May 31, 2013 at 8:41 AM, Piyush <
piyushk@gmail.com> wrote:
> I would highly recommend against only supporting Ubuntu LTS releases. I
> completely agree with you that robot hardware will probably never require
> anything other than a backported kernel. However users new to robotics,
> Ubuntu and/or ROS might have the latest (Non-LTS) Ubuntu release installed
> for other projects. I think some care should be taken not to disenfranchise
> these new users from trying out ROS.
>
> I like Daniel's proposal (pasted again below).
>
> i-turtle: LTS, LTS+1
> j-turtle: LTS+2, LTS+3 <- Staging Release
> k-turtle: NLTS, NLTS+1 (Next LTS)
>
> As an Ubuntu LTS only user, this means that I am going to miss out on a
> new ROS release for a span of a year (i.e unlikely to use j-turtle). Here's
> another thought. Would an October release make sense?
>
> h-turtle (released in october with LTS-1): LTS-1, LTS (maintained for 30
> months)
> i-turtle (released in october with LTS+1): LTS, LTS+1, LTS+2 (maintained
> for 24 months)
> j-turtle (release in october with LTS+3/NLTS-1): LTS+3/NLTS-1, NLTS
> (maintained for 30 months)
>
> This way, if I like features in j-turtle a lot, I can upgrade to NLTS once
> released and only have to wait 6 months for the upgrade (which coincides
> with the median upgrade period), or perhaps even to NLTS beta.
>
> Piyush
>
> On Fri, May 31, 2013 at 12:27 AM, Chad Rockey <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.
>>
>
>> 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.
>>
>> 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.
>>
>> From 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)
>>
>> ...
>>
>> 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/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.
>>>
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
(text/plain)