[Rock-dev] It is RELEASE Time

Mon Aug 11 10:57:49 CEST 2014

Why this should the case?.
I freeze by commit pinning the rock installation.
If i do some patches i create a fork (as usal) and send a pull-request 
to master (or ofter orogen_loaders currently).
So thy should be a commit freeze result in this kind of problems?

In general i would fully agree that the user should have no need to do 
this, and pinning a installation is more work for me (as project 
maintainer).
But for rock in overall, it should make no difference.

Best,
Matthias

On 11.08.2014 10:32, Janosch Machowinski wrote:
> Hm,
> I start to think, that this commit/freeze thing is
> not a good idea. If everyone would use this feature,
> in practice this would mean, that everyone has this
> own PRIVATE branch of rock. The real fun will then
> start if the branches of the packages diverge and
> bugfixes will go on private branches, as the can't
> merge with master for other reasons.
> Just a thought...
>       Janosch
>
> On 08.08.2014 21:53, Christian Clausen wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> AVALON has pinned every Rock-component some time ago and will not
>> update "everything" even if there is any kind of release before SAUC-E.
>> We currently have a working system and do only updates on components
>> we need to update.
>>
>> So you can't use us as a pro or con for release-strategies :-) But
>> thanks for considering.
>>
>> Christian
>>
>> Am 08.08.2014 um 21:24 schrieb Sylvain Joyeux:
>>> Well ... Then we could at least make parallel releases, one "new
>>> style" for the not-so-faint-of-heart-who-need-it-right-now (i.e.
>>> spacebot, sauce) and one "old style" for those that don't want to
>>> have to resolve the issues that will arise. I.e., let's not push a
>>> new release strategy on all new users just because DFKI has two
>>> upcoming competitions.
>>>
>>> Changing how the installation & update process behaves is not a
>>> small thing. I would prefer giving the option to keep to the old
>>> system as long as the new one is not "tested".
>>>
>>> Sylvain
>>>
>>> On Fri, Aug 8, 2014 at 4:17 PM, Janosch Machowinski
>>> <Janosch.Machowinski at dfki.de> wrote:
>>>> As far as I understood it, the "autoproj commit" stuff aims at
>>>> freezing everything, that is not handled by the normal release,
>>>> and is an addition to the release process.
>>>>
>>>> Anyway, at some point we need to test the release process and as
>>>> we got SAUCE-E and Spacebot upcoming, now would be a good time,
>>>> to create a release. If the process itself turn out to be
>>>> suboptimal we can still decide to change it the next time. But we
>>>> won't know that, until we tried it out... Greetings Janosch
>>>>
>>>> Am 08.08.2014 19:29, schrieb Sylvain Joyeux:
>>>>> Dumb question ... But why rushing using the "new" release mode
>>>>> BEFORE we have it nailed instead of doing one more release with
>>>>> the current release method and switch to the new one next time
>>>>> ?
>>>>>
>>>>> I mean, with the "autoproj commit" stuff from jakob, we have
>>>>> quite a bit of things to think about and solve before switching
>>>>> to a new release model... And I would rather not change 5 times
>>>>> how things work release-wise.
>>>>>
>>>>> Sylvain
>>>>>
>>>>> On Fri, Aug 8, 2014 at 11:15 AM, Janosch Machowinski
>>>>> <Janosch.Machowinski at dfki.de> wrote:
>>>>>> Hey, as we all agreed, we want to do a release. In the DFKI,
>>>>>> we agreed, that NOW would be a good moment. As a result of
>>>>>> Sylvains concerns, we modified the release process.
>>>>>>
>>>>>> On Wednsday the 13.8.14 we will branch all Packets, known to
>>>>>> Rock-Next from the Master branch to Rock201408_rc1. EXCEPT
>>>>>> you mail me and tell me not to use Master but commit XXX for
>>>>>> your packet. (The idea is to have at least work on everyone
>>>>>> as possible)
>>>>>>
>>>>>> For all packets, which are only on Master at the moment, we
>>>>>> need to decide how to go on with them. Best would be if
>>>>>> packet maintainers give me a Go or NoGo  for these packages.
>>>>>>
>>>>>> This should be all until Wednesday. Greetings Janosch
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- Dipl. Inf. Janosch Machowinski SAR- & Sicherheitsrobotik
>>>>>>
>>>>>> 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-6614 Empfang: +49 421 178 45-6600
>>>>>> Fax:     +49 421 178 45-4150 E-Mail:
>>>>>> jmachowinski 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
>>>>> _______________________________________________ Rock-dev
>>>>> mailing list Rock-dev at dfki.de
>>>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>>> _______________________________________________ Rock-dev mailing
>>>> list Rock-dev at dfki.de
>>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>> _______________________________________________ Rock-dev mailing
>>> list Rock-dev at dfki.de
>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>>
>>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJT5SrEAAoJEFs1kTdNIsi+cewH/jlYQYdNVnOSWZqJLgagSV7K
>> x+L/yRj5ku4YLSZ0TBtm6vyLJGDATHCVJ+wp+UyZWeRAGkLE1D6JFVEO/KX9kSaQ
>> 7slMS1+EyxjQoea3s49VUs/VUKi96iTjVmEHR3jmeyzp0spjSp8uLVK/RM4yzHfK
>> uQ+COFZmxW6wU/zknoRybEIThUgWqIs39UJnFjth2h+EVT4PZ+6kgMtz8HhlwVi+
>> AewRvUPtwW2T+c90NsZ7MFgfAmn0dDbltsMFHpsfWITPxZdr1RNMFJaXuMDz5rKp
>> LEf60G/Uy221mffwA8e3AF05LOKSneW1A2yxSu3UTf/URPEI6jjqnA0sb93wMmo=
>> =Dwts
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Rock-dev mailing list
>> 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
  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
  -----------------------------------------------------------------------