I can't speak for general acceptance. I certainly think myself that it is worthy, though.
One thing that might be an issue is that the project of just creating a good release proces is not enough to fill an entire GSoC project. So you should consider adding some to it. My suggestion is to improve SymPy-Bot, which despite Travis, is still useful in my opinion. Recently I have set up an old Linux laptop to run SymPy-Bot automatically. But "automatically" actually just means that I have set it to run ./sympy-bot review 1850 1851 1852 ... 1900 --profile all-tests-no-pypy (see my profile at https://github.com/asmeurer/dotfiles/blob/dell/.sympy/sympy-bot.conf). This runs the bot on each request, and if it manages to get to a pull request before it actually exists, it automatically sits there and waits until it does, checking every so often. This much is already implemented, but it would be great to make it smarter. Stefan used to run a bot using some hackish script (https://gist.github.com/Krastanov/2985162 I believe) that checked for commits that weren't tested yet. My idea of how it should work is outlined at https://github.com/sympy/sympy-bot/issues/63. It was also discussed on the mailing list a lot (search for around this time last year). Basically, I think the reviews site should keep track of what reviews are done, and you should be able to put sympy-bot in an automated "work" mode, which would poll the reviews site for a new pull request to review. These would be prioritized based on various factors, like if it's been tested yet on the available platforms, or if it's very active, and so on. Also, currently my laptop is just sitting in my closet, and I check on it every once in a while. But I would like to be able to ssh into it from my main laptop and manage everything. In addition to some tasks that could probably be done automatically, like occasionally doing a "git pull" in the sympy-bot repo, occasionally doing a "git pull; ./bin/use2to3" in the sympy repo (since it copies that over, and to make things faster for testing in Python 3), there are also things that need to be done manually, like making sure that it doesn't die. So it would be nice to have some basic infrastructure on this, as well as some documentation on how to do it (I am not very good with setting up Linux servers, and I imagine others aren't as well). I encourage you to read through all the open issues for sympy-bot (https://github.com/sympy/sympy-bot/issues?state=open), and also search for a similar proposal and its discussion from last year. Regarding your ideas so far, I take it you've read my mailing list post linked to on issue. I think you have oversimplified what needs to be done. Some stuff you missed: - Getting the list of AUTHORS (including making sure that the AUTHORS and .mailmap files are up-to-date). - Writing the release notes. There's not much we can do to automate this, but there is some. For example, literally all changes these days come in pull requests, so to find what has changed in a release, it is enough to look through all the pull requests that were merged in that release. A tool that automatically listed these in a nice way would make writing the release notes much easier. - There are several sites that we need to update. We can probably forgo updating any site not owned by us (of the ones listed at the bottom of https://github.com/sympy/sympy/wiki/new-release), but there are several that are, such as the homepage, sympy-live, sympy-gamma, and the blog. - It would be nice if we could somehow keep the "dev" docs up-to-date automatically. Ondrej probably still has a server somewhere that can do this (he must, because something is updating Planet SymPy). It would also be cool if we could somehow add a "dev" version to SymPy Live and SymPy Gamma. Of course, if we start releasing once a week, this will be completely unnecessary. - There are dozens of little things, some of which are mandatory, and some of which would just be nice, that you can implement. I can help you work through an exact release process, and you can see just how much work it really is (though the wiki page should already give you an idea). For example, it would be nice if the coverage_doctest script checked which docstrings are imported into Sphinx, so that we not only have good documentation coverage in the code, but in the online docs. This would probably take no more than a day to write, but there are dozens of little things like this that relate to the whole idea of automating our workflow. I hope that gives you some ideas. I would wait to see how others feel about this idea. You might want to come up with a secondary proposal in case we decide we don't want this one. Your work so far looks promising, so I would hate to see your GSoC chances destroyed just because you picked a project that we decided we didn't want. Finally, if you want to pursue this idea, I would suggest making another patch, which is more inline with the idea presented here, so that we can see that you are capable of this work too (that isn't to say we don't like your erfc patch, but more is always better). Perhaps a fix to sympy-bot, for example. Aaron Meurer On Thu, Mar 7, 2013 at 9:25 AM, Ramana Venkata <[email protected]> wrote: > Recently in one of the thread I saw somebody mentioning 'automating the > release process of sympy' to be a GSoC idea for 2013 and also vaguely > discussed with Aaron on IRC channel. I want to work on this idea. I have > submitted a pull request and waiting for the review. > > I have read the discussion in the following thread > https://groups.google.com/forum/#!topic/sympy/UfNhyFv-oMg/discussion . i > think the goals of the automating process are broadly the following: > > -> Run all the tests mentioned in New Release page > -> Change the version numbers and create tar balls of the source > -> Upload the tar balls to necessary sites > -> Upload new documentation for the new release at http://docs.sympy.org > -> Change year in necessary places at the start of every year and other > miscellaneous things > > I have also looked at numpy-vendor which Ondrej has suggested. I have been > familiarising myself with Fabric and Vagrant softwares currently for this > idea. > > I am just writing this thread to see the general acceptance of this idea as > a part of GSoC in our community. I haven't presently planned on how to > implement this but if this idea gets accepted I will write an in-depth > proposal. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
