On Tue, Mar 26, 2013 at 5:42 AM, Aaron Meurer <[email protected]> wrote: > We currently have 92 open pull requests, and that number is only going > to get much worse in April if we are accepted for GSoC. Working on > the GSoC application is high priority now, but we should also focus on > clearing the pull requests a bit. > > For those open pull requests that are marked as WIP, we need to > determine exactly what work still needs to be done, and more > importantly, if it is essential or not that the pull request not be > merged until that work is completed. It's tempting to mark a pull > request as WIP until you have done all the work you want to do, but if > the work that is done so far is OK, then it should be merged, and new > work put in a new pull request. > > I think there are several pull requests that are fine to go. They just > need a final review (or a review at all). My two most recent pull > requests (1916 and 1876) fall into this category. > > For those that really do have work to do, add a TODO to the pull > request description (or a comment if you don't have push access). It's > nice to use the GitHub Markdown checkbox lists, which work like > > - [ ] item1 > - [ ] item2 > > Then the items can be checked off as they are completed, and once > everything is checked, you will know that it is done. > > Better yet, send a pull request to the person who made the pull > request fixing the issues. Just fix the issues in your branch, and go > like you are making a pull request to SymPy, but then change it to go > against the person's branch. If GitHub doesn't show the person's name > in the list, go like you are sending a pull request to someone else > and then change the name in the url to the one you want. > > And even though we do want to clear the pull request queue, please > don't merge any pull request unless it has a passing Travis review, or > if Travis is acting up, a passing SymPy Bot review. Clearing the pull > request queue is important, but keeping tests passing in master is > more important.
I would suggest to adopt the ipython approach: * create a policy like: https://github.com/ipython/ipython/wiki/Dev:-Closing-pull-requests * find pull requests that are waiting for a response of the original author for more than a month (or require large redesign), close them and post a link to our policy * create a new issue with a link to the PR Here is an example of my own PR, that I simply don't have time to finish up: https://github.com/ipython/ipython/pull/2504 That is the only reasonable way in my opinion. The PR queue should be for pull requests that are being worked on. There is absolutely nothing wrong with closing a pull request that nobody has time to finish. I went ahead and created our own policy page here: https://github.com/sympy/sympy/wiki/Dev:-Closing-pull-requests Feel free to modify it/update it. Once we all agree with the text, I'll go over old PRs and close them according to the policy (plus create an issue with it). Ondrej -- 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-US. For more options, visit https://groups.google.com/groups/opt_out.
