On Oct 27, 1:28 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> 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
I have never worked in a commericial software development environment
outside a reserach lab, so I do not claim to know the best way to
approach this. But here's an idea.
Rather than state what the next release will be in terms of X.Y.Z, it
could be given a date code, which is the date work first starts on it.
What determines if X, Y or Z is upgraded depends on 'danger points'
system. Things to consider in the 'danger points' system would be:
1) The number of .spkg's updated. (More packages, more danger points)
2) A reviewer for each update give a scale of 1-5 depending on what he
sees has the likelyhood of the changes causes serious problems to a
lot of Sage users if the patch is flawed. (Higher risk, = more points)
3) The length of time since the release candidate was produced (longer
period, = lower points).
4) The more platforms tested on, the less danger points.
If the 'Z' reaches 5, with no obvious issues, it is called a stable
release.
In other words, for a stable release, there would have to be few
changes, the changes considered low risk, Sage tested on seveal
platforms and it been on the web site for some resonable period for
bugs to be known of.
If the danger points is higher, the Y is updated and the Z set to 0.
If the number of 'danger points' is even higher, the X is updated, and
the Y and Z set to 0.
You mathaticians know more than me about probability, so I'm sure you
can come up with something that reflects the probability of a release
having few bugs, and do deserving of a stable releease.
Dave
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
