On Oct 26, 2009, at 3:31 PM, Maurizio wrote: > My answer to William Stein's question is double: first of all, I think > that sometimes people less involved than being active developers can > give suggestions from another perspective, and I hope that those are > not considered useless simply because they are given from people which > are not contributing (contributing is not just writing code, right?). > More than that, I was supposing that this problem of making available > for some more time releases that are a little less bug prone, could > have been not noticed from people involved with every day development. > This is absolutely understandable, but I think that it could be > valuable to consider other points of view as well (especially if it > could cover some significant part of the users).
I think your input is very valuable, though as mentioned just talking about it isn't as sure to cause a change as actually doing stuff (and I've never been release manager yet either). The more interesting question is why the experienced release managers haven't spoken up. I'm actually surprised by the perception that most releases break stuff. Is that a common experience? Or is it simply the most recent release that sparked things? There is usually an extraordinary amount of effort that goes into turning an alpha into a good release, it almost feels disingenuous to call such releases unstable, bug-ridden, and of beta quality. There is also a lot of work to preserve computability (for example, in the rare case that things are deprecated they still work with warnings for more than a year, and we make sure all old pickles still work) Of course things slip through, but the same could be said of nearly every piece of (sufficiently complex) software, especially when there are a large number of developers involved. At least we're open about all the bugs and try to fix them quickly. > My point of view is in complete accordance to what Marshall Hampton > said: > "Having something like no spkg upgrades or other major revisions as a > guideline for double point releases would help too. Maybe it would be > not too much extra work to schedule such a release once a year? It > could happen unplanned more than that, but it could be a good prelude > to a release with more changes. Such a minimal release should be > easier than most, so ideally it could happen quite quickly. " I actually think most releases could be (are?) like that. > As regards Nick Alexander's comment, I do also think that this > strategy has been working, but this doesn't mean that it cannot be > improved with very little effort. I don't think this would be a great > change into developer's mind, but maybe just some fine tuning. I hope > this amount of changes can be discussed openly, and that everybody can > help in this process. Yep. Is anyone against a prohibition of spkg upgrades and major re- factoring for small point releases? This could go a long way with actual stability and perception. Note that this would necessitate the social and technical ability to re-name a release if during the process it was decided that big stuff was ready to go in. The situation can be improved without changing the development process as well. If you publish a paper (or even have calculus worksheets) that you want to guarantee keep working version to version, submit them and we'll test the code as part of the release process. To err on the side of caution, you can recommend people download a specific version of Sage. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
