Eliot I was replying and I throw away the mail :) I already applied my new year resolution :)
Stef PS: we know all that we should have better deprecation policy. We apply that but deprecation is good for little changes not huge ones. > > > On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito > <[email protected]> wrote: > Oh, come on... > > Levente, we all agree with you. Pharo is trying to use that deprecation > policy since some months ago... Sometimes people make mistakes (me included) > and don't do it, but we agreed that we have to deprecate and remove after two > versions of being deprecated. > > I'm tired of this stupid arguments. > > I expect the new year will bring us more doing and less discussing :). > > Unless we are prepared to discuss, discover, admit and correct our mistakes > our doing will be of little worth. I don't see anything stupid in discussing > deprecation policy. This criticism of Levente is entirely unjustified and > reminds me of recent treatment of certain prominent whistle-blowers. Can we > just drop the childish feelings of hurt, and direct ourselves to the > substance of arguments rather than our immediate emotional reactions to > email? We should all know by now that email is a particularly inexpressive > medium, prone to misinterpretation and therefore it behooves us to take a > breath before we reply and try and read beyond our surface perceptions. [I > am a hypocrite in this regard having over-reacted recently over timestamps.] > > Doubtless we are all imperfect in our use of email and can all do better > here. But we won't get any better by lacking objectivity and reacting > emotionally to valid criticism. Can we make one of our new year's > resolutions an attempt to be less emotional and more objective in all our > email discussions in the broader Squeak community? Please? > > Happy New Year > Eliot > > 2010/12/31 Levente Uzonyi <[email protected]> > > On Fri, 31 Dec 2010, Miguel Cobá wrote: > > El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió: > What you describe here is simply bad practice. One should run the tests > before deploying code (besides testing the complete system thoroughly). > If you use RFB, you can access the GUI in headless mode. Also when a > debugger opens with a deprecation warning, the stack trace is written to > the log file, so you will be notified about the problem even when you > don't have access to the GUI. > > Yeah, sure. But if it a second level dependency (a package I use that > uses a package that contains popups deprecation warnings) I have big > chances of being bite by this problem. I concede, this could be avoided > by test-running every and whatnot package in the image but for a system > that updates automatically this will bite. > > So you're saying that it's better to get a DNU instead of a deprecation > warning with proper description about what and how to update/change? > > > Levente > > > Also, even if I can use RFB or read the image logs, I most likely will > monitor the application logs and will pass a time without me knowing > that some part of the application is waiting some user input. > At the end I expect that the maintainer of the package is the > *responsible* of test the application for the image I use, and not the > user of the package. That is what I do with magma on Pharo. I test and > fix the issues generated by the evolution of Pharo and then I release a > new ConfigurationOfMagma that the user can use without knowing that n > deprecations were involved in the upgrade of the package. > > > > Anyway, there's no reason to remove a method (especially an API method) > without deprecating and keeping it around for a few releases. > > > I agree that is better to not forget to mark some method as deprecated > but, again, I think that this promote the external packages not being > updated to the current pharo image. > > Cheers > > -- > Miguel Cobá > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > > >
