From metatracker at psf.upfronthosting.co.za Mon Nov 5 20:11:25 2012 From: metatracker at psf.upfronthosting.co.za (Heikki Partanen) Date: Mon, 05 Nov 2012 19:11:25 +0000 Subject: [Tracker-discuss] [issue490] Review links crash after changing username Message-ID: <1352142685.19.0.283559618206.issue490@psf.upfronthosting.co.za> New submission from Heikki Partanen: Crash in roundup_helper/middleware.py 1. Open an issue review (bugs.python.org/review#####) link in one browser, session gets created 2. Log into your account with another browser, edit your account, change username into something else 3. Open again the issue review link in the old browser that has the session with old username As the old session has the wrong username, it crashes on this line as no user is found with the old username: roundup_user = User.objects.filter(_username=username)[0] ---------- files: username_change_crashes_rietfeld.patch messages: 2628 nosy: heikki.partanen priority: bug status: unread title: Review links crash after changing username _______________________________________________________ PSF Meta Tracker _______________________________________________________ -------------- next part -------------- diff -r 94173dcc4b3b roundup_helper/middleware.py --- a/roundup_helper/middleware.py Sat Jul 07 17:58:10 2012 +0200 +++ b/roundup_helper/middleware.py Sun Nov 04 23:48:06 2012 +0400 @@ -21,8 +21,14 @@ self.logout(request) return username = eval(session[0].session_value)['user'] - # the username comes from the cookie, so it really ought to exist - roundup_user = User.objects.filter(_username=username)[0] + + # the username comes from the cookie, but might still be invalid + users = User.objects.filter(_username=username) + if not users: + # No user found, force logout to clear bad session + self.logout(request) + return + # if we already have a user from the session, we are done. if request.user.is_authenticated(): if request.user.username == username: @@ -41,7 +47,7 @@ nickname=username, fresh=True) account.put() auth.login(request, user) - + def logout(self, request): # Clear django session if roundup session is gone. auth.logout(request) From techtonik at gmail.com Wed Nov 7 10:46:13 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 7 Nov 2012 12:46:13 +0300 Subject: [Tracker-discuss] Patch tracking Message-ID: I want to play with some patch stats. I need to get all patch files that are attached to open issues? Is there a way to do so on b.p.o? -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: From metatracker at psf.upfronthosting.co.za Wed Nov 7 10:53:12 2012 From: metatracker at psf.upfronthosting.co.za (Serhiy Storchaka) Date: Wed, 07 Nov 2012 09:53:12 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures Message-ID: <1352281992.74.0.611660385155.issue491@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: I?propose to ignore an email signature block. I.e. remove from an incoming email the signature mark line "-- " (two hypens and space) and all lines after the mark, and then remove trailing empty lines. ---------- messages: 2629 nosy: lemburg, serhiy.storchaka priority: wish status: unread title: Ignore email signatures _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Nov 7 11:00:01 2012 From: metatracker at psf.upfronthosting.co.za (Marc-Andre Lemburg) Date: Wed, 07 Nov 2012 10:00:01 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352281992.74.0.611660385155.issue491@psf.upfronthosting.co.za> Message-ID: <1352282401.2.0.387684796197.issue491@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: RoundUp already does this, but for some reason it doesn't consistently work: for some email replies the sig is removed, for others, it's added to the tracker item (which is annoying). Unfortunately, RoundUp does not allow editing the tracker item messages. Otherwise, I'd remove the sigs again by hand. ---------- status: unread -> chatting _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Nov 7 11:04:49 2012 From: metatracker at psf.upfronthosting.co.za (Marc-Andre Lemburg) Date: Wed, 07 Nov 2012 10:04:49 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352281992.74.0.611660385155.issue491@psf.upfronthosting.co.za> Message-ID: <1352282689.49.0.510375936978.issue491@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Here's an example of where it did not work: http://bugs.python.org/msg175052 _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Nov 7 11:22:10 2012 From: metatracker at psf.upfronthosting.co.za (Serhiy Storchaka) Date: Wed, 07 Nov 2012 10:22:10 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352281992.74.0.611660385155.issue491@psf.upfronthosting.co.za> Message-ID: <1352283730.15.0.104308919264.issue491@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be RoundUp can't remove the signature if it longer than the text before the signature? Can you open a test issue and send 1-, 2-, 3-, ..., 20-lines messages with your long signature? _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Nov 7 11:23:54 2012 From: metatracker at psf.upfronthosting.co.za (Serhiy Storchaka) Date: Wed, 07 Nov 2012 10:23:54 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352281992.74.0.611660385155.issue491@psf.upfronthosting.co.za> Message-ID: <1352283834.49.0.205632360714.issue491@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Of course, you can send less messages, using binary search. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From techtonik at gmail.com Wed Nov 7 11:27:23 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 7 Nov 2012 13:27:23 +0300 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352282689.49.0.510375936978.issue491@psf.upfronthosting.co.za> References: <1352281992.74.0.611660385155.issue491@psf.upfronthosting.co.za> <1352282689.49.0.510375936978.issue491@psf.upfronthosting.co.za> Message-ID: I can't see the code where Roundup strips signature. If somebody can find it, it will be easier to factor out and test independently of full roundup machinery. -- anatoly t. On Wed, Nov 7, 2012 at 1:04 PM, Marc-Andre Lemburg < metatracker at psf.upfronthosting.co.za> wrote: > > Marc-Andre Lemburg added the comment: > > Here's an example of where it did not work: > > http://bugs.python.org/msg175052 > > _______________________________________________________ > PSF Meta Tracker > > _______________________________________________________ > _______________________________________________ > Tracker-discuss mailing list > Tracker-discuss at python.org > http://mail.python.org/mailman/listinfo/tracker-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From metatracker at psf.upfronthosting.co.za Wed Nov 7 11:27:46 2012 From: metatracker at psf.upfronthosting.co.za (anatoly techtonik) Date: Wed, 07 Nov 2012 10:27:46 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352282689.49.0.510375936978.issue491@psf.upfronthosting.co.za> Message-ID: anatoly techtonik added the comment: I can't see the code where Roundup strips signature. If somebody can find it, it will be easier to factor out and test independently of full roundup machinery. -- anatoly t. On Wed, Nov 7, 2012 at 1:04 PM, Marc-Andre Lemburg < metatracker at psf.upfronthosting.co.za> wrote: > > Marc-Andre Lemburg added the comment: > > Here's an example of where it did not work: > > http://bugs.python.org/msg175052 > > _______________________________________________________ > PSF Meta Tracker > > _______________________________________________________ > _______________________________________________ > Tracker-discuss mailing list > Tracker-discuss at python.org > http://mail.python.org/mailman/listinfo/tracker-discuss > ---------- nosy: +techtonik _______________________________________________________ PSF Meta Tracker _______________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From metatracker at psf.upfronthosting.co.za Wed Nov 7 11:50:24 2012 From: metatracker at psf.upfronthosting.co.za (Marc-Andre Lemburg) Date: Wed, 07 Nov 2012 10:50:24 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352283730.15.0.104308919264.issue491@psf.upfronthosting.co.za> Message-ID: <509A3CEC.4020500@egenix.com> Marc-Andre Lemburg added the comment: On 07.11.2012 11:22, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > May be RoundUp can't remove the signature if it longer than the text before the signature? Can you open a test issue and send 1-, 2-, 3-, ..., 20-lines messages with your long signature? A test on http://bugs.python.org/issue16426 showed that RoundUp only appears to remove sigs in case they have less than 10 lines (e.g. this reply should have the sig removed). _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Nov 7 13:40:46 2012 From: metatracker at psf.upfronthosting.co.za (R David Murray) Date: Wed, 07 Nov 2012 12:40:46 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352281992.74.0.611660385155.issue491@psf.upfronthosting.co.za> Message-ID: <1352292046.78.0.943073909901.issue491@psf.upfronthosting.co.za> R David Murray added the comment: Yes, 10 lines. It happens in mailgw.py in the parseContent routine: elif signature.match(lines[0]) and 2 <= len(lines) <= 10: # lose any signature break that would also be the routine to modify if one wanted to improve the algorithm for detecting quoted text so that it didn't delete doctest-like snippets. ---------- nosy: +r.david.murray _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Nov 7 17:07:38 2012 From: metatracker at psf.upfronthosting.co.za (Marc-Andre Lemburg) Date: Wed, 07 Nov 2012 16:07:38 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352292046.78.0.943073909901.issue491@psf.upfronthosting.co.za> Message-ID: <509A8744.5020107@egenix.com> Marc-Andre Lemburg added the comment: On 07.11.2012 13:40, R David Murray wrote: > > R David Murray added the comment: > > Yes, 10 lines. It happens in mailgw.py in the parseContent routine: > > elif signature.match(lines[0]) and 2 <= len(lines) <= 10: > # lose any signature > break > > that would also be the routine to modify if one wanted to improve the algorithm for detecting quoted text so that it didn't delete doctest-like snippets. Wouldn't it make sense to remove the <= 10 limit altogether ? Apart from longer signatures, Forwarding emails inline will also result in more than 10 lines being in the email after the "-- ". Does anyone have contact to someone who could make such a change ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 07 2012) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Thu Nov 8 07:07:55 2012 From: metatracker at psf.upfronthosting.co.za (Ezio Melotti) Date: Thu, 08 Nov 2012 06:07:55 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352281992.74.0.611660385155.issue491@psf.upfronthosting.co.za> Message-ID: <1352354875.43.0.158893673486.issue491@psf.upfronthosting.co.za> Ezio Melotti added the comment: I reported this upstream: http://issues.roundup-tracker.org/issue2550780 If they agree, I'll fix it. > for some email replies the sig is removed, for others, > it's added to the tracker item (which is annoying). The latter was already fixed on the main tracker, and I now fixed it on the meta-tracker as well. The solution is adding the following lines to the [mailgw] section of config.ini: # ignore html part of multipart/alternative ignore_alternatives = yes > A test on http://bugs.python.org/issue16426 FWIW there's http://bugs.python.org/issue2771 that can be used for tests. ---------- assignedto: -> ezio.melotti nosy: +ezio.melotti _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Thu Nov 8 08:53:40 2012 From: metatracker at psf.upfronthosting.co.za (Marc-Andre Lemburg) Date: Thu, 08 Nov 2012 07:53:40 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <1352354875.43.0.158893673486.issue491@psf.upfronthosting.co.za> Message-ID: <509B64FE.3020408@egenix.com> Marc-Andre Lemburg added the comment: On 08.11.2012 07:07, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > I reported this upstream: http://issues.roundup-tracker.org/issue2550780 > If they agree, I'll fix it. Thanks, Ezio. At least now I know how to prevent my sig from getting recorded in the tracker ;-) _______________________________________________________ PSF Meta Tracker _______________________________________________________ From ezio.melotti at gmail.com Fri Nov 9 10:00:58 2012 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 9 Nov 2012 10:00:58 +0100 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: The easiest way is probably by using the XML-RPC interface. Follow the examples here: http://roundup.sourceforge.net/docs/xmlrpc.html You can get the list of all the open (status=1) issues with patches (keyword=2) using roundup_server.filter('issue', None, dict(status=1, keyword=2)). You can get the list of files attached to each of the issue using roundup_server.display('issueXXXX', 'files'). I don't know if you can then download the files from there, but you should be able to urlretrieve them from http://bugs.python.org/fileXXXX/. Note that not all the files are necessary patches, so you might need to do some filtering after the download. If you want to experiment with further queries, you can find the keyword, status, etc. ids using e.g. http://bugs.python.org/keyword. Just out of curiosity, what are you planning to do with the patches? If you find something interesting please share it with us. Best Regards, Ezio Melotti -------------- next part -------------- An HTML attachment was scrubbed... URL: From metatracker at psf.upfronthosting.co.za Thu Nov 15 13:53:05 2012 From: metatracker at psf.upfronthosting.co.za (Ezio Melotti) Date: Thu, 15 Nov 2012 12:53:05 +0000 Subject: [Tracker-discuss] [issue483] irker detector for roundup In-Reply-To: <1348834053.04.0.0348292997231.issue483@psf.upfronthosting.co.za> Message-ID: <1352983985.69.0.97200690201.issue483@psf.upfronthosting.co.za> Ezio Melotti added the comment: Committed in http://hg.python.org/tracker/python-dev/rev/045acef7a36f I also updated to irker1.13 (http://www.catb.org/esr/irker/) and irc3.6 (http://pypi.python.org/pypi/irc/). ---------- status: testing -> resolved _______________________________________________________ PSF Meta Tracker _______________________________________________________ From chris.jerdonek at gmail.com Thu Nov 15 22:12:43 2012 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Thu, 15 Nov 2012 13:12:43 -0800 Subject: [Tracker-discuss] "failed issue tracker submission" e-mails Message-ID: I occasionally get e-mails like the below (with three today, which is unusual). Does everyone get these? Is this intended, and what are they for? They don't seem to be linked to my own activity on the tracker. --Chris On Thu, Nov 15, 2012 at 12:58 PM, Python tracker < roundup-admin at psf.upfronthosting.co.za> wrote: > > An unexpected error occurred during the processing > of your message. The tracker administrator is being > notified. > > Return-Path: > X-Original-To: report at bugs.python.org > Delivered-To: roundup+tracker at psf.upfronthosting.co.za > Received: from mail.python.org (mail.python.org [82.94.164.166]) > by psf.upfronthosting.co.za (Postfix) with ESMTPS id 728881C884 > for ; Thu, 15 Nov 2012 21:58:51 +0100 > (CET) > Received: from albatross.python.org (localhost [127.0.0.1]) > by mail.python.org (Postfix) with ESMTP id 3Y2ZgH1WglzRlk > for ; Thu, 15 Nov 2012 21:58:51 +0100 > (CET) > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; > s=200901; > t=1353013131; bh=OUB+ieZrhXLf00fS3ScDXJOs2fZdncpLHhVH8Mq4aG8=; > h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: > Subject:Message-Id:Date; > b=bxgo73yXi3M9v/34ihpVbL175HI0avNqRJ9ZZPR8RJ/Ebf+s6CLSY6KSFvEqsey6o > k9VOuwgxEoJ6EPYG9b80rF0TfIkaPS/ly2PkD0oDeL2MONpJ/T+mCqEYegdK16I1mO > QP53t81gJuW1rACwgBViWQfoGh0NTebNRHzjE2zw= > Received: from localhost (HELO mail.python.org) (127.0.0.1) > by albatross.python.org with SMTP; 15 Nov 2012 21:58:51 +0100 > Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org[140.211.10.72]) > by mail.python.org (Postfix) with ESMTP > for ; Thu, 15 Nov 2012 21:58:50 +0100 > (CET) > MIME-Version: 1.0 > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 > From: python-dev at python.org > To: report at bugs.python.org > Subject: [issue16469] > Message-Id: <3Y2ZgH1WglzRlk at mail.python.org> > Date: Thu, 15 Nov 2012 21:58:51 +0100 (CET) > > > TmV3IGNoYW5nZXNldCBhMmI1NGI2ZDk3NTkgYnkgTWFyayBEaWNraW5zb24gaW4gYnJhbmNoICdk > > ZWZhdWx0JzoKSXNzdWUgIzE2NDY5OiBGcmFjdGlvbihmbG9hdCgnbmFuJykpIGFuZCBGcmFjdGlv > > bihmbG9hdCgnaW5mJykpIG5vdyByYWlzZSBWYWx1ZUVycm9yIGFuZCBPdmVyZmxvd0Vycm9yIChy > > ZXNwLiksIG5vdCBUeXBlRXJyb3IuCmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2L2Ey > YjU0YjZkOTc1OQo= > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Nov 16 03:33:18 2012 From: brett at python.org (Brett Cannon) Date: Thu, 15 Nov 2012 21:33:18 -0500 Subject: [Tracker-discuss] "failed issue tracker submission" e-mails In-Reply-To: References: Message-ID: On Thu, Nov 15, 2012 at 4:12 PM, Chris Jerdonek wrote: > I occasionally get e-mails like the below (with three today, which is > unusual). Does everyone get these? Yes > Is this intended, Yes > and what are they for? I believe Ezio said it's so we know that something failed badly and it isn't overlooked. -Brett > They don't seem to be linked to my own activity on the tracker. > > --Chris > > > > On Thu, Nov 15, 2012 at 12:58 PM, Python tracker < > roundup-admin at psf.upfronthosting.co.za> wrote: > >> >> An unexpected error occurred during the processing >> of your message. The tracker administrator is being >> notified. >> >> Return-Path: >> X-Original-To: report at bugs.python.org >> Delivered-To: roundup+tracker at psf.upfronthosting.co.za >> Received: from mail.python.org (mail.python.org [82.94.164.166]) >> by psf.upfronthosting.co.za (Postfix) with ESMTPS id 728881C884 >> for ; Thu, 15 Nov 2012 21:58:51 +0100 >> (CET) >> Received: from albatross.python.org (localhost [127.0.0.1]) >> by mail.python.org (Postfix) with ESMTP id 3Y2ZgH1WglzRlk >> for ; Thu, 15 Nov 2012 21:58:51 +0100 >> (CET) >> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; >> s=200901; >> t=1353013131; bh=OUB+ieZrhXLf00fS3ScDXJOs2fZdncpLHhVH8Mq4aG8=; >> h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: >> Subject:Message-Id:Date; >> >> b=bxgo73yXi3M9v/34ihpVbL175HI0avNqRJ9ZZPR8RJ/Ebf+s6CLSY6KSFvEqsey6o >> >> k9VOuwgxEoJ6EPYG9b80rF0TfIkaPS/ly2PkD0oDeL2MONpJ/T+mCqEYegdK16I1mO >> QP53t81gJuW1rACwgBViWQfoGh0NTebNRHzjE2zw= >> Received: from localhost (HELO mail.python.org) (127.0.0.1) >> by albatross.python.org with SMTP; 15 Nov 2012 21:58:51 +0100 >> Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org[140.211.10.72]) >> by mail.python.org (Postfix) with ESMTP >> for ; Thu, 15 Nov 2012 21:58:50 +0100 >> (CET) >> MIME-Version: 1.0 >> Content-Type: text/plain; charset="utf-8" >> Content-Transfer-Encoding: base64 >> From: python-dev at python.org >> To: report at bugs.python.org >> Subject: [issue16469] >> Message-Id: <3Y2ZgH1WglzRlk at mail.python.org> >> Date: Thu, 15 Nov 2012 21:58:51 +0100 (CET) >> >> >> TmV3IGNoYW5nZXNldCBhMmI1NGI2ZDk3NTkgYnkgTWFyayBEaWNraW5zb24gaW4gYnJhbmNoICdk >> >> ZWZhdWx0JzoKSXNzdWUgIzE2NDY5OiBGcmFjdGlvbihmbG9hdCgnbmFuJykpIGFuZCBGcmFjdGlv >> >> bihmbG9hdCgnaW5mJykpIG5vdyByYWlzZSBWYWx1ZUVycm9yIGFuZCBPdmVyZmxvd0Vycm9yIChy >> >> ZXNwLiksIG5vdCBUeXBlRXJyb3IuCmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2L2Ey >> YjU0YjZkOTc1OQo= >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> >> > > _______________________________________________ > Tracker-discuss mailing list > Tracker-discuss at python.org > http://mail.python.org/mailman/listinfo/tracker-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Fri Nov 16 07:50:22 2012 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 16 Nov 2012 08:50:22 +0200 Subject: [Tracker-discuss] "failed issue tracker submission" e-mails In-Reply-To: References: Message-ID: Hi, the message you saw was caused by a problem with the new irker detector -- it should be fixed now. For the record the message you received says: """ New changeset a2b54b6d9759 by Mark Dickinson in branch 'default': Issue #16469: Fraction(float('nan')) and Fraction(float('inf')) now raise ValueError and OverflowError (resp.), not TypeError. http://hg.python.org/cpython/rev/a2b54b6d9759 """ I'm not sure why it arrived to you though (or did you see it elsewhere?). Best Regards, Ezio Melotti -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Fri Nov 16 14:23:28 2012 From: rdmurray at bitdance.com (R. David Murray) Date: Fri, 16 Nov 2012 08:23:28 -0500 Subject: [Tracker-discuss] "failed issue tracker submission" e-mails In-Reply-To: References: Message-ID: <20121116132329.C8C7F250070@webabinitio.net> On Fri, 16 Nov 2012 08:50:22 +0200, Ezio Melotti wrote: > Hi, > the message you saw was caused by a problem with the new irker detector -- > it should be fixed now. > For the record the message you received says: > """ > New changeset a2b54b6d9759 by Mark Dickinson in branch 'default': > Issue #16469: Fraction(float('nan')) and Fraction(float('inf')) now raise > ValueError and OverflowError (resp.), not TypeError. > http://hg.python.org/cpython/rev/a2b54b6d9759 > """ > I'm not sure why it arrived to you though (or did you see it elsewhere?). It and at least three others were posted to python-dev. I believe this is because python-dev at python.org is used as the origin address for the emails sent by irker. And I agree with the speculation...I think it is useful that this happens because it alerts us when there are problems with the interface. We could perhaps make it tracker-discuss rather than python-dev, though. --David From chris.jerdonek at gmail.com Fri Nov 16 18:59:38 2012 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Fri, 16 Nov 2012 09:59:38 -0800 Subject: [Tracker-discuss] "failed issue tracker submission" e-mails In-Reply-To: References: Message-ID: On Thu, Nov 15, 2012 at 10:50 PM, Ezio Melotti wrote: > Hi, > the message you saw was caused by a problem with the new irker detector -- > it should be fixed now. > For the record the message you received says: > """ > New changeset a2b54b6d9759 by Mark Dickinson in branch 'default': > Issue #16469: Fraction(float('nan')) and Fraction(float('inf')) now raise > ValueError and OverflowError (resp.), not TypeError. > http://hg.python.org/cpython/rev/a2b54b6d9759 > """ > I'm not sure why it arrived to you though (or did you see it elsewhere?). > The message are being sent to python-dev. See, for instance: http://mail.python.org/pipermail/python-dev/2012-November/122757.html --Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.jerdonek at gmail.com Fri Nov 16 19:07:23 2012 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Fri, 16 Nov 2012 10:07:23 -0800 Subject: [Tracker-discuss] "failed issue tracker submission" e-mails In-Reply-To: References: Message-ID: On Thu, Nov 15, 2012 at 6:33 PM, Brett Cannon wrote: > > On Thu, Nov 15, 2012 at 4:12 PM, Chris Jerdonek wrote: > >> I occasionally get e-mails like the below (with three today, which is >> unusual). Does everyone get these? > > > Yes > > >> Is this intended, > > > Yes > > >> and what are they for? > > > I believe Ezio said it's so we know that something failed badly and it > isn't overlooked. > Yes, they say that something failed. But from each message, it's hard to tell what that "something" is. :) So currently, the messages seem like they might be more confusing than useful -- at least to the general list. --Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Fri Nov 16 19:37:08 2012 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 16 Nov 2012 20:37:08 +0200 Subject: [Tracker-discuss] "failed issue tracker submission" e-mails In-Reply-To: References: Message-ID: On Fri, Nov 16, 2012 at 8:07 PM, Chris Jerdonek wrote: > On Thu, Nov 15, 2012 at 6:33 PM, Brett Cannon wrote: > >> >> On Thu, Nov 15, 2012 at 4:12 PM, Chris Jerdonek > > wrote: >> >>> I occasionally get e-mails like the below (with three today, which is >>> unusual). Does everyone get these? >> >> >> Yes >> >> >>> Is this intended, >> >> >> Yes >> >> >>> and what are they for? >> >> >> I believe Ezio said it's so we know that something failed badly and it >> isn't overlooked. >> > > > Yes, they say that something failed. But from each message, it's hard to > tell what that "something" is. :) So currently, the messages seem like > they might be more confusing than useful -- at least to the general list. > I do receive a separate mail that contains the full traceback (and a few others do as well). Unfortunately there are many such emails, mostly about "undelivered mails returned to sender" and other known issues, so it's easy to miss newly introduced errors. I check these mails every once in a while, especially after I changed something on the tracker, but if you notice any problems feel free to ping me (and/or write on tracker-discuss or the meta tracker) Best Regards, Ezio Melotti > --Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From metatracker at psf.upfronthosting.co.za Fri Nov 16 21:42:09 2012 From: metatracker at psf.upfronthosting.co.za (Chris Jerdonek) Date: Fri, 16 Nov 2012 20:42:09 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic Message-ID: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to make the "Failed issue tracker submission" e-mails sent to python-dev less cryptic for list members. Background: Occasionally (on the order of a couple times per week), the python-dev mailing list receives an e-mail like the following: http://mail.python.org/pipermail/python-dev/2012-November/122757.html Each message starts with the text-- "An unexpected error occurred during the processing of your message. The tracker administrator is being notified." The current message may be confusing to list members because it says "your message," so list members may think the message has to do with them personally. Moreover, because the text says that the "tracker administrator" is being notified, it's not clear if these e-mails were meant to be sent to python-dev, or if the forwarded e-mail is a mistake due to an error state. I think the introductory text for these messages should be rephrased so that it is clear to python-dev list members what the message is for. The introductory text could say something along these lines: "The Python issue tracker at http://bugs.python.org/ has experienced an unexpected error due to a user submission. This message and the error details below are being sent to the python-dev mailing list. The tracker administrators will take responsibility for investigating this error." ---------- messages: 2641 nosy: chris.jerdonek priority: bug status: unread title: make "Failed issue tracker submission" e-mails to python-dev less cryptic _______________________________________________________ PSF Meta Tracker _______________________________________________________ From chris.jerdonek at gmail.com Fri Nov 16 21:44:05 2012 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Fri, 16 Nov 2012 12:44:05 -0800 Subject: [Tracker-discuss] "failed issue tracker submission" e-mails In-Reply-To: References: Message-ID: On Fri, Nov 16, 2012 at 10:37 AM, Ezio Melotti wrote: > On Fri, Nov 16, 2012 at 8:07 PM, Chris Jerdonek wrote: > >> On Thu, Nov 15, 2012 at 6:33 PM, Brett Cannon wrote: >> >>> >>> On Thu, Nov 15, 2012 at 4:12 PM, Chris Jerdonek < >>> chris.jerdonek at gmail.com> wrote: >>> >>>> I occasionally get e-mails like the below (with three today, which is >>>> unusual). Does everyone get these? >>> >>> >>> Yes >>> >>> >>>> Is this intended, >>> >>> >>> Yes >>> >>> >>>> and what are they for? >>> >>> >>> I believe Ezio said it's so we know that something failed badly and it >>> isn't overlooked. >>> >> >> >> Yes, they say that something failed. But from each message, it's hard >> to tell what that "something" is. :) So currently, the messages seem like >> they might be more confusing than useful -- at least to the general list. >> > > I do receive a separate mail that contains the full traceback (and a few > others do as well). Unfortunately there are many such emails, mostly about > "undelivered mails returned to sender" and other known issues, so it's easy > to miss newly introduced errors. > I check these mails every once in a while, especially after I changed > something on the tracker, but if you notice any problems feel free to ping > me (and/or write on tracker-discuss or the meta tracker) > I filed an issue about this on the meta tracker here: http://psf.upfronthosting.co.za/roundup/meta/issue492 --Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From metatracker at psf.upfronthosting.co.za Fri Nov 16 22:13:01 2012 From: metatracker at psf.upfronthosting.co.za (R David Murray) Date: Fri, 16 Nov 2012 21:13:01 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353100381.12.0.919463006316.issue492@psf.upfronthosting.co.za> R David Murray added the comment: The problem with that suggestion is that this is just the message template that is used when an email submission fails. So if a user did a reply to a tracker message, and their reply failed for some reason, they would get a message that said "this message is being sent to python-dev" when it wasn't. The easiest solution here, I think, is to change the 'from' address in the repository hook to be tracker-discuss instead of python-dev. We will presume that people on the tracker-discuss list will not be as surprised to see tracker error messages on the list. ---------- nosy: +r.david.murray status: unread -> chatting _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Fri Nov 16 23:39:30 2012 From: metatracker at psf.upfronthosting.co.za (Chris Jerdonek) Date: Fri, 16 Nov 2012 22:39:30 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353105570.79.0.628060796035.issue492@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I was starting with a suggestion for ideal wording without regard for constraints, since I didn't know the constraints. If the text must be the same and the e-mails will be sent to a mailing list of non-administrators (e.g. python-dev or tracker-discuss), then I would suggest wording that makes sense and reduces the possibility of confusion for both types of recipients (i.e. submitter and mailing list members). For example, the text could incorporate wording like: "The Python issue tracker at http://bugs.python.org/ experienced an unexpected error while processing your submission. This message and the error details below may also be sent to the python-dev mailing list. The tracker administrators will take responsibility for investigating this error." Since I don't know all the details, this wording may need to be adjusted for accuracy. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 17 00:10:48 2012 From: metatracker at psf.upfronthosting.co.za (R David Murray) Date: Fri, 16 Nov 2012 23:10:48 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353107448.82.0.654870760642.issue492@psf.upfronthosting.co.za> R David Murray added the comment: Yes, sorry, I was explaining the constraints but I didn't express that well. Note that the *only* time such messages are sent anywhere other than to the submitter and the roundup-admin (that no one has time to fully track) is when they come from the repo commit hooks. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 17 00:19:37 2012 From: metatracker at psf.upfronthosting.co.za (Chris Jerdonek) Date: Fri, 16 Nov 2012 23:19:37 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353107977.2.0.936163414295.issue492@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Then perhaps something like the following? "The Python issue tracker at http://bugs.python.org/ experienced an unexpected error while processing your submission. The tracker administrators will take responsibility for investigating this error. (In rare cases, this message and the error details below may also be sent to the python-dev mailing list.)" (Or some other phrase in place of "In rare cases.") _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 17 00:41:16 2012 From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 16 Nov 2012 23:41:16 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353109276.8.0.689825949821.issue492@psf.upfronthosting.co.za> Martin v. L?wis added the comment: -1 on the entire issue - no action should be taken. The real problem is that there is a bug in roundup in each and every case where the email is sent. So the proper action is to fix the bug, not to massage the error message. python-dev readers should easily be able to understand the message. ---------- nosy: +loewis _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 17 01:12:20 2012 From: metatracker at psf.upfronthosting.co.za (Chris Jerdonek) Date: Sat, 17 Nov 2012 00:12:20 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353111140.91.0.572223828849.issue492@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Martin, if the messages aren't meant to be sent to python-dev, then I agree with you. This issue was created with the assumption that the messages to python-dev were intentional. The initial feedback I received on this point was different. For example, Brett indicated that the e-mails were intentional here: http://mail.python.org/pipermail/tracker-discuss/2012-November/003586.html I also acknowledged in my opening comment that I wasn't sure: "it's not clear if these e-mails were meant to be sent to python-dev, or if the forwarded e-mail is a mistake due to an error state." Is there already an issue in the meta tracker for the e-mails being mistakenly sent to python-dev? _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 17 10:08:06 2012 From: metatracker at psf.upfronthosting.co.za (Ezio Melotti) Date: Sat, 17 Nov 2012 09:08:06 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353143286.56.0.66291781513.issue492@psf.upfronthosting.co.za> Ezio Melotti added the comment: AFAIU this is what happened: 1) someone pushed something on h.p.o; 2) the roundup hook added a message about the commit to the tracker, through the "python-dev" user; 3) the irker hook was supposed to send a message on IRC, but there was a problem and it raised an exception; 4) at that point the mail you saw was sent back to the "python-dev" user to inform him that there was a problem with the submission, and a second mail with the traceback was sent to the tracker admins; There are two possible reasons why this arrived to the python-dev ML: 1) because the fromaddr used by the hgroundup hook might be set to python-dev at python.org; 2) because python-dev at python.org is listed among the alternate mail addresses of the "python-dev" user; These could both be changed to tracker-discuss, but I'm not able to change the hgroundup myself (I think this should be done in the hgrc of the hooks repo: http://hg.python.org/hooks/file/fc6022656a7b/hgroundup.py#l70). ---------- nosy: +ezio.melotti, pitrou _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 17 20:18:31 2012 From: metatracker at psf.upfronthosting.co.za (Chris Jerdonek) Date: Sat, 17 Nov 2012 19:18:31 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353179911.12.0.810032494805.issue492@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Can a different user be created or used for this? One that does not have as one of its e-mail addresses a mailing list with members who are not roundup administrators? _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 17 20:45:23 2012 From: metatracker at psf.upfronthosting.co.za (Ezio Melotti) Date: Sat, 17 Nov 2012 19:45:23 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353181523.2.0.585751965603.issue492@psf.upfronthosting.co.za> Ezio Melotti added the comment: No need for a different user, the email can be changed on the current one. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 17 20:49:48 2012 From: metatracker at psf.upfronthosting.co.za (Chris Jerdonek) Date: Sat, 17 Nov 2012 19:49:48 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353181788.22.0.427416016335.issue492@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Can the e-mail addresses be changed to an e-mail address of roundup administrators? You only mentioned changing it to tracker-discuss. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From roundup-admin at psf.upfronthosting.co.za Sat Nov 17 21:07:43 2012 From: roundup-admin at psf.upfronthosting.co.za (Python tracker) Date: Sat, 17 Nov 2012 20:07:43 +0000 Subject: [Tracker-discuss] Failed issue tracker submission Message-ID: <20121117200743.14D1D1CE0F@psf.upfronthosting.co.za> You are not a registered user. Please register at: http://bugs.python.org/user?@template=register ...before sending mail to the tracker. Unknown address: tracker-discuss at python.org -------------- next part -------------- Return-Path: X-Original-To: report at bugs.python.org Delivered-To: roundup+tracker at psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [IPv6:2001:888:2000:d::a6]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id C1F4B1CCFE for ; Sat, 17 Nov 2012 21:07:42 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3Y3nRL3sN7zRNS for ; Sat, 17 Nov 2012 21:07:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1353182862; bh=vGNWRd5Xd2cuR3eeFFy0ORwNqRoVVtSmFfBCE4bGngM=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-Id:Date; b=N+8gNg5Hh6rYfUEYQHqbV0dg9ajW1B2B00Zs46ucnKfPQXUxgCG8zTg7SSb76C1U9 btXh6/LE/HF2pkvjpMWabvC8NYlc1XGpkyXBrFHgKdJ4Mn7hsIIpkOY51xUAP5e6BR lk1pxzDONjcIFiY0939s3RCLp80NpOixr2tK8uYM= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 17 Nov 2012 21:07:42 +0100 Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72]) by mail.python.org (Postfix) with ESMTP for ; Sat, 17 Nov 2012 21:07:42 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: tracker-discuss at python.org To: report at bugs.python.org Subject: [issue2771] Message-Id: <3Y3nRL3sN7zRNS at mail.python.org> Date: Sat, 17 Nov 2012 21:07:42 +0100 (CET) TmV3IGNoYW5nZXNldCAyNzI4ZDgxNTgyOTUgYnkgQW50b2luZSBQaXRyb3UgaW4gYnJhbmNoICdk ZWZhdWx0JzoKSXNzdWUgIzI3NzE6IG5vIGUncyBoZXJlCmh0dHA6Ly9oZy5weXRob24ub3JnL3Rl c3QvcmV2LzI3MjhkODE1ODI5NQo= From metatracker at psf.upfronthosting.co.za Sat Nov 17 21:42:17 2012 From: metatracker at psf.upfronthosting.co.za (Ezio Melotti) Date: Sat, 17 Nov 2012 20:42:17 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353184937.88.0.654108996224.issue492@psf.upfronthosting.co.za> Ezio Melotti added the comment: There's roundup-admin, but amany error emails already arrive there, so if we use this address it will be easy to miss new errors. Now we changed the address to tracker-discuss (and an email was sent there already while we were testing). Normally you shouldn't see any error email arriving there, at least until I break something (and if you see them, feel free to ping me). ---------- assignedto: -> ezio.melotti status: chatting -> resolved _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 17 22:15:19 2012 From: metatracker at psf.upfronthosting.co.za (Chris Jerdonek) Date: Sat, 17 Nov 2012 21:15:19 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353186919.31.0.0230432612179.issue492@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, that's a little better. But if roundup-admin is receiving too many e-mails due to CC's of other users' errors (in turn reducing the usefulness of that address), then maybe you can do something to the subject lines of those messages to make it easier to filter them out or apply rules. For example, mailer.bounce_message() takes a subject keyword argument in the code below: http://hg.python.org/tracker/roundup/file/089a52e7a89b/roundup/mailgw.py#l1512 You could do something like prepend "[cc-notification]" to the subject line. It would also be easy to change the subject line in the code below, if these are also an issue: http://hg.python.org/tracker/roundup/file/089a52e7a89b/roundup/mailer.py#l247 ---------- status: resolved -> chatting _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sun Nov 18 14:16:25 2012 From: metatracker at psf.upfronthosting.co.za (Ezio Melotti) Date: Sun, 18 Nov 2012 13:16:25 +0000 Subject: [Tracker-discuss] [issue493] Make usernames clickable for Coordinators Message-ID: <1353244585.31.0.396735500296.issue493@psf.upfronthosting.co.za> New submission from Ezio Melotti: As requested by Antoine, the attached patch allows any user with the 'Coordinator' role to click on the username (the one between parentheses after the real name) on top of each message to go to its user page. Since the username was already used to link to the user homepage, I decided to move that link on the real name (the one before the username) instead, and also fixed a bug (non-logged users were getting a broken link). ---------- assignedto: ezio.melotti files: clickable_usernames.diff messages: 2654 nosy: ezio.melotti, loewis, pitrou, r.david.murray priority: feature status: unread title: Make usernames clickable for Coordinators _______________________________________________________ PSF Meta Tracker _______________________________________________________ -------------- next part -------------- diff --git a/html/issue.item.html b/html/issue.item.html --- a/html/issue.item.html +++ b/html/issue.item.html @@ -312,15 +312,19 @@ - (view) - Author: () - * - - (Python committer) - + Author: + + + + + () + * + (Python committer) Date: From metatracker at psf.upfronthosting.co.za Sun Nov 18 14:27:56 2012 From: metatracker at psf.upfronthosting.co.za (Ezio Melotti) Date: Sun, 18 Nov 2012 13:27:56 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353245276.49.0.979436613618.issue492@psf.upfronthosting.co.za> Ezio Melotti added the comment: I guess that could be done, but we try to avoid changing roundup if possible, so that it doesn't diverge too much from the original. If possible it might be interesting to eliminate / filter out all the "Undelivered mail returned to sender" so that we will end up with only the actual errors (about 3-5 mails per day). _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sun Nov 18 16:08:12 2012 From: metatracker at psf.upfronthosting.co.za (Chris Jerdonek) Date: Sun, 18 Nov 2012 15:08:12 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353251292.96.0.747945340191.issue492@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I don't know how such errors appear to the code, but perhaps making the first N characters of the error text the subject line (after any subject header) would suffice. Currently, it looks like every message has the identical subject line, "Failed issue tracker submission" (the default for the keyword argument to bounce_message()), which I imagine is not very convenient for browsing errors. This might also be enough to let you filter away any undesired messages strictly based on the subject line of the e-mail. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sun Nov 18 16:18:31 2012 From: metatracker at psf.upfronthosting.co.za (Ezio Melotti) Date: Sun, 18 Nov 2012 15:18:31 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353251911.5.0.0559816987753.issue492@psf.upfronthosting.co.za> Ezio Melotti added the comment: That's only to report to the users that their submission wasn't successful, the subject of the mail received by the admins contains already the error, e.g.: Error: could not serialize access due to concurrent update Templating Error: 'There is no class called "None"' Indeed I could just set up my filters to ignore only the "undelivered" ones, but the point is that undelivered mails produce lot of noise and are quite useless. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sun Nov 18 16:57:14 2012 From: metatracker at psf.upfronthosting.co.za (Chris Jerdonek) Date: Sun, 18 Nov 2012 15:57:14 +0000 Subject: [Tracker-discuss] [issue492] make "Failed issue tracker submission" e-mails to python-dev less cryptic In-Reply-To: <1353098529.47.0.735791806646.issue492@psf.upfronthosting.co.za> Message-ID: <1353254234.03.0.736075628643.issue492@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > That's only to report to the users that their submission wasn't successful, the subject of the mail received by the admins contains already the error Okay, I was referring to the copies of those messages to users that are sent to the admin address (the e-mails that I was suggesting above have subject lines prepended with [cc-notification]). Those e-mails to the admins appear to have the uninformative subject line, "Failed issue tracker submission." But yes, I see now that other e-mails to admins do have a proper subject. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From techtonik at gmail.com Tue Nov 20 00:39:24 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 20 Nov 2012 02:39:24 +0300 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: On Fri, Nov 9, 2012 at 12:00 PM, Ezio Melotti wrote: > The easiest way is probably by using the XML-RPC interface. > Follow the examples here: http://roundup.sourceforge.net/docs/xmlrpc.html > You can get the list of all the open (status=1) issues with patches > (keyword=2) using roundup_server.filter('issue', None, dict(status=1, > keyword=2)). > Patch detection is not reliable - http://bugs.python.org/issue15849 Is there a way to get list of issues with attachments? Docs are silent - http://roundup.sourceforge.net/docs/user_guide.html#searching-page You can get the list of files attached to each of the issue using > roundup_server.display('issueXXXX', 'files'). I don't know if you can then > download the files from there, but you should be able to urlretrieve them > from http://bugs.python.org/fileXXXX/. Note that not all the files are > necessary patches, so you might need to do some filtering after the > download. > If you want to experiment with further queries, you can find the keyword, > status, etc. ids using e.g. http://bugs.python.org/keyword. > > Just out of curiosity, what are you planning to do with the patches? > If you find something interesting please share it with us. > > Best Regards, > Ezio Melotti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Tue Nov 20 11:25:49 2012 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Tue, 20 Nov 2012 12:25:49 +0200 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: On Tue, Nov 20, 2012 at 1:39 AM, anatoly techtonik wrote: > On Fri, Nov 9, 2012 at 12:00 PM, Ezio Melotti wrote: > >> The easiest way is probably by using the XML-RPC interface. >> Follow the examples here: http://roundup.sourceforge.net/docs/xmlrpc.html >> You can get the list of all the open (status=1) issues with patches >> (keyword=2) using roundup_server.filter('issue', None, dict(status=1, >> keyword=2)). >> > > Patch detection is not reliable - http://bugs.python.org/issue15849 > Is there a way to get list of issues with attachments? > Docs are silent - > http://roundup.sourceforge.net/docs/user_guide.html#searching-page > Not directly AFAIK. The "patch" keyword is added automatically when a file is attached (even if it's not a patch), and unless someone removes (as it happened with all the PEP 3121/384 issues) it should be set on all the issues with attachments. Otherwise you can loop through all the issues and check for their files as I explained in the previous mail. > > You can get the list of files attached to each of the issue using >> roundup_server.display('issueXXXX', 'files'). I don't know if you can then >> download the files from there, but you should be able to urlretrieve them >> from http://bugs.python.org/fileXXXX/. Note that not all the files are >> necessary patches, so you might need to do some filtering after the >> download. >> > Best Regards, Ezio Melotti -------------- next part -------------- An HTML attachment was scrubbed... URL: From techtonik at gmail.com Tue Nov 20 22:14:16 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 21 Nov 2012 00:14:16 +0300 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: On Tue, Nov 20, 2012 at 1:25 PM, Ezio Melotti wrote: > On Tue, Nov 20, 2012 at 1:39 AM, anatoly techtonik wrote: > >> On Fri, Nov 9, 2012 at 12:00 PM, Ezio Melotti wrote: >> >>> The easiest way is probably by using the XML-RPC interface. >>> Follow the examples here: >>> http://roundup.sourceforge.net/docs/xmlrpc.html >>> You can get the list of all the open (status=1) issues with patches >>> (keyword=2) using roundup_server.filter('issue', None, dict(status=1, >>> keyword=2)). >>> >> >> Patch detection is not reliable - http://bugs.python.org/issue15849 >> Is there a way to get list of issues with attachments? >> Docs are silent - >> http://roundup.sourceforge.net/docs/user_guide.html#searching-page >> > > Not directly AFAIK. The "patch" keyword is added automatically when a > file is attached (even if it's not a patch), and unless someone removes (as > it happened with all the PEP 3121/384 issues) it should be set on all the > issues with attachments. > Otherwise you can loop through all the issues and check for their files as > I explained in the previous mail. > > >> >> You can get the list of files attached to each of the issue using >>> roundup_server.display('issueXXXX', 'files'). I don't know if you can then >>> download the files from there, but you should be able to urlretrieve them >>> from http://bugs.python.org/fileXXXX/. Note that not all the files are >>> necessary patches, so you might need to do some filtering after the >>> download. >> >> This works. Terminating slash in http://bugs.python.org/fileXXXX/ appeared to be essential. In the meanwhile, can you check what's wrong with .po files in http://bugs.python.org/issue9741 - I get 403 error while trying to grab them. -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: From georg at python.org Tue Nov 20 22:29:44 2012 From: georg at python.org (Georg Brandl) Date: Tue, 20 Nov 2012 22:29:44 +0100 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: <50ABF648.20803@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 20.11.2012 22:14, schrieb anatoly techtonik: > You can get the list of files attached to each of the issue using > roundup_server.display('issueXXXX', 'files'). I don't know if you can then > download the files from there, but you should be able to urlretrieve them > from http://bugs.python.org/fileXXXX/. Note that not all the files are > necessary patches, so you might need to do some filtering after the > download. > > > This works. Terminating slash in http://bugs.python.org/fileXXXX/ appeared > to be essential. In the meanwhile, can you check what's wrong with .po > files in http://bugs.python.org/issue9741 - I get 403 error while trying to > grab them. Works fine here. Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCr9kgACgkQN9GcIYhpnLBu2wCfYSIe1WnJ0zb75PjiXcyYwrts cX8AoKzg/UnnTkMqZpmGHxTjYPpIjsk+ =qxBT -----END PGP SIGNATURE----- From techtonik at gmail.com Tue Nov 20 22:41:33 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 21 Nov 2012 00:41:33 +0300 Subject: [Tracker-discuss] Patch tracking In-Reply-To: <50ABF648.20803@python.org> References: <50ABF648.20803@python.org> Message-ID: On Wed, Nov 21, 2012 at 12:29 AM, Georg Brandl wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 20.11.2012 22:14, schrieb anatoly techtonik: > > > You can get the list of files attached to each of the issue using > > roundup_server.display('issueXXXX', 'files'). I don't know if you can > then > > download the files from there, but you should be able to urlretrieve them > > from http://bugs.python.org/fileXXXX/. Note that not all the files are > > necessary patches, so you might need to do some filtering after the > > download. > > > > > > This works. Terminating slash in http://bugs.python.org/fileXXXX/appeared > > to be essential. In the meanwhile, can you check what's wrong with .po > > files in http://bugs.python.org/issue9741 - I get 403 error while > trying to > > grab them. > > Works fine here. > Try anonymous access. -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Tue Nov 20 23:20:52 2012 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Wed, 21 Nov 2012 00:20:52 +0200 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: <50ABF648.20803@python.org> Message-ID: Hi, On Tue, Nov 20, 2012 at 11:41 PM, anatoly techtonik wrote: > On Wed, Nov 21, 2012 at 12:29 AM, Georg Brandl wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 20.11.2012 22:14, schrieb anatoly techtonik: >> > This works. Terminating slash in http://bugs.python.org/fileXXXX/appeared >> > to be essential. >> > For the record whatever you put after the trailing '/' will be used as the filename of the downloaded file. > In the meanwhile, can you check what's wrong with .po >> > files in http://bugs.python.org/issue9741 - I get 403 error while >> trying to >> > grab them. >> >> Works fine here. >> > > Try anonymous access. > The files were marked as spam, and therefore blocked to anonymous users. I now marked them as ham, so you should be able to download them. Best Regards, Ezio Melotti > -- > anatoly t. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From metatracker at psf.upfronthosting.co.za Thu Nov 22 11:02:42 2012 From: metatracker at psf.upfronthosting.co.za (Marc-Andre Lemburg) Date: Thu, 22 Nov 2012 10:02:42 +0000 Subject: [Tracker-discuss] [issue491] Ignore email signatures In-Reply-To: <509B64FE.3020408@egenix.com> Message-ID: <50ADF83C.2000506@egenix.com> Marc-Andre Lemburg added the comment: On 08.11.2012 08:53, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > On 08.11.2012 07:07, Ezio Melotti wrote: >> >> Ezio Melotti added the comment: >> >> I reported this upstream: http://issues.roundup-tracker.org/issue2550780 >> If they agree, I'll fix it. > > Thanks, Ezio. > > At least now I know how to prevent my sig from getting recorded > in the tracker ;-) I think you have their approval: http://issues.roundup-tracker.org/msg4670 Would be great to get this fix in, as it's really annoying to always have to remember to truncate the sig when replying to a tracker email. Thanks, -- Marc-Andre Lemburg eGenix.com _______________________________________________________ PSF Meta Tracker _______________________________________________________ From techtonik at gmail.com Sat Nov 24 00:48:24 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Sat, 24 Nov 2012 02:48:24 +0300 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: The first part of experiment is complete. It took a week to finish, but it is ready. The source at https://bitbucket.org/techtonik/python-stdlib/srcgives the following stats: Open issues with patch keyword: 1654 Issues with confirmed patches: 1583 Files attached: 3432 Patches: 2926 json: 8 distutils: 58 Finished in 0:04:32.32 What is left is to complete stdlib.json module description file. -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Sat Nov 24 05:04:26 2012 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Sat, 24 Nov 2012 06:04:26 +0200 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: Thanks for your work! I played a bit with the code tonight and used it to create a json that maps filename -> list of issues with a patch that affects that filename. I made a simple page to filter the results and uploaded it here for now: http://wolfprojects.altervista.org/issues.html It requires javascript and it's a bit slow (at least on my pc), but it allows you to enter a module name or path and it will list all the issues related to the files that match the search (regex search should also work). This is still a work in progress though. If you want you can find the json at http://wolfprojects.altervista.org/files.json Best Regards, Ezio Melotti -------------- next part -------------- An HTML attachment was scrubbed... URL: From techtonik at gmail.com Sat Nov 24 23:24:37 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Sun, 25 Nov 2012 01:24:37 +0300 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: On Sat, Nov 24, 2012 at 7:04 AM, Ezio Melotti wrote: > Thanks for your work! > > I played a bit with the code tonight and used it to create a json that > maps filename -> list of issues with a patch that affects that filename. > Nice. Is it possible to add this lookup to the post commit hook script to report about amount of patches available for files that had been committed? It is much easier to review code that's already in your mind. I made a simple page to filter the results and uploaded it here for now: > http://wolfprojects.altervista.org/issues.html > It requires javascript and it's a bit slow (at least on my pc), but it > allows you to enter a module name or path and it will list all the issues > related to the files that match the search (regex search should also work). > This is still a work in progress though. > If you want you can find the json at > http://wolfprojects.altervista.org/files.json Good work. I've pulled all the changes, but now I am getting: Traceback (most recent call last): File "modstats.py", line 142, in print('#%s: %s' % (issuen, issue['title'])) File "C:\Python27\lib\encodings\cp437.py", line 12, in encode return codecs.charmap_encode(input,errors,encoding_map) UnicodeEncodeError: 'charmap' codec can't encode character u'\u2019' in position 65: character maps to Path cleaning is a good thing. Good auto classification also needs some rules that needs additional data: - detect full path from just filename - if path is unknown, analyse filename - if filename is unique in Python source tree, return it's path - if filename is not unique, compare parent path components recursively - if not successful, try context match patch - if everything fails, choose the first one - if it fails also, maintain manual connection patch <---> file For that to work we need an index of Python source code directory tree. And add % of recognized patches. With manual classification (triaging) it is possible to keep this per-cent at 100. BTW, what kind of license do you prefer? I didn't mention it first, but it's better to set this early. I am for public domain with some credits file at the top. -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Sat Nov 24 23:56:29 2012 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Sun, 25 Nov 2012 00:56:29 +0200 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: Hi, On Sun, Nov 25, 2012 at 12:24 AM, anatoly techtonik wrote: > On Sat, Nov 24, 2012 at 7:04 AM, Ezio Melotti > wrote: > >> Thanks for your work! >> >> I played a bit with the code tonight and used it to create a json that >> maps filename -> list of issues with a patch that affects that filename. >> > > Nice. Is it possible to add this lookup to the post commit hook script to > report about amount of patches available for files that had been committed? > It is much easier to review code that's already in your mind. > I'm not sure I understand what you are asking here. Are you suggesting to add a mercurial hook that, once you commit/push something, suggests other issues with patches that affect the same file(s)? This could be done, but I think it's better to make the data available in the tracker so that developers can search other issues themselves. > > I made a simple page to filter the results and uploaded it here for now: >> http://wolfprojects.altervista.org/issues.html >> It requires javascript and it's a bit slow (at least on my pc), but it >> allows you to enter a module name or path and it will list all the issues >> related to the files that match the search (regex search should also work). >> This is still a work in progress though. >> If you want you can find the json at >> http://wolfprojects.altervista.org/files.json > > > Good work. I've pulled all the changes, but now I am getting: > > Traceback (most recent call last): > File "modstats.py", line 142, in > print('#%s: %s' % (issuen, issue['title'])) > File "C:\Python27\lib\encodings\cp437.py", line 12, in encode > return codecs.charmap_encode(input,errors,encoding_map) > UnicodeEncodeError: 'charmap' codec can't encode character u'\u2019' in > position 65: character maps to > That's probably due to the limitations of the windows console. > > Path cleaning is a good thing. Good auto classification also needs some > rules that needs additional data: > - detect full path from just filename > The cleanup function I wrote just removes extraneous things from the path. It doesn't verify if the file exists in the Python codebase. > - if path is unknown, analyse filename > - if filename is unique in Python source tree, return it's path > - if filename is not unique, compare parent path components > recursively > - if not successful, try context match patch > - if everything fails, choose the first one > - if it fails also, maintain manual connection patch <---> file > For that to work we need an index of Python source code directory tree. > I don't think all this is necessary. Once we have the list of file names extracted from the patches, it's enough to search for keyword or module name to find all the related issues. For example if you try searching for 'json' on http://wolfprojects.altervista.org/issues.html you will find all the json-related files, including the ones in the Python package, the C acceleration module, the documentation, the tests, and even files like "doc\json.rst" that don't exist in the Python codebase or got renamed at some point. And add % of recognized patches. > With manual classification (triaging) it is possible to keep this per-cent > at 100. > Trying to establish a mapping between the patches and the actual files is both cumbersome (especially if requires manual classification) and might end up missing some of the patches if they specify an incorrect path, add new files, or affected files that got renamed or deleted. I'm considering adding a way to search for modules to the tracker, in a way similar to what I did on http://wolfprojects.altervista.org/issues.html. The tracker has direct access to the files and issues so analyzing the patches and keep the database updated as new patches are attached should be easier. Once we have the equivalent of files.json (maybe in a db table), it's just a matter to add a search form. > BTW, what kind of license do you prefer? I didn't mention it first, but > it's better to set this early. I am for public domain with some credits > file at the top. > SGTM. Best Regards, Ezio Melotti -- > anatoly t. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From techtonik at gmail.com Sun Nov 25 14:30:39 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Sun, 25 Nov 2012 16:30:39 +0300 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: On Sun, Nov 25, 2012 at 1:56 AM, Ezio Melotti wrote: > On Sun, Nov 25, 2012 at 12:24 AM, anatoly techtonik wrote: > >> On Sat, Nov 24, 2012 at 7:04 AM, Ezio Melotti >> wrote: >> >>> Thanks for your work! >>> >>> I played a bit with the code tonight and used it to create a json that >>> maps filename -> list of issues with a patch that affects that filename. >>> >> >> Nice. Is it possible to add this lookup to the post commit hook script to >> report about amount of patches available for files that had been committed? >> It is much easier to review code that's already in your mind. >> > > I'm not sure I understand what you are asking here. Are you suggesting to > add a mercurial hook that, once you commit/push something, suggests other > issues with patches that affect the same file(s)? > Right. After you've pushed something, a short message from server on the screen: Thanks for your contribution to the module XXX, YYY, ... . Please note that files that you've touched have X open patches on the bug tracker. It might be the best time to review some now. ... This serves two purpose: 1. Encourages people to review patches or do something else about them (split issues) to avoid languishing 2. Complete stdlib.json mapping (yes, I am lazy, and it will be more fun for people to fill their missing modules themselves) This could be done, but I think it's better to make the data available in > the tracker so that developers can search other issues themselves. > Tracker integration is the next logical step (because it requires more effort). It is good to have both, because we can't enforce any process other than people used to. There is a chance that new search capabilities just won't be used. > I made a simple page to filter the results and uploaded it here for now: >>> http://wolfprojects.altervista.org/issues.html >>> It requires javascript and it's a bit slow (at least on my pc), but it >>> allows you to enter a module name or path and it will list all the issues >>> related to the files that match the search (regex search should also work). >>> This is still a work in progress though. >>> If you want you can find the json at >>> http://wolfprojects.altervista.org/files.json >> >> >> Good work. I've pulled all the changes, but now I am getting: >> >> Traceback (most recent call last): >> File "modstats.py", line 142, in >> print('#%s: %s' % (issuen, issue['title'])) >> File "C:\Python27\lib\encodings\cp437.py", line 12, in encode >> return codecs.charmap_encode(input,errors,encoding_map) >> UnicodeEncodeError: 'charmap' codec can't encode character u'\u2019' in >> position 65: character maps to >> > > That's probably due to the limitations of the windows console. > http://wiki.python.org/moin/PrintFails#Windows described the problem, but proposes no acceptable solution. Setting environment variable beforehand is like placing a mattress just before hitting the ground. Why it is not possible to fix the situation from inside of script? >> Path cleaning is a good thing. Good auto classification also needs some >> rules that needs additional data: >> - detect full path from just filename >> > > The cleanup function I wrote just removes extraneous things from the > path. It doesn't verify if the file exists in the Python codebase. > > >> - if path is unknown, analyse filename >> - if filename is unique in Python source tree, return it's path >> - if filename is not unique, compare parent path components >> recursively >> - if not successful, try context match patch >> - if everything fails, choose the first one >> - if it fails also, maintain manual connection patch <---> file >> For that to work we need an index of Python source code directory tree. >> > > I don't think all this is necessary. Once we have the list of file names > extracted from the patches, it's enough to search for keyword or module > name to find all the related issues. > For example if you try searching for 'json' on > http://wolfprojects.altervista.org/issues.html you will find all the > json-related files, including the ones in the Python package, the C > acceleration module, the documentation, the tests, and even files like > "doc\json.rst" that don't exist in the Python codebase or got renamed at > some point. > Good user story. I've added C acceleration module to the stdlib.json description. My goal is to make patch classification an automatic process. In the long run there won't be any patches in tracker that are hard to apply. So "doc\json.rst" will gone. There should be a place to list all those unknown patches though, so that people can take and work on them. And add % of recognized patches. >> With manual classification (triaging) it is possible to keep this >> per-cent at 100. >> > > Trying to establish a mapping between the patches and the actual files is > both cumbersome (especially if requires manual classification) and might > end up missing some of the patches if they specify an incorrect path, add > new files, or affected files that got renamed or deleted. > Mapping is just a table with is a temporary association. It may be not necessary if there will be a separate page with all kinds of incorrect patches. > I'm considering adding a way to search for modules to the tracker, in a > way similar to what I did on > http://wolfprojects.altervista.org/issues.html. The tracker has direct > access to the files and issues so analyzing the patches and keep the > database updated as new patches are attached should be easier. Once we > have the equivalent of files.json (maybe in a db table), it's just a matter > to add a search form. > Sounds good as a temporary solution. I'd still prefer automatic classification rules, but considering the fact that people can not remove their patches, a search form can be the only viable solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Sun Nov 25 15:07:56 2012 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Sun, 25 Nov 2012 16:07:56 +0200 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: On Sun, Nov 25, 2012 at 3:30 PM, anatoly techtonik wrote: > On Sun, Nov 25, 2012 at 1:56 AM, Ezio Melotti wrote: > >> On Sun, Nov 25, 2012 at 12:24 AM, anatoly techtonik wrote: >> >>> On Sat, Nov 24, 2012 at 7:04 AM, Ezio Melotti >>> wrote: >>> >>>> Thanks for your work! >>>> >>>> I played a bit with the code tonight and used it to create a json that >>>> maps filename -> list of issues with a patch that affects that filename. >>>> >>> >>> Nice. Is it possible to add this lookup to the post commit hook script >>> to report about amount of patches available for files that had >>> been committed? It is much easier to review code that's already in your >>> mind. >>> >> >> I'm not sure I understand what you are asking here. Are you suggesting >> to add a mercurial hook that, once you commit/push something, suggests >> other issues with patches that affect the same file(s)? >> > > Right. After you've pushed something, a short message from server on the > screen: > > Thanks for your contribution to the module XXX, YYY, ... . > > Please note that files that you've touched have X open patches > on the bug tracker. It might be the best time to review some now. > ... > > This serves two purpose: > 1. Encourages people to review patches or do something else about them > (split issues) to avoid languishing > 2. Complete stdlib.json mapping (yes, I am lazy, and it will be more fun > for people to fill their missing modules themselves) > It might turns out to be annoying for developers though. If they are the maintainers of some specific module they probably know the other issues already, if they aren't they might not care. This will also make pushing slower and might introduce problems. > > This could be done, but I think it's better to make the data available in >> the tracker so that developers can search other issues themselves. >> > > Tracker integration is the next logical step (because it requires more > effort). It is good to have both, because we can't enforce any process > other than people used to. There is a chance that new search capabilities > just won't be used. > There is this possibility, but I don't think that forcing the user to look at the related issues is a good idea either. Integrating this and advertising it on python-dev is enough IMHO. > >> I made a simple page to filter the results and uploaded it here for >>>> now: http://wolfprojects.altervista.org/issues.html >>>> It requires javascript and it's a bit slow (at least on my pc), but it >>>> allows you to enter a module name or path and it will list all the issues >>>> related to the files that match the search (regex search should also work). >>>> This is still a work in progress though. >>>> If you want you can find the json at >>>> http://wolfprojects.altervista.org/files.json >>> >>> >>> Good work. I've pulled all the changes, but now I am getting: >>> >>> Traceback (most recent call last): >>> File "modstats.py", line 142, in >>> print('#%s: %s' % (issuen, issue['title'])) >>> File "C:\Python27\lib\encodings\cp437.py", line 12, in encode >>> return codecs.charmap_encode(input,errors,encoding_map) >>> UnicodeEncodeError: 'charmap' codec can't encode character u'\u2019' in >>> position 65: character maps to >>> >> >> That's probably due to the limitations of the windows console. >> > > http://wiki.python.org/moin/PrintFails#Windows described the problem, but > proposes no acceptable solution. Setting environment variable beforehand is > like placing a mattress just before hitting the ground. Why it is not > possible to fix the situation from inside of script? > Try print('#%s: %r' % (issuen, issue['title'])), it should print the repr of the title and use an \uxxxx escape instead of the equivalent Unicode char. Otherwise you can just drop the title and print only the issue number, the title is not so useful anyway. >>> Path cleaning is a good thing. Good auto classification also needs some >>> rules that needs additional data: >>> - detect full path from just filename >>> >> >> The cleanup function I wrote just removes extraneous things from the >> path. It doesn't verify if the file exists in the Python codebase. >> >> >>> - if path is unknown, analyse filename >>> - if filename is unique in Python source tree, return it's path >>> - if filename is not unique, compare parent path components >>> recursively >>> - if not successful, try context match patch >>> - if everything fails, choose the first one >>> - if it fails also, maintain manual connection patch <---> file >>> For that to work we need an index of Python source code directory tree. >>> >> >> I don't think all this is necessary. Once we have the list of file names >> extracted from the patches, it's enough to search for keyword or module >> name to find all the related issues. >> For example if you try searching for 'json' on >> http://wolfprojects.altervista.org/issues.html you will find all the >> json-related files, including the ones in the Python package, the C >> acceleration module, the documentation, the tests, and even files like >> "doc\json.rst" that don't exist in the Python codebase or got renamed at >> some point. >> > > Good user story. I've added C acceleration module to the stdlib.json > description. My goal is to make patch classification an automatic process. > What do you mean exactly with "classification"? If the goal is being able to find all the patches related to a module, the search I implemented already does that without any (manually maintained) mapping. > In the long run there won't be any patches in tracker that are hard to > apply. So "doc\json.rst" will gone. There should be a place to list all > those unknown patches though, so that people can take and work on them. > > And add % of recognized patches. >>> With manual classification (triaging) it is possible to keep this >>> per-cent at 100. >>> >> >> Trying to establish a mapping between the patches and the actual files is >> both cumbersome (especially if requires manual classification) and might >> end up missing some of the patches if they specify an incorrect path, add >> new files, or affected files that got renamed or deleted. >> > > Mapping is just a table with is a temporary association. It may be not > necessary if there will be a separate page with all kinds of incorrect > patches. > If the patches have a name that makes sense (e.g. the module name without the path, or the module name with some addition like '-new') the search will include them anyway. If they don't and get "lost" is not a big deal IMHO, they might still be found through regular search. > > >> I'm considering adding a way to search for modules to the tracker, in a >> way similar to what I did on >> http://wolfprojects.altervista.org/issues.html. The tracker has direct >> access to the files and issues so analyzing the patches and keep the >> database updated as new patches are attached should be easier. Once we >> have the equivalent of files.json (maybe in a db table), it's just a matter >> to add a search form. >> > > Sounds good as a temporary solution. I'd still prefer automatic > classification rules, but considering the fact that people can not remove > their patches, a search form can be the only viable solution. > What should this automatic classification do? "tag" the issue with the module name(s)? If this is what you want to do and the purpose of the tag is just to search for issues with patches about that module, then -- as I said -- it's already doable with the normal search I proposed. Best Regards, Ezio Melotti -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Mon Nov 26 02:55:28 2012 From: rdmurray at bitdance.com (R. David Murray) Date: Sun, 25 Nov 2012 20:55:28 -0500 Subject: [Tracker-discuss] Patch tracking In-Reply-To: References: Message-ID: <20121126015528.C812E250069@webabinitio.net> On Sun, 25 Nov 2012 16:07:56 +0200, Ezio Melotti wrote: > On Sun, Nov 25, 2012 at 3:30 PM, anatoly techtonik wrote: > > > On Sun, Nov 25, 2012 at 1:56 AM, Ezio Melotti wrote: > > > >> On Sun, Nov 25, 2012 at 12:24 AM, anatoly techtonik wrote: > >> > >>> On Sat, Nov 24, 2012 at 7:04 AM, Ezio Melotti > >>> wrote: > >>> Nice. Is it possible to add this lookup to the post commit hook script > >>> to report about amount of patches available for files that had > >>> been committed? It is much easier to review code that's already in your > >>> mind. > >>> > >> > >> I'm not sure I understand what you are asking here. Are you suggesting > >> to add a mercurial hook that, once you commit/push something, suggests > >> other issues with patches that affect the same file(s)? > >> > > > > Right. After you've pushed something, a short message from server on the > > screen: > > > > Thanks for your contribution to the module XXX, YYY, ... . > > > > Please note that files that you've touched have X open patches > > on the bug tracker. It might be the best time to review some now. > > ... > > > > This serves two purpose: > > 1. Encourages people to review patches or do something else about them > > (split issues) to avoid languishing > > 2. Complete stdlib.json mapping (yes, I am lazy, and it will be more fun > > for people to fill their missing modules themselves) > > > > It might turns out to be annoying for developers though. If they are the > maintainers of some specific module they probably know the other issues > already, if they aren't they might not care. This will also make pushing > slower and might introduce problems. If someone writes such a commit hook, it could be provided for developers to install locally. That way only those who find it useful will see the output. --David From ezio.melotti at gmail.com Mon Nov 26 13:57:03 2012 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Mon, 26 Nov 2012 14:57:03 +0200 Subject: [Tracker-discuss] Patch tracking In-Reply-To: <20121126015528.C812E250069@webabinitio.net> References: <20121126015528.C812E250069@webabinitio.net> Message-ID: On Mon, Nov 26, 2012 at 3:55 AM, R. David Murray wrote: > On Sun, 25 Nov 2012 16:07:56 +0200, Ezio Melotti > wrote: > > It might turns out to be annoying for developers though. If they are the > > maintainers of some specific module they probably know the other issues > > already, if they aren't they might not care. This will also make pushing > > slower and might introduce problems. > > If someone writes such a commit hook, it could be provided for developers > to install locally. That way only those who find it useful will see > the output. > Good point, I guess the bug tracker could provide some API to return a json list of issues that match the search. Best Regards, Ezio Melotti > > --David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From metatracker at psf.upfronthosting.co.za Fri Nov 30 21:24:15 2012 From: metatracker at psf.upfronthosting.co.za (Ezio Melotti) Date: Fri, 30 Nov 2012 20:24:15 +0000 Subject: [Tracker-discuss] [issue493] Make usernames clickable for Coordinators In-Reply-To: <1353244585.31.0.396735500296.issue493@psf.upfronthosting.co.za> Message-ID: <1354307055.33.0.270704361843.issue493@psf.upfronthosting.co.za> Ezio Melotti added the comment: Done in http://hg.python.org/tracker/python-dev/rev/e7831662fb04. ---------- status: unread -> resolved _______________________________________________________ PSF Meta Tracker _______________________________________________________