On Dec 2, 2011, at 1:49 PM, "Ondřej Čertík" <[email protected]> wrote:
> 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 > Aside from some test failures in master, the release blockers are mainly about starting deprecation cycles. See the issues with the milestone-0.7.2 tag. I guess we should also figure out what to do with the translated tutorials. What happens with them now? For Python 3, I think the way to do is to just treat the generated py3k-sympy as a fully working sympy repository for Python 3. So you can just cd py3k-sympy and run setup.py sdist like you would or the normal one, and it will create a Python 3 tarball in py3k-sympy/build/. It shouldn't require more than that, from what I can tell. I will do this in two weeks when I am free (and do it the right way, so that we don't miss anything important). Aaron Meurer -- 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.
