On Fri, Dec 2, 2011 at 10:42 AM, Aaron Meurer <[email protected]> wrote: > On Fri, Dec 2, 2011 at 10:57 AM, Vladimir Perić <[email protected]> wrote: >> On Fri, Dec 2, 2011 at 5:05 PM, Aaron Meurer <[email protected]> wrote: >>> On Fri, Dec 2, 2011 at 2:22 AM, Mateusz Paprocki <[email protected]> wrote: >>>> Hi, >>>> >>>> On 30 November 2011 22:50, Aaron Meurer <[email protected]> wrote: >>>>> >>>>> Yeah, I'm totally free until the end of January, starting in two >>>>> weeks. We'll probably need to do some cleaning up from pull requests >>>>> and stuff after GCI too (e.g., right now, I'm basically ignoring all >>>>> non-critical non-gci pull requests). >>>> >>>> >>>> I also overestimated my spare time before leaving to India. Right now I'm >>>> waiting for my flight at Munich airport. Well, at least we started writing >>>> release notes, which is good because there are so many changes (over 1400 >>>> commits already). >>>> >>> >>> Exactly. Releasing takes forever. If we released once a month, we >>> would constantly be in a release cycle. >> >> Ok, we can also brainstorm what is needed to make the release process >> quicker and less painful? Aaron, ideas? You are the only one who >> actually went through it. > > Others have done it too (I've only done the last two). > > The most time consuming thing was fixing all the blocking issues. I > don't know of any way to alleviate that, other than that the less time > it has been since the last release, the fewer things there will be to > do. > > As far as things on https://github.com/sympy/sympy/wiki/New-Release > go, the more automated they can be, the easier it will be. For > example, fixing the PyPI thing will make that part much easier the > next time around. > > Going through that, the things that I remember taking the longest to do were: > > - Running all the tests with tox. This isn't hard, especially if you > already have a ready-to-go tox.ini file, but it takes forever > nonetheless. > > - There are almost always test failures, which have to be fixed. > Sometimes, these happen on all the branches, sometimes, they happen on > just some configurations. If we had some kind of a build-bot, I think > this could be alleviated by fixing them before release time. Also, we > need to get into the habit of running sympy-bot on *every* pull > request before merging it, so that failures don't get into master (a > build-bot would help with this too). > > - Here's something very concrete that we could fix. There are several > things to test at https://github.com/sympy/sympy/wiki/New-Release that > we only test at release time. Since we don't look at it in between, > there are more often than not little problems that crop up with it. > We should add these to setup.py test: > > - Examples: (http://code.google.com/p/sympy/issues/detail?id=698) > > - Plotting: This is to check that the plotting actually works, with > the pictures. This will probably change with the new module, so let's > look at this again once that is in. > > - External tests: If we have a build-bot, we need to make sure that > we test configurations with numpy, scipy, and matplotlib installed. > Also, the sage tests are never run, except at release time. We should > incorporate it into the test runner to actually run them if sage is > installed (there were quite a few sage errors with 0.7.0 because of > this and the fact that they weren't even run for 0.6.7 or 0.6.6). > This is http://code.google.com/p/sympy/issues/detail?id=2481. > > - Authors list: We need to update .mailmap, so that we can directly > compare git log --format="%aN <%ae>" | sort -u exactly with the > AUTHORS file. Then, a simple extension of that shell command will give > you all authors who weren't added to the AUTHORS file, and where they > should be in it. I created a GCI task for this > (http://code.google.com/p/sympy/issues/detail?id=2893). > > - Making the release notes. Any thoughts on how to make the release > notes process easier? I know we discussed this the last time we > released, but we apparently didn't implement any useful suggestions. > > I've made sure that all the relevant issues here are marked for > Code-In, since this seems to be a good way to get things done. > > Other than those things, the best way to make this easier is if other > people help out, instead of just one person doing it all :)
I've done tons of sympy releases. I think that we just need to learn how to distribute the work. What are the release blockers for this release? Let me know if you agree, but as to me, I am perfectly fine with releasing what we have, as long as all tests pass and there are no regressions. One thing that is new in this release is the python 3 support -- should we just run the 2to3 tool and create a tarball, or should we create a repository (or branch in sympy?) for it? Or should the 2to3 tool be run when setup.py is called (I don't like that it is slow)? I think one safe option is to create sympy-py3 repository, that would only contain autogenerated code from 2to3 tool. All fixes/development/changes will go into the proper sympy repository. That way, we can easily and anytime test the python 3 version. Creating a tarball from it will be trivial. In principle this can be automated, but for now I would simply do that by hand for the release candidates. Besides python3, I think that we can just create a new branch 0.7.2, do rc1 tarballs, we'll all test it with all configurations that we can do and so on. Until it all passes, and then we'll rename rc5 (let's say) to release. I can do this if you want and you can help out with the testing. Let me know what you think the best way to handle the py3 thing is. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
