Since its about me I might just as well add my 2c: Its a good rule to deprecate things before changing/removing them. Also, rules are there so you can break them once in a while. Its not a law of physics (good luck with breaking those). Use your judgement. If you take it literally then you can only ever pile more stuff onto Sage, and never refactor anything meaningful. Judgement questions include:
* is this about core mathematical functionality or miscellaneous, user interface, ...? * did the feature ever work correctly? * had the removed feature ever any doctest coverage on the buildbot (no coverage = not working) * how long was that feature in Sage * how well thought out was the feature. There is quite a spectrum between "broken" and "well-designed". On Tuesday, April 14, 2015 at 6:31:47 PM UTC+2, martin....@gmx.net wrote: > > Hi! > > The deprecation guideline > <http://www.sagemath.org/doc/developer/coding_in_python.html#deprecation> > reads: “Before removing any functionality, you should keep a deprecation > warning in place for at least one year (if possible).” To me, “any > functionality” means just that: any functionality, even if I don't ever use > it myself, and believe that others will use it rarely as well. That policy > was pointed out to me in ticket 16533 comment 28 > <http://trac.sagemath.org/ticket/16533#comment:28> (where it was > referring to some rather obscure and undesirable usage in my opinion), and > I've been trying to follow it ever since. However, I've recently come > across several instances where others don't follow that policy in as strict > a sense. In ticket 17783 comment 6 > <http://trac.sagemath.org/ticket/17783#comment:6> Volker Braun compared > the feature I was suggesting to preserve to the Spacebar Heating Feature > from xkcd 1172 <http://xkcd.com/1172/>. I still don't see how he could be > so certain that this thing I considered a feature was being used so little > that it could be removed without deprecation. And in ticket 18176 > <http://trac.sagemath.org/ticket/18176> Volker had originally proposed a > branch which simply removes documentation for functionality broken by an > eralier commit of his, instead of aiming at restoring said functionality. > > I'm not about to say that Volker is wrong per se. But I do feel that he is > not following the mentioned guideline in the strict and literal sense. What > does that mean for the rest of us? Is there some leeway in that guideline, > where we can remove stuff if keeping it around seems too much of a hassle? > Or is that freedom only granted to key contributors, perhaps those who know > their way around not only the code but its users as well, so they can > reliably say which features are being used and which are not? Or is it that > the some features might get sacrificed for the greater good? Perhaps > writing a proper fix in 18176 would have taken too much time and therefore > delayed a release, so that removing functionality (and the documentation > for it) was preferable to a delayed release with restored functionality? > And perhaps the great improvements for IPython from ticket 17234 > <http://trac.sagemath.org/ticket/17234> are so much of a benefit that its > authors and reviewers should indeed rather delete obscure functionality > than try to preserve it and get tangled in the process. > > I really want to understand, so that I can keep preserving the features we > need when writing patches myself, while at the same time not being too > demanding when I review code from others. > > Greetings, > Martin > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
