[Rock-dev] The issue with Rock
Matthias Goldhoorn
matthias.goldhoorn at dfki.de
Wed Jun 18 16:37:17 CEST 2014
...sounds good... but howto integrate this into the flavored concept,
simply not using flavors at all for rock.core?
Best,
Matthias
On 18.06.2014 15:16, Sylvain Joyeux wrote:
> One possible solution: decouple rock master from rock.core master
> (different release schedules). rock.core master would then become
> really a development branch where people should not fear to push
> tested but not heavily tested code.
>
> The rules:
> 1. rock master CANNOT depend on features in rock.core master. This
> ensures that the current up-to-date packages are not dependent on
> development features in the toolchain. This is ensured by making
> people always use rock.core next or stable.
> 2. rock.core master MUST stay backward compatible, i.e. at the point
> of release of rock.core, rock next should be usable with rock.core
> master. In other words, releasing rock.core (from master to next)
> should not break existing 'next' applications.
>
> Thoughts?
>
> Sylvain
>
>
>
> On Thu, Jun 5, 2014 at 2:02 PM, Matthias Goldhoorn
> <matthias.goldhoorn at dfki.de <mailto:matthias.goldhoorn at dfki.de>> wrote:
>
> -1 because for checkint our tree we need master, on we simply
> remove it from the server i'm sure people find ways like in the
> overrides
>
> *:
> - branch: master
>
> to do such things.
>
> Best,
> Matthias
>
>
> On 05.06.2014 13:23, Vincent vittori wrote:
>> +1 for removing master
>>
>>
>> 2014-06-05 9:25 GMT+02:00 Alexander Duda <Alexander.Duda at dfki.de
>> <mailto:Alexander.Duda at dfki.de>>:
>>
>>
>> Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn
>> <matthias.goldhoorn at dfki.de <mailto: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
>>>> <mailto: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 list
>>>>> Rock-dev at dfki.de <mailto: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 <tel:%2B49%20%280%29421%20218-64100>
>>>> Fax:+49 (0)421 218-64150 <tel:%2B49%20%280%29421%20218-64150>
>>>> E-Mail:robotik at dfki.de <mailto: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 <tel:%2B49%20421%20178%2045-6611>
>>>
>>> Besuchsadresse der Nebengeschäftstelle:
>>> Robert-Hooke-Straße 5
>>> 28359 Bremen, Germany
>>>
>>> Tel.:+49 421 178 45-4193 <tel:%2B49%20421%20178%2045-4193>
>>> Empfang:+49 421 178 45-6600 <tel:%2B49%20421%20178%2045-6600>
>>> Fax:+49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
>>> E-Mail:matthias.goldhoorn at informatik.uni-bremen.de <mailto: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 <mailto: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 <tel:%2B49%20421%20178%2045-6620>
>> Zentrale: +49 421 178 45-0 <tel:%2B49%20421%20178%2045-0>
>> Fax: +49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
>> (Faxe bitte namentlich kennzeichnen)
>> E-Mail: Alexander.Duda at dfki.de <mailto: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 <mailto: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
>>
>> *DE Mobile :* +49 152 242 37 465
>> *DE Office :*+49 421 218 65 641
>> *FR Mobile :* +33 612 12 35 39 <tel:%2B33%20612%2012%2035%2039>
>> *Email:* vittori.vincent at gmail.com <mailto:vittori.vincent at gmail.com>
>> *IM:* vincent.vittori1 (Skype)
>> *http://de.linkedin.com/in/vincentvittori/en
>> <http://de.linkedin.com/in/vincentvittori/en>*
>>
>>
>>
>>
>
>
> --
> 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 <tel:%2B49%20421%20178%2045-6611>
>
> Besuchsadresse der Nebengeschäftstelle:
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Tel.:+49 421 178 45-4193 <tel:%2B49%20421%20178%2045-4193>
> Empfang:+49 421 178 45-6600 <tel:%2B49%20421%20178%2045-6600>
> Fax:+49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
> E-Mail:matthias.goldhoorn at informatik.uni-bremen.de <mailto: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 <mailto: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
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140618/e8c977c6/attachment-0001.htm
More information about the Rock-dev
mailing list