1) who is the notification e-mail sent to when a review is published?

I haven't figured that out yet. I'm not even sure whether email gets sent at all. I'll look into this a week from now, unless someone resolves that earlier. But...

I just tried on one of my patches and the e-mail came with the following headers:

From: pitrou@free.fr Reply-to: pitrou@free.fr, None@psf.upfronthosting.co.za To: pitrou@free.fr Cc: None@psf.upfronthosting.co.za Sujet: Fast path for small int-indexing of lists and tuples (issue9800)

Am I right in assuming that nobody except me (even other people nosied in the Roundup issue) received the notification?

So email did get send ... good. It certainly doesn't consider the nosy list at all at the moment.

(is None@psf some kind of /dev/null?)

I have no idea where that came from.

2) if I look at http://bugs.python.org/issue9962, only the second patch of all three has been enabled for review. Yet they were all created through "svn diff" against a recent py3k checkout.

They had both the same problem: it could figure out the revision number the patch applied to (e.g. 85039), but not the branch that this revision is for. That's because the revision is 85039, and in r85039, only /peps got modified. I see... so the revision number is mostly useless when trying to identify the branch. You should be able to fix this by manually filling out the branch on the file. I'll have to come up with a better way to determine the branch which a patch was created on. Perhaps going back in history and taking the first branch where the patch cleanly applies can do the trick. Regards, Martin

On Sat, Oct 2, 2010 at 3:55 PM, "Martin v. Löwis" wrote:

I'll have to come up with a better way to determine the branch which a patch was created on.

That would also be helpful for those of us using DVCS software to talk to the svn server. :-) -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com/

On Thu, 07 Oct 2010 23:04:54 +0200 "Martin v. Löwis" wrote:

However, if I get something like

diff -r e981b6cc56b0 Include/longintrepr.h --- a/Include/longintrepr.h Thu Oct 07 03:12:19 2010 +0200 +++ b/Include/longintrepr.h Thu Oct 07 13:53:41 2010 +0200

I have no clue where I should look for the base revision that the patch was created against.

As I said, most patches are supposed to be produced against py3k HEAD, so you could try just that as the primary heuristic. I think you may trying too hard to find smart ways of inferring the correct svn rev and branch, while developing against latest py3k is, most of the time, the required standard. Outdated patches are not really helpful anyway. Regards Antoine.

Le jeudi 07 octobre 2010 à 23:17 +0200, "Martin v. Löwis" a écrit :

...

As I said, most patches are supposed to be produced against py3k HEAD, so you could try just that as the primary heuristic.

I think this is impractical. There are tons of patches (the majority) which are in the tracker and *not* against py3k head. So this heuristics will only cover a small minority.

I don't understand what the problem is. As long as the patch *applies* cleanly on py3k HEAD, it's ok. If it doesn't, the patch will have to be re-generated anyway.

...

I think you may trying too hard to find smart ways of inferring the correct svn rev and branch, while developing against latest py3k is, most of the time, the required standard. Outdated patches are not really helpful anyway

Hmm. So how many versions should I go back in py3k until giving up?

Zero. Regards Antoine.

I feel that, only if a roundup issue has patch, the corresponding rietveld issue be created, it is more helpful there and avoids needless duplication.

I have changed that now. Regards, Martin

Am 05.10.10 20:15, schrieb Alexander Belopolsky:

I followed the review link from issue5109 to arrive at http://bugs.python.org/review/5109/patch/179/325 . On the review page I clicked on Modules/arraymodule.c> View for side-by-side diff and got

Error fetching None/Modules/arraymodule.c?rev=83179: InvalidURLError: Protocol '%s' is not supported.

That currently happens for a lot of patches. It can't figure out what the base branch is, and goes to the Rietveld Issue object - on which it is None (because I believe Rietveld is misguided in associating base URLs with issues - they belong to patchsets, as different patches on the same issues might work on different branches).

On the other hand, the unified diff link works.

It already has the unified diff - just not the base text that it was generated from (and hence also not the new text).

Note that the "Tracker Branch" shows /branches/release27-maint even though the patch is for py3k.

Yes - it miscomputed it, based on the revision number in the patch (which was a revision in which 2.7 was modified). Regards, Martin

I attempted to fix the branch at http://bugs.python.org/file18220 , but it did not trigger rietveld update. I assume you made "Tracker Branch" editable on purpose, but there should be a way rietveld side to know when this field is changed I think.

Please start submitting issues with the Rietveld integration into the meta tracker. Regards, Martin