[Rock-dev] Flavours, freezes, updates

[Sylvain Joyeux]

>
> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140623/5798cdce/attachment-0001.htm