On Oct 13, 2009, at 8:09 PM, Jason Grout wrote: > Dr. David Kirkby wrote: > >> >> I know we have had this discussion before, but I do not seem to be >> alone >> on my views on this one. >> >> It is not clear to me there needs to be very frequent releases. I >> know >> you say Apple itunes brings out a new release every couple of >> weeks, but >> this is quite a different sort of market. Wolfram Research bring >> out a >> major Mathematica release every couple of years, and minor releases >> every 6 months or so. That seems about the norm for professional >> software. > > > I see this as an advantage of Sage. For example, there were bugs in > Mathematica that I ran into that had to wait a long while before they > were fixed (one I'm thinking of still is not fixed, and bothered me > the > other day when I drew a graph!). I just have to live with it for > another 6 months. > > >> >> IMHO, making a new release every 6 months, whilst making all >> alphas, and >> release candidates available to anyone who want them would be better. >> The releases could be more thoroughly tested, but people could still >> play with the latest unstable stuff if they want to. > > > Here are some random responses to this comment: > > You make this comment as if the code base is unstable after only 2-3 > months. If a patch makes the code unstable (e.g., doctests fail or > compilation fail), then it is good grounds for rejecting the patch. I > think it's much easier to maintain stability (e.g., make sure doctests > pass, it compiles, etc.) all along, rather than let the codebase be > unstable for several months and then tighten it up for a release. > > As a developer who often develops things that I know my class will be > using sometime this semester, it would be a disincentive if official > releases were on the order of 6 months. > > If we have the manpower, 4-5 weeks seemed about right. That was short > enough time that it wasn't a big deal to miss a release in finishing > up > a feature (the next release was always not too far distant). However, > there was always the incentive of "if I work just a bit more on > polishing this up, I can see it in an official release in a week or > two", so it at least helped me to be more active in development. > With a > longer release cycle, there's a greater temptation to either put off > development (at the beginning of a cycle) or argue for delaying the > release for this one last really important patch, so that people can > use > it for the next 6 months. > > For this release especially, it seems like there have been lots of > problems reported that were answered "just wait until the next > release". > Which, as we know, has been a very long wait compared to what we > expected. > > Also, I would imagine that the vast majority of users are using > sagenb.org, which is automatically updated. This takes out the hassle > of always having to update your release to the latest. > > If we are really are trying to help users become developers, then > putting the freshest codebase in their hands is very important. I > think > Linus has the right attitude here of release early, release often. > If I > was thinking of fixing something small (how contributors usually > start), > but then I found out that in order to fix the small thing, I had to > download the latest alpha because a huge amount of the code had > changed > in the 4 months since the past release, I would probably just forget > it. > > As it is, there is a semi-major research code contribution I plan to > make before Christmas that will be needed at a workshop in January, > so I > certainly hope that we don't have 6 months before the next release! > > Jason
I was just about to compose a long email on this thread, but you've essentially hit every point I wanted to make. In fact, I see no advantage for long release cycles at all--it's more work for the release manager, and it's not like users who don't want the new features are forced to upgrade. We have 66 (and counting) positively reviewed tickets out there right now, so for once it's not the reviews that are slowing us down. Hypothetically, all these could just be merged on top of 4.1.2 and 4.1.3 or 4.2 could be released right away, but things are clearly not that simple. Typically there are not many blockers--most of the time if a working patch is not available the bug/feature is simply pushed off to the next release. The question is what, exactly, makes actually getting releases out so difficult? Is most of the time spent getting things working on uncommon (presumably little-tested) systems? Are the obstructions typically due to patches that were not actually ready to go in (despite positive reviews) or changes in the target platforms (e.g. gcc version bumps)? Essentially I'm asking what makes release management hard before trying to figure out if there a way to better distribute the load? - 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 -~----------~----~----~----~------~----~------~--~---
