[Rock-dev] Flavours, freezes, updates
Steffen Planthaber
Steffen.Planthaber at dfki.de
Tue Jun 24 17:51:22 CEST 2014
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
-----------------------------------------------------------------------
More information about the Rock-dev
mailing list