Initial Indigo release from ros-planning/moveit repo #100

Closed
v4hn opened this Issue Aug 22, 2016 · 65 comments

Comments

Projects
None yet
10 participants
@v4hn
Member

v4hn commented Aug 22, 2016


What's the state of the next indigo release?
Will we have the release out tomorrow? (I presume not)
Are we in a situation where we want to have the release?

Do we want to wait for a backported version of #63 to address safety?

If this affects indigo-devel too, this is a regression we shouldn't release into indigo.

@130s @davetcoleman @rhaschke

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Aug 22, 2016

Member

Yeah, I'm about to work on this. I leave up to you guys about the mentioned concern, so please share any thoughts on it.
If everything goes fine we may have debs ready on shadow-fixed.

Member

130s commented Aug 22, 2016

Yeah, I'm about to work on this. I leave up to you guys about the mentioned concern, so please share any thoughts on it.
If everything goes fine we may have debs ready on shadow-fixed.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Aug 22, 2016

Member

As we are currently unsure about the ABI stability of the release, I'm actually not keen to see this released by tomorrow...
Better safe than sorry.
Anyone else?

Member

v4hn commented Aug 22, 2016

As we are currently unsure about the ABI stability of the release, I'm actually not keen to see this released by tomorrow...
Better safe than sorry.
Anyone else?

@davetcoleman davetcoleman changed the title from indigo release to Indigo Release Aug 22, 2016

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Aug 22, 2016

Member

I agree with @v4hn that we've had no soak time and, if we were to release indigo today, there is a chance we'd break our stable LTS on a day when hopefully lots of people will be using them. Let's wait a few days.

Member

davetcoleman commented Aug 22, 2016

I agree with @v4hn that we've had no soak time and, if we were to release indigo today, there is a chance we'd break our stable LTS on a day when hopefully lots of people will be using them. Let's wait a few days.

@de-vri-es

This comment has been minimized.

Show comment
Hide comment
@de-vri-es

de-vri-es Aug 22, 2016

Member

Just a heads up, #77 (cherry-picked from #70) introduces one API change that should be reverted before the indigo release. See also #98.

The specific change was here: https://github.com/ros-planning/moveit/pull/77/files#diff-76b7a92f6aeeed9e7bba70df54cce8a7L101

The typedef ObjectConstPtr was fixed to actually be a pointer-to-const, but it appears in the public API in a number of places, so should be left as it was for Indigo.

Pull request coming in later today. Update: PR now available at #104

Member

de-vri-es commented Aug 22, 2016

Just a heads up, #77 (cherry-picked from #70) introduces one API change that should be reverted before the indigo release. See also #98.

The specific change was here: https://github.com/ros-planning/moveit/pull/77/files#diff-76b7a92f6aeeed9e7bba70df54cce8a7L101

The typedef ObjectConstPtr was fixed to actually be a pointer-to-const, but it appears in the public API in a number of places, so should be left as it was for Indigo.

Pull request coming in later today. Update: PR now available at #104

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Aug 23, 2016

Member

The revert has been merged, thanks @de-vri-es for the quick response

Member

davetcoleman commented Aug 23, 2016

The revert has been merged, thanks @de-vri-es for the quick response

@jspricke

This comment has been minimized.

Show comment
Hide comment
@jspricke

jspricke Aug 23, 2016

Contributor

See #121 for ABI problems.

Contributor

jspricke commented Aug 23, 2016

See #121 for ABI problems.

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Aug 26, 2016

Member

(I've copy-pasted this to the top #100 (comment) so that we could better keep track of the status)

What else?

Member

130s commented Aug 26, 2016

(I've copy-pasted this to the top #100 (comment) so that we could better keep track of the status)

What else?

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Aug 26, 2016

Member

Looks good to me

Member

davetcoleman commented Aug 26, 2016

Looks good to me

@gavanderhoorn gavanderhoorn referenced this issue in ros-industrial/fanuc_experimental Aug 30, 2016

Open

Fix namespace of params for trajectory_execution #24

@130s 130s changed the title from Indigo Release to Initial Indigo release from ros-planning/moveit repo Sep 2, 2016

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Sep 2, 2016

Member

Might be a little early to discuss, but because the next release for Indigo will most likely include ABI change, ideally the version number reflects that to show the incompatibility between previous release. Usually AFAIK this is done by incrementing major/minor version.

Should the next Indigo be 0.9.x, and the Kinetic be 0.10.x?

Member

130s commented Sep 2, 2016

Might be a little early to discuss, but because the next release for Indigo will most likely include ABI change, ideally the version number reflects that to show the incompatibility between previous release. Usually AFAIK this is done by incrementing major/minor version.

Should the next Indigo be 0.9.x, and the Kinetic be 0.10.x?

@mikeferguson

This comment has been minimized.

Show comment
Hide comment
@mikeferguson

mikeferguson Sep 2, 2016

Member

It's still < 1.0, so per ROS guidelines, ABI is not guaranteed anyways. I'd say leave it as 0.7.3.

Member

mikeferguson commented Sep 2, 2016

It's still < 1.0, so per ROS guidelines, ABI is not guaranteed anyways. I'd say leave it as 0.7.3.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Sep 2, 2016

Member

In my opinion, this whole "we are not 1.0 yet" point is a huge farce.
MoveIt is one of the biggest promoters of ROS, it has been used by many groups for years but nobody should rely on anything being stable?
Whatever.

I agree with @mikeferguson though, we misuse the version notation anyway. The notation is not meant to support multiple branches of the software as we have them with different ROS distributions, where we make ABI and feature changes within each branch. Thus, I'd just stay with 0.7.3 too.

Member

v4hn commented Sep 2, 2016

In my opinion, this whole "we are not 1.0 yet" point is a huge farce.
MoveIt is one of the biggest promoters of ROS, it has been used by many groups for years but nobody should rely on anything being stable?
Whatever.

I agree with @mikeferguson though, we misuse the version notation anyway. The notation is not meant to support multiple branches of the software as we have them with different ROS distributions, where we make ABI and feature changes within each branch. Thus, I'd just stay with 0.7.3 too.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Sep 2, 2016

Member

From my point of view #121 has been addressed now,
as good as we can and are willing to. I checked the bullet item in the top post.

Member

v4hn commented Sep 2, 2016

From my point of view #121 has been addressed now,
as good as we can and are willing to. I checked the bullet item in the top post.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Sep 2, 2016

Member

#187 is a block too.
We don't want our users to live with unintuitive behavior of the new author-information field in the setup assistant.

Member

v4hn commented Sep 2, 2016

#187 is a block too.
We don't want our users to live with unintuitive behavior of the new author-information field in the setup assistant.

@mikeferguson

This comment has been minimized.

Show comment
Hide comment
@mikeferguson

mikeferguson Sep 2, 2016

Member

@v4hn -- the thing about 1.0 is that you've reached a point where (A) APIs have gone a complete review process and (B) the system is fairly stable and bug-free. We've never actually done an extensive review of the APIs, yes, we've reviewed things here and there along the way, but not in the way that ros_comm or navigation stack did when they approached 1.0. Since there is a very limited amount of unit/functional testing in the moveit codebase, we are also consistently finding bugs, many of which actually impact API/ABI.

I didn't suggest that "nobody should depend on anything be stable" -- I think the line we are walking right now, that we're only breaking the API/ABI for those cases where it is needed to fix bugs makes sense, but does not warrant changing the version number every time, since we would also have to bump jade/kinetic to make it clear that they are "newer"

And at some point, we really should do a 1.0 review early enough to bump a future version to 1.0, while fixing some of the deficiencies of the API (there have been a number raised over time that have not be fixed because of the difficulty of having those breaks)

Member

mikeferguson commented Sep 2, 2016

@v4hn -- the thing about 1.0 is that you've reached a point where (A) APIs have gone a complete review process and (B) the system is fairly stable and bug-free. We've never actually done an extensive review of the APIs, yes, we've reviewed things here and there along the way, but not in the way that ros_comm or navigation stack did when they approached 1.0. Since there is a very limited amount of unit/functional testing in the moveit codebase, we are also consistently finding bugs, many of which actually impact API/ABI.

I didn't suggest that "nobody should depend on anything be stable" -- I think the line we are walking right now, that we're only breaking the API/ABI for those cases where it is needed to fix bugs makes sense, but does not warrant changing the version number every time, since we would also have to bump jade/kinetic to make it clear that they are "newer"

And at some point, we really should do a 1.0 review early enough to bump a future version to 1.0, while fixing some of the deficiencies of the API (there have been a number raised over time that have not be fixed because of the difficulty of having those breaks)

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Sep 8, 2016

Member

Bumping minor version would make 0.8.x, which is taken by Jade release series.

Is it really a requirement that each branch have different version numbers? Does bloom not work otherwise?

We really should do a 1.0 review early enough to bump a future version to 1.0, while fixing some of the deficiencies of the API

I have long been a fan of the Gazebo approach to breaking API - do not be afraid to increment major versions when necessary, but be strict about only breaking API between major versions. Between ROS Indigo and Jade, Gazebo released 2.2, 3.0, 4.0, and 4.0 (cite @scpeters).

I would prefer we head in the direction of releasing 1.0 so that we can begin making bigger breaking changes in 2.0. I have a hard time picturing what a 1.0 review would look like that - MoveIt! is so large and its use cases so varied that I'm not sure who could go through and say what needs to be changed, and who has those resources. Though I do personally have strong opinions about rewriting KinematicsBase and the the MotionPlanningPlugins pipeline, those changes are better targeted at 2.0 IMHO. In other words, I think we're basically already at 1.0 - we could just call that the Kinetic release.

Member

davetcoleman commented Sep 8, 2016

Bumping minor version would make 0.8.x, which is taken by Jade release series.

Is it really a requirement that each branch have different version numbers? Does bloom not work otherwise?

We really should do a 1.0 review early enough to bump a future version to 1.0, while fixing some of the deficiencies of the API

I have long been a fan of the Gazebo approach to breaking API - do not be afraid to increment major versions when necessary, but be strict about only breaking API between major versions. Between ROS Indigo and Jade, Gazebo released 2.2, 3.0, 4.0, and 4.0 (cite @scpeters).

I would prefer we head in the direction of releasing 1.0 so that we can begin making bigger breaking changes in 2.0. I have a hard time picturing what a 1.0 review would look like that - MoveIt! is so large and its use cases so varied that I'm not sure who could go through and say what needs to be changed, and who has those resources. Though I do personally have strong opinions about rewriting KinematicsBase and the the MotionPlanningPlugins pipeline, those changes are better targeted at 2.0 IMHO. In other words, I think we're basically already at 1.0 - we could just call that the Kinetic release.

@mikeferguson

This comment has been minimized.

Show comment
Hide comment
@mikeferguson

mikeferguson Sep 8, 2016

Member

Is it really a requirement that each branch have different version numbers? Does bloom not work otherwise?

Yep -- very much a requirement.

Member

mikeferguson commented Sep 8, 2016

Is it really a requirement that each branch have different version numbers? Does bloom not work otherwise?

Yep -- very much a requirement.

@davetcoleman davetcoleman referenced this issue in ros-planning/srdfdom Sep 9, 2016

Closed

Change rosdistro for srdfdom in kinetic #20

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Sep 9, 2016

Member

Is it really a requirement that each branch have different version numbers? Does bloom not work otherwise?

Yep -- very much a requirement.

I'm not aware that it's a requirement but here's what I figured personally.

It would be difficult to keep track of which version is made from which branch, if multiple releases are made from multiple different branches using the same version scheme (e.g. same major & minor version). For instance, following could happen: 0.0.1 is for indigo-devel, 0.0.2 is for kinetic. At the next release round, 0.0.3 is indigo, 0.0.4 is kinetic. It could still be possible but messy.

For the major version we can discuss in the next maintainer mtg.

Member

130s commented Sep 9, 2016

Is it really a requirement that each branch have different version numbers? Does bloom not work otherwise?

Yep -- very much a requirement.

I'm not aware that it's a requirement but here's what I figured personally.

It would be difficult to keep track of which version is made from which branch, if multiple releases are made from multiple different branches using the same version scheme (e.g. same major & minor version). For instance, following could happen: 0.0.1 is for indigo-devel, 0.0.2 is for kinetic. At the next release round, 0.0.3 is indigo, 0.0.4 is kinetic. It could still be possible but messy.

For the major version we can discuss in the next maintainer mtg.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Sep 10, 2016

Member
Member

v4hn commented Sep 10, 2016

@davetcoleman davetcoleman referenced this issue Sep 12, 2016

Closed

Kinetic Release #18

19 of 19 tasks complete
@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Sep 19, 2016

Member

I don't understand why #221 is critical for the next indigo release. As far as I can tell we're ready for the next indigo release, whenever @130s has the time.

Member

davetcoleman commented Sep 19, 2016

I don't understand why #221 is critical for the next indigo release. As far as I can tell we're ready for the next indigo release, whenever @130s has the time.

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Sep 21, 2016

Member

I don't understand why #221 is critical for the next indigo release.

@v4hn claimed #100 (comment)

Member

130s commented Sep 21, 2016

I don't understand why #221 is critical for the next indigo release.

@v4hn claimed #100 (comment)

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Sep 21, 2016

Member

@davetcoleman I don't think #221 in particular is required, but we might want to resolve the following issue we have right now:

  • Somebody opens an existing moveit config
  • They have to enter the missing author information because it is mandatory
  • They generate the package's files but do not check .setup_assistant (this is unchecked if they touched the file)
  • next time they have to enter the author information again because it is not stored in .setup_assistant (even if they regenerated package.xml)

@rhaschke's proposed change #221 is much more general and solves this issue as a special case.

Personally, by now I think it would be enough to generate the .setup_assistant unconditionally, although I believe I disagreed with this approach earlier.
All the information currently in that file is loaded on startup, so even if you edited the file by hand it will be regenerated with the edited values.

Member

v4hn commented Sep 21, 2016

@davetcoleman I don't think #221 in particular is required, but we might want to resolve the following issue we have right now:

  • Somebody opens an existing moveit config
  • They have to enter the missing author information because it is mandatory
  • They generate the package's files but do not check .setup_assistant (this is unchecked if they touched the file)
  • next time they have to enter the author information again because it is not stored in .setup_assistant (even if they regenerated package.xml)

@rhaschke's proposed change #221 is much more general and solves this issue as a special case.

Personally, by now I think it would be enough to generate the .setup_assistant unconditionally, although I believe I disagreed with this approach earlier.
All the information currently in that file is loaded on startup, so even if you edited the file by hand it will be regenerated with the edited values.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Sep 21, 2016

Member

w.r.t. the indigo release: I would like to see the following requests merged before releasing.

  • #188 (minor safety check)
  • #148 (streamline the ApplyPlanningScene service)
  • #144 (I know I know, I'm sorry, it's on the top of my list, right after sorting out my personal life)
    If someone wants to move this forward they can look into how #201 relates to this change. This bug report seems to be the exact thing we don't want with an indigo release
  • possibly #42 to make some long-time MoveIt users happy :)

Also because we very recently merged #63 and hopefully merge #144 we definitely need at least a week for testing before we release.

Member

v4hn commented Sep 21, 2016

w.r.t. the indigo release: I would like to see the following requests merged before releasing.

  • #188 (minor safety check)
  • #148 (streamline the ApplyPlanningScene service)
  • #144 (I know I know, I'm sorry, it's on the top of my list, right after sorting out my personal life)
    If someone wants to move this forward they can look into how #201 relates to this change. This bug report seems to be the exact thing we don't want with an indigo release
  • possibly #42 to make some long-time MoveIt users happy :)

Also because we very recently merged #63 and hopefully merge #144 we definitely need at least a week for testing before we release.

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Sep 21, 2016

Member

...#42 is def. not high priority in my mind. If we keep hoping for all new PRs to be merged in we won't ever get a release out. Its been a full 3 months, new features can always get in next month.

Member

davetcoleman commented Sep 21, 2016

...#42 is def. not high priority in my mind. If we keep hoping for all new PRs to be merged in we won't ever get a release out. Its been a full 3 months, new features can always get in next month.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Sep 21, 2016

Member

...#42 is def. not high priority in my mind.

No it's not, that's why I prepended "possibly". It's just not much work either. :)

If we keep hoping for all new PRs to be merged in we won't ever get a release out. Its been a full 3 months, new features can always get in next month.

I agree. If you're fine with having another indigo-release without the ExecuteTrajectory Action Server, #144 could stay out of the release too.

The point about time for testing remains.

Also you and @rhaschke noticed a flaky test (that has likely been there for a long time and succeeded as false-positive before, but I didn't check).
Now #232 is proposed again. This will break ABI changes again. So if we leave this out of the next indigo-release (where we break ABI in multiple places anyway for safety reasons), then I would like to have sonames in the next release so that we can mark new ABI changes afterwards.
This release should definitely be the last time we need to send mails out to users to tell them that they have to recompile their code or weird things might happen.

Member

v4hn commented Sep 21, 2016

...#42 is def. not high priority in my mind.

No it's not, that's why I prepended "possibly". It's just not much work either. :)

If we keep hoping for all new PRs to be merged in we won't ever get a release out. Its been a full 3 months, new features can always get in next month.

I agree. If you're fine with having another indigo-release without the ExecuteTrajectory Action Server, #144 could stay out of the release too.

The point about time for testing remains.

Also you and @rhaschke noticed a flaky test (that has likely been there for a long time and succeeded as false-positive before, but I didn't check).
Now #232 is proposed again. This will break ABI changes again. So if we leave this out of the next indigo-release (where we break ABI in multiple places anyway for safety reasons), then I would like to have sonames in the next release so that we can mark new ABI changes afterwards.
This release should definitely be the last time we need to send mails out to users to tell them that they have to recompile their code or weird things might happen.

@rhaschke

This comment has been minimized.

Show comment
Hide comment
@rhaschke

rhaschke Sep 22, 2016

Contributor

I think #232 should be considered for the release. Having the new trajectory validation in place (#63), user might be annoyed if execution fails because planning in first place didn't use an up-to-date robot state for the starting pose. #232 was started to review here, but was depending on #63, which is now merged.

Contributor

rhaschke commented Sep 22, 2016

I think #232 should be considered for the release. Having the new trajectory validation in place (#63), user might be annoyed if execution fails because planning in first place didn't use an up-to-date robot state for the starting pose. #232 was started to review here, but was depending on #63, which is now merged.

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Sep 22, 2016

Member

I'm not disagreeing with anything, just wanted to give an input. Just to be clear with a risk of being pedantic, making a release:

  • by itself does not necessarily get the released stuff out to the users (it's what they call "public sync" when normal users will have an access to the released software).
  • does allow users to access the binary via a proving ground so-called shadow-repo.
    • I want a name for this period for the convenience. Maybe "shadow-time" (in contrast to soak time)?

That said, now that Indigo public sync cycle just got kicked off, which means sync can happen within a week as announced, we either make a release NOW and ask to push forward the sync (for a few or more days), or wait for the next sync cycle.

Member

130s commented Sep 22, 2016

I'm not disagreeing with anything, just wanted to give an input. Just to be clear with a risk of being pedantic, making a release:

  • by itself does not necessarily get the released stuff out to the users (it's what they call "public sync" when normal users will have an access to the released software).
  • does allow users to access the binary via a proving ground so-called shadow-repo.
    • I want a name for this period for the convenience. Maybe "shadow-time" (in contrast to soak time)?

That said, now that Indigo public sync cycle just got kicked off, which means sync can happen within a week as announced, we either make a release NOW and ask to push forward the sync (for a few or more days), or wait for the next sync cycle.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Sep 22, 2016

Member

That's a really good point! I didn't consider shadow-time.
This is because I indeed tend to consider the release as "get the released stuff out to the users".
Directly after the release happened rosinstall_generator <package> will return the new version, right?
Thus, shadow-time only influences the deb packages provided by osrf.
Everyone who directly uses rosinstall (possibly not using Ubuntu) will circumvent the shadow-time.

I know it's lame, was planned differently earlier, and I would like to have more releases too, but I would like to release after the next sync.
Also with consideration to #232 and the resulting ABI breakage.
As @rhaschke stated above, #63 provides the safety mechanism for a problem with the plan/execute API, but it does not resolve the problem itself. #232 tries to resolve this, so this is worth waiting imo.

Member

v4hn commented Sep 22, 2016

That's a really good point! I didn't consider shadow-time.
This is because I indeed tend to consider the release as "get the released stuff out to the users".
Directly after the release happened rosinstall_generator <package> will return the new version, right?
Thus, shadow-time only influences the deb packages provided by osrf.
Everyone who directly uses rosinstall (possibly not using Ubuntu) will circumvent the shadow-time.

I know it's lame, was planned differently earlier, and I would like to have more releases too, but I would like to release after the next sync.
Also with consideration to #232 and the resulting ABI breakage.
As @rhaschke stated above, #63 provides the safety mechanism for a problem with the plan/execute API, but it does not resolve the problem itself. #232 tries to resolve this, so this is worth waiting imo.

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Sep 22, 2016

Member

Directly after the release happened rosinstall_generator will return the new version, right?
Thus, shadow-time only influences the deb packages provided by osrf.

Oh yeah, correct. My comment in #100 (comment) only applies to binary built on ros buildfarm.

Member

130s commented Sep 22, 2016

Directly after the release happened rosinstall_generator will return the new version, right?
Thus, shadow-time only influences the deb packages provided by osrf.

Oh yeah, correct. My comment in #100 (comment) only applies to binary built on ros buildfarm.

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Sep 22, 2016

Member

I'm not sure where the best place to note this is, but just wanted to point out that for the next release moveit_robots has been split from master to two branches indigo|kinetic-devel and bloom will need to be updated

Member

davetcoleman commented Sep 22, 2016

I'm not sure where the best place to note this is, but just wanted to point out that for the next release moveit_robots has been split from master to two branches indigo|kinetic-devel and bloom will need to be updated

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Oct 9, 2016

Member

#273 is relevant for the indigo release too.

Member

v4hn commented Oct 9, 2016

#273 is relevant for the indigo release too.

@rhaschke

This comment has been minimized.

Show comment
Hide comment
@rhaschke

rhaschke Oct 14, 2016

Contributor

#273 is relevant for the indigo release too.

I would not introduce SO names into Indigo. This is a LTS release.

Contributor

rhaschke commented Oct 14, 2016

#273 is relevant for the indigo release too.

I would not introduce SO names into Indigo. This is a LTS release.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Oct 16, 2016

Member

On Fri, Oct 14, 2016 at 08:29:34AM -0700, Robert Haschke wrote:

I would not introduce SO names into Indigo.
This is a LTS release.

What is your reasoning for this?
We break (broke) ABI in indigo.
If we'll see another indigo release after this one (I suppose we will), we will likely break ABI again.
If we don't add SONAMES in the indigo branch, this would mean we will silently break user setups again.

This is why I consider it relevant for the next indigo release.

Member

v4hn commented Oct 16, 2016

On Fri, Oct 14, 2016 at 08:29:34AM -0700, Robert Haschke wrote:

I would not introduce SO names into Indigo.
This is a LTS release.

What is your reasoning for this?
We break (broke) ABI in indigo.
If we'll see another indigo release after this one (I suppose we will), we will likely break ABI again.
If we don't add SONAMES in the indigo branch, this would mean we will silently break user setups again.

This is why I consider it relevant for the next indigo release.

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Oct 16, 2016

Member

It seems we are assuming sonames are a mission-critical feature, but I think we've lost perspective that most (all?) of ROS does not use them, MoveIt! has never used them, and we've always just broken ABI. Its not the worse thing in the world to run a single command to rebuild the work space, if you are building from source you are probably a developer so are probably already doing that.

But of course sonames are nice to have.

Member

davetcoleman commented Oct 16, 2016

It seems we are assuming sonames are a mission-critical feature, but I think we've lost perspective that most (all?) of ROS does not use them, MoveIt! has never used them, and we've always just broken ABI. Its not the worse thing in the world to run a single command to rebuild the work space, if you are building from source you are probably a developer so are probably already doing that.

But of course sonames are nice to have.

@jspricke

This comment has been minimized.

Show comment
Hide comment
@jspricke

jspricke Oct 17, 2016

Contributor

They are surely not mission-critical, but adding them makes breaking the API explicit which is really nice. +1 for adding them.

Contributor

jspricke commented Oct 17, 2016

They are surely not mission-critical, but adding them makes breaking the API explicit which is really nice. +1 for adding them.

@rhaschke

This comment has been minimized.

Show comment
Hide comment
@rhaschke

rhaschke Oct 17, 2016

Contributor

Introducing sonames is a fundamental change to the way we deploy libs. I do see the motivation for this. But as Dave said, ROS users are not necessarily used to it. Hence, I would vote to not introduce this change in Indigo (in the middle of an existing release). Doing it in Kinetic, users are transitioning anyway, and thus do expect such changes. I think, that we tried to keep the ABI changes in Indigo as small as possible, so that normal users will not even notice. However, introducing sonames, will definitely break their existing installation from now to then.

Contributor

rhaschke commented Oct 17, 2016

Introducing sonames is a fundamental change to the way we deploy libs. I do see the motivation for this. But as Dave said, ROS users are not necessarily used to it. Hence, I would vote to not introduce this change in Indigo (in the middle of an existing release). Doing it in Kinetic, users are transitioning anyway, and thus do expect such changes. I think, that we tried to keep the ABI changes in Indigo as small as possible, so that normal users will not even notice. However, introducing sonames, will definitely break their existing installation from now to then.

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Oct 17, 2016

Member

I don't have a strong opinion on merging this into indigo either way, I just wanted to point out we were assuming sonames were too big a deal.

will definitely break their existing installation from now to then.

When you say it will "break", is the fix to simply run catkin build on the whole indigo work space again?

Member

davetcoleman commented Oct 17, 2016

I don't have a strong opinion on merging this into indigo either way, I just wanted to point out we were assuming sonames were too big a deal.

will definitely break their existing installation from now to then.

When you say it will "break", is the fix to simply run catkin build on the whole indigo work space again?

130s added a commit that referenced this issue Oct 19, 2016

Version down for release preparation (we want initial Kinetic release…
… to be 0.9.0 #100 but the version is already falsely raised to 0.9.3 without any reason.)

130s added a commit to 130s/moveit-2 that referenced this issue Oct 21, 2016

Squashed commits: See ros-planning#18 (comment) The messages from eac…
…h commit follow:

Version down for release preparation (we want initial Kinetic release to be 0.9.0 ros-planning#100 but the version is already falsely raised to 0.9.3 without any reason.)

More version down for release preparation to consolidate version of to-be released packages (addition to ros-planning@56a3c6f)

More version consolidattion for all package.xml in the moveit repo (addition to ros-planning@4d66734. Seems like catkin_prepare_release requires all packages to be in equal version).

0.9.0

More version consolidattion for all package.xml in the moveit repo, which are not even going to be released (addition to ros-planning@fcb8df1).

0.9.1

Version down and consolidattion once again; having an issue with catkin_prepare_release to bump all packages (asked at http://answers.ros.org/question/245969/catkin_prepare_release-not-bumping-packages-in-a-certain-folder).

130s added a commit to 130s/moveit-2 that referenced this issue Oct 21, 2016

Squash unnecessary commits. See ros-planning#18 (comment)
Version down for release preparation (we want initial Kinetic release to be 0.9.0 ros-planning#100 but the version is already falsely raised to 0.9.3 without any reason.)

More version down for release preparation to consolidate version of to-be released packages (addition to ros-planning@56a3c6f)

More version consolidattion for all package.xml in the moveit repo (addition to ros-planning@4d66734. Seems like catkin_prepare_release requires all packages to be in equal version).

0.9.0

More version consolidattion for all package.xml in the moveit repo, which are not even going to be released (addition to ros-planning@fcb8df1).

0.9.1

Version down and consolidattion once again; having an issue with catkin_prepare_release to bump all packages (asked at http://answers.ros.org/question/245969/catkin_prepare_release-not-bumping-packages-in-a-certain-folder).
@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Nov 5, 2016

Member

AFAIK lots of goodies mentioned in the 2nd MoveIt! community mtg are not yet available in Indigo binary, which the majority of ROS-MoveIt! users might be still on. It'd be great if we can move on soon.
Looks like the only blocker is #144.

Member

130s commented Nov 5, 2016

AFAIK lots of goodies mentioned in the 2nd MoveIt! community mtg are not yet available in Indigo binary, which the majority of ROS-MoveIt! users might be still on. It'd be great if we can move on soon.
Looks like the only blocker is #144.

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
Member

davetcoleman commented Nov 5, 2016

+1

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Nov 11, 2016

Member

Looks like the only blocker is #144.

There is still the matter of sonames. If we don't introduce them now in indigo, there's no sense in doing it later on either.

@rhaschke told me that his lab does automatic updates and thus he might end up with a broken workspace one morning even though there might not have been any breaking ABI changes. This is what happens if we change the sonames with each release.

These are the options I see:

  • leave things as they are and don't change ABI. In many cases this means, don't backport changes to indigo anymore.
  • add sonames and bump them with each release. This is what we do with kinetic now and it ignores @rhaschke's use-case.
  • add sonames but track ABI-changes by hand. I'm willing to do that for further releases into indigo.
    Thus we could change ABI and mark breakage, if we can't or don't want to avoid it.
    I don't want to do that with our main development branch (currently kinetic) though.
    Would that be a valid way out @rhaschke ?

that we tried to keep the ABI changes in Indigo as small as possible, so that normal users will not even notice

Just to be clear about this: There is no "as small as possible". If we break ABI we break ABI and this can introduce breakage. MoveIt is really unforgiving with this though, because we don't compile with visibility=hidden. (something we might want to consider in the future)

Member

v4hn commented Nov 11, 2016

Looks like the only blocker is #144.

There is still the matter of sonames. If we don't introduce them now in indigo, there's no sense in doing it later on either.

@rhaschke told me that his lab does automatic updates and thus he might end up with a broken workspace one morning even though there might not have been any breaking ABI changes. This is what happens if we change the sonames with each release.

These are the options I see:

  • leave things as they are and don't change ABI. In many cases this means, don't backport changes to indigo anymore.
  • add sonames and bump them with each release. This is what we do with kinetic now and it ignores @rhaschke's use-case.
  • add sonames but track ABI-changes by hand. I'm willing to do that for further releases into indigo.
    Thus we could change ABI and mark breakage, if we can't or don't want to avoid it.
    I don't want to do that with our main development branch (currently kinetic) though.
    Would that be a valid way out @rhaschke ?

that we tried to keep the ABI changes in Indigo as small as possible, so that normal users will not even notice

Just to be clear about this: There is no "as small as possible". If we break ABI we break ABI and this can introduce breakage. MoveIt is really unforgiving with this though, because we don't compile with visibility=hidden. (something we might want to consider in the future)

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Nov 28, 2016

Member

@rhaschke Would you give us any feedback to the previous post #100 (comment) ?

Member

130s commented Nov 28, 2016

@rhaschke Would you give us any feedback to the previous post #100 (comment) ?

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Nov 29, 2016

Member

I don't have a strong opinion, but I'd vote for "add sonames but track ABI-changes by hand" - seems like the best of both worlds.

Member

davetcoleman commented Nov 29, 2016

I don't have a strong opinion, but I'd vote for "add sonames but track ABI-changes by hand" - seems like the best of both worlds.

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 12, 2016

Member

Indigo release has been stale since 6 months ago. I'm eager to make a release once more before the year ends. Let's move forward with "add sonames but track ABI-changes by hand" option (voted twice so far, while other options with 0 vote).

...but sorry I don't know what to do with that option. @v4hn @davetcoleman ?

Member

130s commented Dec 12, 2016

Indigo release has been stale since 6 months ago. I'm eager to make a release once more before the year ends. Let's move forward with "add sonames but track ABI-changes by hand" option (voted twice so far, while other options with 0 vote).

...but sorry I don't know what to do with that option. @v4hn @davetcoleman ?

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Dec 12, 2016

Member
Member

v4hn commented Dec 12, 2016

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 20, 2016

Member

We're ready to make a release AFAIK. Maintainers please hold changes to indigo-devel before a new release is made.

Member

130s commented Dec 20, 2016

We're ready to make a release AFAIK. Maintainers please hold changes to indigo-devel before a new release is made.

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 21, 2016

Member

Release requested ros/rosdistro#13444

One issue remaining is that I couldn't update changelogs...For some reason catkin_generate_changelog fails like the following. Hoping that once the first release from this moveit repo is done the command would become functional, I rather went ahead made a release.

$ cd ros-planning/moveit
$ catkin_generate_changelog 
Found packages: chomp_motion_planner, moveit, moveit_commander, moveit_controller_manager_example, moveit_core, moveit_experimental, moveit_fake_controller_manager, moveit_kinematics, moveit_planners, moveit_planners_chomp, moveit_planners_ompl, moveit_plugins, moveit_ros, moveit_ros_benchmarks, moveit_ros_benchmarks_gui, moveit_ros_control_interface, moveit_ros_manipulation, moveit_ros_move_group, moveit_ros_perception, moveit_ros_planning, moveit_ros_planning_interface, moveit_ros_robot_interaction, moveit_ros_visualization, moveit_ros_warehouse, moveit_setup_assistant, moveit_simple_controller_manager
Querying commit information since latest tag...
ERROR: Could not fetch latest tag:
fatal: No tags can describe '746dbf9dcc663751e8b2eb3d68b09c080101dcd8'.
Try --always, or create some tags.
$ git describe
fatal: No tags can describe '746dbf9dcc663751e8b2eb3d68b09c080101dcd8'.
Try --always, or create some tags.
$ git tag
0.8.3
0.9.1
0.9.2
0.9.3
Member

130s commented Dec 21, 2016

Release requested ros/rosdistro#13444

One issue remaining is that I couldn't update changelogs...For some reason catkin_generate_changelog fails like the following. Hoping that once the first release from this moveit repo is done the command would become functional, I rather went ahead made a release.

$ cd ros-planning/moveit
$ catkin_generate_changelog 
Found packages: chomp_motion_planner, moveit, moveit_commander, moveit_controller_manager_example, moveit_core, moveit_experimental, moveit_fake_controller_manager, moveit_kinematics, moveit_planners, moveit_planners_chomp, moveit_planners_ompl, moveit_plugins, moveit_ros, moveit_ros_benchmarks, moveit_ros_benchmarks_gui, moveit_ros_control_interface, moveit_ros_manipulation, moveit_ros_move_group, moveit_ros_perception, moveit_ros_planning, moveit_ros_planning_interface, moveit_ros_robot_interaction, moveit_ros_visualization, moveit_ros_warehouse, moveit_setup_assistant, moveit_simple_controller_manager
Querying commit information since latest tag...
ERROR: Could not fetch latest tag:
fatal: No tags can describe '746dbf9dcc663751e8b2eb3d68b09c080101dcd8'.
Try --always, or create some tags.
$ git describe
fatal: No tags can describe '746dbf9dcc663751e8b2eb3d68b09c080101dcd8'.
Try --always, or create some tags.
$ git tag
0.8.3
0.9.1
0.9.2
0.9.3
@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 21, 2016

Member

To make a release request, I had to remove released entries for the packages within this repo ros/rosdistro#13442 because bloom required so.

Problems rise though: At this instantaneous moment, ros/rosdistro#13442 is merged and ros/rosdistro#13444 is not yet merged. Thus there are no entries for the packages in this repo so that rosdep can fail so does apt-get install ros-indigo-moveit-X (X can be any name of those packages).

There still seem to be DEBS built previously on repositories.ros.org (e.g. moveit_core). So the issue is the missing entries in rosdistro.

As soon as ros/rosdistro#13444 gets merged and binaries are built, those packages should become available again. I don't know though if public sync is necessary for those who use public repo to be able to obtain moveit-X debs again.

At this moment I'm not sure the impact of this (I haven't seen any users yelling on answers yet) so will wait for ros/rosdistro#13444 to be merged.

@tfoote @dirk-thomas if you have any suggestion to shorten the "downtime" for MoveIt! indigo debs, please let us know.

I apologize for any inconvenience due to my hasty release action.

Future note for replacing rosdistro entry
Maybe I should've replaced the entry within a single commit, instead of opening 2 different PRs where one to remove the current entries and the other to add new entry. This way the entry for the existing packages (e.g. moveit_core) would have never been gone from rosdistro.

Member

130s commented Dec 21, 2016

To make a release request, I had to remove released entries for the packages within this repo ros/rosdistro#13442 because bloom required so.

Problems rise though: At this instantaneous moment, ros/rosdistro#13442 is merged and ros/rosdistro#13444 is not yet merged. Thus there are no entries for the packages in this repo so that rosdep can fail so does apt-get install ros-indigo-moveit-X (X can be any name of those packages).

There still seem to be DEBS built previously on repositories.ros.org (e.g. moveit_core). So the issue is the missing entries in rosdistro.

As soon as ros/rosdistro#13444 gets merged and binaries are built, those packages should become available again. I don't know though if public sync is necessary for those who use public repo to be able to obtain moveit-X debs again.

At this moment I'm not sure the impact of this (I haven't seen any users yelling on answers yet) so will wait for ros/rosdistro#13444 to be merged.

@tfoote @dirk-thomas if you have any suggestion to shorten the "downtime" for MoveIt! indigo debs, please let us know.

I apologize for any inconvenience due to my hasty release action.

Future note for replacing rosdistro entry
Maybe I should've replaced the entry within a single commit, instead of opening 2 different PRs where one to remove the current entries and the other to add new entry. This way the entry for the existing packages (e.g. moveit_core) would have never been gone from rosdistro.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Dec 21, 2016

Member
Member

v4hn commented Dec 21, 2016

@ipa-mdl

This comment has been minimized.

Show comment
Hide comment
@ipa-mdl

ipa-mdl Dec 21, 2016

Contributor

Something did break.
For some reason http://build.ros.org/ seems to be down.
http://repositories.ros.org/status_page/ros_indigo_default.html (from 7 hours ago) does not list moveit packages anymore.

Not sure if this was just bad timing ;)

Travis jobs start to fail..
Examples:
https://travis-ci.org/ros-industrial/industrial_ci/jobs/185750071
https://travis-ci.org/ipa320/cob_robots/builds/185693319

Contributor

ipa-mdl commented Dec 21, 2016

Something did break.
For some reason http://build.ros.org/ seems to be down.
http://repositories.ros.org/status_page/ros_indigo_default.html (from 7 hours ago) does not list moveit packages anymore.

Not sure if this was just bad timing ;)

Travis jobs start to fail..
Examples:
https://travis-ci.org/ros-industrial/industrial_ci/jobs/185750071
https://travis-ci.org/ipa320/cob_robots/builds/185693319

@dirk-thomas

This comment has been minimized.

Show comment
Hide comment
@dirk-thomas

dirk-thomas Dec 21, 2016

Contributor

@130s As mentioned by others before: making the changes in a single PR avoids the in between state.

@ipa-mdl The Jenkins master hanging is unfortunate but unrelated to any user actions. Jenkins memory usage simply increases over time for such a large scale deployment and at some point hits the wall. While we are trying to improve things over time it still happens every now and then. I have restarted the master and it should pick up the backlog of jobs.

Contributor

dirk-thomas commented Dec 21, 2016

@130s As mentioned by others before: making the changes in a single PR avoids the in between state.

@ipa-mdl The Jenkins master hanging is unfortunate but unrelated to any user actions. Jenkins memory usage simply increases over time for such a large scale deployment and at some point hits the wall. While we are trying to improve things over time it still happens every now and then. I have restarted the master and it should pick up the backlog of jobs.

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Dec 21, 2016

Member

Ok, I've looked through the logs of abi-compliance-checker between the previous release and current head.

There are two clear ABI breaks, but we agreed to allow them earlier.
One is ros-planning/moveit_core#295, the other is #223.
Both are not nice and we should tell users, but they are mostly used internally and the benefits outweigh the breakage.

I believe rather few users have code that plans with both Joint & Position/Orientation constraints around (it's horribly slow and unreliable due to rejection sampling), and it was actually broke before, but with #188 it does not "seem to work but is horribly slow" anymore, but instead prints a lot of red lines saying

IKConstraintSampler received dirty robot state, but valid transforms are required. Failing.

#384 fixes this and I would have liked to see that as part of the release.

Also, I found that the newly resurrected chomp interfaces and the old benchmark_gui fail to install their headers correctly, but that's not too important. We should really get on with getting our build-system lint-free. :)

Member

v4hn commented Dec 21, 2016

Ok, I've looked through the logs of abi-compliance-checker between the previous release and current head.

There are two clear ABI breaks, but we agreed to allow them earlier.
One is ros-planning/moveit_core#295, the other is #223.
Both are not nice and we should tell users, but they are mostly used internally and the benefits outweigh the breakage.

I believe rather few users have code that plans with both Joint & Position/Orientation constraints around (it's horribly slow and unreliable due to rejection sampling), and it was actually broke before, but with #188 it does not "seem to work but is horribly slow" anymore, but instead prints a lot of red lines saying

IKConstraintSampler received dirty robot state, but valid transforms are required. Failing.

#384 fixes this and I would have liked to see that as part of the release.

Also, I found that the newly resurrected chomp interfaces and the old benchmark_gui fail to install their headers correctly, but that's not too important. We should really get on with getting our build-system lint-free. :)

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Dec 22, 2016

Member

@130s thanks for working on this, I know the first release from the consolidated repo is tricky

Member

davetcoleman commented Dec 22, 2016

@130s thanks for working on this, I know the first release from the consolidated repo is tricky

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 22, 2016

Member

ros/rosdistro#13458 Released 0.7.4 with fixes #387 merged in. Fingers crossed same as the first Jade and Kinetic release from this consolidated repo...

Prerelease test for Trusty passed. For Saucy it failed at the very early stage like below, which I don't feel like tracking down now (looks to me like non-moveit issue. And,...Saucy?).

$  generate_prerelease_script.py   https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml indigo default ubuntu saucy amd64   moveit   --level 0   --output-dir ./
:
Step 15 : RUN echo "2016-12-22 (+0000)"
 ---> Using cache
 ---> 8fd50777fea0
Step 16 : RUN for i in 1 2 3; do apt-get update && apt-get install -q -y python3 && apt-get clean && break || sleep 5; done
 ---> Using cache
 ---> be1c966614a4
Step 17 : RUN python3 -u /tmp/wrapper_scripts/apt.py update-install-clean -q -y git python3-apt python3-catkin-pkg python3-empy python3-rosdep python3-rosdistro wget
 ---> Running in b1057f3d962c
/bin/sh: 1: python3: not found
Removing intermediate container b1057f3d962c
The command '/bin/sh -c python3 -u /tmp/wrapper_scripts/apt.py update-install-clean -q -y git python3-apt python3-catkin-pkg python3-empy python3-rosdep python3-rosdistro wget' returned a non-zero code: 127
Member

130s commented Dec 22, 2016

ros/rosdistro#13458 Released 0.7.4 with fixes #387 merged in. Fingers crossed same as the first Jade and Kinetic release from this consolidated repo...

Prerelease test for Trusty passed. For Saucy it failed at the very early stage like below, which I don't feel like tracking down now (looks to me like non-moveit issue. And,...Saucy?).

$  generate_prerelease_script.py   https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml indigo default ubuntu saucy amd64   moveit   --level 0   --output-dir ./
:
Step 15 : RUN echo "2016-12-22 (+0000)"
 ---> Using cache
 ---> 8fd50777fea0
Step 16 : RUN for i in 1 2 3; do apt-get update && apt-get install -q -y python3 && apt-get clean && break || sleep 5; done
 ---> Using cache
 ---> be1c966614a4
Step 17 : RUN python3 -u /tmp/wrapper_scripts/apt.py update-install-clean -q -y git python3-apt python3-catkin-pkg python3-empy python3-rosdep python3-rosdistro wget
 ---> Running in b1057f3d962c
/bin/sh: 1: python3: not found
Removing intermediate container b1057f3d962c
The command '/bin/sh -c python3 -u /tmp/wrapper_scripts/apt.py update-install-clean -q -y git python3-apt python3-catkin-pkg python3-empy python3-rosdep python3-rosdistro wget' returned a non-zero code: 127
@gavanderhoorn

This comment has been minimized.

Show comment
Hide comment
@gavanderhoorn

gavanderhoorn Dec 22, 2016

Member

awesome work @130s

Member

gavanderhoorn commented Dec 22, 2016

awesome work @130s

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 23, 2016

Member

Indigo Trusty 64b build seems to be ready in shadow-fixed http://repositories.ros.org/status_page/ros_indigo_default.html?q=moveit

Member

130s commented Dec 23, 2016

Indigo Trusty 64b build seems to be ready in shadow-fixed http://repositories.ros.org/status_page/ros_indigo_default.html?q=moveit

@gavanderhoorn

This comment has been minimized.

Show comment
Hide comment
@gavanderhoorn

gavanderhoorn Dec 23, 2016

Member

Could this be the first 'victim' of the SONAMES that were added?

Member

gavanderhoorn commented Dec 23, 2016

Could this be the first 'victim' of the SONAMES that were added?

@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Dec 23, 2016

Member
Member

v4hn commented Dec 23, 2016

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 24, 2016

Member

Some packages haven't been built yet for Saucy (again, S.a.u.c.y?) but the last build timestamp (e.g. moveit_ros_planning_interface) seems to be Dec 22, yesterday, so I assume it's just a matter of time before the next build jobs get started by @thesantaclause.
HHD everyone!

Member

130s commented Dec 24, 2016

Some packages haven't been built yet for Saucy (again, S.a.u.c.y?) but the last build timestamp (e.g. moveit_ros_planning_interface) seems to be Dec 22, yesterday, so I assume it's just a matter of time before the next build jobs get started by @thesantaclause.
HHD everyone!

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 24, 2016

Member

Quick update; Saucy build seems to fail for moveit_kinematics. Seems to me there are multiple errors, at

 00:04:03.955   CMake 2.8.12 or higher is required.  You are running version 2.8.11.2

and

00:04:03.964 E: Building failed
00:04:03.967 Traceback (most recent call last):
00:04:03.967   File "/tmp/ros_buildfarm/ros_buildfarm/binarydeb_job.py", line 133, in build_binarydeb
00:04:03.967     subprocess.check_call(cmd, cwd=source_dir)
00:04:03.967   File "/usr/lib/python3.3/subprocess.py", line 547, in check_call
00:04:03.968     raise CalledProcessError(retcode, cmd)
00:04:03.968 subprocess.CalledProcessError: Command '['apt-src', 'build', 'ros-indigo-moveit-kinematics']' returned non-zero exit status 1

(2nd error seems similar from what I got from prerelease test #100 (comment))

http://build.ros.org/view/Ibin_uS64/job/Ibin_uS64__moveit_kinematics__ubuntu_saucy_amd64__binary/4/console

1.1. build binarydeb
:
00:04:03.527 if [ -f "/opt/ros/indigo/setup.sh" ]; then . "/opt/ros/indigo/setup.sh"; fi && \
00:04:03.527 	dh_auto_configure -- \
00:04:03.527 		-DCATKIN_BUILD_BINARY_PACKAGE="1" \
00:04:03.527 		-DCMAKE_INSTALL_PREFIX="/opt/ros/indigo" \
00:04:03.527 		-DCMAKE_PREFIX_PATH="/opt/ros/indigo"
00:04:03.941 	mkdir -p obj-x86_64-linux-gnu
00:04:03.943 	cd obj-x86_64-linux-gnu
00:04:03.943 	cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCATKIN_BUILD_BINARY_PACKAGE=1 -DCMAKE_INSTALL_PREFIX=/opt/ros/indigo -DCMAKE_PREFIX_PATH=/opt/ros/indigo
00:04:03.955 CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
00:04:03.955   CMake 2.8.12 or higher is required.  You are running version 2.8.11.2
00:04:03.955 
00:04:03.955 
00:04:03.956 -- Configuring incomplete, errors occurred!
00:04:03.957 dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCATKIN_BUILD_BINARY_PACKAGE=1 -DCMAKE_INSTALL_PREFIX=/opt/ros/indigo -DCMAKE_PREFIX_PATH=/opt/ros/indigo returned exit code 1
00:04:03.958 make[1]: *** [override_dh_auto_configure] Error 2
00:04:03.958 make[1]: Leaving directory `/tmp/binarydeb/ros-indigo-moveit-kinematics-0.7.4'
00:04:03.961 make: *** [build] Error 2
00:04:03.961 dpkg-buildpackage: error: debian/rules build gave error exit status 2
00:04:03.964 E: Building failed
00:04:03.967 Traceback (most recent call last):
00:04:03.967   File "/tmp/ros_buildfarm/ros_buildfarm/binarydeb_job.py", line 133, in build_binarydeb
00:04:03.967     subprocess.check_call(cmd, cwd=source_dir)
00:04:03.967   File "/usr/lib/python3.3/subprocess.py", line 547, in check_call
00:04:03.968     raise CalledProcessError(retcode, cmd)
00:04:03.968 subprocess.CalledProcessError: Command '['apt-src', 'build', 'ros-indigo-moveit-kinematics']' returned non-zero exit status 1
00:04:03.968 # END SUBSECTION
00:04:03.968 
00:04:03.968 --------------------------------------------------------------------------------------------------
00:04:03.968 `apt-src build ros-indigo-moveit-kinematics` failed.
00:04:03.968 This is usually because of an error building the package.
00:04:03.968 The traceback from this failure (just above) is printed for completeness, but you can ignore it.
00:04:03.968 You should look above `E: Building failed` in the build log for the actual cause of the failure.
00:04:03.968 --------------------------------------------------------------------------------------------------
00:04:04.026 
00:04:05.486 Build step 'Execute shell' marked build as failure
00:04:05.488 [ssh-agent] Stopped.
00:04:05.529 [description-setter] Could not determine description.
00:04:05.565 Sending e-mails to: ros-buildfarm-indigo@googlegroups.com tfoote+buildfarm@osrfoundation.org dave@dav.ee g.a.vanderhoorn@tudelft.nl
00:04:05.619 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
00:04:05.620 Finished: FAILURE
Member

130s commented Dec 24, 2016

Quick update; Saucy build seems to fail for moveit_kinematics. Seems to me there are multiple errors, at

 00:04:03.955   CMake 2.8.12 or higher is required.  You are running version 2.8.11.2

and

00:04:03.964 E: Building failed
00:04:03.967 Traceback (most recent call last):
00:04:03.967   File "/tmp/ros_buildfarm/ros_buildfarm/binarydeb_job.py", line 133, in build_binarydeb
00:04:03.967     subprocess.check_call(cmd, cwd=source_dir)
00:04:03.967   File "/usr/lib/python3.3/subprocess.py", line 547, in check_call
00:04:03.968     raise CalledProcessError(retcode, cmd)
00:04:03.968 subprocess.CalledProcessError: Command '['apt-src', 'build', 'ros-indigo-moveit-kinematics']' returned non-zero exit status 1

(2nd error seems similar from what I got from prerelease test #100 (comment))

http://build.ros.org/view/Ibin_uS64/job/Ibin_uS64__moveit_kinematics__ubuntu_saucy_amd64__binary/4/console

1.1. build binarydeb
:
00:04:03.527 if [ -f "/opt/ros/indigo/setup.sh" ]; then . "/opt/ros/indigo/setup.sh"; fi && \
00:04:03.527 	dh_auto_configure -- \
00:04:03.527 		-DCATKIN_BUILD_BINARY_PACKAGE="1" \
00:04:03.527 		-DCMAKE_INSTALL_PREFIX="/opt/ros/indigo" \
00:04:03.527 		-DCMAKE_PREFIX_PATH="/opt/ros/indigo"
00:04:03.941 	mkdir -p obj-x86_64-linux-gnu
00:04:03.943 	cd obj-x86_64-linux-gnu
00:04:03.943 	cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCATKIN_BUILD_BINARY_PACKAGE=1 -DCMAKE_INSTALL_PREFIX=/opt/ros/indigo -DCMAKE_PREFIX_PATH=/opt/ros/indigo
00:04:03.955 CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
00:04:03.955   CMake 2.8.12 or higher is required.  You are running version 2.8.11.2
00:04:03.955 
00:04:03.955 
00:04:03.956 -- Configuring incomplete, errors occurred!
00:04:03.957 dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCATKIN_BUILD_BINARY_PACKAGE=1 -DCMAKE_INSTALL_PREFIX=/opt/ros/indigo -DCMAKE_PREFIX_PATH=/opt/ros/indigo returned exit code 1
00:04:03.958 make[1]: *** [override_dh_auto_configure] Error 2
00:04:03.958 make[1]: Leaving directory `/tmp/binarydeb/ros-indigo-moveit-kinematics-0.7.4'
00:04:03.961 make: *** [build] Error 2
00:04:03.961 dpkg-buildpackage: error: debian/rules build gave error exit status 2
00:04:03.964 E: Building failed
00:04:03.967 Traceback (most recent call last):
00:04:03.967   File "/tmp/ros_buildfarm/ros_buildfarm/binarydeb_job.py", line 133, in build_binarydeb
00:04:03.967     subprocess.check_call(cmd, cwd=source_dir)
00:04:03.967   File "/usr/lib/python3.3/subprocess.py", line 547, in check_call
00:04:03.968     raise CalledProcessError(retcode, cmd)
00:04:03.968 subprocess.CalledProcessError: Command '['apt-src', 'build', 'ros-indigo-moveit-kinematics']' returned non-zero exit status 1
00:04:03.968 # END SUBSECTION
00:04:03.968 
00:04:03.968 --------------------------------------------------------------------------------------------------
00:04:03.968 `apt-src build ros-indigo-moveit-kinematics` failed.
00:04:03.968 This is usually because of an error building the package.
00:04:03.968 The traceback from this failure (just above) is printed for completeness, but you can ignore it.
00:04:03.968 You should look above `E: Building failed` in the build log for the actual cause of the failure.
00:04:03.968 --------------------------------------------------------------------------------------------------
00:04:04.026 
00:04:05.486 Build step 'Execute shell' marked build as failure
00:04:05.488 [ssh-agent] Stopped.
00:04:05.529 [description-setter] Could not determine description.
00:04:05.565 Sending e-mails to: ros-buildfarm-indigo@googlegroups.com tfoote+buildfarm@osrfoundation.org dave@dav.ee g.a.vanderhoorn@tudelft.nl
00:04:05.619 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
00:04:05.620 Finished: FAILURE
@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 25, 2016

Member

0.7.5 release requested ros/rosdistro#13481

Member

130s commented Dec 25, 2016

0.7.5 release requested ros/rosdistro#13481

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 26, 2016

Member

0.7.5 still fails to build on buildfarm for Saucy but only moveit_setup_assistant. Hope #389 fixes it.

Member

130s commented Dec 26, 2016

0.7.5 still fails to build on buildfarm for Saucy but only moveit_setup_assistant. Hope #389 fixes it.

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 27, 2016

Member

From #389 (comment) by @v4hn

Didn't we discuss Saucy-support before in some thread?

We did for Wily for Kinetic but I can't remember for Saucy.
I asked on answers if there's a way to make a release ignoring EOL distros.

Member

130s commented Dec 27, 2016

From #389 (comment) by @v4hn

Didn't we discuss Saucy-support before in some thread?

We did for Wily for Kinetic but I can't remember for Saucy.
I asked on answers if there's a way to make a release ignoring EOL distros.

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Dec 28, 2016

Member

This is the same discussion as https://discourse.ros.org/t/drop-support-for-wily/727 - @tfoote already explained what is holding back discontinuation, though I don't 100% understand why a workaround can't be found.

Member

davetcoleman commented Dec 28, 2016

This is the same discussion as https://discourse.ros.org/t/drop-support-for-wily/727 - @tfoote already explained what is holding back discontinuation, though I don't 100% understand why a workaround can't be found.

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 29, 2016

Member

A sync is planned to happen soon. If we can't make a new successful release by then, I assume the following will happen:

  • packages that are already successfully built on buildfarm will be synced.
  • failing packages that have already been successfully released before (ie. moveit_setup_assistant) remain as older version.
  • failing packages that have never been released (ie. moveit) won't be synced.

I guess the above is fine (not ideal though) but if not then please leave comments in the linked discussion.

Member

130s commented Dec 29, 2016

A sync is planned to happen soon. If we can't make a new successful release by then, I assume the following will happen:

  • packages that are already successfully built on buildfarm will be synced.
  • failing packages that have already been successfully released before (ie. moveit_setup_assistant) remain as older version.
  • failing packages that have never been released (ie. moveit) won't be synced.

I guess the above is fine (not ideal though) but if not then please leave comments in the linked discussion.

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Dec 30, 2016

Member

At last all green after 0.7.6 release ros/rosdistro#13512 !
Still not available in shadow-fixed yet but it will be soon.

Member

130s commented Dec 30, 2016

At last all green after 0.7.6 release ros/rosdistro#13512 !
Still not available in shadow-fixed yet but it will be soon.

@davetcoleman davetcoleman referenced this issue Dec 31, 2016

Closed

Next Release (targeted Jan 2017) #393

3 of 3 tasks complete
@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Jan 3, 2017

Member

Publicly synced. Now you can install ros-indigo-moveit. Thanks all who helped development on this ticket actively/passively!

Member

130s commented Jan 3, 2017

Publicly synced. Now you can install ros-indigo-moveit. Thanks all who helped development on this ticket actively/passively!

@130s 130s closed this Jan 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment