2.2 release cycle evaluation

I'll try to keep this short, but there were quite some issues I have hit
during the preparation of the 2.2 release. It took me longer to
package/test/fix it because of these issues:

**Debian packages and /usr/local/lib/orocos:
- It's impossible to install both xenomai/gnulinux component/plugin libraries
in the same lib/orocos directory. I had to install them in
/usr/lib/orocos-<target> in order to avoid the plugin loaders to load the libs
for both targets
-> I propose to make this the default for non Debian builds as well. For
macosx/windows systems, I would not change this since they don't have this
problem. So there it remains the 'lib/orocos' subdirectory.
-> this would have an influence on the UseOrocos.cmake macros as well, so not a
light change. We also need to see how this would work in a ROS package tree.
- We have to (or don't we have to?) think about packaging the other toolchain
packages. I have no time to do this however. Debian packaging takes so much
more time than I had hoped for. The major reason here is that we need to keep
track of the multi-target installations (gnulinux/xenomai/lxrt) which
complicates the packaging a lot... and sometimes only reveals problems when
you install the package or run its programs.

**autoproj and/or bootstrap:
I can't run this in my Hudson since it's interactive (or is there a plugin to
provide the input ???) I had to pull the release the last minute because when
manually testing the bootstrap script, it failed to build.
-> Can we make it non-interactive, or is there another solution ?

** bootstrap vs the packaged files
I have a script to create the zip files of the release. I had to hack a custom
autoproj package + release package set to make this work (the zip files are not
upgradable, there is a 'none' vcs associated with their packages).
I just noticed that the 2.2.0 zip files don't contain the log4cpp patches.
Fortunately, recent autobuild covers our 'damage', but maybe we should
think/colaborate on how to make releases of autoproj projects. (note: autoproj
status would have informed me of the branch deviations, my release script
should have run that command...).

** RPATH settings
We had removed/omitted too much rpath settings from the UseOrocos.cmake
macros. These turned up while testing the Debian packages for RTT/OCL (which
don't use an env.sh script) Would it make sense to set the rpaths as such ? :

* programs: prefix/lib; prefix/lib/orocos; prefix/lib/types; prefix/lib/plugins
* components: prefix/lib; prefix/lib/orocos; prefix/lib/types; prefix/lib/plugins
* plugins: prefix/lib; prefix/lib/plugins
* types: prefix/lib; prefix/lib/types

** Documentation
I'd like to set up daily documentation generation for the toolchain-* and
master branches. Such that users have quicker access to updates. With this
mechanism, it would no longer be necessary for me to do the documentation
release steps, since it would always be there.
-> I'm also not happy with the Lua documentation.

** Website
I have updated the front page figure of the Orocos project to the traditional
KDL/BFL/Toolchain trio. I'm unsure how to position the orogen/dfki efforts
here. orogen is part of the toolchain, but I could not write up release notes
about that part in my 'changes' document. I had a similar issue for the Lua
contributions. For the next release, I'd like to setup a wiki page that
contains these changes for all parts of the toolchain. Then these 'non-Peter'
parts can be updated by their maintainer in the run for the release.
-> Other suggestions on this topic ?

Other feedback welcome too.

Peter

2.2 release cycle evaluation

On 14/12/2010, at 23:05 , Peter Soetens wrote:

> I'll try to keep this short, but there were quite some issues I have hit
> during the preparation of the 2.2 release. It took me longer to
> package/test/fix it because of these issues:
>
> **Debian packages and /usr/local/lib/orocos:
> - It's impossible to install both xenomai/gnulinux component/plugin libraries
> in the same lib/orocos directory. I had to install them in
> /usr/lib/orocos-<target> in order to avoid the plugin loaders to load the libs
> for both targets
> -> I propose to make this the default for non Debian builds as well. For
> macosx/windows systems, I would not change this since they don't have this
> problem. So there it remains the 'lib/orocos' subdirectory.

While that extra target prefix/suffix is a pain, I'd suggest leaving it the same for mac/win. Personally, I don't want to have to think one thing for Linux, and a different thing for Mac. That will just result in me swearing in Peter's direction one day, for no good reason ...

> -> this would have an influence on the UseOrocos.cmake macros as well, so not a
> light change. We also need to see how this would work in a ROS package tree.
> - We have to (or don't we have to?) think about packaging the other toolchain
> packages. I have no time to do this however. Debian packaging takes so much
> more time than I had hoped for. The major reason here is that we need to keep
> track of the multi-target installations (gnulinux/xenomai/lxrt) which
> complicates the packaging a lot... and sometimes only reveals problems when
> you install the package or run its programs.

Debian packaging is a nightmare .... :-(

> **autoproj and/or bootstrap:
> I can't run this in my Hudson since it's interactive (or is there a plugin to
> provide the input ???) I had to pull the release the last minute because when
> manually testing the bootstrap script, it failed to build.
> -> Can we make it non-interactive, or is there another solution ?
>
> ** bootstrap vs the packaged files
> I have a script to create the zip files of the release. I had to hack a custom
> autoproj package + release package set to make this work (the zip files are not
> upgradable, there is a 'none' vcs associated with their packages).
> I just noticed that the 2.2.0 zip files don't contain the log4cpp patches.
> Fortunately, recent autobuild covers our 'damage', but maybe we should
> think/colaborate on how to make releases of autoproj projects. (note: autoproj
> status would have informed me of the branch deviations, my release script
> should have run that command...).
>
> ** RPATH settings
> We had removed/omitted too much rpath settings from the UseOrocos.cmake
> macros. These turned up while testing the Debian packages for RTT/OCL (which
> don't use an env.sh script) Would it make sense to set the rpaths as such ? :
>
> * programs: prefix/lib; prefix/lib/orocos; prefix/lib/types; prefix/lib/plugins
> * components: prefix/lib; prefix/lib/orocos; prefix/lib/types; prefix/lib/plugins
> * plugins: prefix/lib; prefix/lib/plugins
> * types: prefix/lib; prefix/lib/types
>
> ** Documentation
> I'd like to set up daily documentation generation for the toolchain-* and
> master branches. Such that users have quicker access to updates. With this
> mechanism, it would no longer be necessary for me to do the documentation
> release steps, since it would always be there.
> -> I'm also not happy with the Lua documentation.

+1 YES! I would love to have auto-created documentation, generated upon commit. That is, use Hudson to auto-build the latest doc's and link the website to the latest stable. I was intending to suggest this for the upcoming Examples repo. Saves generating wiki pages as well as inline doxygen doc's.

> ** Website
> I have updated the front page figure of the Orocos project to the traditional
> KDL/BFL/Toolchain trio. I'm unsure how to position the orogen/dfki efforts
> here. orogen is part of the toolchain, but I could not write up release notes
> about that part in my 'changes' document. I had a similar issue for the Lua
> contributions. For the next release, I'd like to setup a wiki page that
> contains these changes for all parts of the toolchain. Then these 'non-Peter'
> parts can be updated by their maintainer in the run for the release.
> -> Other suggestions on this topic ?

You are suggesting to _not_ produce a changelist within the code distribution itself? That doesn't sound like a good idea.
S

Ruben Smits's picture

2.2 release cycle evaluation

On Tuesday 14 December 2010 20:13:08 S Roderick wrote:
> On 14/12/2010, at 23:05 , Peter Soetens wrote:
> > I'll try to keep this short, but there were quite some issues I have hit
> > during the preparation of the 2.2 release. It took me longer to
> > package/test/fix it because of these issues:
> >
> > **Debian packages and /usr/local/lib/orocos:
> > - It's impossible to install both xenomai/gnulinux component/plugin
> > libraries in the same lib/orocos directory. I had to install them in
> > /usr/lib/orocos-<target> in order to avoid the plugin loaders to load the
> > libs for both targets
> > -> I propose to make this the default for non Debian builds as well. For
> > macosx/windows systems, I would not change this since they don't have
> > this problem. So there it remains the 'lib/orocos' subdirectory.
>
> While that extra target prefix/suffix is a pain, I'd suggest leaving it the
> same for mac/win. Personally, I don't want to have to think one thing for
> Linux, and a different thing for Mac. That will just result in me swearing
> in Peter's direction one day, for no good reason ...
>
> > -> this would have an influence on the UseOrocos.cmake macros as well, so
> > not a light change. We also need to see how this would work in a ROS
> > package tree. - We have to (or don't we have to?) think about packaging
> > the other toolchain packages. I have no time to do this however. Debian
> > packaging takes so much more time than I had hoped for. The major reason
> > here is that we need to keep track of the multi-target installations
> > (gnulinux/xenomai/lxrt) which complicates the packaging a lot... and
> > sometimes only reveals problems when you install the package or run its
> > programs.
>
> Debian packaging is a nightmare .... :-(
>
> > **autoproj and/or bootstrap:
> > I can't run this in my Hudson since it's interactive (or is there a
> > plugin to provide the input ???) I had to pull the release the last
> > minute because when manually testing the bootstrap script, it failed to
> > build.
> > -> Can we make it non-interactive, or is there another solution ?
> >
> > ** bootstrap vs the packaged files
> > I have a script to create the zip files of the release. I had to hack a
> > custom autoproj package + release package set to make this work (the zip
> > files are not upgradable, there is a 'none' vcs associated with their
> > packages). I just noticed that the 2.2.0 zip files don't contain the
> > log4cpp patches. Fortunately, recent autobuild covers our 'damage', but
> > maybe we should think/colaborate on how to make releases of autoproj
> > projects. (note: autoproj status would have informed me of the branch
> > deviations, my release script should have run that command...).
> >
> > ** RPATH settings
> > We had removed/omitted too much rpath settings from the UseOrocos.cmake
> > macros. These turned up while testing the Debian packages for RTT/OCL
> > (which don't use an env.sh script) Would it make sense to set the rpaths
> > as such ? :
> >
> > * programs: prefix/lib; prefix/lib/orocos; prefix/lib/types;
> > prefix/lib/plugins * components: prefix/lib; prefix/lib/orocos;
> > prefix/lib/types; prefix/lib/plugins * plugins: prefix/lib;
> > prefix/lib/plugins
> > * types: prefix/lib; prefix/lib/types
> >
> > ** Documentation
> > I'd like to set up daily documentation generation for the toolchain-* and
> > master branches. Such that users have quicker access to updates. With
> > this mechanism, it would no longer be necessary for me to do the
> > documentation release steps, since it would always be there.
> > -> I'm also not happy with the Lua documentation.
>
> +1 YES! I would love to have auto-created documentation, generated upon
> commit. That is, use Hudson to auto-build the latest doc's and link the
> website to the latest stable. I was intending to suggest this for the
> upcoming Examples repo. Saves generating wiki pages as well as inline
> doxygen doc's.

I've been doing this for a while now for KDL, it pretty easy to configure
Hudson to do this.

> > ** Website
> > I have updated the front page figure of the Orocos project to the
> > traditional KDL/BFL/Toolchain trio. I'm unsure how to position the
> > orogen/dfki efforts here. orogen is part of the toolchain, but I could
> > not write up release notes about that part in my 'changes' document. I
> > had a similar issue for the Lua contributions. For the next release, I'd
> > like to setup a wiki page that contains these changes for all parts of
> > the toolchain. Then these 'non-Peter' parts can be updated by their
> > maintainer in the run for the release. -> Other suggestions on this
> > topic ?
>
> You are suggesting to _not_ produce a changelist within the code
> distribution itself? That doesn't sound like a good idea.

Same opinion, in the ideal case the wiki should be able to extract the
changelist from the codebase and pretty print it.

Ruben

2.2 release cycle evaluation

On Tue, Dec 14, 2010 at 11:05:22AM +0100, Peter Soetens wrote:
> I'll try to keep this short, but there were quite some issues I have hit
> during the preparation of the 2.2 release. It took me longer to
> package/test/fix it because of these issues:

I possibly missed it last time, but could you state at some point
(maybe after releasing a new version) what the intended dates for
upcoming merge window, freeze, release and so on are. That would allow
to push patches to you in time next time.

Markus

2.2 release cycle evaluation

On 12/14/2010 11:05 AM, Peter Soetens wrote:
> I'll try to keep this short, but there were quite some issues I have hit
> during the preparation of the 2.2 release. It took me longer to
> package/test/fix it because of these issues:
>
> **Debian packages and /usr/local/lib/orocos:
> - It's impossible to install both xenomai/gnulinux component/plugin libraries
> in the same lib/orocos directory. I had to install them in
> /usr/lib/orocos-<target> in order to avoid the plugin loaders to load the libs
> for both targets
> -> I propose to make this the default for non Debian builds as well. For
> macosx/windows systems, I would not change this since they don't have this
> problem. So there it remains the 'lib/orocos' subdirectory.
> -> this would have an influence on the UseOrocos.cmake macros as well, so not a
> light change. We also need to see how this would work in a ROS package tree.
And on the orogen cmake

> **autoproj and/or bootstrap:
> I can't run this in my Hudson since it's interactive (or is there a plugin to
> provide the input ???) I had to pull the release the last minute because when
> manually testing the bootstrap script, it failed to build.
> -> Can we make it non-interactive, or is there another solution ?
Yes. Autoproj supports this but it is undocumented. Solution is on its way

> ** bootstrap vs the packaged files
> I have a script to create the zip files of the release. I had to hack a custom
> autoproj package + release package set to make this work (the zip files are not
> upgradable, there is a 'none' vcs associated with their packages).
> I just noticed that the 2.2.0 zip files don't contain the log4cpp patches.
> Fortunately, recent autobuild covers our 'damage', but maybe we should
> think/colaborate on how to make releases of autoproj projects. (note: autoproj
> status would have informed me of the branch deviations, my release script
> should have run that command...).
What is that zip file exactly ? Is it an autoproj tree that includes
everything already checked out and ready to build ? Is it something else ?

Overriding all VCS can be done by creating an autoproj/overrides.yml with

overrides:
.*:
type: none

What would be left is not having autoproj ask questions. Could add a
config.yml to autoproj/ and add a mechanism

> ** RPATH settings
> We had removed/omitted too much rpath settings from the UseOrocos.cmake
> macros. These turned up while testing the Debian packages for RTT/OCL (which
> don't use an env.sh script) Would it make sense to set the rpaths as such ? :
>
> * programs: prefix/lib; prefix/lib/orocos; prefix/lib/types; prefix/lib/plugins
> * components: prefix/lib; prefix/lib/orocos; prefix/lib/types; prefix/lib/plugins
> * plugins: prefix/lib; prefix/lib/plugins
> * types: prefix/lib; prefix/lib/types
FYI, as far as I remember, the Debian policy forbids using RPATH at all.

> ** Website
> I have updated the front page figure of the Orocos project to the traditional
> KDL/BFL/Toolchain trio. I'm unsure how to position the orogen/dfki efforts
> here. orogen is part of the toolchain, but I could not write up release notes
> about that part in my 'changes' document. I had a similar issue for the Lua
> contributions. For the next release, I'd like to setup a wiki page that
> contains these changes for all parts of the toolchain. Then these 'non-Peter'
> parts can be updated by their maintainer in the run for the release.
> -> Other suggestions on this topic ?
I don't know about oroGen. I'd like to have a statement, at this stage,
about how you (= Peter, Markus, Steven, ...) see oroGen as "part of the
toolchain"

What I feel is that typegen is part of the "official" toolchain, but
oroGen is not. Example: the "advertised" workflow is the
write-C++-components-manually workflow. oroGen is barely mentioned.

Note that I don't see that as a bad thing per se. I'd just like to know.

As for release notes, I would be happy to fill in a wiki page.

> Other feedback welcome too.
>
> Peter

2.2 release cycle evaluation

On Tuesday 14 December 2010 12:38:27 Sylvain Joyeux wrote:
> On 12/14/2010 11:05 AM, Peter Soetens wrote:
> > I'll try to keep this short, but there were quite some issues I have hit
> > during the preparation of the 2.2 release. It took me longer to
> > package/test/fix it because of these issues:
> >
> > **Debian packages and /usr/local/lib/orocos:
> > - It's impossible to install both xenomai/gnulinux component/plugin
> > libraries in the same lib/orocos directory. I had to install them in
> > /usr/lib/orocos-<target> in order to avoid the plugin loaders to load
> > the libs for both targets
> > -> I propose to make this the default for non Debian builds as well. For
> > macosx/windows systems, I would not change this since they don't have
> > this problem. So there it remains the 'lib/orocos' subdirectory.
> > -> this would have an influence on the UseOrocos.cmake macros as well,
> > so not a light change. We also need to see how this would work in a ROS
> > package tree.
>
> And on the orogen cmake

Ack.

>
> > **autoproj and/or bootstrap:
> > I can't run this in my Hudson since it's interactive (or is there a
> > plugin to provide the input ???) I had to pull the release the last
> > minute because when manually testing the bootstrap script, it failed to
> > build.
> > -> Can we make it non-interactive, or is there another solution ?
>
> Yes. Autoproj supports this but it is undocumented. Solution is on its way
>
> > ** bootstrap vs the packaged files
> > I have a script to create the zip files of the release. I had to hack a
> > custom autoproj package + release package set to make this work (the zip
> > files are not upgradable, there is a 'none' vcs associated with their
> > packages). I just noticed that the 2.2.0 zip files don't contain the
> > log4cpp patches. Fortunately, recent autobuild covers our 'damage', but
> > maybe we should think/colaborate on how to make releases of autoproj
> > projects. (note: autoproj status would have informed me of the branch
> > deviations, my release script should have run that command...).
>
> What is that zip file exactly ? Is it an autoproj tree that includes
> everything already checked out and ready to build ? Is it something else ?
>
> Overriding all VCS can be done by creating an autoproj/overrides.yml with
>
> overrides:
> .*:
> type: none

I'm indeed using something similar. I have a local autoproj project with one
package set in there named 'release' and has this sources.yml :
$ cat release/source.yml
name: orocos.toolchain

version_control:
- ".*": none

The bootstrap_toolchain script is a slightly modified version of latest
autoproj_bootrap and serves to setup ruby and autoproj. The rest of the zip
are exports of the git repositories...

>
> What would be left is not having autoproj ask questions. Could add a
> config.yml to autoproj/ and add a mechanism

I don't mind that the bootstrap_toolchain script asks users questions.

>
> > ** RPATH settings
> > We had removed/omitted too much rpath settings from the UseOrocos.cmake
> > macros. These turned up while testing the Debian packages for RTT/OCL
> > (which don't use an env.sh script) Would it make sense to set the rpaths
> > as such ? :
> >
> > * programs: prefix/lib; prefix/lib/orocos; prefix/lib/types;
> > prefix/lib/plugins * components: prefix/lib; prefix/lib/orocos;
> > prefix/lib/types; prefix/lib/plugins * plugins: prefix/lib;
> > prefix/lib/plugins
> > * types: prefix/lib; prefix/lib/types
>
> FYI, as far as I remember, the Debian policy forbids using RPATH at all.

I'll be blind to that for now. Seeing Adolfo's mail seems to suggest that
we're not in a 'hard' violation, except that we need to omit the 'prefix/lib'
for Debian packages, which makes sense since prefix is '/usr'.

>
> > ** Website
> > I have updated the front page figure of the Orocos project to the
> > traditional KDL/BFL/Toolchain trio. I'm unsure how to position the
> > orogen/dfki efforts here. orogen is part of the toolchain, but I could
> > not write up release notes about that part in my 'changes' document. I
> > had a similar issue for the Lua contributions. For the next release, I'd
> > like to setup a wiki page that contains these changes for all parts of
> > the toolchain. Then these 'non-Peter' parts can be updated by their
> > maintainer in the run for the release. -> Other suggestions on this
> > topic ?
>
> I don't know about oroGen. I'd like to have a statement, at this stage,
> about how you (= Peter, Markus, Steven, ...) see oroGen as "part of the
> toolchain"
>
> What I feel is that typegen is part of the "official" toolchain, but
> oroGen is not.

I think both are part of the toolchain, but there are two workflows in the
toolchain which I wish to support. With and without orogen, and using typegen
whenever possible.

> Example: the "advertised" workflow is the
> write-C++-components-manually workflow. oroGen is barely mentioned.
>
> Note that I don't see that as a bad thing per se. I'd just like to know.

I currently see the workflow 'dependency' graph like this:

1. Orocos workflow = agreement on the concepts like in the 'Orocos cheatsheet'
2. Choose between 'write' or 'generate' components
2a. Write: use the RTT cheat sheet workflow
2b. Generate: use the oroGen cheat sheet workflow

oroGen is advertised on the toolchain home page. But maybe we can visualise
this better. To make my statement clear: I *want* orogen to be part of the
"official" toolchain. I also think that there are still existing tools lacking
(that build further on orogen). If you can say: if you use orogen, then you'll
also always use tool 'X', then that tool should be part of the toolchain as
well.

>
> As for release notes, I would be happy to fill in a wiki page.

So it will be next time.

Peter

2.2 release cycle evaluation

On Tue, Dec 14, 2010 at 12:38 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 12/14/2010 11:05 AM, Peter Soetens wrote:
> > I'll try to keep this short, but there were quite some issues I have hit
> > during the preparation of the 2.2 release. It took me longer to
> > package/test/fix it because of these issues:
> >
> > **Debian packages and /usr/local/lib/orocos:
> > - It's impossible to install both xenomai/gnulinux component/plugin
> libraries
> > in the same lib/orocos directory. I had to install them in
> > /usr/lib/orocos-<target> in order to avoid the plugin loaders to load
> the libs
> > for both targets
> > -> I propose to make this the default for non Debian builds as well. For
> > macosx/windows systems, I would not change this since they don't have
> this
> > problem. So there it remains the 'lib/orocos' subdirectory.
> > -> this would have an influence on the UseOrocos.cmake macros as well,
> so not a
> > light change. We also need to see how this would work in a ROS package
> tree.
> And on the orogen cmake
>
> > **autoproj and/or bootstrap:
> > I can't run this in my Hudson since it's interactive (or is there a
> plugin to
> > provide the input ???) I had to pull the release the last minute because
> when
> > manually testing the bootstrap script, it failed to build.
> > -> Can we make it non-interactive, or is there another solution ?
> Yes. Autoproj supports this but it is undocumented. Solution is on its way
>
> > ** bootstrap vs the packaged files
> > I have a script to create the zip files of the release. I had to hack a
> custom
> > autoproj package + release package set to make this work (the zip files
> are not
> > upgradable, there is a 'none' vcs associated with their packages).
> > I just noticed that the 2.2.0 zip files don't contain the log4cpp
> patches.
> > Fortunately, recent autobuild covers our 'damage', but maybe we should
> > think/colaborate on how to make releases of autoproj projects. (note:
> autoproj
> > status would have informed me of the branch deviations, my release script
> > should have run that command...).
> What is that zip file exactly ? Is it an autoproj tree that includes
> everything already checked out and ready to build ? Is it something else ?
>
> Overriding all VCS can be done by creating an autoproj/overrides.yml with
>
> overrides:
> .*:
> type: none
>
> What would be left is not having autoproj ask questions. Could add a
> config.yml to autoproj/ and add a mechanism
>
> > ** RPATH settings
> > We had removed/omitted too much rpath settings from the UseOrocos.cmake
> > macros. These turned up while testing the Debian packages for RTT/OCL
> (which
> > don't use an env.sh script) Would it make sense to set the rpaths as such
> ? :
> >
> > * programs: prefix/lib; prefix/lib/orocos; prefix/lib/types;
> prefix/lib/plugins
> > * components: prefix/lib; prefix/lib/orocos; prefix/lib/types;
> prefix/lib/plugins
> > * plugins: prefix/lib; prefix/lib/plugins
> > * types: prefix/lib; prefix/lib/types
> FYI, as far as I remember, the Debian policy forbids using RPATH at all.
>

More details on Debian and rpath use: From [1], "While there's no policy
dictating the accepted use of rpath, it's been a general consensus that
rpath use is discouraged...". "Currently, the only generally accepted use of
this feature in Debian is to add non-standard library path (like
/usr/lib/<package>) to libraries that are only intended to be used by the
executables or other libraries within the same source package". More on when
it is OK to use rpath settings can be found here [2].

[1] http://wiki.debian.org/RpathIssue
[2] http://lists.debian.org/debian-devel/2002/07/msg02030.html

Adolfo

> > ** Website
> > I have updated the front page figure of the Orocos project to the
> traditional
> > KDL/BFL/Toolchain trio. I'm unsure how to position the orogen/dfki
> efforts
> > here. orogen is part of the toolchain, but I could not write up release
> notes
> > about that part in my 'changes' document. I had a similar issue for the
> Lua
> > contributions. For the next release, I'd like to setup a wiki page that
> > contains these changes for all parts of the toolchain. Then these
> 'non-Peter'
> > parts can be updated by their maintainer in the run for the release.
> > -> Other suggestions on this topic ?
> I don't know about oroGen. I'd like to have a statement, at this stage,
> about how you (= Peter, Markus, Steven, ...) see oroGen as "part of the
> toolchain"
>
> What I feel is that typegen is part of the "official" toolchain, but
> oroGen is not. Example: the "advertised" workflow is the
> write-C++-components-manually workflow. oroGen is barely mentioned.
>
> Note that I don't see that as a bad thing per se. I'd just like to know.
>
> As for release notes, I would be happy to fill in a wiki page.
>
> > Other feedback welcome too.
> >
> > Peter
>
>
> --
> Sylvain Joyeux (Dr. Ing.)
> Researcher - Space and Security Robotics
> DFKI Robotics Innovation Center
> Bremen, Robert-Hooke-Straße 5, 28359 Bremen, Germany
>
> Phone: +49 421 218-64136
> Fax: +49 421 218-64150
> Email: sylvain [dot] joyeux [..] ...
>
> Weitere Informationen: http://www.dfki.de
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>