[Rock-dev] Flavours, freezes, updates

[Jakob Schwendner]

Hey,

some of this stuff has been discussed in "The issue with Rock" thread, but I am
starting a new thread here to maybe try and focus this a little bit. Lets say
this is more a collection of thoughts and maybe I'll come to a conclusion and a
proposal in the end. Lets see. I haven't really been thinking or reading on the
philosophy of rolling releases before, so forgive me if I state some obvious
things.

What we call flavours are really synchronisation points between the different
repos. Each of the three flavours is a moving head. Master moves in small steps,
next and stable move in larger steps. The contract is that packages that are on
the same head work well together and are tested also through the build server.
We don't have version numbers and afaik we don't really use any tags or the like
to pin down specific versions.

The current way of how project work is performed is that some project specific
repos including the buildconf are generated, and the project is started. Lets
call this the entry point for that project. We recommend using the next flavour
for this, because its supposedly more stable than master. Note that stable means
two things in this context. One is that it is less frequently updated, and so
less likely to have build errors introduced, and two that the code has been
around longer and might be less likely to have bugs.

Once the project gets going a number of things happen. The project specific
packages are developed and advance, and the non-project - lets call them rock
packages - advance as well. They introduce new features, resolve bugs, create
new bugs and incompatibilties. This happens on both the project side, and the
rock side. People working on the project will perform frequent autoproj updates,
to get what their coworkers have been working on. They will also get the stuff
their current flavour is tracking. If its master, it could be a compile error
that ruins the checkout just before the demo. This is why we recommend to track
next, because its less likely here.

[Traveler Hauptman]

I don't really have time to join the discussion properly, but I'd like
to say that I have thought about this topic quite a bit in a non-rock
context (but still robotics). We have a large number of repositories
under development, all with external dependencies. Our build system is
built directly on cmake scripts but tries to solve the same set of
problems as autoproj.

I arrived at a similar point as Jakob. Repo heads are easy to think
about and are what developers work with but the only way to provide any
guarantees to a down-stream user is to mark the graph of exact commits
that create a "working" system.

-Traveler

[Sylvain Joyeux]

The major issue with making the "snapshot" workflow is the one of
maintenance. It is IMO a great workflow when you are trying to reach either
a ready-to-deploy state (for a customer) or a demo-ready state, as it
ensures that one controls the state of the global system *and* can
reproduce its installation. At this stage, I personally *also* includes the
repositories from the project developers. I've used that workflow for a
previous project (snapshot each version of the 'demo' code so that I can
reproduce it as-is). One can already do this to a certain level with
existing Rock tooling (more on that later).

During development, the problem is the one of bug reporting / interaction
with the developers. It is simply impractical to assume that the developers
can help you if you might be in any state. Updating to newer code is hell
as well as we really can't make release notes from any state to any state
(i.e. people won't know what they might or might not get if they update)

However, I have the impression that Jakob carefully decided to omit the
word "stable" in his text. Whether it is conscious or not is another
question ;-).
I also want to forget about the broader "Rock" and focus on the Rock core
for now. This is IMO implicitly what Jakob does by separating the "coworker
stuff" from the "rock stuff".

Stable *is* a consistent, released, snapshot of the Rock core code.
Moreover, the release notes are meant to give broad information about
backward compatibility issues. Finally, stable releases are the only point
in time where one can check that e.g. documentation got updated.

What I wanted to acknowledge in the original thread is that 'stable' is a
failure. Everyone is using a mixture of next and master. What I personally
want to achieve is that this stops and that 'stable' becomes the rule
instead of the exception /because/ it is the only place where the core
developers can offer some guarantee to the Rock users. And that I
personally don't want someone come to me with "I have bug X on commit Y".
You use half-released stuff ? It should be your problem. Traveler's last
paragraph

Post by Traveler Hauptman
I arrived at a similar point as Jakob. Repo heads are easy to think
about and are what developers work with but the only way to provide any
guarantees to a down-stream user is to mark the graph of exact commits
that create a "working" system.

'stable' is IMO the only practical way it can be done for both the user and
developer.

That's why I started to talk about separating the development workflow of
rock.core. During the weekend, I started thinking about also dropping
'next' altogether. If noone is using stable, then let's just remove the
intermediary:
- separate rock.core and rock release cycles. Maybe make the non-core Rock
code each maintainer's responsibility. If he does not want to release, then
so be it.
- ensure that any stable version of rock.core can be re-bootstrapped. We
already tag the releases, so it just means that we should also generate an
overrides file that allows someone to get back to any stable version.
Bootstrapping stable would "pin" you to the current release (i.e. you would
not automatically update to the 'new' stable).
- guarantee some backward compatibility in rock.core. This means that
updating to the N+1 stable release of rock.core will not break your code. I
would even go as far as having 6 months to a year without breaking
compatibility or two releases, whichever lasts longer.
- schedule the releases long in advance, and nominate one release manager
(also long in advance) to ensure that we release "often enough", thus
removing being drawn to using master.
- finally acknowledge that master can break your stuff. Meaning that if
you pin master versions, good luck with updating later on (you'll have to
find the "consistent set of commits that allow you to not break your code
while still getting the new features / bugfixes you are looking for".

In order to avoid breakage while we release, an *ephemeral* rc branch will
appear to prepare the release code, run the unit tests and let "edgy"
people try the soon-to-be-released code on their codebase. That would be
part of the release cycle and should not last more than say 3 weeks.
.
Now, from the point of view of project development, I personally really
like the idea of having autoproj automatically maintain a history of the
system's state. This is useful *no matter what* because my coworkers can
also break a demo. I know that Steffen already did some scripts that could
do it in Virgo.

Bottom line:
- we need to have the tooling that supports the "snapshot" workflow Jakob
talks about, if only for RTM or demo situations, so the people that feel so
inclined will be able to test this workflow.
- what we need to do however is to provide an improved "standard" workflow
for new users. I personally think that requiring new users to select
commits is ... "suboptimal".

Sylvain


On Sat, Jun 21, 2014 at 2:20 PM, Traveler Hauptman <traveler.hauptman at iit.it

Post by Traveler Hauptman
I don't really have time to join the discussion properly, but I'd like
to say that I have thought about this topic quite a bit in a non-rock
context (but still robotics). We have a large number of repositories
under development, all with external dependencies. Our build system is
built directly on cmake scripts but tries to solve the same set of
problems as autoproj.
I arrived at a similar point as Jakob. Repo heads are easy to think
about and are what developers work with but the only way to provide any
guarantees to a down-stream user is to mark the graph of exact commits
that create a "working" system.
-Traveler
_______________________________________________
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/20140623/e90a57b7/attachment.htm

[Traveler Hauptman]

On a side note: If you do keep 'next' consider renaming it. As a native
english speaker I assumed that rocks 'master' and 'next' were the
equivalent of 'testing' and 'development' respectively. I assumed that
'next' held the newest, most unstable code. It was only when I stumbled
upon the correct documentation that I understood.

When the structure of the group allows, I remove 'master' from my git
repos. There are too many different git workflows and too many git
tutorials using 'master' written by people that aren't yet experienced
using git. New users to git always seem to be confused that the master
branch is special in some way. Removing it creates a little more
confusion and hand-holding in the beginning for the newbs but prevents
bigger problems down the road. (Though since you are migrating to github
you should adopt their workflow to best use their tools.)

Finally, in my opinion, providing tools for maintaining a distribution
(putting together a large collection of libraries/applications and
selecting versions and build configuration for them so that they all
work together without additional work by the end-user) and providing
development automation tools to support developing a group of
interdependent libraries with multiple source repositories, are
different things. These two things have different work-flows and the
person doing the work has to be in two different mindsets if he is doing
both.


-Traveler

Post by Sylvain Joyeux
That's why I started to talk about separating the development workflow
of rock.core. During the weekend, I started thinking about also
dropping 'next' altogether. If noone is using stable, then let's just

[Sylvain Joyeux]

Post by Traveler Hauptman
Finally, in my opinion, providing tools for maintaining a distribution
(putting together a large collection of libraries/applications and
selecting versions and build configuration for them so that they all work
together without additional work by the end-user) and providing development
automation tools to support developing a group of interdependent libraries
with multiple source repositories, are different things. These two things
have different work-flows and the person doing the work has to be in two
different mindsets if he is doing both.

I do agree that the mindsets are completely different. However, I do think
that the tooling is mostly the same (different ways to use the same
tooling).

But that's not why I am replying in any case.

One issue is the definition of 'end-user'. We have multiple end users ...
1. the Rock core developer. I know that he is not an "end user". But we
are all building robots with rock, so we *are* both using and developing
rock. The workflow should support this, because if it becomes painful for
the Rock core developer, either Rock will die or the core developers will
create a completely different workflow for them, which means that the
workflow other users are supposed to use is not going to be improved /
tested / ...
2. the Rock user, that is robotics engineers / researchers that are using
Rock to develop robots. It means that they are software developers
(usually) and use Rock as a software platform. To me, the best for them is
to get what they are used to: software updates (i) when they want them and
(ii) knowing in advance what would be the effect of the update (a.k.a.
changelog or release notes)
3. the professor (in a research context), or the customer (in an industry
context). What he wants is resp. a always-on demo or a working system. In
both cases, he wants User 2 to be able to reproduce the software deployment
with minimal effort and fix bugs when there are some in a very controlled
way (i.e. with minimal side-effect).

IMO
1. is already served well by the current workflow
2. would be served pretty well by the removal of next, the "pinning" of
the current stable version and the ability to update his stable version
when he wants to (what I propose in the previous email). An even better
improvement would be to finally get the binary packages used in a larger
scale (see P.S.)
3. would require the binary packages (what we would deliver) as well as a
streamlined snapshotting / snapshot update workflow (to prepare the RTM
version). autoproj snapshot already offers most of the functionality -- it
prepares a build conf that mostly guarantees that the current build state
can be reproduced (missing are: gem and package set pinning).

Sylvain

P.S.: on the binary packages: getting them properly tested is really a
conflict between (1) and (2). I currently don't see how I can be a core
developer *and* use the binary packages,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140623/5798cdce/attachment-0001.htm

[Traveler Hauptman]

I think your definition covers the end-users really well. The only thing
I might add as a reminder is that (2) are often in-experienced when they
first start interacting with the software; so documentation, clear but
simple mental models, O&A forums, and other help getting up the learning
curve makes a big difference.

A while ago I had a project where I developed with binary packages
(using archlinux because the packages definition files are so easy).
Code-Compile-Test cycles where done with cmake in-situ (ie without 'make
install'), packages used semantic versioning and were installed from the
package file to the development system for further testing and then
deployed to a repository server when ready for the end-user. Archlinux's
package manager worked really well for this

The negatives included the annoyance of having to engage the package
builder manually and repeatedly, especially for quick or rushed fixes
where mistakes were made (forgetting to update documentation being the
most common one). Since the package build tools usually download and
rebuild from your upstream source rather than taking your local,
currently working build, it just takes extra time to include the
packaging step during rapidly changing development. Needless to say the
build-version number increments fast.

The positive was that distribution was dead simple. Setting up a new
system took almost no effort. The cmake LibConfig.cmake scripts were set
to use under-development libraries in the users source folders before
the system installed ones. So one just compiled the source for the
subset of libraries they were actively changing and everything works as
expected.

The key limitation is that this requires either fixing on an existing
package manager and it's distributions, or trying to overlay your own
package manager over the top. (and the break in development flow when
building packages)

-Traveler

Post by Sylvain Joyeux
One issue is the definition of 'end-user'. We have multiple end users ...
1. the Rock core developer. I know that he is not an "end user". But
we are all building robots with rock, so we *are* both using and
developing rock. The workflow should support this, because if it
becomes painful for the Rock core developer, either Rock will die or
the core developers will create a completely different workflow for
them, which means that the workflow other users are supposed to use is
not going to be improved / tested / ...
2. the Rock user, that is robotics engineers / researchers that are
using Rock to develop robots. It means that they are software
developers (usually) and use Rock as a software platform. To me, the
best for them is to get what they are used to: software updates (i)
when they want them and (ii) knowing in advance what would be the
effect of the update (a.k.a. changelog or release notes)
3. the professor (in a research context), or the customer (in an
industry context). What he wants is resp. a always-on demo or a
working system. In both cases, he wants User 2 to be able to reproduce
the software deployment with minimal effort and fix bugs when there
are some in a very controlled way (i.e. with minimal side-effect).
IMO
1. is already served well by the current workflow
2. would be served pretty well by the removal of next, the "pinning"
of the current stable version and the ability to update his stable
version when he wants to (what I propose in the previous email). An
even better improvement would be to finally get the binary packages
used in a larger scale (see P.S.)
3. would require the binary packages (what we would deliver) as well
as a streamlined snapshotting / snapshot update workflow (to prepare
the RTM version). autoproj snapshot already offers most of the
functionality -- it prepares a build conf that mostly guarantees that
the current build state can be reproduced (missing are: gem and
package set pinning).
Sylvain
P.S.: on the binary packages: getting them properly tested is really a
conflict between (1) and (2). I currently don't see how I can be a
core developer *and* use the binary packages,

[Sylvain Joyeux]

On Mon, Jun 23, 2014 at 5:29 PM, Traveler Hauptman <traveler.hauptman at iit.it

A while ago I had a project where I developed with binary packages (using
archlinux because the packages definition files are so easy).
Code-Compile-Test cycles where done with cmake in-situ (ie without 'make
install'), packages used semantic versioning and were installed from the
package file to the development system for further testing and then
deployed to a repository server when ready for the end-user. Archlinux's
package manager worked really well for this

We're currently aiming for that, by generating OSC-compatible packaging
(currently debian, but could be extended for RPMs or arch) and upload to
the OpenSUSE build service. It looks promising, but what is really missing
IMO is testing. Since OSC allows for local package building as well as
remote ones, I want to try it out this way. It is going to be painful for a
while (much longer builds ...) but I don't see any other way.

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

[Steffen Planthaber]

Hi,

I'm against development in pinned commits for all packages, getting
bugfixes then requires attention on the developer side, monitoring all
the packages for significant updates.

For "user" workflow, increasing the usability of snapshots is, I think,
the better option.

As Sylvain mentioned in a side note, some people (including me) already
had a script to place a snapshot into a git repo to keep track of
snapshot versions, it's like tagging a whole checkout.

I just discussed with some colleagues of the project using the script
and we came up with following proposal:

1. The buildconf (aka: autoproj folder) gets a new branch "snapshots"
2. autoproj snapshot behavior changes to commit (and push?) new
snapshots to that branch and also changing the bootstrap.sh included
there to bootstrap only this snapshot
3. Getting the snapshot branch is possible by downloading the
bootstrap.sh from the desired snapshot (commit of the snapshot branch)
which creates a completely new bootstrap containing the versions of the
snapshot.

Getting a specific snapshot by a new bootstrap is not that bad as it
sounds. Pinned commits require the repo to be deleted and checked out
again anyways.

As far I understood git, checking out a specific commit of the buildconf
(done by the bootstrap.sh of the snapshot), creates a detached head in
the local repository, so it won't be updated, correct?. So the
bootstrapped snapshot won't be updated, even if someone calls "autoproj
update"

This way, several checkouts for different demo states can be
automatically available and can be started "on the fly" without
recompiling. As they have been bootstrapped before and can't be updated

Another idea was to give "autoproj update" additional parameters:
autoproj update snapshot -> get the head of snapshots branch
autoproj update 97f5e016b41a5b657a746feb4a7779e55c68e156 -> get specific
snapshot
But that would require autoproj to handle the rollback (delete and
freshly check out the specific commit) automatically


Best,
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.: [phone]
Zentrale: [phone]
Fax: [phone] (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
-----------------------------------------------------------------------

[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. Moreover,
merging is going to be ... interesting.

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)
- 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.
- 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.

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

[Steffen Planthaber]

Hi,

Post by 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"

Post by Sylvain Joyeux
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).

Post by Sylvain Joyeux
- 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.

Post by Sylvain Joyeux
- 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 ;-)

Post by Sylvain Joyeux
- 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.: [phone]
Zentrale: [phone]
Fax: [phone] (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
-----------------------------------------------------------------------

[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

Post by Steffen Planthaber
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

Post by Steffen Planthaber
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".

Post by Steffen Planthaber
- add an "autoproj commit" command that commits the current state with

Post by Sylvain Joyeux
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

[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

Post by 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
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".

Post by Sylvain Joyeux
- add an "autoproj commit" command that commits the current

state with

Post by Sylvain Joyeux
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

Post by Sylvain Joyeux
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

[Sylvain Joyeux]

On Tue, Jun 24, 2014 at 9:33 PM, Janosch Machowinski <

Post by Janosch Machowinski
Hey,
after reading all of this about snapshots I was wondering,
if going for real releases wouldn't be the better option.

Agreed. We're past this already (I believe).

The issue is not anymore for the rock core code (which, I agree with you,
should have proper releases that people can track), but the rest of the
code, i.e. the project's own code or other packages that are shared across
projects but are not part of rock. For those, you won't have proper
releases, stuff can still break two days before a demo and boom. Once the
demo is passed, it is also important to still be able to replicate the
demo's code and so on. And what about one updates to a new rock release but
notices only a few weeks later that something breaks ?

The other nice side-effect of having a global history is that one can do a
global bisect ... :P

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

[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

Post by 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
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".

Post by Sylvain Joyeux
- add an "autoproj commit" command that commits the current

state with

Post by Sylvain Joyeux
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

Post by Sylvain Joyeux
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: [phone]

Besuchsadresse der Nebengesch?ftstelle:
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Tel.: [phone]
Empfang: [phone]
Fax: [phone]
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

[Sylvain Joyeux]

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


On Wed, Jun 25, 2014 at 8:22 AM, Matthias Goldhoorn <

Post by 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
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

Post by Steffen Planthaber
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

Post by Steffen Planthaber
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".

Post by Steffen Planthaber
- add an "autoproj commit" command that commits the current state with

Post by Sylvain Joyeux
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: [phone]
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Tel.: [phone]
Empfang: [phone]
Fax: [phone]
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

[Jakob Schwendner]

Post by Sylvain Joyeux
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

Just a recap to make sure we understand the same things:
autoproj commit - will take the a snapshot of the package in a buildconf, write the result to a refindex file, and may or may not (detail) call a git commit on the buildconf repo.
autoproj tag - creates a tag on the current buildconf repo? Does this do anything more than calling the git tag? Maybe it would be fine then to just use the git command...

Other than that, as far as I can see we discussed giving up the rolling heads (gg) model and effectively switch to releases (which I totally support). Imho there is also no point really in having a next (or replacement name) branch. They should get differentiable names or version numbers. Hey we could finally have our own release names, all derived from anything rock related. rock-star, rocker-bogie, rock-bottom... the possibilities are endless :)

Cheers,

Jakob

[Steffen Planthaber]

Hi,

Post by Jakob Schwendner

Post by Sylvain Joyeux
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

autoproj commit - will take the a snapshot of the package in a buildconf, write the result to a refindex file, and may or may not (detail) call a git commit on the buildconf repo.
autoproj tag - creates a tag on the current buildconf repo? Does this do anything more than calling the git tag? Maybe it would be fine then to just use the git command...

I think it should be as follows:

autoproj update - writes the local refindex (every time)
autoproj commit - copies the head of the refindex to the buildconf
autoproj tag - in case this is only a git tag: I would combine this with
autoproj commit and create the tag automatically when a autoproj commit
is used


When autoproj update writes the index, users may easily roll back to the
(working) state before the update in case "something broke". For this it
is essential that autoproj update writes the refindex every time.

Using autoproj commit you can opt-out the rolling releases at any time
you wish and on any branch. So we can keep also the rolling releases.
We can still name the states on the stable branch, but to use
"rock-stable" as release name we should rename the branch ;-).

Using the tags you can easily find and reproduce former states of the
software. This is only true for a complete snapshot of all packages, so
it it only useful directly after a autoproj commit. Both can be combined
into a single command.


Best, 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.: [phone]
Zentrale: [phone]
Fax: [phone] (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
-----------------------------------------------------------------------

[Sylvain Joyeux]

Thanks Steffen, your summary is IMO quite accurate.

Using the tags you can easily find and reproduce former states of the

Post by Steffen Planthaber
software. This is only true for a complete snapshot of all packages, so
it it only useful directly after a autoproj commit. Both can be combined
into a single command

They can, but they should not IMO. The same way than git commit and git tag
are two different things, I would keep autoproj commit and autoproj tag
separate. If only to reuse prior knowledge about git.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140701/2ad09bd4/attachment.htm

[Jakob Schwendner]

Hi,

Any ideas on a transition plan for these changes? I guess the autoproj commit feature could be independent from having releases instead of our master/next/stable cycle.

Cheers,

Jakob

-----Original Message-----
From: rock-dev-bounces at dfki.de [mailto:rock-dev-bounces at dfki.de] On
Behalf Of Sylvain Joyeux
Sent: Dienstag, 1. Juli 2014 11:21
To: Steffen Planthaber
Cc: rock-dev at dfki.de
Subject: Re: [Rock-dev] Flavours, freezes, updates
Thanks Steffen, your summary is IMO quite accurate.
Using the tags you can easily find and reproduce former states of the
software. This is only true for a complete snapshot of all packages, so
it it only useful directly after a autoproj commit. Both can be combined
into a single command
They can, but they should not IMO. The same way than git commit and git tag
are two different things, I would keep autoproj commit and autoproj tag
separate. If only to reuse prior knowledge about git.
Sylvain

[Sylvain Joyeux]

Before we have an idea for a transition plan, I would argue that we should
have an implementation plan... As you mention, autoproj commit / autoproj
tag have to be implemented prior to the release management changes.

Here comes the neverending question: who has the time ?

Sylvain


On Thu, Jul 10, 2014 at 10:00 AM, Jakob Schwendner <jakob.schwendner at dfki.de

Post by Jakob Schwendner
Hi,
Any ideas on a transition plan for these changes? I guess the autoproj
commit feature could be independent from having releases instead of our
master/next/stable cycle.
Cheers,
Jakob

-----Original Message-----
From: rock-dev-bounces at dfki.de [mailto:rock-dev-bounces at dfki.de] On
Behalf Of Sylvain Joyeux
Sent: Dienstag, 1. Juli 2014 11:21
To: Steffen Planthaber
Cc: rock-dev at dfki.de
Subject: Re: [Rock-dev] Flavours, freezes, updates
Thanks Steffen, your summary is IMO quite accurate.
Using the tags you can easily find and reproduce former states of

the

software. This is only true for a complete snapshot of all

packages, so

it it only useful directly after a autoproj commit. Both can be combined
into a single command
They can, but they should not IMO. The same way than git commit and git

tag

are two different things, I would keep autoproj commit and autoproj tag
separate. If only to reuse prior knowledge about git.
Sylvain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140710/e629d308/attachment.htm

[Janosch Machowinski]

Thomas started a page on this :
https://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockFlavorsOrReleases

Feel free to add some bullet points
Greetings
Janosch

Post by Sylvain Joyeux
Before we have an idea for a transition plan, I would argue that we
should have an implementation plan... As you mention, autoproj commit
/ autoproj tag have to be implemented prior to the release management
changes.
Here comes the neverending question: who has the time ?
Sylvain
On Thu, Jul 10, 2014 at 10:00 AM, Jakob Schwendner
Hi,
Any ideas on a transition plan for these changes? I guess the
autoproj commit feature could be independent from having releases
instead of our master/next/stable cycle.
Cheers,
Jakob

-----Original Message-----
From: rock-dev-bounces at dfki.de <mailto:rock-dev-bounces at dfki.de>

[mailto:rock-dev-bounces at dfki.de <mailto:rock-dev-bounces at dfki.de>] On

Behalf Of Sylvain Joyeux
Sent: Dienstag, 1. Juli 2014 11:21
To: Steffen Planthaber
Cc: rock-dev at dfki.de <mailto:rock-dev at dfki.de>
Subject: Re: [Rock-dev] Flavours, freezes, updates
Thanks Steffen, your summary is IMO quite accurate.
Using the tags you can easily find and reproduce former

states of the

software. This is only true for a complete snapshot of all

packages, so

it it only useful directly after a autoproj commit. Both

can be

combined
into a single command
They can, but they should not IMO. The same way than git commit

and git tag

are two different things, I would keep autoproj commit and

autoproj tag

separate. If only to reuse prior knowledge about git.
Sylvain

_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik

Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Zentrale: [phone]

Besuchsadresse der Nebengesch?ftstelle:
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Tel.: [phone]
Empfang: [phone]
Fax: [phone]
E-Mail: jmachowinski 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/20140710/f2a5a620/attachment-0001.htm

[Jakob Schwendner]

Post by Janosch Machowinski
https://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockFlavorsOrReleas
es
Feel free to add some bullet points

My understanding was that we have passed this stage, and that we want to
implement it now in two steps.
- update the tooling with the commit feature and the tag feature. Also
probably to update the snapshot with an option to do a real snapshot with
e.g. storing all the sources.
- change our master/next/stable regime to a release regime, and set up the
rules for it.

Post by Janosch Machowinski
Here comes the neverending question: who has the time ?

To me its quite important that we start soon on this. I could try to
implement the autoproj extensions.
Sylvain, could you quickly outline how you set up your environment for
developing on the gems? Checkout the repo, and do a gem install everytime
you do a change?

Cheers,

Jakob

[Sylvain Joyeux]

Post by Jakob Schwendner

Post by Sylvain Joyeux
Here comes the neverending question: who has the time ?

To me its quite important that we start soon on this. I could try to
implement the autoproj extensions.
Sylvain, could you quickly outline how you set up your environment for
developing on the gems? Checkout the repo, and do a gem install everytime
you do a change?

1. add tools/autoproj and tools/autobuild to your manifest.
2. run aup tools/autoproj
3. re-source the env.sh (maybe run autoproj envsh, not sure)

To create a subcommand, add an autoproj-XXXX (e.g. autoproj-commit) to
the bin/ folder. You can have a look at autoproj-snapshot for what you
want to do.

Sylvain