[Rock-dev] Minutes of Rock Core videoconference

[Janosch Machowinski]

Am 19.02.2015 um 18:22 schrieb Sylvain Joyeux:
>> Bad wording, I meant breaking of compatibility. With the
>> rule of waiting for 1 to 2 releases (depends when the patch
>> would enter) one will need about a year for any critical change.
>> This is just not feasible.
> Given that it is being done right now, experience shows that it is
> quite feasible
I totally disagree. The cleanup of base types has been postponed
for (wow, it is actually) years. This is stagnation.
>
>> I don't get the point. At some point the backward compatibility
>> will break, even if you delay it. So in the end it does not make a
>> difference, as one needs to port his/her software anyway.
> Because people are warned and have two releases to update their code
> (as you point out yourself, almost a year). The alternative: they get
> a new release and have to update RIGHT NOW or they can't use new
> releases.
Still don't get the point. As we are out of rolling releases, people
don't need to update, they can stay on their current release.
It would be the same issue, if you delay this by two releases, at
some point one needs to stay on the current release, or
update the code.
>
> Actually, this would be the nail in the coffin of the idea for me:
> breaking backward compatibility in master means that non-core packages
> must depend either on core master or core stable. But either not both,
> or have a lot of shitty ifdefs in them.
Yea, or you put the stuff on branches, one for every release.
Also here I don't get you point. After a backward compatible
change (which happens) the code will either work with the
current release, or master. Even if you announced the change
in advance.
>> For the ROS example, I don't think that we have 'users'. Core
>> packages have been crippled for weeks and nobody noticed it.
>> I would propose that we actually acquire real data about the
>> amount of people that use rock and adjust our policies to this.
>> A good way of doing this would be to send a message to a
>> server on every autoproj update (implemented in the init.rb in the
>> rock.core package set).
> (1) If you write policies on the basis that we don't have users, then
> we will never have any. (2) This is not about master.
My point here is, don't over regulate the thing. If you are a 20 person
company, don't act like a multinational enterprise. Our working rules
should be adapted to our current situation, or the overhead is too big.

Therefore this point is relevant to the current discussion.

>> Removing the code right away would lower the workload.
> On that we agree. And, as a project, we have to decide where best to
> spend "groundwork" workload.
Good starting point. My opinion on this one is don't spend work
on backward computability if it is not needed.
>
>> Worst case scenario. Every component would start to
>> use different types on the ports for the same thing.
>> This would basically make everything incompatible.
> Which is why we need to implement on-the-wire conversions to allow for
> smooth transitions (for which a lot of work has already been done in
> RTT). Which would also give us full support for inheritance (as we
> would get subclass-to-superclass connections) and finally break the
> *need* for something like RBS in the first place. Kill two birds with
> one stone.
If this works out like the 'new release mechanism' we may not change
any code within the next 3 years ?

     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