On 2 December 2011 22:23, Aaron Meurer <[email protected]> wrote: > 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? > Part of them are already merged with filenames tutorial.country_code.txt. The other part is as pull request.
> > 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. > > -- 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.
