I have read this thread with interest. Many contributors provided well
thought-out insights and suggestions. I agree with most of what has been
said, even some that are difficult to reconcile with each other. :-)
On Fri, May 31, 2013 at 4:52 PM, Willy Lambert <
lambert.willy@gmail.com>wrote:
> I don't know what's the position about letting ros run on other systems
> that ubuntu, but if the will is to let it run on several OS flavor (which
> is the right way to go imo) then sticking to Ubuntu release cycles has just
> no sense.
>
> There will always be several types of users that on one hand will wish
> high release rate with few changes for agility and on the other one will
> require very stable grouped release with LTS for stability.
>
> "agile" users are required to let the project going ahead as they are the
> boiling source of idea and great debuggers.
>
+1 to all the above. I've been an "agile" user for some projects and an LTS
advocate for others, depending on the needs of the project. That made it
hard to give a single answer for some of the questions Tully asked on his
questionaire.
I would like to see ROS development more closely follow the traditional
open source model, where the main deliverable is a *source* release
supported on a wide range of host systems. Ours should support essentially
all recent Linux distributions, recent OSX releases, and Windows (as best
we can).
Agile developers can build and work with the sources. If most key
developers build most things from source, there will be fewer problems
building on non-Ubuntu platforms. What's more, the tools for doing that
cleanly and repeatably will continue to improve significantly.
Despite all that, I also think providing "unstable" debbuilds for a few
recent Ubuntu versions is worth the effort, mainly because of the
continuous integration and extra testing it could enable. Before, with
distros coming out twice a year, there was little incentive for users to
experiment with the "unstable" distro, so it did not accomplish much. With
longer intervals between distros, that is likely to change.
> As ROS is going into industry (or simply because it s now a mature
> system), LTS and low feature release rate is a must have. People will soon
> use ROS in contexts where security and norms are highering inertia of
> validation step (required after every update).
>
Building and hosting Ubuntu packages should be more clearly a separate step
than it is now. There is already work to make the OSRF build farm and other
infrastructure portable and documented. That is important. Outside
organizations need to be able to run their own build farms for several
reasons.
Many people in industry will need very long-term support, some for a
duration that OSRF is probably not able or willing to provide. If that
happens, there would likely be a business case for one or more for-profit
organizations to supply hosting, build, integration, testing and
maintenance for whatever set of LTS releases people will pay for. A
portable build farm would lower the cost of entry for that business.
As an alternative, government, company or industry groups could fund OSRF
to provide extended support for specific packages and versions.
> Rolling organisation seems adapted to this.
>
> About release cycle duration, what's important is to freeze features at a
> fixed date (cause we always have cooler stuff to add but we need to stop
> sometime), then let the time required to be stable.
>
Its quite important for people who plans things ahead (they exist !) to see
> what's happening next as it may triggers heavy updating work behing for
> users.
>
I am not certain what is meant by "rolling organisation".
The ROS distro concept has proven effective for organizing and integrating
the core packages. In my experience, higher-level packages can often
support two or three ROS distros with a single source version. That's good,
and we need to continue providing that kind of API stability.
ROS distro source releases can happen whenever they make sense, mostly
independent of Ubuntu versions. Of course, the REP-0003 platform
deliberations become even more important for defining minimum versions of
various languages, libraries, and Python modules. For example, I'd like to
see full Python 3 support in the core packages and tools in Indigo.
http://ros.org/reps/rep-0003.html#platforms-by-distribution
It helps to have a road-map with approximate times in mind. Freeze dates
are key, with core packages that everything else depends on frozen early.
The actual release happens only when the release manager decides the
quality is ready.
--
joq
(text/plain)