I have not taken any offense, on the contrary!
Thank you very much for your detailed answer.
Maurizio
On Oct 27, 10:41 pm, William Stein wst...@gmail.com wrote:
On Tue, Oct 27, 2009 at 1:58 PM, Maurizio maurizio.gran...@gmail.com wrote:
What about adopting a simpler strategy?
What do you
William Stein wrote:
On Tue, Oct 27, 2009 at 1:58 PM, Maurizio maurizio.gran...@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
Hi folks,
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,
On Oct 26, 7:37 pm, Nick Alexander ncalexan...@gmail.com wrote:
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
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
On Tue, Oct 27, 2009 at 1:36 AM, Minh Nguyen nguyenmi...@gmail.com wrote:
Hi folks,
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
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. In this way, what happens is that one
release every n months could be considered more stable
On Tue, Oct 27, 2009 at 1:58 PM, Maurizio maurizio.gran...@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
On Oct 27, 2009, at 2:35 PM, gsw wrote:
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
Thank you Rob,
you seem to have caught my point 100%, I completely agree with your
comments
Maurizio
On Oct 26, 1:06 am, Rob Beezer goo...@beezer.cotse.net wrote:
We have a Sage server on our campus. We don't have departmental
sysadmins, instead it is maintained by the same folks who do the
William Stein wrote:
On Sat, Oct 24, 2009 at 10:17 PM, Robert Bradshaw
rober...@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
Jason Grout wrote:
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.
Dr. David Kirkby wrote:
Jason Grout wrote:
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
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
On Oct 26, 2009, at 7:04 AM, Dr. David Kirkby wrote:
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.
Yes, I think doing all those things would help a lot. John Cremona's
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
I hope it's obvious that in my suggested plan, it would be rare for
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 hampto...@gmail.com:
Yes, I think doing all those things would
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
I agree with Rob B. that it would be useful to have ONE (so as not to
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
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
On 26 Okt., 19:22, 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
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
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
Yep. Is anyone against a prohibition of spkg upgrades and major re-
factoring for small point releases?
I would point out that sometimes minor bugfixes require spkg
upgrades. For instance, sometimes to properly fix even tiny
problems with symbolics really requires a change to the pynac
On Oct 26, 2009, at 8:03 PM, kcrisman wrote:
Yep. Is anyone against a prohibition of spkg upgrades and major re-
factoring for small point releases?
I would point out that sometimes minor bugfixes require spkg
upgrades. For instance, sometimes to properly fix even tiny
problems with
For me, it would be enough if the binaries for the previous versions
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
Pablo Angulo wrote:
For me, it would be enough if the binaries for the previous versions
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
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.
Well, I don't think 4.1.2 is any more unstable than 4.1.1, but 4.1.1
happens to be the one we have installed. It's very important to
On Sat, Oct 24, 2009 at 10:17 PM, Robert Bradshaw
rober...@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
One of the main point I took into account was the necessity of not
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
We have a Sage server on our campus. We don't have departmental
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
I agree. I think there are a number of people who feel this way and
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
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
+1 this is a very good idea
On Sat, Oct 24, 2009 at 7:10 PM, Jason Grout
jason-s...@creativetrax.com 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
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
35 matches
Mail list logo
