What about Sage Conservative version?
Maurizio
let me share with you some thoughts.
I know that this community likes a lot the strategy "release soon,
release often"; I tend to like this as well. What I don't like,
altogether, is the chance to have once in a while a quite buggy
release on our way, which is, in my opinion, not unlikely with this
strategy.
Some examples are when big new features are introduced, like new
symbolics, new notebook, new whatever else. From one point of view,
having the current official release providing the brand new features,
is useful in term of bug tracking (they are discovered much faster).
On the other hand, if people are not intending to help and join the
community, but just try testing a piece of software, they could get
really annoyed by finding more or less trivial bugs (lots of them can
pass not caught by a very careful review!) and make very bad
advertisement.
At the end of the day, provided that the community would keep
releasing this way, why don't you also consider providing a
"Conservative" release? That should simply represent a release where
most (or the total amount) of the work is focused on fixing bugs,
regressions, and known issues, rather than providing new features. I
know this already happens once in a while, but I think that those
release are simply not valued enough! That could be released in many
ways: one every six months, one per year, also whenever it's ready can
be a very good choice.
For example, from my point of view (my knowledge is limited) 3.4.2 has
been a pretty reliable release, all the efforts were in fixing stuff
before getting the brand new 4.0. Another conservative release will
probably be the 4.2, where the new symbolic stuff is already quite
integrated and the new notebook will get a good finishing after the
feedbacks from the 4.1.2 (also the backward compatibility break of the
sws format has been restored, I think, which is good). So, the amount
of time from two very casual conservative releases has been around 6
months, which is reasonable for productive oriented environments.
In this way, first time users could be pointed to the conservative
release, and once they get hungry and wants to get their hands dirty,
they won't have problems in switching to the current release. This
would also allow people that are very interested in short term
results, to work with a fairly reliable release, rather than fearing
that something goes wrong because of a simple bug, and discovering it
just one day before the deadline (if not worse!).
I hope this will be useful to the community.
Best regards
Maurizio
mhampton
to some extent have been ignored. Of course this is partly because of
the volunteer effort issue - if this is important than people need to
volunteer to work on it.
One thing that was mentioned on another thread is that the version
number for sage-4.1.2 was quite misleading. It would help a lot if
the version numbers were more grounded in reality. One simple change
might be to not pick the version number until a final release has been
decided on. Perhaps we could call the next release "sage-next" until
it is finalized.
Another idea, but one that requires more effort, would be to have some
sort of "LTS" release, for which only bugfixes would be applied. I
don't want to personally volunteer to do that, but I think it would be
great if someone else did :)
The easiest thing, which I hope can be implemented, is to highlight
former releases that seem especially stable as Maurizio suggests.
-Marshall
Jason Grout
>
> One thing that was mentioned on another thread is that the version
> number for sage-4.1.2 was quite misleading. It would help a lot if
> the version numbers were more grounded in reality. One simple change
> might be to not pick the version number until a final release has been
> decided on. Perhaps we could call the next release "sage-next" until
> it is finalized.
>
+1
> Another idea, but one that requires more effort, would be to have some
> sort of "LTS" release, for which only bugfixes would be applied. I
> don't want to personally volunteer to do that, but I think it would be
> great if someone else did :)
If someone wanted to volunteer, then +1. However, this will probably
not realistically happen any time soon; Just disentangling bugfixes from
feature enhancements will be a job, as often they are included in the
same patch. Sage development is still pretty rapid. I can see this
easily being a full-time job.
>
> The easiest thing, which I hope can be implemented, is to highlight
> former releases that seem especially stable as Maurizio suggests.
>
Somehow the wording needs to be picked to not say "the current release
is not stable; don't use it", but rather something like "major changes
were made in this release; you might find some corners that still need
polishing"
I agree that a more consistent and coherent version number strategy
would help a lot here.
Jason
--
Jason Grout
Timothy Clemans
Robert Bradshaw
> mhampton wrote:
>
>> One thing that was mentioned on another thread is that the version
>> number for sage-4.1.2 was quite misleading. It would help a lot if
>> the version numbers were more grounded in reality. One simple change
>> might be to not pick the version number until a final release has
>> been
>> decided on. Perhaps we could call the next release "sage-next" until
>> it is finalized.
>
> +1
+1 from me too. There are two attitudes to big point upgrades--one is
that they are a big motivation to upgrade and are relatively polished
(certainly they make for good publicity), the other is that x.0
releases have lots of new code (and hence lots of new bugs) and should
be avoided until the x.1 release comes. What view should we take?
>> Another idea, but one that requires more effort, would be to have
>> some
>> sort of "LTS" release, for which only bugfixes would be applied. I
>> don't want to personally volunteer to do that, but I think it would
>> be
>> great if someone else did :)
>
> If someone wanted to volunteer, then +1. However, this will probably
> not realistically happen any time soon; Just disentangling bugfixes
> from
> feature enhancements will be a job, as often they are included in the
> same patch. Sage development is still pretty rapid. I can see this
> easily being a full-time job.
What is meant by a conservative release? Is it one where nothing new
went in? Even bugfixes can sometimes cause other bugs.
It seems that two or three times a year a far-reaching, potentially
destabilizing change goes through, e.g. the new notebook, symbolics,
or coercion. Typically a huge volume of testing goes into these as
well, but there's no test like the real world one of releasing. I
agree that these releases should be clearly flagged as having lots of
new features. We don't need to call them unstable, the conservative
would naturally avoid them. Outside of these big changes, in my
experience it seems that the bulk of bugs are either corner cases that
remain undetected for a long time, or are bugs in functionality that
was not present in previous releases. Making a release without new
features wouldn't help either of these cases.
I suppose spkg dependancy upgrades are another potentially
destabilizing force, and there has already been talk about separating
them from releases that only deal with the sage library (which are
much easier to do distributed testing on from a technical standpoint)
and those that touch stuff outside the library. Short of spkg changes
(and the notebook and new symbolics could be seen as that) I think
that very few release are regressions with respect to what their
predecessor could do.
It would also have to be done is such a way as to not hold up normal
Sage development--long "bugfixes only" releases could stifle
contributions. Also, short of concentrated periods like bug smashing
events, I think its unrealistic for people to devote all the energy
they have writing code used for their research or teaching to fixing
bugs (though most people are more than willing to put some time into
it as part of what they do "for the good of the community").
>> The easiest thing, which I hope can be implemented, is to highlight
>> former releases that seem especially stable as Maurizio suggests.
>>
>
> Somehow the wording needs to be picked to not say "the current release
> is not stable; don't use it", but rather something like "major changes
> were made in this release; you might find some corners that still need
> polishing"
I think it makes more sense to label the "stable" rather than the
normal releases. I'm strongly -1 on having the conservative version as
the default download, and making people go to extra work to get the
latest.
- Robert
Georg S. Weber
no matter how you name it (I would prefer "LTS", i.e. long term
support), the basic problem is time resp. manpower.
I remember that when Linux switched from versions 2.0.x to 2.2.x, from
2.2.x to 2.4.x, and from 2.4.x to 2.6.x, the then "old" versions 2.0,
2.2, 2.4 had specific maintainers "till the very end", which only
included bugfixes (e.g. security ones), and some few enhancements into
the old branches they took care of.
Still, I do not see anything like this happen with Sage anytime soon,
as long as it is as hard as right now to find release managers even
for the current "main" releases.
Cheers,
Georg
Pablo Angulo
did not disappear from the mirrors, and big changes in SAGE came with
big changes in the version number. I could then tell my students to:
"use any version of SAGE starting with 4.1, but use SAGE>=4.2 at your
own risk" right at the begining of the course.
Dr. David Kirkby
Is it not more obvious to call the >=4.2 'beta' versions, if that strategy is
used. Virtually everyone knows a 'beta' version of software is subject to bugs.
I am personally of the opinion that many of the problems found in release
versions could have been caught earlier if a beta version was produced after the
last release candidate, and that beta version was available for everyone for a
month or so, before the final release was made.
Dave
Pablo Angulo
> Is it not more obvious to call the >=4.2 'beta' versions, if that
> strategy is
> used. Virtually everyone knows a 'beta' version of software is subject
> to bugs.
happens to be the one we have installed. It's very important to me that
students install at home a version compatible to the one we have at the
lab. It's more than important than features or stability.
William Stein
<robe...@math.washington.edu> wrote:
>
> On Oct 24, 2009, at 7:10 PM, Jason Grout wrote:
>
>> mhampton wrote:
>>
>>> One thing that was mentioned on another thread is that the version
>>> number for sage-4.1.2 was quite misleading. It would help a lot if
>>> the version numbers were more grounded in reality. One simple change
>>> might be to not pick the version number until a final release has
>>> been
>>> decided on. Perhaps we could call the next release "sage-next" until
>>> it is finalized.
>>
>> +1
>
> +1 from me too.
-1 from me, from both a social and technical perspective.
1. Technical: It will be a huge amount of work and introduce all kinds
of bugs (technically) if we call the next release "sage-next" instead
of what it will actually be, and I suspect it will be confusing
(socially) as well. As just one example, if you were to upgrade
Sage from version 4.1.2 to version "next", then upgrading to version
4.2 from "next" would be completely broken.
2. Social: It is very common for trac comments, comments in source
code, discussion in email, etc., to have references such as "this
fixes a problem in sage-x.y.z.alpha2", or "this was merged into
sage-x.y.z.alpha3", or "we fixed this in sage-x.y.z.alpha1 so expect
to see this in sage-x.y.z when it is released". There are hundreds of
such comments connected with every single release. All such comments
become meaningless if x.y.z is replaced by "next".
Neither of these problems is insurmountable. But I don't have the
time or inclination myself to surmount them.
-- William
Maurizio
adding a significant amount of work to the community, actually.
Basically, my only point was aimed to take advantage of something that
I think we already have, but that we don't value enough right now.
As I see it, I think that it could probably be a good idea to slightly
change the download page, as the user is provided the choice of which
version of Sage to download: either the Sage "current release" which
provides all the exciting new features, constantly updated, or the
Sage "conservative release", which is somehow poorer in terms of
features, but it's more polished in the corners of what is in it. If,
as I understood it (I might be wrong), this kind of releases already
take place once in a while (which I think, make a lot of sense), it is
just a matter of underline them and make them available for a little
longer, and contemporary to the other current releases which happen in
the meantime.
I think that out there there are a lot of people which would consider
VERY useful to get a slightly older software, but with increased
stability and reliability, and I don't think there's something wrong
with it. I think that in this way a lot of people could join the
community, and help as well, without the need of being very active
developers at the same time; that would allow this kind of people to
use Sage for their current work (because they can access to a very
reliable release), and provide something back in the long term (as you
know, it's very easy to become addicted!).
I don't even think the "conservative" should be considered Long Term
Support releases (in the sense that we should backport all the bug
fixing to those releases); I know that also "conservative" releases
can have bugs, but this doesn't mean we have to fix'em all with the
consequence of slowing down the development. Do you think it would be
so much overhead to check if the upgrade from the previous
"conservative" release to the next one works correctly? Shouldn't it
come almost directly from checking the working upgrade of every single
current version?
Best regards
Maurizio
Rob Beezer
sysadmins, instead it is maintained by the same folks who do the
administrative systems for the whole campus. I can probably only
reasonably expect two upgrades a year from them, at most. Once in the
summer and maybe over the winter break between semesters (that's
Northern Hemisphere time). I have a good idea which version to
recommend, but not everybody is going to be paying as close attention
as I do. So I think it would be extremely helpful to
(a) note somewhere in the download section your best bet (ie version
number) for a six-month or twelve-month installation (and keep it
easily available).
(b) give some careful thought to the design of a release that would
help make (a) work well.
For example, this summer the symbolics switchover from May/June began
to stabilize, and the intense notebook upgrade didn't begin until
September. So if a release sometime in August was targeted to be
super-stable for the purpose of part (a), that might be useful to
folks whose installations can't change as quickly as Sage development
progresses.
The above does not require extra maintenance - just a bit more
foresight and planning in the release schedule (which I realize is
subject to a variety of pressures, such as the availability of release
managers and the unpredictability of new code, timely reviews, OS
upgrades, etc, ...)
Rob
Maurizio
you seem to have caught my point 100%, I completely agree with your
comments
Maurizio
Jason Grout
So it sounds like the main problem is that the name "sage-next" would
apply to lots of different releases. How about making it more specific,
like "sage-4.1.2-next"?
Jason
--
Jason Grout
Dr. David Kirkby
> So it sounds like the main problem is that the name "sage-next" would
> apply to lots of different releases. How about making it more specific,
> like "sage-4.1.2-next"?
>
> Jason
Why not 'beta' like most other projects? If something goes wrong, then one might
have a beta2. I've never come across any other open-source project which adds
'next'.
Jason Grout
Because usually "beta" is attached to the version number of the next
piece of software. Our problem is that we don't want to arbitrarily
number the next version of software, because many times the scope has
not been accurately predicted at the start of the release cycle.
Normally "beta" is applied like this:
sage-4.1.1 -> sage-4.1.2-beta -> sage-4.1.2
At least a few people are agreeing that 4.1.2 should really have been
4.2. The decision to keep the 4.1.2 number was done, at least in part,
because we already had lots of references to 4.1.2 (like
sage-4.1.2.alpha1). We're trying to avoid here the mention of 4.1.2
until we know that it is the sort of scope that a double-point upgrade
suggests. So we're suggesting something like:
sage-4.1.1 -> sage-4.1.1-next -> sage-4.1.2
(or probably, it would have been: sage-4.1.1 -> sage-4.1.1-next ->
sage-4.2, since we put off figuring out what the next number was until
we saw the scope of the changes).
Thanks,
Jason
John Cremona
during the sequence of alpha-releases it becomes apparent that the
"next" release is going to have some significant change which warrants
a different number from that of the alpha versions (e.g. 4.1.2.alpha?
should have been called 4.2.alpha?) then this change could be made at
the point when alpha? becomes rc? (which surely means the same as
beta? anyway), since that's when there is a freeze on new features.
As long as there is a log somewhere explaining how 4.1.2.alpha?
matured into 4.2 instead of 4.1.2 (or whatever the numbers are next
time this happens) then this would seem to keep everyone happy.
John
2009/10/26 Jason Grout <jason...@creativetrax.com>:
Robert Bradshaw
> Why not 'beta' like most other projects? If something goes wrong,
> then one might
> have a beta2. I've never come across any other open-source project
> which adds
> 'next'.
We essentially do have betas, we just don't call them such. Usually
the sequence goes alpha -> beta -> release candidate -> release. I'm
not sure why, but historically we have been jumping directly from
alpha to release candidate.
On Oct 26, 2009, at 7:58 AM, John Cremona wrote:
> Would it not be a lot simpler if we did what we do now, except that if
> during the sequence of alpha-releases it becomes apparent that the
> "next" release is going to have some significant change which warrants
> a different number from that of the alpha versions (e.g. 4.1.2.alpha?
> should have been called 4.2.alpha?) then this change could be made at
> the point when alpha? becomes rc? (which surely means the same as
> beta? anyway), since that's when there is a freeze on new features.
>
> As long as there is a log somewhere explaining how 4.1.2.alpha?
> matured into 4.2 instead of 4.1.2 (or whatever the numbers are next
> time this happens) then this would seem to keep everyone happy.
I think this is a great way to handle it.
There seem to be two topics under discussion here: version numbering
and conservative releases. Right now version numbering is fairly
arbitrary--it seems we choose a number and then stick whatever is
ready into it. When a year rolls around, we issue a major point
upgrade just because. This means picking out release as stable or not
is hard to do (especially for the "non-developer, non-bleeding-edge"
crowd). Would it be enough if we had some standard like no .spkg
upgrades and or other major revisions in x.y.z releases? I think this
alone could help a lot.
Also, perhaps we could put a "previous versions" on the main page next
to/under the "download binary - source - components" link. We wouldn't
have to mirror them. I used to like how it was so easy to get to a
list of all releases (at least the source ones).
- Robert
mhampton
versioning plan seems to be the best compromise between convenience
and accuracy, and doesn't seem like it would cause big problems. And
adding an unmirrored link to the previous versions would be great for
a number of reasons - hopefully this would be relatively easy to do.
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.
-Marshall
On Oct 26, 12:25 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
John Cremona
the number to change between alpha & rc, as this would happen only if
something major was deemed ready, like the recent notebook rewrite.
John
2009/10/26 mhampton <hamp...@gmail.com>:
William Stein
I wonder why everybody (*) making suggestions has never put together a
single Sage release themselves, yet everybody who has done significant
work putting together Sage releases, organizing the web page, mirror
binaries, etc., has completely refrained from making any suggestions?
William
(*) The one exception is Robert Bradshaw who I think helped Craig
Citro with one Sage release once.
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
kcrisman
suffer from option paralysis!) slightly less feature-rich choice that
has been proved to be stable for sysadmins to put up. +1 to that.
Here's why:
In my experience, nothing kills use of Sage in a classroom setting
more than something like backward incompatibility, or a browser that
doesn't work right the first time with the NB, or whatever. And once
you've lost them, you've lost them (at least in non-major classes, and
even elsewhere). I just visited some colleagues at a college where,
the day before, Mma had given a free presentation (they don't have a
site license, but are thinking about it). When I mentioned Sage to
them and they asked some questions, some of them really were concerned
about things like not having drag-and-drop or the 'prime' derivative
notation in Sage. With that mindset (which I think is common, and not
really at all unreasonable if your students are used that), I can't
imagine how they would deal with some upgrade that turned out to break
stuff mid-semester.
I have no opinion on the numbering, though ;)
- kcrisman
Nick Alexander
On 26-Oct-09, at 11:22 AM, William Stein wrote:
>
> Hi,
>
> I wonder why everybody (*) making suggestions has never put together a
> single Sage release themselves, yet everybody who has done significant
> work putting together Sage releases, organizing the web page, mirror
> binaries, etc., has completely refrained from making any suggestions?
I didn't spend significant time, but I did spend an entire week being
release manager once.
It is my personal opinion that the system has been working. I was
disappointed that major backwards incompatibility was lost to a double-
point upgrade, but that's infrequent. I opted out of this discussion
because no matter what is agreed to, I don't see anything changing:
Sage is, for better or for worse, driven by developers. All talk of
releases marked stable, etc, doesn't fit with that reality.
Nick
Georg S. Weber
> Hi,
>
> I wonder why everybody (*) making suggestions has never put together a
> single Sage release themselves, yet everybody who has done significant
> work putting together Sage releases, organizing the web page, mirror
> binaries, etc., has completely refrained from making any suggestions?
>
> William
>
> (*) The one exception is Robert Bradshaw who I think helped Craig
> Citro with one Sage release once.
>
The latter would join the discussion, if it took place on "sage-
release".
Cheers,
Georg
Maurizio
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).
My point of view is in complete accordance to what Marshall Hampton
said:
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. "
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.
Regards
Maurizio
Robert Bradshaw
> 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
kcrisman
> Yep. Is anyone against a prohibition of spkg upgrades and major re-
> factoring for small point releases?
upgrades. For instance, sometimes to "properly" fix even tiny
problems with symbolics really requires a change to the pynac package,
and obviously now lots of things with the notebook would require a
change to that spkg, etc. So I don't know how realistic this is, but
some modification of that proposal would probably be a good idea; for
instance, perhaps that only bugfix skpg upgrades allowed for minor
point releases, as opposed to taking in new upstream releases? Just a
thought.
- kcrisman
Robert Bradshaw
That is a good thing to consider, certainly there's a difference
between "our" spkgs and upstream. The alternative would be to just
call it a x.y release even if the spkg changes are small.
Part of the point I was trying to make is that I think it's more
realistic and useful to minimize/concentrate potentially disruptive
changes than trying to establish a pattern of stable/bufgix only
releases. This makes whether or not something's "just a bugfix" less
relevant to the discussion.
- Robert
P.S. On a tangentially related note, only changing the sage library
also has the advantage of making widespread/automated testing easier.
Minh Nguyen
On Tue, Oct 27, 2009 at 5:22 AM, William Stein <wst...@gmail.com> wrote:
>
> Hi,
>
> I wonder why everybody (*) making suggestions has never put together a
> single Sage release themselves, yet everybody who has done significant
> work putting together Sage releases, organizing the web page, mirror
> binaries, etc., has completely refrained from making any suggestions?
I have two excuses.
Lame excuse: I was busy preparing a draft of my Honours thesis.
Good excuse: I wanted to spend some time gathering my thoughts on the
issue of maintaining a conservative series of releases. Here are my
thoughts.
Let's imagine for the sake of discussion that we have two separate
releases. On the one hand, there is a conservative double point
release series like Sage 4.2.x which only have bug fixes and also bug
fixes that have been back ported from major releases. Such bug fixes
include fixing bugs in the Sage standard library, bug fixes in the
Sage standard documentation, updating standard packages but not
upgrading spkg's to upstream releases, etc. On the other hand, we have
a major single dot release like Sage 4.x which includes new features
in addition to bug fixes that have been back ported to the Sage 4.2.x
series. Furthermore, both the double dot point and major releases are
released more or less roughly at the same time. For something close to
what I'm talking about, refer to the current situation with Python in
which there is a maintenance release for Python 2.6.x, and at the same
time there is a major release (i.e. Python 3.x) that includes new
features and backward incompatible changes.
Now let's explore ramifications regarding human resources of having
two separate branches: a conservative branch, and a major branch. One
of the first questions that come to my mind is: Are there human
resources around to maintain two separate branches? And if so, how can
such resources be divided between the above two branches? Who are
willing to step up to the task of doing a maintenance release for the
Sage 4.2.x series? In order to understand the latter question, assume
for the sake of discussion that new features, backward incompatible
changes, bug fixes and other wild/crazy stuffs can go into the major
release. Do we need at least two release managers: one for the
conservative release, and one for the major release? On the issue of
release management, see the release management wiki page [1] for an
incomplete list of tasks involved in managing a release.
Other questions include: Who are available/willing to fix bugs in a
conservative release? Who are available/willing to back-port bug fixes
from a major release? Who are available/willing to test and review bug
fixes for a conservative release as well as for a major release? What
can we do to empower users to explore a bug, narrow down its cause(s),
fix the bug, and produce a patch? I don't claim to have answers to any
of the above questions.
Now let's explore the issue of infrastructure. We require a farm
consisting of different systems for testing and building Sage. This is
already in place in the form of the dozen Linux virtual machines
hosted on boxen.math, machines on the Sage network and SkyNet, and any
machines that people can get their hands on. From download statistics,
Windows users account for the majority of users of Sage. Of the people
who are using Sage under Windows XP, under Windows Vista, or Windows
7, how many of them are willing to help with developing Sage under
Windows? This can range from using Sage under Windows to testing Sage
and even producing patches. Similar questions can be raised for Mac OS
X. From my experience, people who use Sage under OS X have been
actively contributing to the OS X port of Sage. It is reported, and I
know from personal experience, that Sage 4.1.2 compiles and work OK on
Intel Mac OS X 10.4.11. People who use Sage on a Mac have been
reported to do so under Mac OS X 10.4.x, 10.5.x and 10.6.x in addition
to different CPU architectures (Intel, PowerPC, G4, G5). As for Linux,
there are reports that people have used or tried to compile Sage under
Arch Linux, Gentoo, SUSE 10.x, RHEL 5.3, and Slackware. There might be
other exotic Linux distributions that I have missed. Does the Sage
development infrastructure contain all such machines listed above?
Contrast the above to the actual state of the Sage infrastructure. The
Linux virtual machines on boxen.math at their current state consist of
the following Linux distributions in both 32- and 64-bit versions:
CentOS 5.3, Debian 5.0, Fedora 11, Mandriva 2009.1, openSUSE 11.1, and
Ubuntu 9.04. The machine bsd.math is a MacIntel running OS X 10.6.1.
The machine t2.math is a SPARC machine running Solaris 10. I've heard
that disk.math runs x86 OpenSolaris 10. The SkyNet cluster consists of
the following machines on which Sage is known to compile and run OK:
* cicero: x86 Fedora 9
* eno: x86_64 Fedora 9
* lena: x86_64 RHEL Server 5.3
* menas: x86_64 openSUSE 11.1
There are also two IA64 machines on SkyNet, one running openSUSE and
the other running RHEL. SkyNet also has a number of Solaris machines.
At the moment, Sage is known to fail to compile on either of the
Itanium machines as well as on the Solaris machines (I might be wrong
here). William Stein also has access to the latest version of Red Hat,
namely the machine rosemary.math, which runs x86_64 RHEL Server 5.4.
For release management, it's a good idea for a release manager to have
access to machines that make up the Sage development infrastructure.
In addition to that, a release manager also needs to have access to
Windows machines (XP, Vista, Win7) together with Cygwin and/or the
latest version of MSVC. This might or might not be necessary,
depending on your point of view. However, since the Cygwin port is
nearly complete (minus some failures), one also needs to test a
release of Sage on Cygwin. As for MSVC, I'm not optimistic about
anyone having access to the latest version of that expensive
development environment. There have also been discussions about
porting Sage to AIX and HP-UX. But how many people in the Sage
community have access to either of those platforms? David Kirkby has
access to an AIX machine and he has tested some patches/packages on
it. I recently sent a request to OpenAIX for a free account on an AIX
machine, but have so far received no reply. David Kirkby said that the
person in charge of OpenAIX is on vacation.
Notwithstanding issues of human resources and development
infrastructure, how are we going to sort out the issue of mirroring
out two separate releases at the same time? Say that we have two
versions: a conservative version with only bug fixes, and a major
version with new features and backward incompatibilities. Furthermore,
both are released at the same time. Are we going to mirror out both
releases? If so, what changes need to be made to web sites, and web
sites of mirrors around the world, so that people won't be confused
about information presented on web sites? For a whole year during 2008
or so, Harald Schilly was the only person who maintained the Sage web
site. Python has two different releases: a bug fixes release for
2.6.x, and a new features release in the form of 3.x. Can we mimic how
the Python web masters structure their web sites, in particular the
download page [2] and the documentation page [3]?
If people want to upgrade, they have the choice of upgrading to the
bug fixes only release, or upgrade to the major release. At the
moment, I understand that any of these two tasks can be accomplished
in two ways. Download the relevant source or binary tarballs by going
to the relevant download pages; or do an upgrade with "./sage
-upgrade". However, note that the current behaviour of "./sage
-upgrade" is to download updates from a mirror. How can mirrors and/or
the upgrade script be restructured in such a way so that if you want
to upgrade from Sage 4.2 to 4.2.1 you don't end up with 4.3? At the
moment, this is not an issue because only one repository is mirrored
out. If we are to maintain a conservative release in addition to a
major release, I think it would require maintaining two separate
repositories that need to be somehow kept separate on each mirror,
including on the master server.
By now, I guess you are tired of me rambling on about human resources
this and development infrastructure that. And you ask yourself, "Is
this guy going to do anything about maintaining a conservative
release? Or is he just making a lot of hot air?" So to put my money
(err... my free-time-away-from-work) where my mouth is, I propose to
take the Sage 4.2 release and maintain a bug fixes only Sage 4.2.x
series. I want to experiment with maintaining the Sage 4.2.x series
for at most six months and would step up to be a release manager for
that bug fixes only series. After six months, I would drop maintenance
of that series and would take on the major release current at that
time and continue on maintaining a bug fixes only series of that major
release. My aim is to cater to people who don't want to upgrade to
major changes/features and the latest and greatest, but are happy to
upgrade to bug fixes only releases. While doing a maintenance release
of Sage 4.2, people should use for development whatever alpha or rc
versions of Sage that Mike Hansen releases.
Sage is a volunteer project whose success is due to its user base, the
untiring commitment of its growing development community, as well as
the countless hours of volunteer time its community has devoted to it.
I consider it a privilege to volunteer my time to be release manager
of the Sage 4.2.x bug fixes series. Any serious objections why I
shouldn't maintain the Sage 4.2.x series for at most six months?
[1] http://wiki.sagemath.org/release
[2] http://www.python.org/download/
[3] http://www.python.org/doc/
--
Regards
Minh Van Nguyen
Dr David Kirkby
> I opted out of this discussion
> because no matter what is agreed to, I don't see anything changing:
> Sage is, for better or for worse, driven by developers. All talk of
> releases marked stable, etc, doesn't fit with that reality.
>
> Nick
change their habits if their is evidence to suggest that is better for
the project. Whilst there is a natural tendancy to want to see ones
changes integrated into the next release it does not take a genious to
work out that stratergy is probably not optimal.
Dr David Kirkby
On Oct 27, 1:28 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:
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
William Stein
I don't see the Python 2.x series as just a maintenance/bug fix
series. The difference between 3.x and 2.x is that 3.x made major
backward incompatible changes to 2.x. But 2.x still sees nontrivial
new development, packages, functionality, etc.
An analogous project might be how the Linux kernel used to have a
stable and unstable version at the same time. In Linux development
they realized that entire approach was a huge mistake and got rid of
it. (Some people might not be old enough to remember this.)
Another analogy might be PARI, which also has a stable and unstable
release. These evidently merge every 3-4 years or so, and I've been
told by many people (including the lead dev of pari) that it is a bad
idea to use the stable release, unless you have no choice. (He
repeatedly strongly recommend we switch to the unstable version for
Sage last time I visited him in Bordeaux.)
Another analogous project would be Ubuntu, which has both say 9.10
(any moment now), and 8.04.LTS. Probably the LTS releases of Ubuntu
are the most successful project I can think of right now as far as
stable/unstable goes. This is also nice because a Linux
distribution is more analogous to Sage than some of the other projects
above.
William
Jason Grout
> Another analogous project would be Ubuntu, which has both say 9.10
> (any moment now), and 8.04.LTS. Probably the LTS releases of Ubuntu
> are the most successful project I can think of right now as far as
> stable/unstable goes. This is also nice because a Linux
> distribution is more analogous to Sage than some of the other projects
> above.
>
FreeBSD is also another huge successful example of stable/unstable. See
http://www.freebsd.org/doc/en/books/handbook/current-stable.html
However, both Linux and FreeBSD have *much* bigger communities willing
to do the work, and a (much?) greater motivation to have an extremely
steady, non-changing stable line.
Thanks,
Jason
--
Jason Grout
Maurizio
What do you think about this: every 6 months (or 9, or 12 whatever),
the developers are asked to focus on producing bugfixing instead of
introducing new features. In this way, what happens is that one
release every "n" months could be considered more stable and reliable,
and these releases are kept on the website available for downloading
together with the current release.
In this way, I hope, there's really no overhead in the current work.
Of course, some effort in changing goals twice a year would be
required, so that old problems are solved.
Thanks for discussing this
Regards
Maurizio
On 27 Ott, 17:54, William Stein <wst...@gmail.com> wrote:
William Stein
>
> What about adopting a simpler strategy?
> What do you think about this: every 6 months (or 9, or 12 whatever),
> the developers are asked to focus on producing bugfixing instead of
> introducing new features.
Asked by whom? For how long? And, who are "the developers"? The
Sage project has no fulltime employees: Michael Abshoff was the only
one we ever had, and his funding ran out in May. The vast majority
of people who work on Sage do so for very specific reasons related to
their own research or teaching, and consequently they work on
specifically what they want to work on. Moreover, I try my best not
to boss anybody around involved in the project (if anybody feels
bossed around by me, definitely let me know -- it's not intentional).
I personally would be uncomfortable telling "the developers" to focus
for a month (say) on producing bugfixes instead of new features.
However, I think there is value in thinking about specific ways to
improve the quality of Sage overall. There are many things we can all
do to help. Here are some concrete suggestions:
1. Improve the doctest coverage. It is currently 79.5%:
$ sage -coverageall
Overall weighted coverage score: 79.5%
Total number of functions: 22734
We need 114 more function to get to 80% coverage.
----------
TAKE ACTION: Anybody reading this right now could sit down and put a
dent in that "114 more functions".
2. Report bugs. I checked yesterday and there are 822 known bugs in
Sage, according to trac. If you find a bug, make sure to report it
and get it into trac. Don't just blow it off. The more bugs we know
about (with clean, easy to test reproducible examples!), the better.
TAKE ACTION: I bet you know about one bug in Sage that isn't listed in
trac -- report it, and make sure it gets listed there!
3. Organize a bug day. A few years ago Martin Albrecht introduced a
"Bug Day" idea into Sage development. This is a pre-announced day
when people meet on irc and fix bugs. We have had 17 of these, but
they stopped for no apparent reason nearly a *year* ago. See the list
here: http://wiki.sagemath.org#BugDays
TAKE ACTION: Organizing a Bug Day is easy! Just come up with a time,
announce it on sage-devel, see if you can get some other people
interested, make a list of specific bugs to work on (with some common
theme), show up, "keep score", and report on what happened in another
sage-devel followup email.
4. Help write a Selenium test suite for the sage notebook. If we had
a sufficiently good one, this would have prevented most (all?) of the
many recent issues with the notebook. I personally won't do any
nontrivial further development on the notebook or merging of patches
until there is a test suite.
TAKE ACTION: I'm going to do this.
> In this way, what happens is that one
> release every "n" months could be considered more stable and reliable,
> and these releases are kept on the website available for downloading
> together with the current release.
> In this way, I hope, there's really no overhead in the current work.
This is trying to introduce some committee-style rules into the future
of Sage development, instead of suggesting specific concrete actions
people can take to improve the quality of Sage. This makes me a
little bit uncomfortable, as if I'm being told what to do. It also
seems idealistic to ask a hundred people to work a few weeks on fixing
bugs -- "the developers are asked to focus on producing bugfixing
instead of introducing new features" -- and assume that this will
result in "no overhead" and a release that is "more stable and
reliable". My concerns are that:
(1) This suggestion asks many people to do for free a bunch of
painful, difficult work that they likely don't want to do, and don't
have the time to do.
(2) Without a top notch test suite and multiple rounds of alpha/beta
testing, often fixing a bunch of bugs can easily results in software
that is less stable and more buggy. I think Sage has a good test
suite, but honestly it is nowhere near where I want it to be -- which
is 100% doctest coverage, plus a large suite of randomized testing
that is run 24/7 on a cluster hunting for bugs, like what is done in
the MPIR project.
I want to emphasize point (2). In my experience, *most* people's
attempts to fix a bug results in something they think fixes the bug,
but in fact adds several other bugs. This is just the reality of
software engineering. This is the case for extremely experienced
developers new to a project, for experienced developers who have been
involved for a long time, but forget something subtle, etc.
I'm all for fixing bugs, but don't consider it necessarily capable of
producing a more *stable* Sage release -- indeed it can result in a
much less stable one, unless there is a perfect test suite.
> Of course, some effort in changing goals twice a year would be
> required, so that old problems are solved.
>
> Thanks for discussing this
>
> Regards
>
> Maurizio
Thanks to you to. Please try not to take any offense to what I wrote
above. I'm just trying to engage in a helpful intellectual way.
Honestly, I would rather be doing something else right now, but you've
patiently and painstakingly laid out your thoughts in detail
repeatedly, so I think it is unfair if I don't respond.
-- William
Robert Bradshaw
> Well,
>
> matter-of-factly, there is unhappiness in the Sage user community.
> There obviously is the desire, and sometimes (think of lectures) a
> user's need to settle for *a single one* Sage version for quite some
> time to come, say a year or so. Only developers want to download (or -
> upgrade :-))) every two weeks or so the tool they want to use for some
> specific purpose.
>
> I myself have not been upgrading my Latex distribution for years, nor
> my editor (jEdit), nor my operating system (and I will stick to Mac OS
> 10.4.11 for quite some time to come). They're just tools.
I agree 100%, thats the way I am with most of my software too. But
there's *nothing* preventing you from downloading a single version of
Sage and sticking with it (and all its specific features and bugs) for
a year In fact you can go and re-download any old version you want in
case you loose it.
It seems the most common reason to encourage people to upgrade is "oh,
that bug was already fixed" or sometimes "that bug will be fixed in
the next release." If I run into a bug or feature in any software, my
first instinct is to see if there's a new version available, and
consider it perfectly natural to have to upgrade to get the new
features.
Trying to understand the apparent unhappiness, is it because users are
feeling forced to upgrade, or that people are scared of upgrading, or
both?
>
> However, there might be a scenario, where branching Sage might bring a
> real gain worth the pain.
>
> One other unhappiness of Sage users or potential users voiced several
> times, is that Sage is not "apt-gettable". To be more precise,
> Sage-3.0.6dfsg (or so) is part of Debian (unstable? testing?), but
> that's pretty outdated, and trying to update it is like trying to hit
> a quickly moving target.
We would love to have this! There was even a recent thread about it.
This doesn't depend on conservative versions--I bet people would love
to have *any* recent release apt-gettable. The primary difficulty is
(to my understanding) that Debian, etc. don't accept monolithic
distributions, but chopping Sage up into its various components and
getting all the dependancies working correctly when we don't package
and ship the them ourselves is an order of magnitude harder than
releasing already is. Getting it into other packaging systems would be
great too, but of course the question of porting comes before the
question of distribution.
- Robert
Maurizio
Thank you very much for your detailed answer.
Maurizio
On Oct 27, 10:41 pm, William Stein <wst...@gmail.com> wrote:
Dr. David Kirkby
> On Tue, Oct 27, 2009 at 1:58 PM, Maurizio <maurizio...@gmail.com> wrote:
>> What about adopting a simpler strategy?
>> What do you think about this: every 6 months (or 9, or 12 whatever),
>> the developers are asked to focus on producing bugfixing instead of
>> introducing new features.
>
> Asked by whom? For how long? And, who are "the developers"? The
> Sage project has no fulltime employees: Michael Abshoff was the only
> one we ever had, and his funding ran out in May. The vast majority
> of people who work on Sage do so for very specific reasons related to
> their own research or teaching, and consequently they work on
> specifically what they want to work on. Moreover, I try my best not
> to boss anybody around involved in the project (if anybody feels
> bossed around by me, definitely let me know -- it's not intentional).
Trying to dictate too much would certainly **** many developers off, given they
donate their time free. There is no doubt about that.
But that does not mean that you could not declare occasional intervals (every 6
months has suggested by some), when the only changes that will be committed at
that time are bug fixes, and bug fixes submitted are not expected to contain
enhancements. What I mean by that, is that is very common to try to fix a bug,
and notice one could enhance the code too, so doing both at the same time.
That's not to say that people do not work on what they want, do not produce
patches, but simply that the only changes permitted would be to fix known bugs.
As you rightly point out, fixing bugs can sometimes result in introducing other
bugs. I do not believe there is any magic bullet which will stop that. The way
to never write buggy code is to not write any code.
> I personally would be uncomfortable telling "the developers" to focus
> for a month (say) on producing bugfixes instead of new features.
You do not need to ask them to focus on bugfixes, but just make them away only
bug-fixes will be incorporated for a month.
I think if the rationale for this is explained, I do not believe many would mind
too much. And if they felt unwilling to focus on bug-fixing, then they can carry
on with whatever they want to do, but will just have to understand their patches
will not be incorporated for a month or so.
> However, I think there is value in thinking about specific ways to
> improve the quality of Sage overall. There are many things we can all
> do to help. Here are some concrete suggestions:
>
> 1. Improve the doctest coverage. It is currently 79.5%:
<SNIP>
> 2. Report bugs. I checked yesterday and there are 822 known bugs in
<SNIP>
> 3. Organize a bug day. A few years ago Martin Albrecht introduced a
<SNIP>
> 4. Help write a Selenium test suite for the sage notebook.
>> In this way, what happens is that one
>> release every "n" months could be considered more stable and reliable,
>> and these releases are kept on the website available for downloading
>> together with the current release.
>> In this way, I hope, there's really no overhead in the current work.
>
> This is trying to introduce some committee-style rules into the future
> of Sage development, instead of suggesting specific concrete actions
> people can take to improve the quality of Sage. This makes me a
> little bit uncomfortable, as if I'm being told what to do. It also
> seems idealistic to ask a hundred people to work a few weeks on fixing
> bugs -- "the developers are asked to focus on producing bugfixing
> instead of introducing new features" -- and assume that this will
> result in "no overhead" and a release that is "more stable and
> reliable". My concerns are that:
>
> (1) This suggestion asks many people to do for free a bunch of
> painful, difficult work that they likely don't want to do, and don't
> have the time to do.
No problem. They do not need to do it. They can continue to work on what they
want, just understanding it will not be incorporated quite as quickly as before.
> (2) Without a top notch test suite and multiple rounds of alpha/beta
> testing, often fixing a bunch of bugs can easily results in software
> that is less stable and more buggy. I think Sage has a good test
> suite, but honestly it is nowhere near where I want it to be -- which
> is 100% doctest coverage, plus a large suite of randomized testing
> that is run 24/7 on a cluster hunting for bugs, like what is done in
> the MPIR project.
> I want to emphasize point (2). In my experience, *most* people's
> attempts to fix a bug results in something they think fixes the bug,
> but in fact adds several other bugs. This is just the reality of
> software engineering. This is the case for extremely experienced
> developers new to a project, for experienced developers who have been
> involved for a long time, but forget something subtle, etc.
I suspect *part* of the reason bug fixes introduce bugs is the temptation to add
enhancements when bugs are fixed.
For example, I'm updating 'prereq' again. I see it has specific bugs.
1) My previous version will detect if gcc is used but not g++, but it fails to
detect if g++ is used, but gcc is not.
2) There's a portability issue on HP-UX due to the fact that 'uname -p' is not
portable.
3) The tests for programs in one script does not work on Solaris, as it thinks
the programs exist, even when they do not.
But the temptation is not to simply fix the bugs, but add enhancements at the
same time. So I added teh following enhancements.
4) Check for 'bash', which is not currently done.
5) Check that 'make' is GNU make.
6) Check 'tar' is GNU tar.
I'd say that during a bug-fixing release, only 1,2 and 3 were submitted, and 4,
5 and 6 which add enhancements were not. In fact, as HP-UX is not a supported
platform, perhaps (2) should not be incorporated either.
> I'm all for fixing bugs, but don't consider it necessarily capable of
> producing a more *stable* Sage release -- indeed it can result in a
> much less stable one, unless there is a perfect test suite.
You will never get a perfect test suite. You will never get Sage bug-free. But
IMHO there are things that could be done to produce a more stable version, that
has less features, but is more stable.
> -- William
Dave