[ros-users] Update to release policy: no use of svn_checkout.mk
Ken Conley
kwc at willowgarage.com
Mon Feb 7 20:27:16 UTC 2011
Hi all,
Our stack release system [1] enables contributors to release stacks
that become part of the ROS distribution debians. Due to recent
integration issues, we've decided to add one prohibition on these
stacks: they may not download external source control repositories
during the build process. This is generally done with the
svn_checkout.mk file and the like. This prohibition is only on stacks
in our debian build system.
External Subversion repositories are frequently used to download
thirdparty libraries to integrate into the ROS build system. When you
do a stack release, a tarball of your stack is created and uploaded to
our servers. This tarball does not contain the source of these
external subversion repositories, which creates problems later.
In particular, we've had major issues with SourceForge. They recently
changed the SSL certificates on their site to use an intermediary
signer that is not recognized on Ubuntu systems. Each repository has
a separate certificate, which creates additional issues. We are
attempting a workaround for this, but there have been other issues,
like downtime, that have also led to this decision. Stacks that
successfully built just a day before may suddenly stop building, which
requires lengthy investigation and forces us to choose between pulling
the stack or delaying the next distribution release.
This policy only affects a limited number of stacks, and the
workaround is straightforward. We ask that you instead create a
tarball of the required source and use `download_unpack_build.mk`
instead. We are happy to host this tarball if you contact us.
Although downloading a separate tarball could have potential issues,
we expect better reliability and less stack-specific workarounds.
We've used this policy internally for our own stacks and the effect
has been very positive.
It pains us to point out these issues with SourceForge as ROS was
first hosted there, and they host many, useful robotics libraries. We
are grateful to the service they provide and we will continue to do
our best to support a wide variety of hosting providers and source
control tools. That said, in this case, we think that a general
prohibition in our debian build system will significantly improve the
stability and enable us to focus on other development.
regards,
Ken
[1]: http://www.ros.org/wiki/release
More information about the ros-users
mailing list