On Tue, Jun 18, 2013 at 10:23 AM, Tully Foote wrote: > Hi Everyone, > > Thank you for taking the time to fill out the survey. You can download > the the pdf summary of the results from: > https://docs.google.com/file/d/0BzNmzxy4pVGMNDdxNFNDblJTN1k/edit?usp=sharing > > 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. > > 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. > > The net result is as follows: > Ubuntu LTS supports ROS, ROS+1 > LTS+1 supports ROS+1 Beta > LTS+2 supports ROS+1 > LTS+3 supports ROS+2 Beta > ... > LTS2 supports ROS+2, ROS+3 > > > 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. > > > 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. > > > 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. > > Please take a look at the results of both surveys and the above proposal > and give your feedback. > Looks good to me. So, when can we expect Hydro for Precise? :-) Marcus > > > Tully > > > > On Sun, Jun 2, 2013 at 9:27 AM, Jack O'Quin wrote: > >> 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 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 >> >> _______________________________________________ >> 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 > > -- Marcus Liebhardt Control Engineer Yujin Robot 주소: 대한민국 서울시 금천구 가산동 345-30 남성프라자 #601, 153-023. Address: Door #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu, Seoul, 153-023, Republic of Korea Website: http://www.yujinrobot.com Email: marcus.liebhardt@yujinrobot.com Phone: +82-70-46577073