<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 27, 2013 at 1:51 PM, Dirk Thomas <span dir="ltr"><<a href="mailto:dthomas@osrfoundation.org" target="_blank">dthomas@osrfoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The branching policy of a ROS package as well as a pure Python package is determined by the maintainer.<br>

For ROS packages there are two common options:<br>
 * creating separate branches for each distro<br>
 * keeping a single master from where a release is made into all distros<br>
 * (or sometimes even a mix: separate branches for Fuerte and Groovy but Hydro uses Groovy since there are no changes between those two)<br></blockquote><div><br class="">That mixture is the usual situation for most packages. Except for a few core ROS packages that really do change for every distro, most ROS packages can and do support multiple distros in the same source. For those packages, I dislike the ${DISTRO}-devel branch naming convention, because it tends to create more branches than necessary, and obscures continuity of implementation.</div>
<div><br></div><div>Normal version control practice works fine for things like this. Development happens in "master" or "trunk", releases are tagged, and other branches are only created for applying fixes to old releases or for new experimental code. Almost every package I currently maintain has a "rosbuild" branch for Electric and Fuerte (maybe released to Groovy also), and a "master" that has been converted to catkin and works with Groovy and Hydro.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">For ROS distro independent releases there is commonly only one master branch.<br>

<br>
rosdoc_lite is a mixture of both.<br>
It needs two different branches for Fuerte (old logic) and Groovy/Hydro (new logic).<br>
The buildfarm checks out the respective branch and uses rosdoc_lite from source (as far as I know).</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Adding the Groovy branch to the Hydro doc.yaml is the right way for this.<br>
Just creating a Hydro branch for the sake of have that name creates unnecessary overhead.<br></blockquote><div><br></div><div>I agree that adding a hydro-devel branch makes no sense. That's why I asked about this in the first place.</div>
<div><br></div><div>Since the groovy-devel version will presumably be around for a long time, I'd like to call it "master". Unless you object, I'll make "master" an identical fork of "groovy-devel", create pull requests to update the many references including jenkins_scripts, then delete or retire "groovy-devel".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I am not sure why rosdoc_lite is at all released as a ROS Debian package.<br>

That decision backdates to the time where Eitan / Wim worked on these tools.<br></blockquote><div><br></div><div>It is released as a Debian because users need to run it. </div><div><br></div><div>Ideally, it should be python-rosdoc-lite and not ros-hydro-rosdoc-lite. I suppose the problem is that it depends on genmsg, which depends on catkin, and both of them would have to become distro-independent, first.</div>
<div><br></div><div>Does that imply that no catkin package can be distro-independent?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
With the EOL of Fuerte coming soon we might want to consider removing the ROS distro specific package, unlisting it from the distro files including doc.<br></blockquote><div><br></div><div>It has no useful API documentation right now. That's unfortunate, since doc packages should be self-documenting. I'll open an issue to write some.</div>
<div><br></div><div>We don't want to remove the release entries until we have a reasonable alternative...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

We could than either release it as a ROS distro agnostic pure Python package and deploy that on the farm using puppet or just keep it as it is and checkout the repo on the farm.<br></blockquote><div><br></div><div>It needs to be released, because users require it. </div>
<div><br></div><div>Pip install is OK up to a point, but we've all been bitten by packages like this that did not get updated when the rest of the Ubuntu repository changed. So, I favor building a pure python-rosdoc-lite Ubuntu package, too. I guess I'll have to learn how to do that.</div>
<div><br></div></div>-- <br> joq
</div></div>