<div dir="ltr"><div>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. :-)</div>
<br><div class="gmail_extra"><div class="gmail_quote">On Fri, May 31, 2013 at 4:52 PM, Willy Lambert <span dir="ltr"><<a href="mailto:lambert.willy@gmail.com" target="_blank">lambert.willy@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p>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.</p>



<p>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.</p>
<p>"agile" users are required to let the project going ahead as they are the boiling source of idea and great debuggers.</p></blockquote><div>+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. </div>
<div><br></div><div>I would like to see ROS development more closely follow the traditional open source model, where the main deliverable is a <i>source</i> 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).</div>

<div><br></div><div>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.</div>
<div><br></div><div style>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.</div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p>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).</p>

</blockquote><div>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. <br>

</div><div><br></div><div>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.</div>
<div><br></div><div style>As an alternative, government, company or industry groups could fund OSRF to provide extended support for specific packages and versions.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<p>Rolling organisation seems adapted to this.</p>
<p>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.</p></blockquote>

<div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p>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.</p>

</blockquote></div></div><div style>I am not certain what is meant by "rolling organisation".<br></div><div style><br></div><div style>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.</div>
<div><br></div><div>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.  </div>
<div><br></div><div> <a href="http://ros.org/reps/rep-0003.html#platforms-by-distribution">http://ros.org/reps/rep-0003.html#platforms-by-distribution</a></div><div><br></div><div>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.<br>

</div></div><div><br></div></div>-- <br> joq
</div></div>