On the topic of testing: What is the reason that the pull requests are not all tested automatically? And tox run every week or so. I thought that all the code for the automated testing is already written. And there is that google app engine instance. If it's only a processing power issue I have a relatively old core2due computer that is almost completely unused and I'll gladly make an ssh account for you so you install the automated sympy-bot (or I can do it with your help). Or if I'm wrong and this stuff is not automated one can just write a one line cron job workaround for it.
Stefan 2011/12/2 Ondřej Čertík <ondrej.cer...@gmail.com> > On Fri, Dec 2, 2011 at 10:42 AM, Aaron Meurer <asmeu...@gmail.com> wrote: > > On Fri, Dec 2, 2011 at 10:57 AM, Vladimir Perić <vlada.pe...@gmail.com> > wrote: > >> On Fri, Dec 2, 2011 at 5:05 PM, Aaron Meurer <asmeu...@gmail.com> > wrote: > >>> On Fri, Dec 2, 2011 at 2:22 AM, Mateusz Paprocki <matt...@gmail.com> > wrote: > >>>> Hi, > >>>> > >>>> On 30 November 2011 22:50, Aaron Meurer <asmeu...@gmail.com> 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 sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > 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 sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
