<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote>
<div>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).</div><div><br></div><div>But that's not why I am replying in any case.</div>
<div><br></div><div>One issue is the definition of 'end-user'. We have multiple end users ...</div><div> 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 / ...</div>
<div> 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)</div>
<div> 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).</div>
<div><br></div><div>IMO</div><div> 1. is already served well by the current workflow</div><div> 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.)</div>
<div> 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). </div>
<div><br></div><div>Sylvain </div><div><br></div><div>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,</div>
<div><br></div></div></div></div>