[Rock-dev] Minutes of Rock Core videoconference

[Janosch Machowinski]

Am 18.02.2015 um 19:02 schrieb Sylvain Joyeux:
> On Tue, Feb 17, 2015 at 4:55 PM, Janosch Machowinski
> <Janosch.Machowinski at dfki.de> wrote:
>> I vote for a more dynamic scheme on deprecation.
>> Deprecation should be possible at any time in master.
> This policy proposed that one can always *deprecate* in master. What
> you can't do is randomly break backward compatibility.
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.
>> This is the reason, why we created releases in thY
>> first place, so that we can do drastic changes.
> That's your interpretation. I personally like releases so that I can
> do *dangerous* changes. And break backward compatibility when I have
> no other choice (for the record, orogen_loaders is the fourth attempt
> I made at refactoring orogen .. and the least intrusive). Randomly
> breaking backward compatibility is just a recipe for rendering a piece
> of software completely useless to anybody but its developers. ROS
> users were regularly two releases behind *because* migrating to each
> new ROS release was a pain (I don't know if it is still the case, but
> it definitely was at the time of Electric)
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.

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).

>
> Finally, this policy would apply only on rock-core packages.
> Individual maintainers  can always do whatever the f... they want for
> non-core packages. And pay the price - I can say for myself that I
> won't depend on packages that regularly break backward compatibility.
>
>> We got a bunch of old stuff lying around, that
>> was marked as deprecated, but never cleaned up
>> (good example are the backward compatibility header
>> in base). This shows, that the current system of
>> marking an cleaning up later is not working, because
>> people forget about it, or just don't care.
> In the case of base/types, it only shows that the people who actually
> cared (a.k.a. me in the case of base/types) did not have a good policy
> in place and had more important things to do than discuss one at the
> time. Can't say for other packages. In fine, the deprecated code which
> is still here has zero maintenance cost. Because if it *had* a
> maintenance cost, it would be removed already.
There is a maintenance cost. Perhaps not a imminent cost, but still work:
You still need to remove the code, to clean it up. So someone needs to
keep track of what may be removed now, or what is still in the 
'deprecation'
phase. Removing the code right away would lower the workload.

>> Also the suggested method is not feasible for
>> incompatible changes to existing types. These
>> need to applied right away, or you end up with
>> something like RigidBodyState31.
> And that actually might be the best choice. And, by the way, the path
> some people are getting into to phase out RBS (ref: the pull request
> for TransformWithUncertainty)
Worst case scenario. Every component would start to
use different types on the ports for the same thing.
This would basically make everything incompatible.
>> Another point is, that autoproj suppresses all
>> compile warning (yea, I know there is the X
>> warnings line). So most people will never see
>> the deprecation warning in the first place,
>> if they do not explicitly look into the log file.
> You of all people should know that autoproj has support to display the
> warning messages - given that you're the one who made the original
> patch - but at the time there was no consensus whether it should be
> enabled by default or not. Care to reboot that discussion ?
I know the patch is there. I always wanted it to be enabled by default.
You were the one that disabled it, because I quote 'this would just
annoy everyone'.
     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