another 2c: There is also the option of deprecating, but for less than the somewhat arbitrary 1 year.
On Tuesday, April 14, 2015 at 12:57:44 PM UTC-4, Volker Braun wrote: > > 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.
