[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