[Rock-dev] Flavours, freezes, updates

[Sylvain Joyeux]

The tags are created on *your project's* buildconf repository.


On Wed, Jun 25, 2014 at 8:22 AM, Matthias Goldhoorn <
matthias.goldhoorn at dfki.de> wrote:

>  Morning,
> I don't get the tag thing...
>
> So each "team" is able to create/add tags to the core rock packages?
> If not, how are the tags are preserved if for e.g. the system crashes or
> needs to be re-installed?
>
> Best,
> Matthias
>
>
>
>
> On 24.06.2014 21:09, Sylvain Joyeux wrote:
>
>  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
>
>
> _______________________________________________
> Rock-dev mailing listRock-dev at dfki.dehttp://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
>
> --
>  Dipl.-Inf. Matthias Goldhoorn
>  Space and Underwater Robotic
>
>  Universität Bremen
>  FB 3 - Mathematik und Informatik
>  AG Robotik
>  Robert-Hooke-Straße 1
>  28359 Bremen, Germany
>
>  Zentrale: +49 421 178 45-6611
>
>  Besuchsadresse der Nebengeschäftstelle:
>  Robert-Hooke-Straße 5
>  28359 Bremen, Germany
>
>  Tel.:    +49 421 178 45-4193
>  Empfang: +49 421 178 45-6600
>
>  Fax:     +49 421 178 45-4150
>
>  E-Mail:  matthias.goldhoorn at informatik.uni-bremen.de
>
>  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140625/51c0846d/attachment-0001.htm