[Rock-dev] Flavours, freezes, updates

[Sylvain Joyeux]

I think this discussion is going the wrong way. Instead of looking at the
technical how, we should be looking at the how it is going to be used

Scenario 1: normal development workflow. The goal here is to be able to
rollback to a known working state, and save these states. The states don't
really have a relationship. They are just ways for each developers to save
a known-to-work system so that one can rollback to it.

Scenario 2: prepare a release to customer, or demo. In this case, the goal
is to converge to a working demo. The working system *will* be pinned to
state X at a point in time and then slowly advanced to the point where the
system works.

In my opinion, we should be using tags for (1) since the states have no
relationships between each other. One developer can very well commit a
state that is *older* than a state that already has been pushed, using a
branch is harmful.

However, (2) is a typical branch scenario. The branch is made of a set of
snapshots that allow to progress to a common goal (a working demo / ready
to release system). Happily for us, the branch *is* the currently
checked-out buildconf branch.

To reflect the two different cases, I would think of adding
   autoproj tag -> create a tag with the current state in autoproj/
   autoproj commit -> update the current buildconf to pin the current state
and commit in autoproj/. The workflow is the traditional update, fix bug,
commit

The command that would allow to go back to any saved state
   autoproj rollback -> argument can be a time/date, tag name or commit ID.

The issue of getting back in time when adding a commit ID / tag ID can
easily be fixed in the git importer. We just have to check that all commits
in HEAD are also in the remote branch before we reset the branch. "autoproj
rollback" would then make sure that all packages that have been rolled back
will be rebuilt at the next autoproj build (whether a rebuild or a
force-build, I am not sure).

On Tue, Jun 24, 2014 at 5:51 PM, Steffen Planthaber <Steffen.Planthabt
er at dfki.de <Steffen.Planthaber at dfki.de>> wrote:

> 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.
>
Agreed. An easy one would be to replicate what "git stash" does so that we
are sure of not pushing anything "by mistake".

>   - 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 ;-)
>
The only two files that autoproj snapshot currently modifies is
overrides.yml and manifest. With the idea of adding an overrides.d folder
that I mentioned earlier, we would even not have to modify overrides.yml.
We then add a way to pin the package sets directly in overrides.yml and we
won't have to modify the manifest. In the end, the difference between a
buildconf and a snapshot would be a single (new) file in
autoproj/overrides.d

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140624/490a7ca3/attachment.htm