[Rock-dev] Rock1408 and orogen_loaders
Matthias Goldhoorn
matthias.goldhoorn at dfki.de
Mon Aug 18 16:56:07 CEST 2014
On 18.08.2014 16:39, Janosch Machowinski wrote:
> Am 18.08.2014 02:26, schrieb 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
>> +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
More information about the Rock-dev
mailing list