REP 140 rollout

[dirk-thomas]

The following tasks are necessary to rollout REP 140 (ros-infrastructure/rep#68):

• add support for package format version 2 as specified in REP 140 ros-infrastructure/catkin_pkg#88 released as 0.2.0 0.2.1
• consider test_depends for dependencies catkin#612
  • use test dependencies for topological order
• add test dependencies to package build dependencies ros-infrastructure/bloom#263 released as 0.5.3
  • since testing is enabled by default the Debian package should contain test dependencies as part of the build dependencies
• consider test dependencies ros-infrastructure/rosdep#318 released as 0.10.27
  • must consider test dependencies in order to satisfy the default behavior with testing being enabled
• consider test dependencies ros-infrastructure/rosinstall_generator#23 released as 0.1.9
  • same as for rosdep
• consider test dependencies ros-infrastructure/rospkg#58 released as 1.0.27
  • consider test dependencies

The following tasks require the modified catkin_pkg to be released:

• consider test dependencies in dependency walker ros-infrastructure/buildfarm#187
  • use test dependencies for dependency walker
• updates for rep 140 ros-infrastructure/jenkins_scripts#70
  • doc jobs must install doc dependencies
  • for dependencies test stuff is considered to be either a build or a run dependency (depending on the package format)

This would be nice-to-have but is not blocking the rollout:

• rosdep / rosinstall_generator, may support a --no-test-dependencies option
  • Option to skip installing test dependencies of packages ros-infrastructure/rosdep#317
  • Add option to skip test dependencies ros-infrastructure/rosinstall_generator#24

The following repos might not require changes?

• rosdistro
• rosdoc_lite

Make some packages use format 2:

• update package manifest to format 2 catkin#619

Documentation:

• wiki pages
  • ...list specific pages...
• catkin doc documentation: separate format1 and format2 how-to pages catkin#440

[jack-oquin]

The whole point of introducing a new package.xml format number was so these changes would only apply to packages specifying <package format="2">.

[dirk-thomas]

All these tools/repos do need to be changed in order to handle packages with format 2.

[wjwwood]

@jack-oquin these tools need to be touched to take advantage of the package version 2 changes. For example, the build farm's doc jobs should install dependencies in the <doc_depend> tag iff the package.xml version is 2. That is an example of a change that we should make which is not required for version 1 to keep working, but that we should make before releasing version 2 so that doc jobs for version 2 will work. These are the kind of changes that are captured here.

Does that make sense?

[jack-oquin]

Yes.

The concept is simple, the devil is in the details.

[wjwwood]

The concept is simple, the devil is in the details.

We know that, and that is why we wanted to the the REP as correct as possible before starting on this work (which is work that we will likely do, because of the nature of the things which are affected), and that's why we are capturing them here and working on them before rolling out version 2.

Do you have a suggestion for how to do it differently (this work or the version 2 specification)? I would genuinely like to know if you would execute this differently or if you have any constructive criticism for this process.

[jack-oquin]

William: I am sorry you feel my comments are not constructive.

Please try to make allowances for distance and latency, and grant the assumption of good faith. My earlier comment was made two days ago and a thousand miles away. At that time, I was worried about changes to format one package semantics due to changes to <test_depend>. I have since learned that they were the result of a bug in the format one implementation, not due to confusion about whether the two formats should be handled separately.

[wjwwood]

William: I am sorry you feel my comments are not constructive.

That's not the case, I was just soliciting for constructive criticism, I didn't mean to imply that previous input wasn't constructive.

That's fine, it just didn't seem to me that you were satisfied with my most recent response about why we need to track these things.

[jack-oquin]

On Mar 17, 2014 3:27 PM, "William Woodall" notifications@github.com wrote:

William: I am sorry you feel my comments are not constructive.

That's not the case, I was just soliciting for constructive criticism, I didn't mean to imply that previous input wasn't constructive.

That's fine, it just didn't seem to me that you were satisfied with my most recent response about why we need to track these things.

That comment was made before your response. No criticism is implied.

[dirk-thomas]

I updated the first comment and referenced several pull requests from there.

@esteve @tfoote @wjwwood Please review them thoroughly in order to catch missing / wrong stuff before we go ahead with it. Please also consider if further code paths require patching which I might have missed.

[dirk-thomas]

Starting the roll out - updating the first comment with the progress...

[dirk-thomas]

Filled ticket against cram_core to address circular dependency: cram-code/cram_core#23

[dirk-thomas]

Update some core packages in Indigo to use package.xml format 2. I will update the list in the first comment.

[jack-oquin]

I am not aware of any required rosdoc_lite changes. Actually resolving <doc_depend> packages will be handled at a higher level, such as the build farm.

[dirk-thomas]

Until someone comments with further wiki pages which need to be updated I will close this ticket.