On Wed, Mar 31, 2010 at 1:14 PM, Andrey Novoseltsev <[email protected]> wrote: >> > We all want more testing. I see two options: >> >> > (1) Change lots of other people's behavior. >> > (2) Set up a large-scale automated build farm. >> >> > Though we have neither right now, I see (2) happening before (1). >> > ... >> If I don't either >> >> (a) get much more money in grants, >> (b) have more volunteers willing to do (2) and (1), or >> (c) start a company and sell Sage binaries that are more polished, >> >> then indeed Sage releases will likely never be as polished as >> Mathematica, or even RedHat releases. > > Sage does have now the policy of 100% doctests, patch review system > and detailed guidelines for reviewers (thanks to Minh!). How can > waiting for build confirmations be more difficult?
It is way more difficult. If you did release management you might understand. > How about, say, > such a policy: > - release candidate is made > - if there are no blockers/build problems reported for it during one > WEEK (instead of like 24 hours), it is completely released Reported by whom? The above policy doesn't guarantee anything. > - if there are things that must be fixed, they get fixed and the one > week timer is reset My first worry -- how can you fix the problems that do get reported? Often when people report build problems, those problems are on their personal crufty Linux installs, which they won't or can't give access to, and which can be (mis-)configured in all kinds of ways, or even have faulty hardware. > - meanwhile, this release candidate can be used as a base for the NEXT > release, making sure that all the new blockers also get merged > Even if not all platforms will get checked, most of them probably will > be, at least more than in one day. Is it actually more work for the > release managers to do this?.. No, I don't volunteer to be a release > manager who does this, but if there are mandatory policies for patch > writers and reviewers, why should not there be policies for release > managers? > > By the way, while it is possible to make a patch/package for Sage in 3 > minutes, > http://sagemath.org/doc/developer/walk_through.html#creating-a-change > states > "Once you have something you like, do everything suggested for > reviewing a patch." > and > http://sagemath.org/doc/developer/walk_through.html#reviewing-a-patch > states > "If affected files pass tests, then run ./sage -testall. This will > take a while to complete. No, it is not optional. " > so I don't think that it is possible to follow standard policies and > make something which is "ready to merge" so fast... Perhaps in this > case it was reasonable to make an exception, but I also understand how > David can have enough time to write a long email, but not enough to > post a patch. If you understand the details of the change in the spkg we're talking about, you might have a different perspective.... > I definitely prefer Sage over Maple, which I used for a while, and > from my little experience with other "M"s I also think that Sage has a > lot of advantages. I also think that Sage has a lot of advantages > compared to some other free/open-source math programs. So - I think > that Sage is great and I intend to continue using it indefinitely. > However more than once I regretted "sage -upgrade" because it broke > something that I was using and had to use it again right then. As John said later, don't use "sage -upgrade" in a context that could *possible* result in such a regret. The "sage -upgrade" command asks you the explicit question: "WARNING: This is a source-based upgrade, which could take hours, fail, and render your Sage install useless!! Do you want to continue [y/N]?" for a reason. > I also > had several occasions of "live Sage introductions" when I had to say > "Usually, you can do this cool thing: ... , but unfortunately now it > is broken and probably will be fixed in the next release." It would be > really nice not to say it often. That's unfortunate. Some ways you can help: (a) help us get the doctest coverage of the Sage library up from 80+eps% to 100% (b) help referee patches -- There are over 150 tickets needing review right now: http://trac.sagemath.org/sage_trac/report/10 (c) help fixing bugs -- There are over 800 bugs listed here: http://trac.sagemath.org/sage_trac/query?group=status&type=defect&milestone=sage-4.4 -- William -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org To unsubscribe, reply using "remove me" as the subject.
