[Rock-dev] The issue with Rock
Matthias Goldhoorn
matthias.goldhoorn at dfki.de
Thu Jun 19 11:46:40 CEST 2014
Sounds fine,
but we should thik about not callign this flavour here too to prevent
confusions.
But this brings me to another point, it becomes standart that the
overrides.yml and overrides.rb ist part of the autoproj build
configuration. Therefore it's hard to define local overrides. Could we
maybe add a local-overrides.rb and local-overrides.yml that will be
checked by autoproj too?
Best,
Matthias
On 19.06.2014 11:38, Sylvain Joyeux wrote:
> We basically would separate the flavor of rock.core from the flavor of
> the rest of the packages. The only flavor users would be asked about
> would be the non-core one and we would automatically pick the
> rock.core one based on that (next for next, stable for stable). People
> that would want 'master' on rock.core would have to do it manually in
> their init.rb
>
>
> On Wed, Jun 18, 2014 at 4:37 PM, Matthias Goldhoorn
> <matthias.goldhoorn at dfki.de <mailto:matthias.goldhoorn at dfki.de>> wrote:
>
> ...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 <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
>
>
--
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/20140619/0bc9f07b/attachment-0001.htm
More information about the Rock-dev
mailing list