[Rock-dev] Flavours, freezes, updates

[Traveler Hauptman]

I think your definition covers the end-users really well. The only thing 
I might add as a reminder is that (2) are often in-experienced when they 
first start interacting with the software; so documentation, clear but 
simple mental models, O&A forums, and other help getting up the learning 
curve makes a big difference.

A while ago I had a project where I developed with binary packages 
(using archlinux because the packages definition files are so easy). 
Code-Compile-Test cycles where done with cmake in-situ (ie without 'make 
install'), packages used semantic versioning and were installed from the 
package file to the development system for further testing and then 
deployed to a repository server when ready for the end-user. Archlinux's 
package manager worked really well for this

The negatives included the annoyance of having to engage the package 
builder manually and repeatedly, especially for quick or rushed fixes 
where mistakes were made (forgetting to update documentation being the 
most common one). Since the package build tools usually download and 
rebuild from your upstream source rather than taking your local, 
currently working build, it just takes extra time to include the 
packaging step during rapidly changing development. Needless to say the 
build-version number increments fast.

The positive was that distribution was dead simple. Setting up a new 
system took almost no effort. The cmake LibConfig.cmake scripts were set 
to use under-development libraries in the users source folders before 
the system installed ones. So one just compiled the source for the 
subset of libraries they were actively changing and everything works as 
expected.

The key limitation is that this requires either fixing on an existing 
package manager and it's distributions, or trying to overlay your own 
package manager over the top. (and the break in development flow when 
building packages)

-Traveler

On 06/23/2014 04:47 PM, Sylvain Joyeux wrote:
>
> 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,
>