[Dune] Removal of deprecated VTKOptions

[Andreas Lauser]

Hi All,

I heartly agree with Robert, and actually I know quite a few people who lost 
their motivation to contribute because they were constantly bounced. (Another 
pool of people does not even bother to try to get their stuff in for that 
reason.) Sure, Dune is a volunteer project, but most people involved earn 
their salary with something closely related to Dune, so there should at least 
some willingness to give _constructive_ feedback on a timely basis.

One other -- IMHO poisonos -- tendency I've often observed in Dune (also at 
this occasion) is that people stick to the "we need to stay backward 
compatible" dogma at any cost, even if this means much higher overhead for the 
one implementing the change than for the ones affected by it. If something goes 
wrong anyway, then the implementer gets punched in the face. I think this 
should change. Honestly, how complicated is it to run "find -type f | xargs sed 
-i 's/VTKOptions::/VTK::/g'" on your source tree? If a bullet point to the 
changelog is added before the release, I as a user do not have a problem with 
such changes. On the other hand, if you want absolute stability and follow 
trunk, you're doing something dead wrong. In that case, you ought to use a 
release branch. That's what they are for, right?

Just my 2c of frustration...

cheers
  Andreas

Am Donnerstag, 14. Juni 2012, 20:59:01 schrieb Markus Blatt:
> Hi Robert,
> 
> nice to hear from you. Hope you are doing OK.
> 
> On Thu, Jun 14, 2012 at 08:30:31PM +0200, Robert Kloefkorn wrote:
> > Christoph did the correct thing by removing the deprecated VTKOptions
> > class after the release and I hereby thank him for all the work that he
> > has been doing lately to improve the code quality of DUNE. There is
> > absolutely no need to have an additional announcement for removing
> > deprecated classes, big change or not. Next time we'll have to fill a
> > form or what?
> > This is exactly the right way to get people less and less
> > interested in investing time into something like DUNE.
> 
> Let's not exaggerate. Nobody said something about filling the form.
> 
> Fortunately, DUNE is in a state where there are users that people
> investing time should care about, too. We already implemented some
> utilities to help them. Deprecations with meaningful messages and
> proper documentation are such a thing. Unfortunately, removing
> deprecated methods/classes also removes theses messages and
> instructions on how to prevent them/move to the new
> interface. Therefore we should take good care to
> put everything into the recent changes. Just like Christoph did. The
> problem is that these have to incorporate all the information needed
> to move to the new interface. Which was not the case here because both
> the class name _and_ some members were renamed. Probably many previous
> times, too.
> 
> But users need a detailed description about
> the migration path. This saves them time and because of lesser
> complaints/question it even saves the developer's time, too.
> 
> > From the people complaining nobody mentioned so far that the
> > DUNE_DEPRECATED tag for the VTKOptions class did not work at all. The
> > deprecation was there for a long time an nobody noticed. So if somebody
> > should be blamed then the one you implemented this deprecation tag
> > without checking that it works correctly. On the other hand this problem
> > is just to unimportant to care about it. By the way in dune-fem it was
> > two or three lines to change at it took about 5 min. So what's the big
> > fuzz all about?
> 
> 5 minutes for three lines and I consider you as an expert. For me this
> took longer. Imagine howmuch time this is for a regular user and maybe
> 15 lines.
> 
> > People that are not satisfied with these problems that occur from time
> > to time in the trunk can stick with the release and they won't stumble
> > upon these things.
> 
> IMHO in this particular case this just moves the problem into the
> future and chances are the awareness for the change is even lesser on
> both the developer and user side.
> 
> Just my two cents,
> 
> Markus
-- 
Andreas Lauser
Department of Hydromechanics and Modelling of Hydrosystems
University of Stuttgart
Pfaffenwaldring 61
D-70569 Stuttgart
Phone: (+49) 711 685-64719
Fax: (+49) 711 685-60430
www.hydrosys.uni-stuttgart.de