[Rock-dev] The issue with Rock

Thu Jun 5 13:23:25 CEST 2014

+1 for removing master


2014-06-05 9:25 GMT+02:00 Alexander Duda <Alexander.Duda at dfki.de>:

>
> Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn <
> matthias.goldhoorn at dfki.de>:
>
>  Good Morning,
>
> I don't know what you mean with resistance, in the past master was the
> most "stable" version with the newest features.
> Therefore there was no resistance.
>
> Specially for Syskit/Roby i not posted all bugs, most of the bugs i
> workaround, but i will start to create bug-requests for this...
>
> Regarding the new functionality, you are right, most of these features are
> not needed, they make only the life easier..., but if i as developer see
> the need of a feature and implement it, i want to use this directly. I
> think this is normal, since the rock-devs are not pure-rock devs, work is
> done if we feel that we need enhancements...
>
> Maybe we should rename the structure or introduce a experimental branch.
> Phsychological i have the impression that "master" gets associated with
> "newest" not with an "unstable development" version. Maybe we should rename
> or create an additional "unstable" branch, from where the release policy to
> master is not so fixed windowed...
>
> example development:
> - work is done on experimental and pushed as soon as the dev thing it
> might work
> - experimental is pushed to master, as soon the responsible dev thing his
> changes work for all (few days upto a week?)
>
> Again i thing the primary reasons why most of all stays on master ist that
> the other branches does not have the "needed"("wished") features, or they
> have bugs that are not pushed from master
>
>
> I have my doubt here. None of the core packages had major issues the last
> couple of months forcing people to use master for the hole bootstrap.
>
>
> Thoughts?
>
>
> I have the feeling we should just remove master as flavor. In this case
> everyone has to bootstrap next or stable and if needed he/she can manually
> overwrite specific packages.
>
> Alex
>
>
> Matthias
>
>
>
> On 04.06.2014 17:00, Sylvain Joyeux wrote:
>
> Then ... my next question would be:
>
>    Why isn't there more resistance w.r.t. switching to master ?
>
>  I mean, when you say "oh I had a bug on syskit on next", did you report
> it as a functionality bug on next ? Did you insist that it should be fixed
> *on next* ? instead of switching to master ?
>
>  For new functionality, how much of it is "oh but I need X, it is so
> shiny" instead of "without X, I really cannot do it !". I mean, when I
> worked on the Orion I *wanted* some features from master, but quickly
> realized that I did not *need* them. I had what was strictly needed to get
> the Joints type (meaning typelib/master but orogen/next)
>
>  As for the release schedule / frequency, I can only do +1. Releases are
> too far apart.
>
>  My big problem here is that master has become the de-facto version of
> Rock that everyone uses, which really hinders possibility to do some actual
> development.
>
>  Sylvain
>
>
> On Wed, Jun 4, 2014 at 3:54 PM, Matthias Goldhoorn <
> matthias.goldhoorn at dfki.de> wrote:
>
>>   On 04.06.2014 15:43, Sylvain Joyeux wrote:
>>
>> Is that everyone seem to think that they need master. The majority should
>> be using stable or next.
>>
>>  Now, I *know* that there are reasons (there are always reasons) why one
>> might think that master is required. However, the main question for me is:
>>
>>    How can we make people feel confident that they can use next ?
>>
>>  Or
>>
>>    How can we ensure that 'next' can be used except for a few packages
>> that would go on master ?
>>
>>  The best way to start answering these questions is to answer another
>> one:
>>
>>    Why are you on master ?
>>
>>
>>  Because i using syskit and the next version is even more unstable than
>> master. I had several times that the depandancy between roby/syskit and
>> other 'core' packages is hard. So i cannot stay a long time on next and
>> only with syskit/roby on master.
>> Indeed i'm not sure if i can currently use syskit/roby on next and
>> everything else on master.
>>
>> So generally speaking, incompatibilities between
>> syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)
>>
>>
>> The Second point, is that the release cycle to next is to long for new
>> features, i i (as  rock-dev) add new features to rock. I take ofter months
>> before it goes into next.
>> Therefore i have (due to the same reasons above) switch to master, also
>> for other members of my project. I would prefer a shorter release time
>> between master/stable/next...
>>
>>
>>
>> Best,
>> Matthias
>>
>>
>>
>>
>>  Sylvain
>>
>>
>> _______________________________________________
>> Rock-dev mailing listRock-dev at dfki.dehttp://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
>>  -----------------------------------------------------------------------
>>
>>
>>
>>
>
>
> --
>  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
>
>  _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
>
> --
> Dipl.-Ing. Alexander Duda
> Unterwasserrobotik
> Robotics Innovation Center
>
> Hauptgeschäftsstelle Standort Bremen:
>
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 1
> 28359 Bremen, Germany
>
> Tel.:     +49 421 178 45-6620
> Zentrale: +49 421 178 45-0
> Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
> E-Mail:   Alexander.Duda 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
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>


-- 
Vincent Vittori
Robotic engineer MARUM
University of Bremen
4 Leobener Straße, 28359 Bremen RAUM 1520

<http://maps.google.com/maps?q=&hl=en>*DE Mobile :* +49 152 242 37 465
*DE Office  :* +49 421 218 65 641
*FR Mobile :* +33 612 12 35 39
*Email:* vittori.vincent at gmail.com
*IM:* vincent.vittori1 (Skype)
*http://de.linkedin.com/in/vincentvittori/en
<http://de.linkedin.com/in/vincentvittori/en>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140605/c0d7cbdb/attachment-0001.htm