Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On 06/ 2/10 01:12 PM, kcrisman wrote: On Jun 2, 4:08 am, John Cremona wrote: Sage surely benefits from having a very wide range of people who are developers, ranging in age, motivations, mathematician vs. software professional, and so on. Don't make assumptions about the volunteer mathematicians all being youngsters! (Some of us are over 50, and, I think, amateurs in the best sense of the word.) Very much so. I never made such an assumption. If contributing to Sage meant always (and only) promising to do specific things by deadlines, many would (I think) fall by the wayside, including (probably) me. +1 Me too. I was not saying that we had to sign up in blood to keep to a rigid structure. But to have some idea how long something is expected, when a release might be made, how much testing time will be devoted to that release, would be useful. I think the best policy, given the current state (not necessarily best overall), is to have a few reliable people who are knowledgeable about your type of ticket, who care at least a little bit about that type, and whom you trust to give good feedback even if it means "needs work". For better or for worse, there are always more tickets ready for review than people to review them - it's probably human nature ;) > but I think honestly also it's the fact that many of us feel we would be doing a disservice to review most tickets, due to ignorance or lack of experience in those areas. But there are some good 2-5 person teams who put in very high quality stuff. I think there are enough people interested in and reliable with the build system/env. variables/ etc. that it would be easy to have an informal list of people who would review them. It has became more difficult with the creating of sage-solaris. There are 7 members, and I've never had a single reply to any of the 26 messages I've posted there. I believe there is far too little time between a release candidate and a final release - a fact that would be obvious to any professional software developer if a roadmap was published. I'd agree with you here. +1 It would be great if William could see this. Of all the things I like and dislike about Sage, the single biggest dislike of mine is probably the way a release is made without what I consider sufficient testing. At the most basic level, Sage releases are made without them even being built on all supported platforms, so sometimes they don't even compile. In terms of a roadmap, I think it would be extremely valuable to have a list of features that Sage is clearly lacking to be a viable alternative to the closed source offerings, perhaps somewhere on the wiki by topic. I agree with Robert there. -- 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On 06/ 2/10 09:08 AM, John Cremona wrote: Sage surely benefits from having a very wide range of people who are developers, ranging in age, motivations, mathematician vs. software professional, and so on. Yes Don't make assumptions about the volunteer mathematicians all being youngsters! (Some of us are over 50, and, I think, amateurs in the best sense of the word.) I did not use the word "all". I said: "Peter Jeremy and myself are quite a bit older than most Sage developers." I would add John I believe you are one of the most "professional" developers. I recall when someone wanted to change a doc test just because it gave a different result on their computer, that I questioned what the answer should be. You went away and calculated it by another means. Too many others tend to accept the answer a doc test to look for is what their computer gives. If contributing to Sage meant always (and only) promising to do specific things by deadlines, many would (I think) fall by the wayside, including (probably) me. I was not implying that. But to have some strategy would be sensible. I'd like to see clearly defined terms of what the alphas and release candidates are. When they take place. How much time between the final release candidate and a release being made public. John On 2 June 2010 01:22, Robert Bradshaw wrote: On Jun 1, 2010, at 4:09 PM, Dr. David Kirkby wrote: On 06/ 1/10 11:56 AM, Robert Bradshaw wrote: On May 29, 2010, at 3:34 AM, Dr. David Kirkby wrote: The real question though is why do you think Sage would be better off with a roadmap? Would we have more users? Probably not. Happier users? Yes. Would it attract more developers? It would probably put less off. The random nature of Sage at the moment is not attractive to developers. I don't know anyone who's been turned off due to the nature of Sage development or lack of clear roadmap, but I could see it happening. Are we suffering due to the lack of a roadmap? I think we are. I believe that if there were specific dates for feature freezes, it would be useful to know. I for example have a lot of tickets I need reviewing, which has become increasing difficult to get done since sage-solaris was created. Should I try to badger someone to review them tomorrow, since the release will be made Thursday, or I should not worry, since no releases will be made soon? Releases are always going to be made soon, so it's always worth trying to get a review as soon as possible. (I've got a lot of tickets in that situation as well, but I've been otherwise occupied lately). The only urgent ones would be blockers (e.g. something that produces incorrect results) or occasionally something that's really a pain to rebase. If Sage has a mission of being a viable alternative to the commercial products, it should have some roadmap of how it is going to do that. Student projects could be proposed to address specific areas of weakness. Yes, it's amazing what students can do. As you know, there was a full-time employee working on the Solaris port, yet that was many years late. Had there been specific milestones to reach by certain dates, it would have been realised that port was slipping badly. It's more difficult when there is no plan. Honestly, I don't know if such a plan or milestones would have made a difference here. I believe there is far too little time between a release candidate and a final release - a fact that would be obvious to any professional software developer if a roadmap was published. I'd agree with you here. Would a user download a verion today, if there was a new release scheduled for tomorrow? He/she would probably wait a day or so. Or, he would decide to do that, then never come back for a long time. (It's happened to me.) With frequent releases this is less of an issue. Or is it more of a PR need? You may consider it "PR" but I would say it looks more professional than random dates. I think appearing professional is a good thing if you want to compete with professional software. I didn't mean this in the derogatory sense at all--I agree it's important to be professional. I think our different views may be age related. It might not be a coincidence that both Peter Jeremy and myself are quite a bit older than most Sage developers. Perhaps we see things from a different perspective. And I sincerely do appreciate another perspective, thank you for elaborating. It may also be the cathedral vs. the bazaar difference of perspective. It could also be professional software developers vs. volunteering mathematicians (and in particular, Sage is developed primarily by its users, who put in the work to get the features they need and want them in as soon as possible rather than being directed by external customers). In terms of a roadmap, I think it would be extremely valuable to have a list of features that Sage is clearly lacking to be a viable alternative to the closed source offerings, per
[sage-devel] Re: What's the point of two "stable" releases in two days?
On Jun 2, 4:08 am, John Cremona wrote: > Sage surely benefits from having a very wide range of people who are > developers, ranging in age, motivations, mathematician vs. software > professional, and so on. > > Don't make assumptions about the volunteer mathematicians all being > youngsters! (Some of us are over 50, and, I think, amateurs in the > best sense of the word.) Very much so. > If contributing to Sage meant always (and only) promising to do > specific things by deadlines, many would (I think) fall by the > wayside, including (probably) me. +1 > >> I think we are. I believe that if there were specific dates for feature > >> freezes, it would be useful to know. I for example have a lot of tickets I > >> need reviewing, which has become increasing difficult to get done since > >> sage-solaris was created. Should I try to badger someone to review them > >> tomorrow, since the release will be made Thursday, or I should not worry, > >> since no releases will be made soon? I think the best policy, given the current state (not necessarily best overall), is to have a few reliable people who are knowledgeable about your type of ticket, who care at least a little bit about that type, and whom you trust to give good feedback even if it means "needs work". For better or for worse, there are always more tickets ready for review than people to review them - it's probably human nature ;) but I think honestly also it's the fact that many of us feel we would be doing a disservice to review most tickets, due to ignorance or lack of experience in those areas. But there are some good 2-5 person teams who put in very high quality stuff. I think there are enough people interested in and reliable with the build system/env. variables/ etc. that it would be easy to have an informal list of people who would review them. > >> I believe there is far too little time between a release candidate and a > >> final release - a fact that would be obvious to any professional software > >> developer if a roadmap was published. > > > I'd agree with you here. +1 > > In terms of a roadmap, I think it would be extremely valuable to have a list > > of features that Sage is clearly lacking to be a viable alternative to the > > closed source offerings, perhaps somewhere on the wiki by topic. We need > > something higher level than tickets, but lower level than the mission. This > > has been done haphazardly for some areas, but doing this systematically > > (with a common place to accumulate the results) would be very valuable. This > > has and will happen, to some extent, as part of grant proposals and sage > > days planning. The combinatorics group is a stellar example of this: > >http://trac.sagemath.org/sage_trac/wiki/SageCombinatRoadMap. I'm not > > convinced that tying things to specific milestones/timelines will be as > > realistic given the dynamic nature of the developer base, but setting goals > > for specific Sage days, or "big" releases like 5.0 makes a lot of sense. +1 - kcrisman -- 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
Sage surely benefits from having a very wide range of people who are developers, ranging in age, motivations, mathematician vs. software professional, and so on. Don't make assumptions about the volunteer mathematicians all being youngsters! (Some of us are over 50, and, I think, amateurs in the best sense of the word.) If contributing to Sage meant always (and only) promising to do specific things by deadlines, many would (I think) fall by the wayside, including (probably) me. John On 2 June 2010 01:22, Robert Bradshaw wrote: > On Jun 1, 2010, at 4:09 PM, Dr. David Kirkby wrote: > >> On 06/ 1/10 11:56 AM, Robert Bradshaw wrote: >>> >>> On May 29, 2010, at 3:34 AM, Dr. David Kirkby wrote: >> >>> The real question though is why do you think Sage would be better off >>> with a roadmap? Would we have more users? >> >> Probably not. >>> >>> Happier users? >> >> Yes. >> >>> Would it attract more developers? >> >> It would probably put less off. The random nature of Sage at the moment is >> not attractive to developers. > > I don't know anyone who's been turned off due to the nature of Sage > development or lack of clear roadmap, but I could see it happening. > >>> Are we suffering due to the lack of a roadmap? >> >> I think we are. I believe that if there were specific dates for feature >> freezes, it would be useful to know. I for example have a lot of tickets I >> need reviewing, which has become increasing difficult to get done since >> sage-solaris was created. Should I try to badger someone to review them >> tomorrow, since the release will be made Thursday, or I should not worry, >> since no releases will be made soon? > > Releases are always going to be made soon, so it's always worth trying to > get a review as soon as possible. (I've got a lot of tickets in that > situation as well, but I've been otherwise occupied lately). The only urgent > ones would be blockers (e.g. something that produces incorrect results) or > occasionally something that's really a pain to rebase. > >> If Sage has a mission of being a viable alternative to the commercial >> products, it should have some roadmap of how it is going to do that. Student >> projects could be proposed to address specific areas of weakness. > > Yes, it's amazing what students can do. > >> As you know, there was a full-time employee working on the Solaris port, >> yet that was many years late. Had there been specific milestones to reach by >> certain dates, it would have been realised that port was slipping badly. >> It's more difficult when there is no plan. > > Honestly, I don't know if such a plan or milestones would have made a > difference here. > >> I believe there is far too little time between a release candidate and a >> final release - a fact that would be obvious to any professional software >> developer if a roadmap was published. > > I'd agree with you here. > >> Would a user download a verion today, if there was a new release scheduled >> for tomorrow? He/she would probably wait a day or so. > > Or, he would decide to do that, then never come back for a long time. (It's > happened to me.) With frequent releases this is less of an issue. > >>> Or is it more of a PR need? >> >> You may consider it "PR" but I would say it looks more professional than >> random dates. I think appearing professional is a good thing if you want to >> compete with professional software. > > I didn't mean this in the derogatory sense at all--I agree it's important to > be professional. > >> I think our different views may be age related. It might not be a >> coincidence that both Peter Jeremy and myself are quite a bit older than >> most Sage developers. Perhaps we see things from a different perspective. > > And I sincerely do appreciate another perspective, thank you for > elaborating. It may also be the cathedral vs. the bazaar difference of > perspective. It could also be professional software developers vs. > volunteering mathematicians (and in particular, Sage is developed primarily > by its users, who put in the work to get the features they need and want > them in as soon as possible rather than being directed by external > customers). > > In terms of a roadmap, I think it would be extremely valuable to have a list > of features that Sage is clearly lacking to be a viable alternative to the > closed source offerings, perhaps somewhere on the wiki by topic. We need > something higher level than tickets, but lower level than the mission. This > has been done haphazardly for some areas, but doing this systematically > (with a common place to accumulate the results) would be very valuable. This > has and will happen, to some extent, as part of grant proposals and sage > days planning. The combinatorics group is a stellar example of this: > http://trac.sagemath.org/sage_trac/wiki/SageCombinatRoadMap . I'm not > convinced that tying things to specific milestones/timelines will be as > realistic given the dynamic nature of the developer base, but setting go
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On Jun 1, 2010, at 4:09 PM, Dr. David Kirkby wrote: On 06/ 1/10 11:56 AM, Robert Bradshaw wrote: On May 29, 2010, at 3:34 AM, Dr. David Kirkby wrote: The real question though is why do you think Sage would be better off with a roadmap? Would we have more users? Probably not. Happier users? Yes. Would it attract more developers? It would probably put less off. The random nature of Sage at the moment is not attractive to developers. I don't know anyone who's been turned off due to the nature of Sage development or lack of clear roadmap, but I could see it happening. Are we suffering due to the lack of a roadmap? I think we are. I believe that if there were specific dates for feature freezes, it would be useful to know. I for example have a lot of tickets I need reviewing, which has become increasing difficult to get done since sage-solaris was created. Should I try to badger someone to review them tomorrow, since the release will be made Thursday, or I should not worry, since no releases will be made soon? Releases are always going to be made soon, so it's always worth trying to get a review as soon as possible. (I've got a lot of tickets in that situation as well, but I've been otherwise occupied lately). The only urgent ones would be blockers (e.g. something that produces incorrect results) or occasionally something that's really a pain to rebase. If Sage has a mission of being a viable alternative to the commercial products, it should have some roadmap of how it is going to do that. Student projects could be proposed to address specific areas of weakness. Yes, it's amazing what students can do. As you know, there was a full-time employee working on the Solaris port, yet that was many years late. Had there been specific milestones to reach by certain dates, it would have been realised that port was slipping badly. It's more difficult when there is no plan. Honestly, I don't know if such a plan or milestones would have made a difference here. I believe there is far too little time between a release candidate and a final release - a fact that would be obvious to any professional software developer if a roadmap was published. I'd agree with you here. Would a user download a verion today, if there was a new release scheduled for tomorrow? He/she would probably wait a day or so. Or, he would decide to do that, then never come back for a long time. (It's happened to me.) With frequent releases this is less of an issue. Or is it more of a PR need? You may consider it "PR" but I would say it looks more professional than random dates. I think appearing professional is a good thing if you want to compete with professional software. I didn't mean this in the derogatory sense at all--I agree it's important to be professional. I think our different views may be age related. It might not be a coincidence that both Peter Jeremy and myself are quite a bit older than most Sage developers. Perhaps we see things from a different perspective. And I sincerely do appreciate another perspective, thank you for elaborating. It may also be the cathedral vs. the bazaar difference of perspective. It could also be professional software developers vs. volunteering mathematicians (and in particular, Sage is developed primarily by its users, who put in the work to get the features they need and want them in as soon as possible rather than being directed by external customers). In terms of a roadmap, I think it would be extremely valuable to have a list of features that Sage is clearly lacking to be a viable alternative to the closed source offerings, perhaps somewhere on the wiki by topic. We need something higher level than tickets, but lower level than the mission. This has been done haphazardly for some areas, but doing this systematically (with a common place to accumulate the results) would be very valuable. This has and will happen, to some extent, as part of grant proposals and sage days planning. The combinatorics group is a stellar example of this: http://trac.sagemath.org/sage_trac/wiki/SageCombinatRoadMap . I'm not convinced that tying things to specific milestones/ timelines will be as realistic given the dynamic nature of the developer base, but setting goals for specific Sage days, or "big" releases like 5.0 makes a lot of sense. - 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On 06/ 1/10 11:56 AM, Robert Bradshaw wrote: On May 29, 2010, at 3:34 AM, Dr. David Kirkby wrote: The real question though is why do you think Sage would be better off with a roadmap? Would we have more users? Probably not. Happier users? Yes. Would it attract more developers? It would probably put less off. The random nature of Sage at the moment is not attractive to developers. Are we suffering due to the lack of a roadmap? I think we are. I believe that if there were specific dates for feature freezes, it would be useful to know. I for example have a lot of tickets I need reviewing, which has become increasing difficult to get done since sage-solaris was created. Should I try to badger someone to review them tomorrow, since the release will be made Thursday, or I should not worry, since no releases will be made soon? If Sage has a mission of being a viable alternative to the commercial products, it should have some roadmap of how it is going to do that. Student projects could be proposed to address specific areas of weakness. As you know, there was a full-time employee working on the Solaris port, yet that was many years late. Had there been specific milestones to reach by certain dates, it would have been realised that port was slipping badly. It's more difficult when there is no plan. I believe there is far too little time between a release candidate and a final release - a fact that would be obvious to any professional software developer if a roadmap was published. Would a user download a verion today, if there was a new release scheduled for tomorrow? He/she would probably wait a day or so. Or is it more of a PR need? You may consider it "PR" but I would say it looks more professional than random dates. I think appearing professional is a good thing if you want to compete with professional software. I think our different views may be age related. It might not be a coincidence that both Peter Jeremy and myself are quite a bit older than most Sage developers. Perhaps we see things from a different perspective. 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On May 29, 2010, at 3:34 AM, Dr. David Kirkby wrote: On May 26, 10:56 pm, Robert Bradshaw wrote: I didn't know anyone even looked at those numbers--maybe it would be better to put it in the *past* so people know not to trust it. I just deleted the date for now, though hopefully June is still a realistic target. - Robert IMHO, Sage development should have a plan like Jeremy showed for OpenOffice and FreeBSD - not have development occur in an uncoordinated haphazard manner. That's not to say we expect everything to happen on the days indicated, but at least have something to aim at. Both of those roadmaps seem to focus primarily on the a single release cycle, which given their different pace, makes sense. On the other hand, I'm not able to find a clear roadmap for Python--though at a lower level PEPs serve the same purpose (though not tied to a date, other than the release cycle ones) and they seem to get along just fine. The Sage project does have some concrete goals [1] and we do occasionally have specific pushes (e.g. the new symbolics, coercion, linear algebra overhaul, documentation) though those are usually shorter term (e.g. associated with a Sage Days). The real question though is why do you think Sage would be better off with a roadmap? Would we have more users? Happier users? Would it attract more developers? Are we suffering due to the lack of a roadmap? Or is it more of a PR need? Given that Sage has no full-time developers, and in particular is primarily driven by the personal needs of those who use it in teaching and research, I think it is unrealistic to attach dates or releases to most feature requests or bug reports unless someone is actively working on it (in which case the answer is still "it'll be in as soon as I get it done" and given our rolling release schedule there's no +6 months until the next release). So what would be on this roadmap? The recent discussion about overhauling permutation groups comes to mind, though again I don't know if a timeline could be assigned at this point (but a Sage Enhancement Proposal would be nice). At the moment when I create a trac ticket, I gets a choice of several milestones including 4.4.3 or 5.0. With no plan of what one of those releases is supposed to consist of, when it is supposed to occur, its hard to chose. (Actually, I just set it to the earliest, but if there was a proper plan, then I'd be more choosy) If something has a positively reviewed patch that doesn't break, there's little motivation to put it off until a later release (meaning the next one, if the current release is in a feature freeze--or I suppose if the release manager decides do to a stability/bug-fix-only release), so we always assign tickets to the next release, and bump everything that didn't go in when a new release comes out. The 5.0 milestone is there to collect items that are goals/blockers for 5.0, but if something's ready no sense in waiting until then to get it out. I know you won't like the answer, but the releases consist of whatever's ready to go when a release is cut. Personally, I think it's great for both developers (your stuff gets in and released quickly) and users (they get new features and bug fixes quickly, though if they're happy with the version they have there's no need to upgrade). - Robert [1] http://trac.sagemath.org/sage_trac/milestone/sage-5.0 -- 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On May 26, 10:56 pm, Robert Bradshaw wrote: > I didn't know anyone even looked at those numbers--maybe it would be > better to put it in the *past* so people know not to trust it. I just > deleted the date for now, though hopefully June is still a realistic > target. > > - Robert IMHO, Sage development should have a plan like Jeremy showed for OpenOffice and FreeBSD - not have development occur in an uncoordinated haphazard manner. That's not to say we expect everything to happen on the days indicated, but at least have something to aim at. At the moment when I create a trac ticket, I gets a choice of several milestones including 4.4.3 or 5.0. With no plan of what one of those releases is supposed to consist of, when it is supposed to occur, its hard to chose. (Actually, I just set it to the earliest, but if there was a proper plan, then I'd be more choosy) Dave 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On May 26, 9:23 pm, kcrisman wrote: > Wouldn't it be easiest for someone to change the 5.0 release date > thingie on Trac to "sometime in June, but may be pushed to July or > later in order to fulfill goals (Cygwin, etc.)"? This seems like even > more of a tempest in a teapot than the SPKG.txt thread ;) > > - kcrisman The underlying problems would not be changed by that. 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On May 26, 9:13 am, William Stein wrote: > On Wed, May 26, 2010 at 12:59 AM, David Kirkby > wrote: > > Looking at the Sage roadmap > > >http://trac.sagemath.org/sage_trac/roadmap > > > I see Sage 4.4.3 is "A tiny minor release on the way to 5.0" which is > > due on 30th May. > > > Sage 5.0 is due out two days later on first of June. > > > I don't believe such a release strategy says anything positive for > > Sage. In fact, quite the opposite - I think it looks incredibly > > amateurish. Who can take a program serious if two releases are made > > two days apart? > > Sage releases rarely come out on the random day that they happened to > be scheduled for on trac. That day is just some field one fills in > when making the milestone. I wouldn't take it too seriously. Sage has a mission of creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab. Those are all professionally developed software Randomly scheduled release days is not a very professional approach to software development. IMHO, Sage should have some plan, like Jeremy showed with links to FreeBSD and OpenOffice. That's not to say everyone should give up if deadlines are not met, but at least if milestones are set, people can see where Sage is aiming, If milestones are repeatedly missed, it would suggest that a goal is unrealistic, or will need changes to the approach to make it more realistic. I can't see to find this archived on Google groups, but http://www.mail-archive.com/sage-devel@googlegroups.com/msg04618.html has a comment from Michael Abshoff in August 2007 that: "I guess it isn't a secret that William want Sage 2.8.1 to work on Solaris "out of the box". It took about 2.5 years after that before Sage would build properly and pass the tests on Solaris. Currently to me at least, Sage development looks a bit haphazard. I realise you are a mathematician, but you are the lead developer of an open-source project. You might consider looking at a book on software engineering, as there are a lot of things that can be learned from such book that could be applied to Sage. http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/0137035152/ref=sr_1_4?ie=UTF8&s=books&qid=1275123329&sr=1-4 has quite a good reputation. I've not seen that book, but have an older book on a similar subject by Roger Pressman, though I believe Pressman's more recent books are not so up to date now. > If you want to make a parallel stable version of Sage and release it > that way, go for it. I will do at a later date, if I think you are convinced of the need for a more stable releases and you can convince some others. At the minute, it appears to me my views are in quite a minority and given the problems that caused with Solaris, I'm not so keen to get involved in something else that I can see some of your regular developers would certainly not like. IMHO, producing stable versions should be the primary aim rather than a secondary aim. 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On 27 Mai, 16:30, kcrisman wrote: > On May 27, 5:39 am, Harald Schilly wrote: > > > On May 27, 2:27 am, kcrisman wrote: > > > > But quite different here - there are no email reminders, no anything. > > > We have an RSS feed and release announcements are emailed to over 1400 > > people!http://groups.google.com/group/sage-announce/about > > Right, but only if you want it; there is no requirement. That was my > point. > > I can't resist point out also > thathttp://groups.google.com/group/sage-support/about > says there are 1740 people there, so clearly sage-announce is not even > reaching the whole community interested in getting updates about > Sage. Yet they find out ;) Some of those recipients might be other mailing lists or mail forwarders.. ;-) How do you know the actual number of Sage users? (And in case of site installations, most end users won't care about updates because they're made by admins; they will most probably notice them though.) -Leif -- 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On May 27, 5:39 am, Harald Schilly wrote: > On May 27, 2:27 am, kcrisman wrote: > > > But quite different here - there are no email reminders, no anything. > > We have an RSS feed and release announcements are emailed to over 1400 > people!http://groups.google.com/group/sage-announce/about > Right, but only if you want it; there is no requirement. That was my point. I can't resist point out also that http://groups.google.com/group/sage-support/about says there are 1740 people there, so clearly sage-announce is not even reaching the whole community interested in getting updates about Sage. Yet they find out ;) - kcrisman -- 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On May 27, 2:27 am, kcrisman wrote: > But quite different here - there are no email reminders, no anything. We have an RSS feed and release announcements are emailed to over 1400 people! http://groups.google.com/group/sage-announce/about h -- 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On May 26, 2010, at 5:06 PM, Tim Daly wrote:
William Stein wrote:
On Wed, May 26, 2010 at 3:08 PM, Tim Daly developer.org> wrote:
The Axiom project had a long debate about releases
and version numbers which I see is about to happen here.
Axiom decided that a reasonable balance was to make 2 decisions,
one about releases and one about versions.
RELEASES
There is a choice between releasing often and releasing,
say, yearly. Sage releases about every week or two at the
moment. The upside of this strategy is that people get the
latest version immediately. The downside of this strategy
is that people are ALWAYS in update mode and big changes
are very hard to manage in a small window (2 days?)
First, there would be a "silver" and a "gold" releases. The
silver version is updated continuously and available from
most of the sites with a git pull or git clone. The "gold"
release would be a time-boxed release every 2 months.
This gives people who care about a particular change a way to
get the latest release immediately. It allows others who just
want "the system", a way to update at a more reasonable pace,
maximally, every 2 months. The "gold" release is maintained
on github, the "silver" is on all other sites.
VERSIONS
Version numbers get religious really fast and the debate is
not very productive. Essentially, a single number is not
sufficient to carry all of the information about what might
have changed, especially if you have a component system.
Since git maintains a 40-digit SHA1 hash for every commit
it is sufficient for a version number. Any reference to a
single hash number gives all of the required information.
This is sufficient for "silver" releases.
Since the time-boxed "gold" releases are 2 months apart it
is sufficient to use the form "May 2010" as the unique
"release number". This is easy to distinguish from "March 2010".
I'm sure that the Sage list will find this method "not right"
for a variety of reasons but I can tell you that there is no
perfect solution. The Axiom debate raged on for about a year.
Time-boxing isn't perfect but it allows big changes to
occur without breaking everyone and little changes to occur
without annoying everyone.
Every project seems to have this debate. Good luck with it.
Thanks for sharing the above.
1. How do you think your choice of releases and version numbers
impacted the number of Axiom users? Developers?
I have no way to track the number of users so I can't say.
Axiom forked (twice) and the forks have their own version numbering
schemes,
each one different and neither one is clear, at least to me.
Developers will track whatever scheme you use and they won't like
it :-)
It is very difficult to introduce large changes to the system if the
updates are too
frequent. I'm introducing a new package that includes over 50 new
pieces of
algebra in this next release. The developer "silver" version has
seen each new
piece of algebra as it was introduced, with updates happening
several times a
day all month long but each new piece is useless standalone.
The "gold" version will have a fully implemented and tested piece so
users
won't see the intermediate states.
At the rate you are currently releasing I don't know how you can
introduce
fundamental changes like a reorganization of the categories. If
there is a mistake
the whole user community gets hit. And if it takes a couple weeks to
debug then
you'll have the world at your throat. The "silver" releases give
your developers
a chance to play before it goes out to the general public. I make NO
guarantees
about silver releases. They might not even build (although breaking
the build
is on my list of major sins).
If you "succeed" wildly then you'll have thousands of universities
downloading
versions, students will each have a different version depending on
the day of
the week they decided to download. A "gold" version would give
professors
something concrete to point at e.g. the "September 2010" version.
2. Now that you've had the above version/release schedule for a few
years, is there anything you would change?
Well you'd be amazed at how quickly 8 weeks goes by
The pace of 8 weeks between releases leaves 7 weeks of work and a
week of
deep test, binary builds, etc. Fedora always seems to break things
on every
release so it just takes a lot of time. I see you have the same
breakage happening
on certain platforms. It is very frustrating.
Having done the silver/gold release mechanism for about 4 years now
I think it is
"just about right". It gives lots of pressure to "hit the timebox"
but enough time
to plan for a major change.
Timeboxing also allows estimates of when to stop adding new features
("a freeze")
and start cleaning up the little details. This subtle side-effect
forces fixing the little
annoying things that nobody notices but make it cleaner and more
professional.
3. How did your debate about the above end? Was their
[sage-devel] Re: What's the point of two "stable" releases in two days?
On 27 Mai, 02:27, kcrisman wrote: > > > For Sage, this is simply not true for the majority of *users*. The > > > vast majority of Sage users could care less that we release new > > > versions -- most don't even notice or care. > > > I can't judge this. If it's true, fine. > > Especially for those running servers. But for most the updates are > not as important. Yes, admins love less frequent updates, as long as users don't complain (and there are no security issues). And alphas & rcs aren't mirrored... (some kind of unintentional? "gold release" feature) > > My experience is rather that many people just update (not only) > > software in general either because they fear missing something or just > > feel they have to have the latest version (they *believe* to be best/ > > superior), i.e. rather *not* driven by *functional* demand. > > But quite different here - there are no email reminders, no anything. Subscribe to sage-release (where pre-releases are announced, too), or sage-announce? ;-) On certain failures, you get a "run sage -upgrade" message. > No huge marketing campaigns (at least not for upgrades; hopefully for > 5.0 we will make a big push for *new* users). As long as you don't > encounter a life-threatening bug, you just keep using it. When you > do, you update (or use sagenb.org). I really like this aspect. I > think this makes Sage a little different from both productivity > software/OSes and more academic/industrial software. The Sagenb aspect is nice. Like Live-CDs for getting an impression before updating/installing (though I even hate reboots). And it's easy to have/keep multiple Sage installations, a rarely available opportunity. -Leif -- 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
> > > For Sage, this is simply not true for the majority of *users*. The > > vast majority of Sage users could care less that we release new > > versions -- most don't even notice or care. > > I can't judge this. If it's true, fine. Especially for those running servers. But for most the updates are not as important. > My experience is rather that many people just update (not only) > software in general either because they fear missing something or just > feel they have to have the latest version (they *believe* to be best/ > superior), i.e. rather *not* driven by *functional* demand. > But quite different here - there are no email reminders, no anything. No huge marketing campaigns (at least not for upgrades; hopefully for 5.0 we will make a big push for *new* users). As long as you don't encounter a life-threatening bug, you just keep using it. When you do, you update (or use sagenb.org). I really like this aspect. I think this makes Sage a little different from both productivity software/OSes and more academic/industrial software. - kcrisman -- 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On Wed, May 26, 2010 at 5:06 PM, Tim Daly wrote: > > > William Stein wrote: >> >> On Wed, May 26, 2010 at 3:08 PM, Tim Daly >> wrote: >> >>> >>> The Axiom project had a long debate about releases >>> and version numbers which I see is about to happen here. >>> >>> Axiom decided that a reasonable balance was to make 2 decisions, >>> one about releases and one about versions. >>> >>> RELEASES >>> >>> There is a choice between releasing often and releasing, >>> say, yearly. Sage releases about every week or two at the >>> moment. The upside of this strategy is that people get the >>> latest version immediately. The downside of this strategy >>> is that people are ALWAYS in update mode and big changes >>> are very hard to manage in a small window (2 days?) >>> >>> First, there would be a "silver" and a "gold" releases. The >>> silver version is updated continuously and available from >>> most of the sites with a git pull or git clone. The "gold" >>> release would be a time-boxed release every 2 months. >>> >>> This gives people who care about a particular change a way to >>> get the latest release immediately. It allows others who just >>> want "the system", a way to update at a more reasonable pace, >>> maximally, every 2 months. The "gold" release is maintained >>> on github, the "silver" is on all other sites. >>> >>> VERSIONS >>> >>> Version numbers get religious really fast and the debate is >>> not very productive. Essentially, a single number is not >>> sufficient to carry all of the information about what might >>> have changed, especially if you have a component system. >>> >>> Since git maintains a 40-digit SHA1 hash for every commit >>> it is sufficient for a version number. Any reference to a >>> single hash number gives all of the required information. >>> This is sufficient for "silver" releases. >>> >>> Since the time-boxed "gold" releases are 2 months apart it >>> is sufficient to use the form "May 2010" as the unique >>> "release number". This is easy to distinguish from "March 2010". >>> >>> I'm sure that the Sage list will find this method "not right" >>> for a variety of reasons but I can tell you that there is no >>> perfect solution. The Axiom debate raged on for about a year. >>> Time-boxing isn't perfect but it allows big changes to >>> occur without breaking everyone and little changes to occur >>> without annoying everyone. >>> >>> Every project seems to have this debate. Good luck with it. >>> >> >> Thanks for sharing the above. >> >> 1. How do you think your choice of releases and version numbers >> impacted the number of Axiom users? Developers? >> > > I have no way to track the number of users so I can't say. > > Axiom forked (twice) and the forks have their own version numbering schemes, > each one different and neither one is clear, at least to me. > > Developers will track whatever scheme you use and they won't like it :-) > > It is very difficult to introduce large changes to the system if the updates > are too > frequent. I'm introducing a new package that includes over 50 new pieces of > algebra in this next release. The developer "silver" version has seen each > new > piece of algebra as it was introduced, with updates happening several times > a > day all month long but each new piece is useless standalone. > The "gold" version will have a fully implemented and tested piece so users > won't see the intermediate states. > > At the rate you are currently releasing I don't know how you can introduce > fundamental changes like a reorganization of the categories. If there is a Just a remark -- we do not release as frequently as you think. There have been 10 releases in the last 6 months. > mistake > the whole user community gets hit. And if it takes a couple weeks to debug > then > you'll have the world at your throat. The "silver" releases give your > developers > a chance to play before it goes out to the general public. I make NO > guarantees > about silver releases. They might not even build (although breaking the > build > is on my list of major sins). > > If you "succeed" wildly then you'll have thousands of universities > downloading > versions, I think we have around 8000 downloads per month, last time I checked. > students will each have a different version depending on the day > of > the week they decided to download. A "gold" version would give professors > something concrete to point at e.g. the "September 2010" version. > > >> 2. Now that you've had the above version/release schedule for a few >> years, is there anything you would change? >> >> > > Well you'd be amazed at how quickly 8 weeks goes by > > The pace of 8 weeks between releases leaves 7 weeks of work and a week of > deep test, binary builds, etc. Fedora always seems to break things on every > release so it just takes a lot of time. I see you have the same breakage > happening > on certain platforms. It is very frustrating. Yes, Fedora is indeed annoying that way. > > Having done th
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
William Stein wrote:
On Wed, May 26, 2010 at 3:08 PM, Tim Daly wrote:
The Axiom project had a long debate about releases
and version numbers which I see is about to happen here.
Axiom decided that a reasonable balance was to make 2 decisions,
one about releases and one about versions.
RELEASES
There is a choice between releasing often and releasing,
say, yearly. Sage releases about every week or two at the
moment. The upside of this strategy is that people get the
latest version immediately. The downside of this strategy
is that people are ALWAYS in update mode and big changes
are very hard to manage in a small window (2 days?)
First, there would be a "silver" and a "gold" releases. The
silver version is updated continuously and available from
most of the sites with a git pull or git clone. The "gold"
release would be a time-boxed release every 2 months.
This gives people who care about a particular change a way to
get the latest release immediately. It allows others who just
want "the system", a way to update at a more reasonable pace,
maximally, every 2 months. The "gold" release is maintained
on github, the "silver" is on all other sites.
VERSIONS
Version numbers get religious really fast and the debate is
not very productive. Essentially, a single number is not
sufficient to carry all of the information about what might
have changed, especially if you have a component system.
Since git maintains a 40-digit SHA1 hash for every commit
it is sufficient for a version number. Any reference to a
single hash number gives all of the required information.
This is sufficient for "silver" releases.
Since the time-boxed "gold" releases are 2 months apart it
is sufficient to use the form "May 2010" as the unique
"release number". This is easy to distinguish from "March 2010".
I'm sure that the Sage list will find this method "not right"
for a variety of reasons but I can tell you that there is no
perfect solution. The Axiom debate raged on for about a year.
Time-boxing isn't perfect but it allows big changes to
occur without breaking everyone and little changes to occur
without annoying everyone.
Every project seems to have this debate. Good luck with it.
Thanks for sharing the above.
1. How do you think your choice of releases and version numbers
impacted the number of Axiom users? Developers?
I have no way to track the number of users so I can't say.
Axiom forked (twice) and the forks have their own version numbering schemes,
each one different and neither one is clear, at least to me.
Developers will track whatever scheme you use and they won't like it :-)
It is very difficult to introduce large changes to the system if the
updates are too
frequent. I'm introducing a new package that includes over 50 new pieces of
algebra in this next release. The developer "silver" version has seen
each new
piece of algebra as it was introduced, with updates happening several
times a
day all month long but each new piece is useless standalone.
The "gold" version will have a fully implemented and tested piece so users
won't see the intermediate states.
At the rate you are currently releasing I don't know how you can introduce
fundamental changes like a reorganization of the categories. If there is
a mistake
the whole user community gets hit. And if it takes a couple weeks to
debug then
you'll have the world at your throat. The "silver" releases give your
developers
a chance to play before it goes out to the general public. I make NO
guarantees
about silver releases. They might not even build (although breaking the
build
is on my list of major sins).
If you "succeed" wildly then you'll have thousands of universities
downloading
versions, students will each have a different version depending on the
day of
the week they decided to download. A "gold" version would give professors
something concrete to point at e.g. the "September 2010" version.
2. Now that you've had the above version/release schedule for a few
years, is there anything you would change?
Well you'd be amazed at how quickly 8 weeks goes by
The pace of 8 weeks between releases leaves 7 weeks of work and a week of
deep test, binary builds, etc. Fedora always seems to break things on every
release so it just takes a lot of time. I see you have the same breakage
happening
on certain platforms. It is very frustrating.
Having done the silver/gold release mechanism for about 4 years now I
think it is
"just about right". It gives lots of pressure to "hit the timebox" but
enough time
to plan for a major change.
Timeboxing also allows estimates of when to stop adding new features ("a
freeze")
and start cleaning up the little details. This subtle side-effect forces
fixing the little
annoying things that nobody notices but make it cleaner and more
professional.
3. How did your debate about the above end? Was their some definitive
argument, or?
Originally the development was released every 2 m
[sage-devel] Re: What's the point of two "stable" releases in two days?
On 27 Mai, 01:11, William Stein wrote: > On Wed, May 26, 2010 at 4:06 PM, leif wrote: > > On 27 Mai, 00:08, Tim Daly wrote: > >> [...] > >> There is a choice between releasing often and releasing, > >> say, yearly. Sage releases about every week or two at the > >> moment. The upside of this strategy is that people get the > >> latest version immediately. The downside of this strategy > >> is that people are ALWAYS in update mode and big changes > >> are very hard to manage in a small window (2 days?) > > > Indeed, not to mention testing/quality. > > For Sage, this is simply not true for the majority of *users*. The > vast majority of Sage users could care less that we release new > versions -- most don't even notice or care. I can't judge this. If it's true, fine. My experience is rather that many people just update (not only) software in general either because they fear missing something or just feel they have to have the latest version (they *believe* to be best/ superior), i.e. rather *not* driven by *functional* demand. In fact, newer versions often introduce new problems, often without any (subjective) advantage to the individual user. (Microsoft was forced to offer a Vista-to-XP downgrade option for example... :D :D :D ) Never change a running system... ;-) > In fact, probably most > just use sagenb.org. Many people on this list might pipe up that > *they* are "ALWAYS in update mode". But the people reading this are > a small fraction of users. > > In fact, even me -- when I'm *using* Sage for my research --- I will > have a copy of Sage for that project, and I will not upgrade that copy > of Sage for months on end. :-) -Leif -- 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On 27 Mai, 00:52, "Dr. David Kirkby" wrote: > On 05/26/10 09:48 PM, leif wrote: > > On 26 Mai, 21:50, "Dr. David Kirkby" wrote: > >> On 05/26/10 05:34 PM, leif wrote: > I like the risk assessment field idea. > > >>> Me too, perhaps give it a different name. > > >> What would you call it? There are at least three things to consider I can > >> think of. > > >> 1) What are the risks associated with a change? > > > impact (quantitive; severity is too hard) > > >> 2) The probability of the change causing a problem. > > > ? at least *what* it might cause? Who knows... > > >> 3) The impact such a problem would cause. > > > affected components > > >> There might be others. > > > Yes. Just lost one. > > I don't follow you. What have you lost? I simply had a 3rd/4th aspect in mind, but immediately forgot it. :( Perhaps one should also differentiate between the impact on users and that on the source code/development process. -Leif > 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On Wed, May 26, 2010 at 4:06 PM, leif wrote: > On 27 Mai, 00:08, Tim Daly wrote: >> [...] >> There is a choice between releasing often and releasing, >> say, yearly. Sage releases about every week or two at the >> moment. The upside of this strategy is that people get the >> latest version immediately. The downside of this strategy >> is that people are ALWAYS in update mode and big changes >> are very hard to manage in a small window (2 days?) > > Indeed, not to mention testing/quality. For Sage, this is simply not true for the majority of *users*. The vast majority of Sage users could care less that we release new versions -- most don't even notice or care. In fact, probably most just use sagenb.org.Many people on this list might pipe up that *they* are "ALWAYS in update mode".But the people reading this are a small fraction of users. In fact, even me -- when I'm *using* Sage for my research --- I will have a copy of Sage for that project, and I will not upgrade that copy of Sage for months on end. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On 27 Mai, 00:08, Tim Daly wrote: > [...] > There is a choice between releasing often and releasing, > say, yearly. Sage releases about every week or two at the > moment. The upside of this strategy is that people get the > latest version immediately. The downside of this strategy > is that people are ALWAYS in update mode and big changes > are very hard to manage in a small window (2 days?) Indeed, not to mention testing/quality. > First, there would be a "silver" and a "gold" releases. The > silver version is updated continuously and available from > most of the sites with a git pull or git clone. The "gold" > release would be a time-boxed release every 2 months. > > This gives people who care about a particular change a way to > get the latest release immediately. It allows others who just > want "the system", a way to update at a more reasonable pace, > maximally, every 2 months. Agree, too. Though I would call these "releases" and "snapshots". > VERSIONS > > Version numbers get religious really fast and the debate is > not very productive. Essentially, a single number is not > sufficient to carry all of the information about what might > have changed, especially if you have a component system. > > Since git maintains a 40-digit SHA1 hash for every commit > it is sufficient for a version number. Any reference to a > single hash number gives all of the required information. > This is sufficient for "silver" releases. > > Since the time-boxed "gold" releases are 2 months apart it > is sufficient to use the form "May 2010" as the unique > "release number". This is easy to distinguish from "March 2010". Such naming has advantages and disadvantages, too. (It e.g. doesn't reflect major and minor changes; perhaps less relevant because Sage consists of many components, but there are other aspects, too.) > [...] > Time-boxing isn't perfect but it allows big changes to > occur without breaking everyone and little changes to occur > without annoying everyone. Agree, but one shouldn't make a release just because "it is time to" (in the worst case, just to make it sound up-to-date or superior to some other thing). -Leif -- 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On Wed, May 26, 2010 at 3:08 PM, Tim Daly wrote: > The Axiom project had a long debate about releases > and version numbers which I see is about to happen here. > > Axiom decided that a reasonable balance was to make 2 decisions, > one about releases and one about versions. > > RELEASES > > There is a choice between releasing often and releasing, > say, yearly. Sage releases about every week or two at the > moment. The upside of this strategy is that people get the > latest version immediately. The downside of this strategy > is that people are ALWAYS in update mode and big changes > are very hard to manage in a small window (2 days?) > > First, there would be a "silver" and a "gold" releases. The > silver version is updated continuously and available from > most of the sites with a git pull or git clone. The "gold" > release would be a time-boxed release every 2 months. > > This gives people who care about a particular change a way to > get the latest release immediately. It allows others who just > want "the system", a way to update at a more reasonable pace, > maximally, every 2 months. The "gold" release is maintained > on github, the "silver" is on all other sites. > > VERSIONS > > Version numbers get religious really fast and the debate is > not very productive. Essentially, a single number is not > sufficient to carry all of the information about what might > have changed, especially if you have a component system. > > Since git maintains a 40-digit SHA1 hash for every commit > it is sufficient for a version number. Any reference to a > single hash number gives all of the required information. > This is sufficient for "silver" releases. > > Since the time-boxed "gold" releases are 2 months apart it > is sufficient to use the form "May 2010" as the unique > "release number". This is easy to distinguish from "March 2010". > > I'm sure that the Sage list will find this method "not right" > for a variety of reasons but I can tell you that there is no > perfect solution. The Axiom debate raged on for about a year. > Time-boxing isn't perfect but it allows big changes to > occur without breaking everyone and little changes to occur > without annoying everyone. > > Every project seems to have this debate. Good luck with it. Thanks for sharing the above. 1. How do you think your choice of releases and version numbers impacted the number of Axiom users? Developers? 2. Now that you've had the above version/release schedule for a few years, is there anything you would change? 3. How did your debate about the above end? Was their some definitive argument, or? -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On 05/26/10 09:48 PM, leif wrote: On 26 Mai, 21:50, "Dr. David Kirkby" wrote: On 05/26/10 05:34 PM, leif wrote: I like the risk assessment field idea. Me too, perhaps give it a different name. What would you call it? There are at least three things to consider I can think of. 1) What are the risks associated with a change? impact (quantitive; severity is too hard) 2) The probability of the change causing a problem. ? at least *what* it might cause? Who knows... 3) The impact such a problem would cause. affected components There might be others. Yes. Just lost one. I don't follow you. What have you lost? 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
The Axiom project had a long debate about releases and version numbers which I see is about to happen here. Axiom decided that a reasonable balance was to make 2 decisions, one about releases and one about versions. RELEASES There is a choice between releasing often and releasing, say, yearly. Sage releases about every week or two at the moment. The upside of this strategy is that people get the latest version immediately. The downside of this strategy is that people are ALWAYS in update mode and big changes are very hard to manage in a small window (2 days?) First, there would be a "silver" and a "gold" releases. The silver version is updated continuously and available from most of the sites with a git pull or git clone. The "gold" release would be a time-boxed release every 2 months. This gives people who care about a particular change a way to get the latest release immediately. It allows others who just want "the system", a way to update at a more reasonable pace, maximally, every 2 months. The "gold" release is maintained on github, the "silver" is on all other sites. VERSIONS Version numbers get religious really fast and the debate is not very productive. Essentially, a single number is not sufficient to carry all of the information about what might have changed, especially if you have a component system. Since git maintains a 40-digit SHA1 hash for every commit it is sufficient for a version number. Any reference to a single hash number gives all of the required information. This is sufficient for "silver" releases. Since the time-boxed "gold" releases are 2 months apart it is sufficient to use the form "May 2010" as the unique "release number". This is easy to distinguish from "March 2010". I'm sure that the Sage list will find this method "not right" for a variety of reasons but I can tell you that there is no perfect solution. The Axiom debate raged on for about a year. Time-boxing isn't perfect but it allows big changes to occur without breaking everyone and little changes to occur without annoying everyone. Every project seems to have this debate. Good luck with it. Tim Daly kcrisman wrote: On May 26, 3:56 pm, William Stein wrote: On Wed, May 26, 2010 at 12:50 PM, Dr. David Kirkby wrote: On 05/26/10 05:34 PM, leif wrote: On 26 Mai, 18:09, Robert Bradshaw I like the risk assessment field idea. Me too, perhaps give it a different name. What would you call it? There are at least three things to consider I can think of. 1) What are the risks associated with a change? 2) The probability of the change causing a problem. 3) The impact such a problem would cause. There might be others. Even things that have a fairly high probability of causing a problem are probably not worth worrying about too much if the impact would be minimal. Conversely, even something which has a low probability of causing a problem, but would have major consequences, needs to be taken seriously. However, unless there was a *major* change in Sage release practices, it would be a bit pointless doing any sort of risk analysis. I don't detect much of an appetite for a major change in Sage release practices. In fact, I detect quite the converse. At a bare minimum, any major change should be designed by people who have actually done some Sage releases. Wouldn't it be easiest for someone to change the 5.0 release date thingie on Trac to "sometime in June, but may be pushed to July or later in order to fulfill goals (Cygwin, etc.)"? This seems like even more of a tempest in a teapot than the SPKG.txt thread ;) - kcrisman -- 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On May 26, 2010, at 1:23 PM, kcrisman wrote: On May 26, 3:56 pm, William Stein wrote: On Wed, May 26, 2010 at 12:50 PM, Dr. David Kirkby wrote: On 05/26/10 05:34 PM, leif wrote: On 26 Mai, 18:09, Robert Bradshaw I like the risk assessment field idea. Me too, perhaps give it a different name. What would you call it? There are at least three things to consider I can think of. 1) What are the risks associated with a change? 2) The probability of the change causing a problem. 3) The impact such a problem would cause. There might be others. Even things that have a fairly high probability of causing a problem are probably not worth worrying about too much if the impact would be minimal. Conversely, even something which has a low probability of causing a problem, but would have major consequences, needs to be taken seriously. However, unless there was a *major* change in Sage release practices, it would be a bit pointless doing any sort of risk analysis. I don't detect much of an appetite for a major change in Sage release practices. In fact, I detect quite the converse. At a bare minimum, any major change should be designed by people who have actually done some Sage releases. Wouldn't it be easiest for someone to change the 5.0 release date thingie on Trac to "sometime in June, but may be pushed to July or later in order to fulfill goals (Cygwin, etc.)"? This seems like even more of a tempest in a teapot than the SPKG.txt thread ;) I didn't know anyone even looked at those numbers--maybe it would be better to put it in the *past* so people know not to trust it. I just deleted the date for now, though hopefully June is still a realistic target. - 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On 26 Mai, 21:50, "Dr. David Kirkby" wrote: > On 05/26/10 05:34 PM, leif wrote: > > > On 26 Mai, 18:09, Robert Bradshaw > > >> I like the risk assessment field idea. > > > Me too, perhaps give it a different name. > > What would you call it? There are at least three things to consider I can > think of. > > 1) What are the risks associated with a change? impact (quantitive; severity is too hard) > 2) The probability of the change causing a problem. ? at least *what* it might cause? Who knows... > 3) The impact such a problem would cause. affected components > There might be others. Yes. Just lost one. > Even things that have a fairly high probability of causing a problem are > probably not worth worrying about too much if the impact would be minimal. Such as not being functional on an obsolete platform ;-) > Conversely, even something which has a low probability of causing a problem, > but > would have major consequences, needs to be taken seriously. Yes, as Robert B. stated in another thread, a minimal "not hard" (1 character) change can have big consequences... :) (So it might be "trivial" as well as "critical".) > However, unless there was a *major* change in Sage release practices, it would > be a bit pointless doing any sort of risk analysis. I don't detect much of an > appetite for a major change in Sage release practices. In fact, I detect quite > the converse. Looks like... (I personally would replace many Sage "releases" by commits to the central repository, which should be a developer's resource, as opposed to "true" releases (including betas) for end users. IMHO some tickets are merged into "releases" too early, others too late. The notion of "alpha" releases is also different in Sage; have there ever been betas? ... Intermediate releases and their download could be avoided/replaced by just announcing which tickets will be/have been merged, s.t. a developer (more or less automatically) only updates the parts he's working on if appropriate.) -Leif -- 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On May 26, 3:56 pm, William Stein wrote: > On Wed, May 26, 2010 at 12:50 PM, Dr. David Kirkby > > > > > > wrote: > > On 05/26/10 05:34 PM, leif wrote: > > >> On 26 Mai, 18:09, Robert Bradshaw > > >>> I like the risk assessment field idea. > > >> Me too, perhaps give it a different name. > > > What would you call it? There are at least three things to consider I can > > think of. > > > 1) What are the risks associated with a change? > > > 2) The probability of the change causing a problem. > > > 3) The impact such a problem would cause. > > > There might be others. > > > Even things that have a fairly high probability of causing a problem are > > probably not worth worrying about too much if the impact would be minimal. > > > Conversely, even something which has a low probability of causing a problem, > > but would have major consequences, needs to be taken seriously. > > > However, unless there was a *major* change in Sage release practices, it > > would be a bit pointless doing any sort of risk analysis. I don't detect > > much of an appetite for a major change in Sage release practices. In fact, I > > detect quite the converse. > > At a bare minimum, any major change should be designed by people who > have actually done some Sage releases. > Wouldn't it be easiest for someone to change the 5.0 release date thingie on Trac to "sometime in June, but may be pushed to July or later in order to fulfill goals (Cygwin, etc.)"? This seems like even more of a tempest in a teapot than the SPKG.txt thread ;) - kcrisman -- 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On Wed, May 26, 2010 at 12:50 PM, Dr. David Kirkby wrote: > On 05/26/10 05:34 PM, leif wrote: >> >> On 26 Mai, 18:09, Robert Bradshaw >> >>> I like the risk assessment field idea. >> >> Me too, perhaps give it a different name. > > What would you call it? There are at least three things to consider I can > think of. > > 1) What are the risks associated with a change? > > 2) The probability of the change causing a problem. > > 3) The impact such a problem would cause. > > There might be others. > > Even things that have a fairly high probability of causing a problem are > probably not worth worrying about too much if the impact would be minimal. > > Conversely, even something which has a low probability of causing a problem, > but would have major consequences, needs to be taken seriously. > > However, unless there was a *major* change in Sage release practices, it > would be a bit pointless doing any sort of risk analysis. I don't detect > much of an appetite for a major change in Sage release practices. In fact, I > detect quite the converse. At a bare minimum, any major change should be designed by people who have actually done some Sage releases. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
Re: [sage-devel] Re: What's the point of two "stable" releases in two days?
On 05/26/10 05:34 PM, leif wrote: On 26 Mai, 18:09, Robert Bradshaw I like the risk assessment field idea. Me too, perhaps give it a different name. What would you call it? There are at least three things to consider I can think of. 1) What are the risks associated with a change? 2) The probability of the change causing a problem. 3) The impact such a problem would cause. There might be others. Even things that have a fairly high probability of causing a problem are probably not worth worrying about too much if the impact would be minimal. Conversely, even something which has a low probability of causing a problem, but would have major consequences, needs to be taken seriously. However, unless there was a *major* change in Sage release practices, it would be a bit pointless doing any sort of risk analysis. I don't detect much of an appetite for a major change in Sage release practices. In fact, I detect quite the converse. 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On 26 Mai, 18:09, Robert Bradshaw wrote: > On May 26, 2010, at 12:59 AM, David Kirkby wrote: > > > Looking at the Sage roadmap > > >http://trac.sagemath.org/sage_trac/roadmap > > > I see Sage 4.4.3 is "A tiny minor release on the way to 5.0" which is > > due on 30th May. > > > Sage 5.0 is due out two days later on first of June. > > The release date for 5.0 was picked somewhat arbitrarily way in > advance. It will be released when the goals are met, which is highly > unlikely to be the first of June (though hopefully not too much > further than that). June 1st what year? ;-) 50% of the tickets for 5.0 have already been closed (unfortunately, that's only one out of two). > I like the risk assessment field idea. Me too, perhaps give it a different name. -Leif -- 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On 26 Mai, 16:32, Jason Grout wrote: > On 5/26/10 2:59 AM, David Kirkby wrote: > > > I sometimes wonder if trac tickets should have a "risk factor" > > attached to them. Something like > > > 1)- Very low risk (Typos, documentation errors, numerical noise on > > doctests.) > > 2) Low risk. (Changes that occur on only one or two rarer operating > > systems, or specific versions of specific Linux distributions). > > 3) Medium risk (Changes to the library) > > 4) High risk. (Updates of most standard packages) > > 5) Very high risk (Updates to standard packages which are used by many > > people on all systems (MPIR, MPFR, Python etc) or if a new standard > > package is added to Sage. > > I would be willing to try filling out such "risk factor" fields in trac, +1 That would avoid setting "priority" to minor or trivial to indicate harmless patches. Awaiting an "official" release announcement on sage-release/sage- devel, with documentation of what was merged. So far, I've found 17 tickets merged, 16 of them related to Cygwin; some of them not closed the usual way. (More to come on other threads, but or because it is early morning in Seattle... ;-) -Leif -- 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
[sage-devel] Re: What's the point of two "stable" releases in two days?
On 5/26/10 2:59 AM, David Kirkby wrote: I sometimes wonder if trac tickets should have a "risk factor" attached to them. Something like 1)- Very low risk (Typos, documentation errors, numerical noise on doctests.) 2) Low risk. (Changes that occur on only one or two rarer operating systems, or specific versions of specific Linux distributions). 3) Medium risk (Changes to the library) 4) High risk. (Updates of most standard packages) 5) Very high risk (Updates to standard packages which are used by many people on all systems (MPIR, MPFR, Python etc) or if a new standard package is added to Sage. I would be willing to try filling out such "risk factor" fields in trac, though of course, risk assessments also carry a risk factor. Jason -- 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
