Discussion:
[Rock-dev] Rock1408 and orogen_loaders
Janosch Machowinski
2014-08-15 15:33:28 UTC
Permalink
Hey,
a lot of people told me, that 'orogen_loaders' is THE branch to
use at the moment. Neither avalon/dagon nor spacebot would
work without switching to this branch.
As these two systems will make the most 'real' use of rock in
the near future, I would suggest, to merge 'orogen_loaders'
into Rock1408 and use this to stabilize the branch and the
release at the same time. If we don't merge, the whole syskit
path would be relatively untested in the release, as the most
used systems are working on a different branch.
Any comments on this ?
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
Matthias Goldhoorn
2014-08-16 10:32:24 UTC
Permalink
Ehm...
The Release are for Fixing One more or less known working version.

Th releases are not Intended for getting something more stable.

For Avalon ye we need orogen loaders but it is in a quite new and not really stable state. I don't want to recommend this branch for normal users so far

We could really maybe push it to master but I would even not recommend this so far.

We need more projects with good developers and with persons that are not already frustrated regarding non working things for testing the branch.

So definitely no for the release but maybe for master after the release and after a discussion how we handle master

But as more as I thing about the releases I don't like them..., but that is another topic

Best matthias


Von iPhone gesendet
Post by Janosch Machowinski
Hey,
a lot of people told me, that 'orogen_loaders' is THE branch to
use at the moment. Neither avalon/dagon nor spacebot would
work without switching to this branch.
As these two systems will make the most 'real' use of rock in
the near future, I would suggest, to merge 'orogen_loaders'
into Rock1408 and use this to stabilize the branch and the
release at the same time. If we don't merge, the whole syskit
path would be relatively untested in the release, as the most
used systems are working on a different branch.
Any comments on this ?
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
Sylvain Joyeux
2014-08-18 00:26:39 UTC
Permalink
no fucking way

If so many people were using orogen_loaders, then they should have
mentioned it earlier and let it getting more stable on the master
branch. I've left it there *because* I got ZERO return of experience
and I can't test it / stabilize it myself.

+1 on Matthias' comment: a release is not meant to stabilize alpha-quality code.

I would add DFKI is not the sole Rock user, and it is much more
important to me to not arbitrarily break other people's environment
just because avalon and spacebot are super-bleeding edge and using it.
Moreover, Spacebot will probably require the ROS support which is at
this time completely untested (apart from unit-tests) on the
orogen_loaders branch.

In other words, I don't want this (my) experimental code to end up in
a stable release.

Sylvain
Janosch Machowinski
2014-08-18 14:39:51 UTC
Permalink
Post by Sylvain Joyeux
no fucking way
If so many people were using orogen_loaders, then they should have
mentioned it earlier and let it getting more stable on the master
branch. I've left it there *because* I got ZERO return of experience
and I can't test it / stabilize it myself.
Hm, ok. Then a question (for I guess Matthias and Thomas), if this code
is so pre alpha,
why in gods name are we using it to run our systems in a competition ?
Post by Sylvain Joyeux
+1 on Matthias' comment: a release is not meant to stabilize alpha-quality code.
Just in general : We are still in the RC phase. For me this is a phase,
were code can still be
integrated, or dropped.
Greetings
Janosch
Matthias Goldhoorn
2014-08-18 14:56:07 UTC
Permalink
Post by Janosch Machowinski
Post by Sylvain Joyeux
no fucking way
If so many people were using orogen_loaders, then they should have
mentioned it earlier and let it getting more stable on the master
branch. I've left it there *because* I got ZERO return of experience
and I can't test it / stabilize it myself.
Hm, ok. Then a question (for I guess Matthias and Thomas), if this code
is so pre alpha,
why in gods name are we using it to run our systems in a competition ?
I can only speak for dagon + avalon:
The most important thing for us is a bug fix for the merge-time.
orogen_loader setup is on syskit ~10x upto 100x faster than on master.
There are also other changes that make the system setup more smooth
(profile-tags). And a lot of mintor things...

Another reason is, if no one ever is willing to test and evaluate
experimental code the new code will never be stabilize.
I'm open for debugging and testing new features... that's why i decided
to use it.

BUT if i would have known this before that the whole orogen_loader stuff
took SO long i might have decided against syskit/roby, but so it is now
i took the decision and now, we are using it. If we are lucky in the end
with it i will inform you after the competitions.
But again: To get a stable code-basis someone needs to WORK on these big
changes like orogen_loaders.
So even i crying with a eye because i see that we are losing time, but i
still assuming that rock (even our institute) will earn the results of
this overhead...
Thats even what sylvain triing to enforce with the pull-requests, the
user base (or developer base however) needs to validate changes and make
sure everyting is still working. Rock is too lage as that one person can
maintain everything and know each particular aspect. It might be anoying
even for me sometimes, but in the end i have no other solution for this.
Specially because some people yielding that "rock is unstable"...

*drifted away from the topic* sorry

Best,
Matthias
Post by Janosch Machowinski
Post by Sylvain Joyeux
+1 on Matthias' comment: a release is not meant to stabilize alpha-quality code.
Just in general : We are still in the RC phase. For me this is a phase,
were code can still be
integrated, or dropped.
Greetings
Janosch
_______________________________________________
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
Sylvain Joyeux
2014-08-18 15:19:08 UTC
Permalink
On Mon, Aug 18, 2014 at 11:39 AM, Janosch Machowinski
Post by Janosch Machowinski
Hm, ok. Then a question (for I guess Matthias and Thomas), if this code
is so pre alpha,
why in gods name are we using it to run our systems in a competition ?
Because that's their call to make. From my p.o.v.: you don't care
about the toolchain, fair enough. They do, and a competition is
actually a good place to harden software *if* you are ready to spend
the time needed to stabilize it.

The bottom line is: if you get that on stable, you basically decide
*for me* that I should spend the time to stabilize it. You don't have
the right to do that.

I can only repeat what I said: the only person that can decide if some
piece of code should go on stable *is the person maintaining it*. You
can't decide for him whether (1) it is of sufficient quality and (2)
that person can spend the time necessary to fix bugs quickly
(something we all expect on a stable release).
Post by Janosch Machowinski
Post by Sylvain Joyeux
+1 on Matthias' comment: a release is not meant to stabilize alpha-quality code.
Just in general : We are still in the RC phase. For me this is a phase,
were code can still be
integrated, or dropped.
Of unstable code ? The RC phases should be short (or you are just
creating a new 'next'), which does not allow for stabilizing unstable
code.

Sylvain
Janosch Machowinski
2014-08-18 16:00:20 UTC
Permalink
Post by Sylvain Joyeux
On Mon, Aug 18, 2014 at 11:39 AM, Janosch Machowinski
Post by Janosch Machowinski
Hm, ok. Then a question (for I guess Matthias and Thomas), if this code
is so pre alpha,
why in gods name are we using it to run our systems in a competition ?
Because that's their call to make. From my p.o.v.: you don't care
about the toolchain, fair enough. They do, and a competition is
actually a good place to harden software *if* you are ready to spend
the time needed to stabilize it.
The bottom line is: if you get that on stable, you basically decide
*for me* that I should spend the time to stabilize it. You don't have
the right to do that.
I can only repeat what I said: the only person that can decide if some
piece of code should go on stable *is the person maintaining it*. You
can't decide for him whether (1) it is of sufficient quality and (2)
that person can spend the time necessary to fix bugs quickly
(something we all expect on a stable release).
woooow, were did this come from ? As you can read above, I acked your
decision,
that loaders does not go on the RC branch.
And for my question, this has nothing to do with you. As you might know,
I am
involved with the spacebot. And just to return this, it is not your
call, to say
what software should be used in a completion, were you are not involved in.
Janosch
Post by Sylvain Joyeux
Post by Janosch Machowinski
Post by Sylvain Joyeux
+1 on Matthias' comment: a release is not meant to stabilize alpha-quality code.
Just in general : We are still in the RC phase. For me this is a phase,
were code can still be
integrated, or dropped.
Of unstable code ? The RC phases should be short (or you are just
creating a new 'next'), which does not allow for stabilizing unstable
code.
Sylvain
Sylvain Joyeux
2014-08-18 16:12:08 UTC
Permalink
Post by Janosch Machowinski
woooow, were did this come from ? As you can read above, I acked your
decision, that loaders does not go on the RC branch.
Ah. Sorry then, I did not have that impression. My mistake.
Post by Janosch Machowinski
And for my question, this has nothing to do with you. As you might know, I
am involved with the spacebot. And just to return this, it is not your call, to
say what software should be used in a completion, were you are not involved in.
Fair enough. Now, if that was a private discussion about decisions on
spacebot / sauc-e, you probably should have kept it private...

Sylvain
Thomas Roehr
2014-08-19 08:46:47 UTC
Permalink
Post by Janosch Machowinski
Post by Sylvain Joyeux
no fucking way
If so many people were using orogen_loaders, then they should have
mentioned it earlier and let it getting more stable on the master
branch. I've left it there *because* I got ZERO return of experience
and I can't test it / stabilize it myself.
Hm, ok. Then a question (for I guess Matthias and Thomas), if this code
is so pre alpha,
why in gods name are we using it to run our systems in a competition ?
Actually, 'orogen_loaders' finds some of its origins in the last
competition.
It's known to be unstable at the moment, but that had already been
communicated to you a week ago.
The main intention for using it with spacebot now is to actually get to
a stable version, since with spacebot we have a significant application
test including the ROS integration part.
Looking at the actual competition for spacebot -- which is held in a
year -- there should be enough time to do this.

Best
Thomas
--
Thomas R?hr (M.Sc.)
Space Robotics

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.: +49 421 178 45-4151
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: thomas.roehr 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-18 15:24:34 UTC
Permalink
On Fri, Aug 15, 2014 at 12:33 PM, Janosch Machowinski
Post by Janosch Machowinski
If we don't merge, the whole syskit
path would be relatively untested in the release, as the most
used systems are working on a different branch.
Any comments on this ?
Another one: syskit on master was used by avalon until 1.5 months ago.
It has issues with big networks, but it is tested.

Sylvain
Loading...