<div dir="ltr">Hi Everyone, <div><br></div><div>Thank you for taking the time to fill out the survey. You can download the the pdf summary of the results from: <a href="https://docs.google.com/file/d/0BzNmzxy4pVGMNDdxNFNDblJTN1k/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0BzNmzxy4pVGMNDdxNFNDblJTN1k/edit?usp=sharing</a></div>
<div><br></div><div>Based on the above discussion and the survey results. We'd like to propose the following solution. Dirk's made another nice svg which is attached for visualization. </div>
<div><br></div>
<div>From the survey there is very strong support for an long term support of ROS(ROS going forward) in sync with Ubuntu LTS(LTS going forward), so we will start with that as a premis of this proposal. And we believe that we have built a consensus about a one year release cycle which would make the ROS+1 release on LTS+2. Now to fill in the gaps before ROS+2 (the next long term support) we will need to be able to build more than 6 months ahead in our 1 year cycle, so we would plan to use LTS+3 as a beta build ground for ROS+2. And to prepare for ROS+1 we need to be able to build early enough that we will beta build on LTS+1. And as there is strong support for multiple ROS distributions available on LTS, we will also backport ROS+1 to the LTS. </div>
<div><br></div><div>The net result is as follows:</div><div>Ubuntu LTS supports ROS, ROS+1</div><div>LTS+1 supports ROS+1 Beta</div><div>LTS+2 supports ROS+1</div><div>LTS+3 supports ROS+2 Beta</div>
<div>...</div><div>LTS2 supports ROS+2, ROS+3</div><div><br></div><div><br></div><div>This proposal provides the large userbase who will just use the Ubuntu LTS releases with two releases. The other set of users who would like to use the latest version of Ubuntu are following an aggressive cycle set by Ubuntu. For them we can make sure there's at least one version of ROS or the Beta release of ROS which should be in the soak period before the next release. </div>
<div><br></div><div><br></div><div>With regards to not tying ROS to Ubuntu only we will also definitely see to support other platforms. Right now we do not have the resources or expertise to support other platforms. We expect each ROS release to accept patches for support on other platforms. This also holds true for other arches such as arm, which is strongly supported in Q5 of the recent survey. </div>
<div><br></div><div>Related to this it has been suggested to me that we could setup a bidding/kickstarter style campaign for different platform or arch support. If people are interested we could estimate what it would take to support builds on extra arch/platform combinations for the duration of a release. And if there is enough community support to fund the project we can turn on specific architectures. Also we are currently building i386 and amd64, we could consider dropping i386 on some platforms to save resources. </div>
<div><br></div><div>Please take a look at the results of both surveys and the above proposal and give your feedback.<br></div><div><div><br></div></div><div>Tully</div>
<div><br></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 2, 2013 at 9:27 AM, Jack O'Quin <span dir="ltr"><<a href="mailto:jack.oquin@gmail.com" target="_blank">jack.oquin@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"><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"><div>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><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>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>
<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><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>As an alternative, government, company or industry groups could fund OSRF to provide extended support for specific packages and versions.</div><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><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><div>I am not certain what is meant by "rolling organisation".<br></div><div><br></div><div>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" target="_blank">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.<span><font color="#888888"><br>
</font></span></div></div><span><font color="#888888"><div><br></div></font></span></div><span><font color="#888888">-- <br> joq
</font></span></div></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div></div>