How about support for Python 3.3 (to be released within a month) and PR #376?

I've added your PR in. Can you post issues that are not working in Python 3.3? I thought that everything is fixed there.

I don't think your patches for Python 3.3 were backported/applied to the maintenance/1.7.x branch. Am I wrong?

I see. You are right. I've created the issue #399 and added it into my issues above.

PR #390 should be back-ported to maintenance/1.7.x

eebd7b2 should also be back-ported to fix separate compilation.

#378, #392 both represent the same regression, and as a regression they're release-critical. Worst case we can revert the offending commit (2c04244), since it's better to leave an old bug unfixed than to introduce a new one. But it should be pretty easy to fix; #392 practically has a patch already.

#387 is also a regression, and probably easy to fix.

@njsmith, thanks for the issues. I've added it to the description.

Another task for Python 3.3: regenerate numpy/random/mtrand/mtrand.c with Cython 0.17.

@cgohlke, I've created #416 for this.

Can we backport #433 (Intel compiler flags) too?

Can #445 be made release critical? It breaks several third party packages as reported on the mailing list.

I think there are several untracked bugs described in this message (maybe just need notes in the release notes, but that's still a bug):
http://thread.gmane.org/gmane.comp.python.numeric.general/51429/focus=51447

Re: #445: for 1.7 purposes you could either merge it (or something like it), or you could revert 5a471b5 and the followup commit ("Retain backward compatibility. Enforce C order"). The first commit is basically just a code cleanup along with some tiny speed increase, so absolutely not release-critical, and the second commit (and #445) are then fixing release-critical bugs introduced by the first commit. So as release manager I guess you get to make the call as to which approach to getting the release out will work better for you :-).

Hi @certik: I would use the milestones mechanism for keeping such a list up to date. We have found it fairly effective.

I've added issues concerning regressing and backward incompatibilities:
#469 and #470
I can submit pull requests for them if my proposed solution is acceptable

In addition, I have added a couple of issues that I think should be fixed before the release:
#465 and #471

#471 is basically a feature request, certainly not a regression... so shouldn't block the release IMO.

@njsmith : agreed that it shouldn't block the release, as it isn't a regression. However it is more of a bug than a feature request IMHO :)

On Sep 30, 2012, at 1:19 PM, njsmith wrote:

#471 is basically a feature request, certainly not a regression... so shouldn't block the release IMO.

+1

—
Reply to this email directly or view it on GitHub.

@GaelVaroquaux, thanks for the tip with milestones, I was not aware of them! I am going to make use of it now.

hi @certik would you consider merging #646 into master? a fellow debian developer verified it fixes the crash against the current master - thanks

I went through all the comments here and everything has been merged or fixed by now. We now use the milestones to keep track of issues that need fixing before the release. I am now going over the issues in the description to make sure that all is fixed or tracked.

I went over the issues in the description and it looks like that they are all fixed & backported, or open and milestone added. So I am closing this issue.