> > Finally, in my opinion, providing tools for maintaining a distribution > (putting together a large collection of libraries/applications and > selecting versions and build configuration for them so that they all work > together without additional work by the end-user) and providing development > automation tools to support developing a group of interdependent libraries > with multiple source repositories, are different things. These two things > have different work-flows and the person doing the work has to be in two > different mindsets if he is doing both.
I do agree that the mindsets are completely different. However, I do think that the tooling is mostly the same (different ways to use the same tooling). But that's not why I am replying in any case. One issue is the definition of 'end-user'. We have multiple end users ... 1. the Rock core developer. I know that he is not an "end user". But we are all building robots with rock, so we *are* both using and developing rock. The workflow should support this, because if it becomes painful for the Rock core developer, either Rock will die or the core developers will create a completely different workflow for them, which means that the workflow other users are supposed to use is not going to be improved / tested / ... 2. the Rock user, that is robotics engineers / researchers that are using Rock to develop robots. It means that they are software developers (usually) and use Rock as a software platform. To me, the best for them is to get what they are used to: software updates (i) when they want them and (ii) knowing in advance what would be the effect of the update (a.k.a. changelog or release notes) 3. the professor (in a research context), or the customer (in an industry context). What he wants is resp. a always-on demo or a working system. In both cases, he wants User 2 to be able to reproduce the software deployment with minimal effort and fix bugs when there are some in a very controlled way (i.e. with minimal side-effect). IMO 1. is already served well by the current workflow 2. would be served pretty well by the removal of next, the "pinning" of the current stable version and the ability to update his stable version when he wants to (what I propose in the previous email). An even better improvement would be to finally get the binary packages used in a larger scale (see P.S.) 3. would require the binary packages (what we would deliver) as well as a streamlined snapshotting / snapshot update workflow (to prepare the RTM version). autoproj snapshot already offers most of the functionality -- it prepares a build conf that mostly guarantees that the current build state can be reproduced (missing are: gem and package set pinning). Sylvain P.S.: on the binary packages: getting them properly tested is really a conflict between (1) and (2). I currently don't see how I can be a core developer *and* use the binary packages,
_______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
