[Rock-dev] Flavours, freezes, updates

[Matthias Goldhoorn]

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 <mailto: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 list
> Rock-dev at dfki.de
> http://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

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140625/ee3fa5f9/attachment.htm