[Rock-dev] PROPOSAL(s): fixing recurrent breakage on the rock package sets

[Alexander Duda]

On 12/12/2011 12:06 PM, Thomas Roehr wrote:
> On 12.12.2011 11:33, Janosch Machowinski wrote:
>> The reasons against 2 are still valid. So it is not an option
>> from my point of view. So either it is 1 or we leave it the
>> way it is and hope that it just works in the future.
>> Greetings
>>        Janosch
>>
>> On 12.12.2011 10:52, Sylvain Joyeux wrote:
>>> The rock package sets are shared among the next, stable and master
>>> users. This scheme was based on the idea that people that would commit
>>> on these package sets would "know what they're doing". I.e. would have read
>>>
>>>        http://rock.opendfki.de/wiki/WikiStart/Toolchain/Flavors
>>>
>>> Since it does not seem to be the case, I would propose two "fixes":
>>>
>>>      1. make the package sets "curated", i.e. have only a few select people
>>>         that are allowed to change these package sets. Others would have to
>>>         propose patches to the rock-dev mailing list
> 1 would be fine with me.
> However, I still would like to avoid too much restriction and it might
> be sufficient to just reorganize orogen.autobuild / libs.autobuild , e.g.
> first what goes into master, second what goes into flavor master and
> next, etc. and adding warnings before editing any of the
> sections (especially involving next/stable).
>
> Thomas
>
>>>      2. branch off the package sets when we update next and stable.
>>>
>>> The original rationale for avoiding (2) is that, since we all share the
>>> same package set definition, users of next and stable can also compile
>>> packages that are only on master. We thought that it was critical in
>>> order to make this master/next/stable scheme work.
>>>
>>> Thoughts ?
I would vote for a combination between 1 and 2.
--> master where everyone can push
--> a second branch for next and stable which should only be updated by 
some people

This would have the benefit that everyone can integrate its stuff by 
himself if he is on master (test it on the build sever) and if something 
breaks next and stable are not effected (less work for the few people).

Alex

-- 
Dipl.-Ing. Alexander Duda
Unterwasserrobotik

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
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