[Rock-dev] Update to master/next/stable

Discussion:

Sylvain Joyeux

2014-09-29 14:47:50 UTC

I've created two pull requests, which will obviously need some testing
... If anyone is interested.

This is basically the option 3 described here:
http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockFlavorsOrReleases/How

https://github.com/rock-core/package_set/pull/12
- makes 'stable' track the rock1408 branch
- makes 'next' an alias for 'stable' (for backward compatibility reasons)

https://github.com/rock-core/rock-package_set/pull/19
- updates the rock package set accordingly

TODO:
- update the post-commit hook to warn people who commit on the stable branch

DIFFERENCES WITH THE ROCK1408 BRANCH
-----------------------------------------------------------------------
I've NOT moved any packages from master to stable (unlike rock1408
which moved all master packages to stable). If these PRs get accepted
into the package set, I'll announce on rock-users that maintainers
will have to request it explicitly. Two exceptions:
base/orogen/interfaces and drivers/velodyne_lidar as they were
dependencies of "released packages".

The non-Rock-branched packages are NOT pinned to a particular commit.
The PR contain the setup code for it, but I need to backport an
autoproj patch to make it work (will do it ASAP).

People using 'stable' will get switched to the new release next time
we release anything. What I want is that we've ironed out the release
process by then and "pin" them transparently before we release.

Sylvain

Sylvain Joyeux

2014-09-29 14:57:11 UTC

Permalink

Another patch that needs to be applied:
https://github.com/rock-core/base-orogen-std/pull/2

Sylvain

Post by Sylvain Joyeux
I've created two pull requests, which will obviously need some testing
... If anyone is interested.
http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockFlavorsOrReleases/How
https://github.com/rock-core/package_set/pull/12
- makes 'stable' track the rock1408 branch
- makes 'next' an alias for 'stable' (for backward compatibility reasons)
https://github.com/rock-core/rock-package_set/pull/19
- updates the rock package set accordingly
- update the post-commit hook to warn people who commit on the stable branch
DIFFERENCES WITH THE ROCK1408 BRANCH
-----------------------------------------------------------------------
I've NOT moved any packages from master to stable (unlike rock1408
which moved all master packages to stable). If these PRs get accepted
into the package set, I'll announce on rock-users that maintainers
base/orogen/interfaces and drivers/velodyne_lidar as they were
dependencies of "released packages".
The non-Rock-branched packages are NOT pinned to a particular commit.
The PR contain the setup code for it, but I need to backport an
autoproj patch to make it work (will do it ASAP).
People using 'stable' will get switched to the new release next time
we release anything. What I want is that we've ironed out the release
process by then and "pin" them transparently before we release.
Sylvain

Raul Dominguez

2014-09-30 13:39:10 UTC

Permalink

A couple of question about the wiki text
(http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockFlavorsOrReleases/How).

First one:

Options 2 and 3 share the same first point in the procedure of making a
release:
"Branch all master branches to the release branch/tag ".

Does this mean that the release is generated from the (at release time)
state of the master branch?
To me, it would make more sense to generate a release from the most
stable and documented code we have (i.e. stable).

Second question:

In option 2 is written:
"Rename the 'stable' flavor to match the release name (supposedly so
that the ROCK_FLAVOR variable becomes the "right" branch)"

Does this mean that the stable branch is replaced by the release branch
right after the release branch was generated from master?
Wouldn't that introduce a lot of untested code in the stable branch
users? What is then with next? I am sure I am misunderstanding this one...

Ra?l

Post by Sylvain Joyeux
https://github.com/rock-core/base-orogen-std/pull/2
Sylvain

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

--
Ra?l Dom?nguez (M.Sc.)
Space Robotics

Besuchsadresse der Nebengesch?ftsstelle:
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.: +49 421 178 45-6617
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: raul.dominguez 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

Janosch Machowinski

2014-09-30 13:51:53 UTC

Permalink

Post by Raul Dominguez
A couple of question about the wiki text
(http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockFlavorsOrReleases/How).
Options 2 and 3 share the same first point in the procedure of making a
"Branch all master branches to the release branch/tag ".
Does this mean that the release is generated from the (at release time)
state of the master branch?
To me, it would make more sense to generate a release from the most
stable and documented code we have (i.e. stable).

Yes, rock1408 was generated from master. What is missing in the description
is the release candidate phase. In this phase the stack was tested. Only
after
there are no known bugs in the release candidate, the release was done.

The goal of this was to have a stable version, which also features a lot
of new features.
The old stable was more than a year behind master...

Post by Raul Dominguez
"Rename the 'stable' flavor to match the release name (supposedly so
that the ROCK_FLAVOR variable becomes the "right" branch)"
Does this mean that the stable branch is replaced by the release branch
right after the release branch was generated from master?

No, see above

Post by Raul Dominguez
Wouldn't that introduce a lot of untested code in the stable branch
users? What is then with next? I am sure I am misunderstanding this one...

Next was dropped.
Greetings
Janosch

Post by Raul Dominguez
Ra?l

Post by Sylvain Joyeux
https://github.com/rock-core/base-orogen-std/pull/2
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: +49 421 178 45-6611

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

Tel.: +49 421 178 45-6614
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: jmachowinski at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

Sylvain Joyeux

2014-09-30 18:50:51 UTC

Permalink

On Tue, Sep 30, 2014 at 10:51 AM, Janosch Machowinski

Post by Janosch Machowinski

Saying that all packages got tested during the RC is preposterous.
It's simply not possible.

Examples ? orogen_metadata was not supposed to end up being released.
base/orogen/interfaces is deprecated (so releasing it does not seem a
super-sane thing to do). auv_control is still "in flux" (I would
definitely not mark it as "release-ready").

Sylvain

Sylvain Joyeux

2014-09-30 19:00:04 UTC

Permalink

Post by Raul Dominguez
Does this mean that the stable branch is replaced by the release branch
right after the release branch was generated from master?
Wouldn't that introduce a lot of untested code in the stable branch
users? What is then with next? I am sure I am misunderstanding this one...

next disappears, that much we all agreed on.

I completely agree with you that only stable code should end up in
stable (and that the so-called "release manager" does not have the
mean to decide what qualifies as "stable"). The rock1408 branches
contain whatever was in master at the time, and I did use the rock1408
branch to avoid too much divergence. What I did not have to do is put
in stable packages that had never been released. IMO, the package
maintainers should be the ones deciding what should be released.

Sylvain

Sylvain Joyeux

2014-10-01 15:10:24 UTC

Permalink

(and that the so-called "release manager" does not have the mean to decide what qualifies as "stable").

Since this sentence seem to have been taken as a personal attack --
which I really did not intend -- here's an explanation:
- a better word for "so-called" here would have been "ill-defined".
The role and power(s) of the person doing the release has never been
defined in the same way than other roles have been defined during the
github migration
(http://rock.opendfki.de/wiki/WikiStart/Standards/RG9). Which is part
of "defining how we do the release".
- I did not mean to single out anybody in this sentence. When I did
the releases, I did not have the means to decide what qualified as
stable. Nobody does for something decentralized. Even limiting
ourselves to rock.core, the only people that can decide are the ones
that are taking care of the subsystems. One should defer to Alex when
Orocos::Async or Vizkit are concerned (or, more recently, telemetry).
To Matthias when orogen_metadata was. Even seemingly working code
might not be deemed release-ready by the developers, and they are the
ones that will have to maintain it.

Sylvain