From ros-release-bounces@lists.ros.org Wed Nov 2 17:32:53 2016 Return-Path: X-Original-To: ros-lurker@osuosl.org Delivered-To: ros-lurker@osuosl.org Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 0275E1C2D1A for ; Wed, 2 Nov 2016 17:32:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id EB53B31788 for ; Wed, 2 Nov 2016 17:32:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01] autolearn=unavailable Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8l0730rbLPH; Wed, 2 Nov 2016 17:32:49 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by silver.osuosl.org (Postfix) with ESMTP id 2645331917; Wed, 2 Nov 2016 17:32:49 +0000 (UTC) X-Original-To: ros-release@lists.ros.org Delivered-To: ros-release@osuosl.org Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id 3C2C81C2D1A for ; Wed, 2 Nov 2016 17:32:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 392DC922D5 for ; Wed, 2 Nov 2016 17:32:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS5aeh2ab1jE for ; Wed, 2 Nov 2016 17:32:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out-04a.sjc1.discourse.org (mx-out-04a.sjc1.discourse.org [64.71.168.240]) by whitealder.osuosl.org (Postfix) with ESMTPS id 24E0D92314 for ; Wed, 2 Nov 2016 17:32:46 +0000 (UTC) Received: from localhost.localdomain (unknown [IPv6:2001:470:aa:6::23a:b8ad:15f8]) by mx-out-04a.sjc1.discourse.org (Postfix) with ESMTP id 65E6B1603AF for ; Wed, 2 Nov 2016 17:32:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=discoursemail.com; s=sjc1; t=1478107965; bh=p/EGStMo1Oz3aL5yzfjHRuutLLFi1RSK22PFwHZLiNA=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject: List-Unsubscribe:List-ID:List-Archive; b=GP4K+THK3BjVtpyqDQugMTmUO7p5vM+wY4Qf3Ssl4vpFJucdE4V9PBzSQAdSt9XjD 0npJlGvwvogKYuLlMz7Ijf6jy1HjRoGJ0FNkvhco5mDftV6LL42ObsekzKxukCKFBD QfdIbFdlk65MnHJzphEG/l3KCiPlwhIUjH0BAydkziTX5l4OjSCBR4+pj+y8OHJ++3 D2yfOa+vKDwg0g2LbuieaHUj30jDDtfbBUUsCvOx3xP/NR7Vi2WpPFEmTxvh/Nl4qy RrJeQtQIj1QfkKfxhl0/2alFVuwvlFTpb/9G18OXLIjkeiSPF+mUK7A8eD9WgpRfVq f+wWkx4oZMfmQ== Date: Wed, 02 Nov 2016 17:32:45 +0000 To: ros-release@lists.ros.org Message-ID: In-Reply-To: References: Mime-Version: 1.0 X-Auto-Response-Suppress: All Auto-Submitted: auto-generated Precedence: list Subject: [ros-release] [Discourse.ros.org] [Release] Maintainer best practices handling changes through ROS releases X-BeenThere: ros-release@lists.ros.org X-Mailman-Version: 2.1.18-1 List-Id: The ROS release mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Jose Luis Rivero via ros-release Reply-To: "Discourse.ros.org" , Jose Luis Rivero , The ROS release mailing list Content-Type: multipart/mixed; boundary="===============5593575477369334333==" Errors-To: ros-release-bounces@lists.ros.org Sender: "ros-release" --===============5593575477369334333== Content-Type: multipart/alternative; boundary="--==_mimepart_581a233d6014b_cf3fc11abf5700760417"; charset=UTF-8 Content-Transfer-Encoding: 7bit ----==_mimepart_581a233d6014b_cf3fc11abf5700760417 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Some of my ideas: try to define "virtual types of distributions" that match stability vs new features. We could consider an "stable release" and "development release" and how these concepts fit into the ROS releases: * **stable release:** most of the users, any disruptive change should not be permitted only important bug fixes to be committed. * **development release:** brave users expecting fast new features and able to adapt quickly to changes. At this moment I would say that `Indigo` would fit perfectly in what we consider a stable release. I'm not so sure about `Jade`. Probably `Kinetic` can fit well into what we can consider a development release. Obviously the upcoming `Lunar` falls into this category. Reviewing the types of changes that I listed in my first post: * **Bugs**: if they fix things clearly broken, stable and development. * **Changes to the API**: clearly unacceptable for stable. If we consider `Kinetic` as a development release they probably are acceptable although they are have a large impact. * **Changes to the ABI**: given the position of ROS in this topic, they should not represent a problem except for people relying on mixing packages and catkin builds. I would probably exclude stable of this. * **Changes that affect rostopic/roslaunch/rosparams/.. names or arguments**: in most the cases the impact could be really important, even worse than modifying the API since problems could not be directly visible. * **Changes that affect behaviour (some of them are bug fixes)**: this category or group is difficult to manage. Take [this PR](https://github.com/ros-simulation/gazebo_ros_pkgs/pull/397) as a good example of how a clear bug fix needs to be handle with care. I would say that have a case by case analysis and decision is a good way but by default anything touching a behaviour in an stable release (even if clearly fix it in the right way) should not be accepted. There are other models if we define other "virtual types" of distributions (for example having `Jade` as a **testing release** before changes landed into `Indigo`) but I would like to keep the whole thing somehow simple. --- [Visit Topic](http://discourse.ros.org/t/maintainer-best-practices-handling-changes-through-ros-releases/771/2) or reply to this email to respond. To unsubscribe from these emails, [click here](http://discourse.ros.org/email/unsubscribe/e38c24220570c6523dcce4dbceb34d266108dd4a37375c90746b4e14cd325778). ----==_mimepart_581a233d6014b_cf3fc11abf5700760417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
jrivero
November 2

Some of my ideas: try to define "virtual types of distributions" that match stability vs new features. We could consider an "stable release" and "development release" and how these concepts fit into the ROS releases:

  • stable release: most of the users, any disruptive change should not be permitted only important bug fixes to be committed.
  • development release: brave users expecting fast new features and able to adapt quickly to changes.

At this moment I would say that Indigo would fit perfectly in what we consider a stable release. I'm not so sure about Jade. Probably Kinetic can fit well into what we can consider a development release. Obviously the upcoming Lunar falls into this category.

Reviewing the types of changes that I listed in my first post:

  • Bugs: if they fix things clearly broken, stable and development.

  • Changes to the API: clearly unacceptable for stable. If we consider Kinetic as a development release they probably are acceptable although they are have a large impact.

  • Changes to the ABI: given the position of ROS in this topic, they should not represent a problem except for people relying on mixing packages and catkin builds. I would probably exclude stable of this.

  • Changes that affect rostopic/roslaunch/rosparams/.. names or arguments: in most the cases the impact could be really important, even worse than modifying the API since problems could not be directly visible.

  • Changes that affect behaviour (some of them are bug fixes): this category or group is difficult to manage. Take this PR as a good example of how a clear bug fix needs to be handle with care. I would say that have a case by case analysis and decision is a good way but by default anything touching a behaviour in an stable release (even if clearly fix it in the right way) should not be accepted.

There are other models if we define other "virtual types" of distributions (for example having Jade as a testing release before changes landed into Indigo) but I would like to keep the whole thing somehow simple.


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

----==_mimepart_581a233d6014b_cf3fc11abf5700760417-- --===============5593575477369334333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ros-release mailing list ros-release@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-release --===============5593575477369334333==--