[Rock-dev] Flavours, freezes, updates

[Steffen Planthaber]

Hi,

Am 24.06.2014 16:51, schrieb Sylvain Joyeux:
> While I like the general workflow very much, I am totally against
> committing automatically to the snapshot branch. If you do so, you are
> actually committing (1) without any message that explains something and
> (2) something that you do not know yet whether it works or not.

Full ack. Calling "autoproj snapshot" here is a manual action AFTER 
someone made the software working. That command could have a -m option 
and default to a "date - time commit message", in case -m was not used

autoproj snapshot -m"visitors demonstation 2014-06-24"

> Moreover, merging is going to be ... interesting.

Instead of "git pull" -> "git fetch && git merge -s ours"
This uses the full local commit, or do I miss something here?
Only to use on the snapshots branch of course.

Merging between buildconf master and a snapshots shouldn't be done at 
all. I don't see a use case here (see example workflow below).


> So, I would update the proposal to:
>   - have the equivalent of a reflog, that is a list of snapshots that
> are *local* to the current user (i.e. not part of any public repository)
> so that *the developer who remembers what he did in the last days* has
> the ability to go back to any state he has seen before in its current
> repository. This is updated automatically by autoproj each time
> 'autoproj update' is executed and can be re-bootstrapped by pointing to
> the source repository while bootstrapping (e.g. autoproj bootstrap
> --snapshot /path/to/original:snapshot_id)

I also like this approach, as one could just revert an autoproj update 
in case it does not compile. But I still like the idea of having all 
build configuration related stuff in one single repository. That makes 
it easier to find certain snapshots or the snapshots at all.


>   - add an "autoproj commit" command that commits the current state with
> a commit message *as a tag* in the repository. This way, there is no
> branch and therefore no problem with merging. Pushing all snapshots
> means doing git push --tags. Of course, autoproj commit would have the
> ability to store any state from the reflog.

I'm assuming "the repository" is the buildconf. Going back to a normal 
state after a snapshot was done, means reverting changes in quite some 
files: overrides.rb, removing local filenames from source.yml for 
import_packages, can't remember more.
As long of course, as there is no special branch for snapshots ;-)

>   - add an "autoproj snapshots" command that presents these tags in
> historical order with commit messages (kind of a git log of history tags)
>   - bootstrapping the right snapshot would be as easy as adding a
> tag=<tagname> to the bootstrap line. The script could be easily
> generated by using the "current" bootstrap.sh as a template.

good ideas.

So the only issue is where to put the snapshots?


For my understanding the buildconf master should always be on HEAD and 
is used to generate snapshots or "fast forward development of core 
components".

Users which don't want frequent updates have following workflow:

1. Use the master buildconf of whatever flavor to get to a working state 
of the software
2. Create a snapshot committed to the snapshots branch (by using 
"autoproj commit?")
3. Switch the buildconf to snapshots branch (to "snapshot mode") 
(autoproj switch-config branch=snapshots)

When updates of software are needed, either
a) Single packages pinned commits are changed to other commits or 
deleted (committed and pushed to snapshots branch)
or
b) Switch the buildconf to master and start over at 1.

This way, the global update can be prepared and checked by a single 
person, which creates a snapshot after everything is working again.

This differs a bit from my previous proposal because in this case the 
head of the snapshots branch is not detached, and will be updated. Users 
may also decide to have certain packages updated on their snapshot 
buildconf, so "snapshots" might not be the best name for this kind of 
"slow moving" or "fixed" branch in the buildconf.


Some projects are already using different buildconf branches (e.g. for 
control laptops and the robot, as the robot don't need GUI Software and 
might missing libraries like X11 or Qt). So the snapshots branch (or 
folders, or whatever) should have a branch prefix, .e.g.:

master <- HEAD
robot <- HEAD
master_snapshots  <- fixed with some on HEAD (developed packages of the 
user himself)
robot_snapshots <- fixed completely


master_snapshots_snapshots <- fixed completely

As I said, "snapshots" is not the best name for this workflow

Steffen

-- 
  Steffen Planthaber
  Weltraumrobotik

  Besuchsadresse der Nebengeschäftstelle:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Postadresse der Hauptgeschäftsstelle Standort Bremen:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4125
  Zentrale: +49 421 178 45-0
  Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
  E-Mail:   Steffen.Planthaber at dfki.de

  Weitere Informationen: http://www.dfki.de/robotik
  -----------------------------------------------------------------------
  Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
  Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
  Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
  (Vorsitzender) Dr. Walter Olthoff
  Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
  Amtsgericht Kaiserslautern, HRB 2313
  Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
  USt-Id.Nr.:    DE 148646973
  Steuernummer:  19/673/0060/3
  -----------------------------------------------------------------------