[Rock-dev] Flavours, freezes, updates

[Janosch Machowinski]

Hey,
after reading all of this about snapshots I was wondering,
if going for real releases wouldn't be the better option.
This would cover both working scenarios:
1 : You work on a release. You got the grantee, that only bugfixes will come
in, if you do an autoproj update.  Big plus for me : YOU can decide, when
to upgrade to the next release. ATM this is not the case if you track next
or stable. (would be the case is you snapshot everything).
This would also simplify bug reporting, as for now we don't really know the
'state' in which bugs happen, this is especially true for 'old' bugs.
Another plus, we can say in the Documentation/Tutorials, that they are
valid for version XYZ.
For 2. it is straight forward, just never upgrade to a newer release...

I was wondering, can one overwrite the repository in the overwrites.yml ?
Greetings
     Janosch

Am 24.06.2014 21:09, schrieb 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 <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