Open tickets are being serviced with the target of a new release before Electric. 13 tickets have been closed in the last 2 weeks in preparation for the next release. If you would like it to happen sooner patches are welcome. Tully On Wed, Jul 27, 2011 at 2:09 PM, Kevin Watts wrote: > As part of this rosinstall refactoring, are the open tickets on rosinstall > going to be addressed: > > https://code.ros.org/trac/ros/query?component=rosinstall&status=new&status=assigned&status=reopened > > Looks like there are about a dozen defect tickets on rosinstall. > > Is it possible to patch the existing defects in rosinstall during the > Electric Beta? rosinstall has not been released in 4 months according to the > SVN logs. It would be nice to make rosinstall usable, even if we're working > on a replacement. > > Kevin > > > On Mon, Jul 25, 2011 at 2:10 PM, Tully Foote wrote: > >> >> >> On Sun, Jul 24, 2011 at 11:51 AM, Thibault Kruse wrote: >> >>> Even though the thought may be heretic, a possibility to overcome the >>> linguistic difficulty of expressiong >>> >>> rosinstall install xyz >>> >>> is to not call the script rosinstall, but something else. The reference >>> implementation already uses the name "rosenv" for the script, though >>> that was just because I wanted to keep it in sync with original >>> rosinstall with minor patches. >>> >>> Linguistically, I guess is makes sense that an SCM like syntax does not >>> start with something that contains a verb. >>> >>> As an example, take the roscommands, direkt args: >>> >>> roscd >>> rosclean >>> roslaunch >>> rosconfig >>> roslocate >>> ... >>> >>> vs. those with an SCM like syntax: >>> >>> rosbag >>> rosmsg >>> rosnode >>> rospack >>> rosservice >>> ... >>> >>> As you can see those with an SCM like syntax have as name ros + a noun, >>> the others have ros + a verb. >>> So >>> rosinstall would not fit. >>> >>> so maybe we can find a suitable name for a noun of what rosinstall is >>> about. >>> I like rosenv, but maybe others here prefer other solutions, like >>> rosdir, rosws (taken?), roslocal, ... >>> I don't know. >>> >> >> Good point, also we've talked about making rosinstall be ROS independent, >> as it's only actual connection to ROS is the generation of the setup.(ba)sh >> scripts. But renaming to something like "multivcs" or "multiscm" would >> allow us to design the command line syntax w/o needing backwards >> compatability. >> >> And as rosws etc start being integrated we can let them leverage the new >> tool but retain ROS integration through that path. >> >> Also for the check/WTF sanity checks, I think it would be better to write >> a roswtf plugin which would check all those things. It will help keep a >> single debugging tool. And most of that is also ROS specific. >> >> Tully >> >> >>> >>> regards, >>> Thibault >>> >>> >>> On 07/21/2011 08:15 PM, Thibault Kruse wrote: >>> > Thanks Tully for the feedback, >>> > >>> > > The other commands start to get into configuration management >>> > > and although they share a lot of the names of SCM commands >>> > > they actually are noteably different. init, add, remove, apply, >>> > update, check. >>> > >>> > True for all but check. Though bzr check exists, but I'd also go with >>> > rosinstall wtf >>> > >>> > I still think "check" may be useful, providing verbose information for >>> > all that is strange but not dangerous, like >>> > - stacks mentioned in .rosinstall but missing >>> > - stacks in ROS_PACKAGE_PATH after ROS_ROOT >>> > - duplicate URIs >>> > - different .rosinstall and setup.sh >>> > I think all future rosinstall should give warnings on such occasions, >>> > and "check" would be the verbose information about the warnings. >>> > >>> > > And as Dave suggested adding status would be good. >>> > >>> > I will implement the status command. "info" in its current state >>> already >>> > shows a flag modified or not, but as a list of modified files, the >>> > outputs of the scm status commands will have to be post-processed to >>> > give a useful path. >>> > >>> > > Inventing a whole new syntax is something we should not do lightly >>> > especially >>> > > if there's other solutions. Most of the ordering ones can be done >>> > more easily by using an editor >>> > > and cut and paste without learning a new command set. >>> > > The differentiation between init and update is not really required >>> in >>> > this case. >>> > >>> > By now, having the user modify his .rosinstall by hand is what covers >>> > several usecases now anyway in the REP. >>> > The problem with having an scm like syntax and a powerful ubiquitous >>> > command for init/add/merge/apply/update is to find a suitable name for >>> > that command. The word "install" can cover all of those, but >>> "rosinstall >>> > install" looks silly. I also kept thinking of "dwim" (do what I mean). >>> > But that is also non-intuitive. >>> > >>> > The differentiation between init, update, add, apply, merge, is not >>> > technically required, it is merely a usability issue. >>> > >>> > > I would suggest that we take the configuration methods you have >>> layed out >>> > > here and use them in the rosws/rosworkspace discussion which Brian >>> > started. >>> > > And pare down the existing REP 110 draft to be just the SCM >>> commands >>> > status, diff, and info. >>> > >>> > The REP still has to mention the name of the command to use for >>> > init/add/update/apply/merge. >>> > And I see no word in English that would serve the purpose (other than >>> dwim). >>> > >>> > The alternative is to use rosinstall without further command for that, >>> > but then the target directory may not be named after one of the other >>> > commands (or must be "escaped" e.g. as ./diff). >>> > >>> > I also still argue for "regenerate" as a harmless way of updating one's >>> > setup.* files without touching anything else on the filesystem. However >>> > adding a confirmation questions before any change would make that >>> > somewhat obsolete. >>> > >>> > So I still advocate the commands >>> > status >>> > diff >>> > info >>> > snapshot >>> > check/wtf >>> > [regenerate] >>> > >>> > I'll wait for your suggestion, Tully, on how to deal with >>> > init/add/update/merge as an SCM-like command. >>> > >>> > >>> > >>> > On 07/20/2011 08:12 PM, Tully Foote wrote: >>> >> Hi, >>> >> >>> >> I think that the SCM syntax is good. As proposed info and diff are >>> >> good extensions. And as Dave suggested adding status would be good. >>> >> >>> >> snapshot is also probably a better name than --generate-versioned... >>> >> we can add that as an alias. >>> >> >>> >> The other commands start to get into configuration management and >>> >> although they share a lot of the names of SCM commands they actually >>> >> are noteably different. init, add, remove, apply, update, check. >>> >> Inventing a whole new syntax is something we should not do lightly >>> >> especially if there's other solutions. Most of the ordering ones can >>> >> be done more easily by using an editor and cut and paste without >>> >> learning a new command set. The differentiation between init and >>> >> update is not really required in this case. >>> >> >>> >> I would suggest that we take the configuration methods you have layed >>> >> out here and use them in the rosws/rosworkspace discussion which Brian >>> >> started. And pare down the existing REP 110 draft to be just the SCM >>> >> commands status, diff, and info. >>> >> >>> >> Tully >>> > _______________________________________________ >>> > ros-users mailing list >>> > ros-users@code.ros.org >>> > https://code.ros.org/mailman/listinfo/ros-users >>> >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >>> >> >> >> >> -- >> Tully Foote >> Systems Engineer >> Willow Garage, Inc. >> tfoote@willowgarage.com >> (650) 475-2827 >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> >> > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > -- Tully Foote Systems Engineer Willow Garage, Inc. tfoote@willowgarage.com (650) 475-2827