[Rock-dev] It is RELEASE Time

Discussion:

Janosch Machowinski

2014-08-08 14:15:08 UTC

Hey,
as we all agreed, we want to do a release. In the DFKI, we agreed, that
NOW would be a good moment. As a result of Sylvains concerns, we
modified the release process.

On Wednsday the 13.8.14 we will branch all Packets, known to Rock-Next
from the Master branch to Rock201408_rc1.
EXCEPT you mail me and tell me not to use Master but commit XXX for
your packet. (The idea is to have at least work on everyone as possible)

For all packets, which are only on Master at the moment, we need to decide
how to go on with them. Best would be if packet maintainers give me a
Go or NoGo for these packages.

This should be all until Wednesday.
Greetings
Janosch
--
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-08-08 17:29:16 UTC

Permalink

Dumb question ... But why rushing using the "new" release mode BEFORE
we have it nailed instead of doing one more release with the current
release method and switch to the new one next time ?

I mean, with the "autoproj commit" stuff from jakob, we have quite a
bit of things to think about and solve before switching to a new
release model... And I would rather not change 5 times how things work
release-wise.

Sylvain

On Fri, Aug 8, 2014 at 11:15 AM, Janosch Machowinski

Post by Janosch Machowinski
Hey,
as we all agreed, we want to do a release. In the DFKI, we agreed, that
NOW would be a good moment. As a result of Sylvains concerns, we
modified the release process.
On Wednsday the 13.8.14 we will branch all Packets, known to Rock-Next
from the Master branch to Rock201408_rc1.
EXCEPT you mail me and tell me not to use Master but commit XXX for
your packet. (The idea is to have at least work on everyone as possible)
For all packets, which are only on Master at the moment, we need to decide
how to go on with them. Best would be if packet maintainers give me a
Go or NoGo for these packages.
This should be all until Wednesday.
Greetings
Janosch
--
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
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
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

Janosch Machowinski

2014-08-08 19:17:34 UTC

Permalink

As far as I understood it, the "autoproj commit" stuff
aims at freezing everything, that is not handled by the
normal release, and is an addition to the release process.

Anyway, at some point we need to test the release process
and as we got SAUCE-E and Spacebot upcoming, now
would be a good time, to create a release. If the process itself
turn out to be suboptimal we can still decide to change it the
next time. But we won't know that, until we tried it out...
Greetings
Janosch

Post by Sylvain Joyeux
Dumb question ... But why rushing using the "new" release mode BEFORE
we have it nailed instead of doing one more release with the current
release method and switch to the new one next time ?
I mean, with the "autoproj commit" stuff from jakob, we have quite a
bit of things to think about and solve before switching to a new
release model... And I would rather not change 5 times how things work
release-wise.
Sylvain
On Fri, Aug 8, 2014 at 11:15 AM, Janosch Machowinski

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

Sylvain Joyeux

2014-08-08 19:24:10 UTC

Permalink

Well ... Then we could at least make parallel releases, one "new
style" for the not-so-faint-of-heart-who-need-it-right-now (i.e.
spacebot, sauce) and one "old style" for those that don't want to have
to resolve the issues that will arise. I.e., let's not push a new
release strategy on all new users just because DFKI has two upcoming
competitions.

Changing how the installation & update process behaves is not a small
thing. I would prefer giving the option to keep to the old system as
long as the new one is not "tested".

Sylvain

On Fri, Aug 8, 2014 at 4:17 PM, Janosch Machowinski

Post by Janosch Machowinski
As far as I understood it, the "autoproj commit" stuff
aims at freezing everything, that is not handled by the
normal release, and is an addition to the release process.
Anyway, at some point we need to test the release process
and as we got SAUCE-E and Spacebot upcoming, now
would be a good time, to create a release. If the process itself
turn out to be suboptimal we can still decide to change it the
next time. But we won't know that, until we tried it out...
Greetings
Janosch

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

Christian Clausen

2014-08-08 19:53:44 UTC

Permalink

Hi,

AVALON has pinned every Rock-component some time ago and will not
update "everything" even if there is any kind of release before SAUC-E.
We currently have a working system and do only updates on components
we need to update.

So you can't use us as a pro or con for release-strategies :-) But
thanks for considering.

Christian

Post by Sylvain Joyeux
Well ... Then we could at least make parallel releases, one "new
style" for the not-so-faint-of-heart-who-need-it-right-now (i.e.
spacebot, sauce) and one "old style" for those that don't want to
have to resolve the issues that will arise. I.e., let's not push a
new release strategy on all new users just because DFKI has two
upcoming competitions.
Changing how the installation & update process behaves is not a
small thing. I would prefer giving the option to keep to the old
system as long as the new one is not "tested".
Sylvain
On Fri, Aug 8, 2014 at 4:17 PM, Janosch Machowinski

As far as I understood it, the "autoproj commit" stuff aims at
freezing everything, that is not handled by the normal release,
and is an addition to the release process.
Anyway, at some point we need to test the release process and as
we got SAUCE-E and Spacebot upcoming, now would be a good time,
to create a release. If the process itself turn out to be
suboptimal we can still decide to change it the next time. But we
won't know that, until we tried it out... Greetings Janosch

Post by Sylvain Joyeux
Dumb question ... But why rushing using the "new" release mode
BEFORE we have it nailed instead of doing one more release with
the current release method and switch to the new one next time
?
I mean, with the "autoproj commit" stuff from jakob, we have
quite a bit of things to think about and solve before switching
to a new release model... And I would rather not change 5 times
how things work release-wise.
Sylvain
On Fri, Aug 8, 2014 at 11:15 AM, Janosch Machowinski

Hey, as we all agreed, we want to do a release. In the DFKI,
we agreed, that NOW would be a good moment. As a result of
Sylvains concerns, we modified the release process.
On Wednsday the 13.8.14 we will branch all Packets, known to
Rock-Next from the Master branch to Rock201408_rc1. EXCEPT
you mail me and tell me not to use Master but commit XXX for
your packet. (The idea is to have at least work on everyone
as possible)
For all packets, which are only on Master at the moment, we
need to decide how to go on with them. Best would be if
packet maintainers give me a Go or NoGo for these packages.
This should be all until Wednesday. Greetings Janosch
-- 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
jmachowinski at informatik.uni-bremen.de
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

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

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

Matthias Goldhoorn

2014-08-11 07:00:16 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
AVALON has pinned every Rock-component some time ago and will not
update "everything" even if there is any kind of release before SAUC-E.
We currently have a working system and do only updates on components
we need to update.
So you can't use us as a pro or con for release-strategies :-) But
thanks for considering.

And we are using the orogen_loader stuff anyways, to we are offroad of
all release strategies either...

In general i prefer the two-way release stlye, because even i don't have
the time to get fully into the new release strategy.
I prefer to keep this in parralel a pice of time until the new one has
sattelt, from point of view of usage AND from point of view of the
toolchain.

Best,
Matthias

Christian

As far as I understood it, the "autoproj commit" stuff aims at
freezing everything, that is not handled by the normal release,
and is an addition to the release process.
Anyway, at some point we need to test the release process and as
we got SAUCE-E and Spacebot upcoming, now would be a good time,
to create a release. If the process itself turn out to be
suboptimal we can still decide to change it the next time. But we
won't know that, until we tried it out... Greetings Janosch

Post by Sylvain Joyeux
Dumb question ... But why rushing using the "new" release mode
BEFORE we have it nailed instead of doing one more release with
the current release method and switch to the new one next time
?
I mean, with the "autoproj commit" stuff from jakob, we have
quite a bit of things to think about and solve before switching
to a new release model... And I would rather not change 5 times
how things work release-wise.
Sylvain
On Fri, Aug 8, 2014 at 11:15 AM, Janosch Machowinski

Hey, as we all agreed, we want to do a release. In the DFKI,
we agreed, that NOW would be a good moment. As a result of
Sylvains concerns, we modified the release process.
On Wednsday the 13.8.14 we will branch all Packets, known to
Rock-Next from the Master branch to Rock201408_rc1. EXCEPT
you mail me and tell me not to use Master but commit XXX for
your packet. (The idea is to have at least work on everyone as possible)
For all packets, which are only on Master at the moment, we
need to decide how to go on with them. Best would be if
packet maintainers give me a Go or NoGo for these packages.
This should be all until Wednesday. Greetings Janosch
-- 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
jmachowinski at informatik.uni-bremen.de
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

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJT5SrEAAoJEFs1kTdNIsi+cewH/jlYQYdNVnOSWZqJLgagSV7K
x+L/yRj5ku4YLSZ0TBtm6vyLJGDATHCVJ+wp+UyZWeRAGkLE1D6JFVEO/KX9kSaQ
7slMS1+EyxjQoea3s49VUs/VUKi96iTjVmEHR3jmeyzp0spjSp8uLVK/RM4yzHfK
uQ+COFZmxW6wU/zknoRybEIThUgWqIs39UJnFjth2h+EVT4PZ+6kgMtz8HhlwVi+
AewRvUPtwW2T+c90NsZ7MFgfAmn0dDbltsMFHpsfWITPxZdr1RNMFJaXuMDz5rKp
LEf60G/Uy221mffwA8e3AF05LOKSneW1A2yxSu3UTf/URPEI6jjqnA0sb93wMmo=
=Dwts
-----END PGP SIGNATURE-----
_______________________________________________
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

Janosch Machowinski

2014-08-11 08:32:07 UTC

Permalink

Hm,
I start to think, that this commit/freeze thing is
not a good idea. If everyone would use this feature,
in practice this would mean, that everyone has this
own PRIVATE branch of rock. The real fun will then
start if the branches of the packages diverge and
bugfixes will go on private branches, as the can't
merge with master for other reasons.
Just a thought...
Janosch

As far as I understood it, the "autoproj commit" stuff aims at
freezing everything, that is not handled by the normal release,
and is an addition to the release process.
Anyway, at some point we need to test the release process and as
we got SAUCE-E and Spacebot upcoming, now would be a good time,
to create a release. If the process itself turn out to be
suboptimal we can still decide to change it the next time. But we
won't know that, until we tried it out... Greetings Janosch

Post by Sylvain Joyeux
Dumb question ... But why rushing using the "new" release mode
BEFORE we have it nailed instead of doing one more release with
the current release method and switch to the new one next time
?
I mean, with the "autoproj commit" stuff from jakob, we have
quite a bit of things to think about and solve before switching
to a new release model... And I would rather not change 5 times
how things work release-wise.
Sylvain
On Fri, Aug 8, 2014 at 11:15 AM, Janosch Machowinski

Hey, as we all agreed, we want to do a release. In the DFKI,
we agreed, that NOW would be a good moment. As a result of
Sylvains concerns, we modified the release process.
On Wednsday the 13.8.14 we will branch all Packets, known to
Rock-Next from the Master branch to Rock201408_rc1. EXCEPT
you mail me and tell me not to use Master but commit XXX for
your packet. (The idea is to have at least work on everyone as possible)
For all packets, which are only on Master at the moment, we
need to decide how to go on with them. Best would be if
packet maintainers give me a Go or NoGo for these packages.
This should be all until Wednesday. Greetings Janosch
-- 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
jmachowinski at informatik.uni-bremen.de
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

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

_______________________________________________ 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

Matthias Goldhoorn

2014-08-11 08:57:49 UTC

Permalink

Why this should the case?.
I freeze by commit pinning the rock installation.
If i do some patches i create a fork (as usal) and send a pull-request
to master (or ofter orogen_loaders currently).
So thy should be a commit freeze result in this kind of problems?

In general i would fully agree that the user should have no need to do
this, and pinning a installation is more work for me (as project
maintainer).
But for rock in overall, it should make no difference.

Best,
Matthias

Post by Janosch Machowinski
Hm,
I start to think, that this commit/freeze thing is
not a good idea. If everyone would use this feature,
in practice this would mean, that everyone has this
own PRIVATE branch of rock. The real fun will then
start if the branches of the packages diverge and
bugfixes will go on private branches, as the can't
merge with master for other reasons.
Just a thought...
Janosch

As far as I understood it, the "autoproj commit" stuff aims at
freezing everything, that is not handled by the normal release,
and is an addition to the release process.
Anyway, at some point we need to test the release process and as
we got SAUCE-E and Spacebot upcoming, now would be a good time,
to create a release. If the process itself turn out to be
suboptimal we can still decide to change it the next time. But we
won't know that, until we tried it out... Greetings Janosch

Post by Sylvain Joyeux
Dumb question ... But why rushing using the "new" release mode
BEFORE we have it nailed instead of doing one more release with
the current release method and switch to the new one next time
?
I mean, with the "autoproj commit" stuff from jakob, we have
quite a bit of things to think about and solve before switching
to a new release model... And I would rather not change 5 times
how things work release-wise.
Sylvain
On Fri, Aug 8, 2014 at 11:15 AM, Janosch Machowinski

Hey, as we all agreed, we want to do a release. In the DFKI,
we agreed, that NOW would be a good moment. As a result of
Sylvains concerns, we modified the release process.
On Wednsday the 13.8.14 we will branch all Packets, known to
Rock-Next from the Master branch to Rock201408_rc1. EXCEPT
you mail me and tell me not to use Master but commit XXX for
your packet. (The idea is to have at least work on everyone as possible)
For all packets, which are only on Master at the moment, we
need to decide how to go on with them. Best would be if
packet maintainers give me a Go or NoGo for these packages.
This should be all until Wednesday. Greetings Janosch
-- 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
jmachowinski at informatik.uni-bremen.de
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

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

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

--
--
Matthias Goldhoorn
Unterwasserrobotik

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64100
Fax: +49 (0)421 218-64150
E-Mail: robotik 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
-----------------------------------------------------------------------

Martin Zenzes

2014-08-11 12:15:32 UTC

Permalink

I would do a -1 for using two parallel releases. There is no win
(besides collecting some experiences). But it would double certain work
and mote importantly confuse users.

Post by Sylvain Joyeux
Changing how the installation & update process behaves is not a small
thing. I would prefer giving the option to keep to the old system as
long as the new one is not "tested".
Sylvain
On Fri, Aug 8, 2014 at 4:17 PM, Janosch Machowinski

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

--
M.Sc. Martin Zenzes
Space Robotics

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Phone: +49 (0) 421 178 45 - 6658
Fax: +49 (0) 421 178 45 - 4150
E-Mail: martin.zenzes 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

2014-08-11 20:14:04 UTC

Permalink

Post by Martin Zenzes

I would do a -1 for using two parallel releases. There is no win
(besides collecting some experiences). But it would double certain work
and mote importantly confuse users.

My problem is: the new release style is currently half-baked, and that
*is* one of the most important thing project-wise. In addition, since
it will probably be far from perfect (given that the only description
of it we have so far is "let's branch everything"), we'll have to
change it in the future. Which means even more confusion.

So, yes, I would go for testing the new release style for Rock
developers while the users still use the old one. No confusion for the
users, and still allows to test the new release system and refine it
for those that really really want to go this route.

Sylvain