From kwc@willowgarage.com Mon Feb 7 12:27:39 2011 Return-Path: X-Original-To: ros-users@code.ros.org Delivered-To: ros-users@code.ros.org Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.216.174]) by pub5.willowgarage.com (Postfix) with ESMTPS id B954E25C13E for ; Mon, 7 Feb 2011 12:27:39 -0800 (PST) Received: by qyj19 with SMTP id 19so1832558qyj.5 for ; Mon, 07 Feb 2011 12:27:38 -0800 (PST) Received: by 10.224.135.232 with SMTP id o40mr395759qat.392.1297110456200; Mon, 07 Feb 2011 12:27:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.184.12 with HTTP; Mon, 7 Feb 2011 12:27:16 -0800 (PST) From: Ken Conley Date: Mon, 7 Feb 2011 12:27:16 -0800 Message-ID: To: ros-users Content-Type: text/plain; charset=ISO-8859-1 Subject: [ros-users] Update to release policy: no use of svn_checkout.mk X-BeenThere: ros-users@code.ros.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: User discussions List-Id: User discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:27:39 -0000 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