From metatracker at psf.upfronthosting.co.za Tue Apr 3 22:16:58 2007 From: metatracker at psf.upfronthosting.co.za (Erik Forsberg) Date: Tue, 03 Apr 2007 20:16:58 -0000 Subject: [Tracker-discuss] [issue110] Showstopper: sf.net is generating invalid XML Message-ID: <1175631418.11.0.566050664293.issue110@psf.upfronthosting.co.za> New submission from Erik Forsberg: FYI: Sourceforge's backup system is currently generating an invalid xml file. Not all entries are present, and it ends with an , not matching the top-level . % grep '' tracker2007-02-21.xml|wc 12175 12175 133925 % grep '' tracker2007-04-03.xml|wc 9895 9895 108845 I reported this 2007-03-25, see https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1687916&group_id=1 ---------- messages: 608 nosy: forsberg priority: urgent status: chatting title: Showstopper: sf.net is generating invalid XML _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Apr 4 01:08:24 2007 From: metatracker at psf.upfronthosting.co.za (Brett C.) Date: Tue, 03 Apr 2007 23:08:24 -0000 Subject: [Tracker-discuss] [issue110] Showstopper: sf.net is generating invalid XML In-Reply-To: <1175631418.11.0.566050664293.issue110@psf.upfronthosting.co.za> Message-ID: Brett C. added the comment: Crap. Here is to hoping they get this fixed soon. On 4/3/07, Erik Forsberg wrote: > > > New submission from Erik Forsberg: > > FYI: > > Sourceforge's backup system is currently generating an invalid xml > file. Not all entries are present, and it ends with an , > not matching the top-level . > > % grep '' tracker2007-02-21.xml|wc > 12175 12175 133925 > % grep '' tracker2007-04-03.xml|wc > 9895 9895 108845 > > I reported this 2007-03-25, see > > https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1687916&group_id=1 > > ---------- > messages: 608 > nosy: forsberg > priority: urgent > status: chatting > title: Showstopper: sf.net is generating invalid XML > > _______________________________________________________ > Meta Tracker > > _______________________________________________________ > _______________________________________________ > Tracker-discuss mailing list > Tracker-discuss at python.org > http://mail.python.org/mailman/listinfo/tracker-discuss > _______________________________________________________ Meta Tracker _______________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20070403/ad4863d0/attachment.htm From martin at v.loewis.de Wed Apr 4 07:03:27 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 04 Apr 2007 07:03:27 +0200 Subject: [Tracker-discuss] [issue110] Showstopper: sf.net is generating invalid XML In-Reply-To: <1175631418.11.0.566050664293.issue110@psf.upfronthosting.co.za> References: <1175631418.11.0.566050664293.issue110@psf.upfronthosting.co.za> Message-ID: <4613319F.9040004@v.loewis.de> > Sourceforge's backup system is currently generating an invalid xml > file. Not all entries are present, and it ends with an , > not matching the top-level . What is the file size? When this happened the last time, it would truncate roughly at a power of 2. Regards, Martin From metatracker at psf.upfronthosting.co.za Wed Apr 4 07:03:31 2007 From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 04 Apr 2007 05:03:31 -0000 Subject: [Tracker-discuss] [issue110] Showstopper: sf.net is generating invalid XML In-Reply-To: <1175631418.11.0.566050664293.issue110@psf.upfronthosting.co.za> Message-ID: <4613319F.9040004@v.loewis.de> Martin v. L?wis added the comment: > Sourceforge's backup system is currently generating an invalid xml > file. Not all entries are present, and it ends with an , > not matching the top-level . What is the file size? When this happened the last time, it would truncate roughly at a power of 2. Regards, Martin _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Apr 4 07:58:51 2007 From: metatracker at psf.upfronthosting.co.za (Erik Forsberg) Date: Wed, 04 Apr 2007 05:58:51 -0000 Subject: [Tracker-discuss] [issue110] Showstopper: sf.net is generating invalid XML In-Reply-To: <4613319F.9040004@v.loewis.de> Message-ID: <200704040758.50136.forsberg@efod.se> Erik Forsberg added the comment: > What is the file size? When this happened the last time, it would > truncate roughly at a power of 2. 37992568 bytes. Rgds, \EF -- http://efod.se/ _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Thu Apr 5 22:18:21 2007 From: metatracker at psf.upfronthosting.co.za (Stefan Seefeld) Date: Thu, 05 Apr 2007 20:18:21 -0000 Subject: [Tracker-discuss] [issue111] Roundup not fault tolerant enough about duplicate form values. Message-ID: <1175804301.19.0.913796619645.issue111@psf.upfronthosting.co.za> New submission from Stefan Seefeld: I'm receiving mails with stack traces about this exception a couple of times per day: -------- File "/home/roundup/roundup-production/lib/python2.4/site-packages/roundup/cgi/templating.py", line 2234, in _post_init self.search_text = self.form[name].value AttributeError: 'list' object has no attribute 'value' -------- The underlaying error appears to be that Roundup's CGI handler expects a single form value where multiple values are present (in the incoming URL). While the URL may in fact be wrong, it would be good if Roundup could still tolerate it (or at least provide a more meaningful error message to the user, instead of sending a stack trace to the admin). Has anything been done to enhance this ? ---------- assignedto: richard messages: 612 nosy: richard, stefan priority: bug status: unread title: Roundup not fault tolerant enough about duplicate form values. _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Fri Apr 6 02:34:06 2007 From: metatracker at psf.upfronthosting.co.za (Richard Jones) Date: Fri, 06 Apr 2007 00:34:06 -0000 Subject: [Tracker-discuss] [issue111] Roundup not fault tolerant enough about duplicate form values. In-Reply-To: <1175804301.19.0.913796619645.issue111@psf.upfronthosting.co.za> Message-ID: <200704061033.57383.richard@commonground.com.au> Richard Jones added the comment: On Fri, 6 Apr 2007, Stefan Seefeld wrote: > The underlaying error appears to be that Roundup's CGI handler > expects a single form value where multiple values are present > (in the incoming URL). Indeed - why are there multiple search terms in the request? > Has anything been done to enhance this ? No, and if it needs fixing then a bug report should be filed against the Roundup project. ---------- status: unread -> chatting _______________________________________________________ Meta Tracker _______________________________________________________ From seefeld at sympatico.ca Fri Apr 6 06:48:38 2007 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 06 Apr 2007 00:48:38 -0400 Subject: [Tracker-discuss] [issue111] Roundup not fault tolerant enough about duplicate form values. In-Reply-To: <200704061033.57383.richard@commonground.com.au> References: <200704061033.57383.richard@commonground.com.au> Message-ID: <4615D126.70802@sympatico.ca> Richard Jones wrote: > Richard Jones added the comment: > > On Fri, 6 Apr 2007, Stefan Seefeld wrote: >> The underlaying error appears to be that Roundup's CGI handler >> expects a single form value where multiple values are present >> (in the incoming URL). > > Indeed - why are there multiple search terms in the request? I have no idea (the mail sent to the admin doesn't contain the original URL, neither what page (URL) it originated in. It may be a faulty template, or something different. >> Has anything been done to enhance this ? > > No, and if it needs fixing then a bug report should be filed against the > Roundup project. That's the question: do you think that such a check would be worth adding to the roundup code ? If so, I can submit a formal bug report (and prepare a patch). Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... From metatracker at psf.upfronthosting.co.za Fri Apr 6 06:48:50 2007 From: metatracker at psf.upfronthosting.co.za (Stefan Seefeld) Date: Fri, 06 Apr 2007 04:48:50 -0000 Subject: [Tracker-discuss] [issue111] Roundup not fault tolerant enough about duplicate form values. In-Reply-To: <200704061033.57383.richard@commonground.com.au> Message-ID: <4615D126.70802@sympatico.ca> Stefan Seefeld added the comment: Richard Jones wrote: > Richard Jones added the comment: > > On Fri, 6 Apr 2007, Stefan Seefeld wrote: >> The underlaying error appears to be that Roundup's CGI handler >> expects a single form value where multiple values are present >> (in the incoming URL). > > Indeed - why are there multiple search terms in the request? I have no idea (the mail sent to the admin doesn't contain the original URL, neither what page (URL) it originated in. It may be a faulty template, or something different. >> Has anything been done to enhance this ? > > No, and if it needs fixing then a bug report should be filed against the > Roundup project. That's the question: do you think that such a check would be worth adding to the roundup code ? If so, I can submit a formal bug report (and prepare a patch). Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... _______________________________________________________ Meta Tracker _______________________________________________________ From draghuram at gmail.com Mon Apr 9 23:21:38 2007 From: draghuram at gmail.com (Raghuram Devarakonda) Date: Mon, 9 Apr 2007 17:21:38 -0400 Subject: [Tracker-discuss] contribution Message-ID: <2c51ecee0704091421l654a638w1b927ead99e353bd@mail.gmail.com> Hi, I am writing to offer my help in new tracker related work. Just to give a brief introduction, - I am on the python-dev list for few months (mostly lurking) - I am on this list for less than a month - I haven't used roundup before - I commented on few python bugs/patches in SF (user name is "draghuram") I do not have any preferences as to the type of work I am interested in (at least at this point). So you can try pretty much anything including documentation. Thanks, Raghu. From brett at python.org Mon Apr 9 23:53:14 2007 From: brett at python.org (Brett Cannon) Date: Mon, 9 Apr 2007 14:53:14 -0700 Subject: [Tracker-discuss] contribution In-Reply-To: <2c51ecee0704091421l654a638w1b927ead99e353bd@mail.gmail.com> References: <2c51ecee0704091421l654a638w1b927ead99e353bd@mail.gmail.com> Message-ID: On 4/9/07, Raghuram Devarakonda wrote: > > Hi, > > I am writing to offer my help in new tracker related work. Just to > give a brief introduction, > > - I am on the python-dev list for few months (mostly lurking) > - I am on this list for less than a month > - I haven't used roundup before > - I commented on few python bugs/patches in SF (user name is "draghuram") > > I do not have any preferences as to the type of work I am interested > in (at least at this point). So you can try pretty much anything > including documentation. Thanks for the offer, Raghu! As of right now we are in a holding pattern until 2.5.1 comes out. Once it has we will do the transition two to four weeks after depending on how many issues end up being reported. In terms of helping with stuff, we are kind of sitting here waiting. =) You can try out the test tracker and give feedback on the meta tracker, but realize that only showstopper bugs will be considered at this point until the switch is made. -Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20070409/7ee29427/attachment.html From draghuram at gmail.com Tue Apr 10 06:33:33 2007 From: draghuram at gmail.com (Raghuram Devarakonda) Date: Tue, 10 Apr 2007 00:33:33 -0400 Subject: [Tracker-discuss] contribution In-Reply-To: References: <2c51ecee0704091421l654a638w1b927ead99e353bd@mail.gmail.com> Message-ID: <2c51ecee0704092133hf21ed13nc16389a2b288745f@mail.gmail.com> > Thanks for the offer, Raghu! As of right now we are in a holding pattern > until 2.5.1 comes out. Once it has we will do the transition two to four > weeks after depending on how many issues end up being reported. > > In terms of helping with stuff, we are kind of sitting here waiting. =) > You can try out the test tracker and give feedback on the meta tracker, but > realize that only showstopper bugs will be considered at this point until > the switch is made. Sure. I will see what I can do. Thanks, Raghu. From metatracker at psf.upfronthosting.co.za Tue Apr 10 21:18:40 2007 From: metatracker at psf.upfronthosting.co.za (Erik Forsberg) Date: Tue, 10 Apr 2007 19:18:40 -0000 Subject: [Tracker-discuss] [issue111] Roundup not fault tolerant enough about duplicate form values. Message-ID: <1176232720.99.0.991224431207.issue111@psf.upfronthosting.co.za> Erik Forsberg added the comment: I've added some debug code to the roundup used on psf, which (if the debug code works.. :-) )will tell us the output of self.current_url() the next time the bug triggers. _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Apr 11 21:10:54 2007 From: metatracker at psf.upfronthosting.co.za (Erik Forsberg) Date: Wed, 11 Apr 2007 19:10:54 -0000 Subject: [Tracker-discuss] [issue112] psf's postfix presents itself as psf.localdomain Message-ID: <87veg2d8w5.fsf@uterus.efod.se> New submission from Erik Forsberg: The postfix of psf.upfronthosting.co.za presents itself as psf.localdomain when saying EHLO/HELO. This seems to trigger some spam filters. \EF -- Erik Forsberg http://efod.se GPG/PGP Key: 1024D/0BAC89D9 ---------- messages: 616 nosy: forsberg status: unread title: psf's postfix presents itself as psf.localdomain _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Apr 11 23:18:18 2007 From: metatracker at psf.upfronthosting.co.za (Izak Burger) Date: Wed, 11 Apr 2007 21:18:18 -0000 Subject: [Tracker-discuss] [issue112] psf's postfix presents itself as psf.localdomain In-Reply-To: <87veg2d8w5.fsf@uterus.efod.se> Message-ID: <461D507C.8060708@upfrontsystems.co.za> Izak Burger added the comment: Erik Forsberg wrote: > The postfix of psf.upfronthosting.co.za presents itself as > psf.localdomain when saying EHLO/HELO. This seems to trigger some spam > filters. Weird. The documentation says that myhostname (which is used as the default value for helo_name) defaults to the value of gethostname(2), which returns "psf". So it gets the localdomain part from somewhere but I cannot figure out where. In any case, I set myhostname to "psf.upfronthosting.co.za". That should sort it out. ---------- status: unread -> chatting _______________________________________________________ Meta Tracker _______________________________________________________ From izak at upfrontsystems.co.za Wed Apr 11 23:17:48 2007 From: izak at upfrontsystems.co.za (Izak Burger) Date: Wed, 11 Apr 2007 23:17:48 +0200 Subject: [Tracker-discuss] [issue112] psf's postfix presents itself as psf.localdomain In-Reply-To: <87veg2d8w5.fsf@uterus.efod.se> References: <87veg2d8w5.fsf@uterus.efod.se> Message-ID: <461D507C.8060708@upfrontsystems.co.za> Erik Forsberg wrote: > The postfix of psf.upfronthosting.co.za presents itself as > psf.localdomain when saying EHLO/HELO. This seems to trigger some spam > filters. Weird. The documentation says that myhostname (which is used as the default value for helo_name) defaults to the value of gethostname(2), which returns "psf". So it gets the localdomain part from somewhere but I cannot figure out where. In any case, I set myhostname to "psf.upfronthosting.co.za". That should sort it out. From metatracker at psf.upfronthosting.co.za Sat Apr 14 21:30:48 2007 From: metatracker at psf.upfronthosting.co.za (Erik Forsberg) Date: Sat, 14 Apr 2007 19:30:48 -0000 Subject: [Tracker-discuss] [issue112] psf's postfix presents itself as psf.localdomain Message-ID: <1176579048.19.0.302822018159.issue112@psf.upfronthosting.co.za> Erik Forsberg added the comment: Running 'postconf myhostname' before your change in main.cf, it returned psf.localdomain. Which is, indeed, weird, as the rest of the system seems rather convinced that its name is psf.upfronthosting.co.za. Oh well.. let's just be happy with the 'setting myhostname' solution. ---------- assignedto: -> izak nosy: +izak priority: -> bug status: chatting -> resolved _______________________________________________________ Meta Tracker _______________________________________________________ From izak at upfrontsystems.co.za Wed Apr 18 09:33:00 2007 From: izak at upfrontsystems.co.za (Izak Burger) Date: Wed, 18 Apr 2007 09:33:00 +0200 Subject: [Tracker-discuss] Serialization error Message-ID: <4625C9AC.7050504@upfrontsystems.co.za> Hi all, I recall that at some point someone asked about this error but I lost the thread that was in. Occasionally this error is mailed to roundup-admin: Tracker: ERROR: could not serialize access due to concurrent update While working on another postgresql based project I noticed that this error is a postgresql error. It occurs when you do things inside a transaction and you set the isolation level to serializable. The documentation says you have to watch out for failures and be prepared to retry. Here's a link: http://www.postgresql.org/docs/8.1/interactive/transaction-iso.html I'm mentioning this here as it might mean (on the one hand) that some attention needs to be given to the database part of roundup, and (on the other hand) it at least explains where that error comes from. regards, Izak From forsberg at efod.se Wed Apr 18 14:14:11 2007 From: forsberg at efod.se (Erik Forsberg) Date: Wed, 18 Apr 2007 14:14:11 +0200 Subject: [Tracker-discuss] Serialization error In-Reply-To: <4625C9AC.7050504@upfrontsystems.co.za> (Izak Burger's message of "Wed, 18 Apr 2007 09:33:00 +0200") References: <4625C9AC.7050504@upfrontsystems.co.za> Message-ID: <87mz15nalo.fsf@uterus.efod.se> Izak Burger writes: > I'm mentioning this here as it might mean (on the one hand) that some > attention needs to be given to the database part of roundup, and (on the > other hand) it at least explains where that error comes from. It's a known problem with roundup, see [1]. It has been fixed, but we're running 1.3.2, so the fix might not be in that version. Should probably upgrade to 1.3.3 before going live. [1] http://thread.gmane.org/gmane.comp.bug-tracking.roundup.user/7135 Cheers, \EF -- Erik Forsberg http://efod.se GPG/PGP Key: 1024D/0BAC89D9 From metatracker at psf.upfronthosting.co.za Wed Apr 18 18:51:10 2007 From: metatracker at psf.upfronthosting.co.za (Erik Forsberg) Date: Wed, 18 Apr 2007 16:51:10 -0000 Subject: [Tracker-discuss] [issue111] Roundup not fault tolerant enough about duplicate form values. Message-ID: <1176915070.07.0.401692024267.issue111@psf.upfronthosting.co.za> Erik Forsberg added the comment: I'm beginning to think that this problem is caused not by a faulty template (the complaints are from the meta tracker, on issue.index, from what I can see. AFAIK, we haven't done any changes there), but instead from some kind of spam or virus trying to abuse the system. Therefore, some resistance code in roundup is probably the way to go to avoid error messages to the administrators. _______________________________________________________ Meta Tracker _______________________________________________________ From forsberg at efod.se Wed Apr 18 18:59:35 2007 From: forsberg at efod.se (Erik Forsberg) Date: Wed, 18 Apr 2007 18:59:35 +0200 Subject: [Tracker-discuss] Serialization error In-Reply-To: <87mz15nalo.fsf@uterus.efod.se> (Erik Forsberg's message of "Wed, 18 Apr 2007 14:14:11 +0200") References: <4625C9AC.7050504@upfrontsystems.co.za> <87mz15nalo.fsf@uterus.efod.se> Message-ID: <87irbtmxe0.fsf@uterus.efod.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Forsberg writes: > Izak Burger writes: > >> I'm mentioning this here as it might mean (on the one hand) that some >> attention needs to be given to the database part of roundup, and (on the >> other hand) it at least explains where that error comes from. > > It's a known problem with roundup, see [1]. It has been fixed, but > we're running 1.3.2, so the fix might not be in that version. Wrong by me - it's still a problem, the fix implemented by Richard doesn't work. I'll talk to the roundup-users list about it. Cheers, \EF - -- Erik Forsberg http://efod.se GPG/PGP Key: 1024D/0BAC89D9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ iD8DBQFGJk53rJurFAusidkRAr/lAKDJp49gKaFIs4zvvJsD6dHLvW5njgCfb7ns tnYDVOpWqpkEYd2xGko8URw= =Yrqm -----END PGP SIGNATURE----- From pfdubois at gmail.com Wed Apr 18 19:00:56 2007 From: pfdubois at gmail.com (Paul Dubois) Date: Wed, 18 Apr 2007 10:00:56 -0700 Subject: [Tracker-discuss] [issue111] Roundup not fault tolerant enough about duplicate form values. In-Reply-To: <1176915070.07.0.401692024267.issue111@psf.upfronthosting.co.za> References: <1176915070.07.0.401692024267.issue111@psf.upfronthosting.co.za> Message-ID: FWIW that is what I have been thinking too. Also those concurrent access things, at a time when we don't have any users. Only a bot can do that, I'm thinking. When I get strange stuff like this at work I am often able to trace it back to attacks by my own security people trying to break in. They do so many probes at once it amounts to a denial of service attack. But hey, they're SECURITY, so it is ok. (:-> On 4/18/07, Erik Forsberg wrote: > > Erik Forsberg added the comment: > > I'm beginning to think that this problem is caused not by a faulty template (the > complaints are from the meta tracker, on issue.index, from what I can see. > AFAIK, we haven't done any changes there), but instead from some kind of spam or > virus trying to abuse the system. > > Therefore, some resistance code in roundup is probably the way to go to avoid > error messages to the administrators. > > _______________________________________________________ > Meta Tracker > > _______________________________________________________ > _______________________________________________ > Tracker-discuss mailing list > Tracker-discuss at python.org > http://mail.python.org/mailman/listinfo/tracker-discuss > From metatracker at psf.upfronthosting.co.za Wed Apr 18 19:00:59 2007 From: metatracker at psf.upfronthosting.co.za (Paul Dubois) Date: Wed, 18 Apr 2007 17:00:59 -0000 Subject: [Tracker-discuss] [issue111] Roundup not fault tolerant enough about duplicate form values. In-Reply-To: <1176915070.07.0.401692024267.issue111@psf.upfronthosting.co.za> Message-ID: Paul Dubois added the comment: FWIW that is what I have been thinking too. Also those concurrent access things, at a time when we don't have any users. Only a bot can do that, I'm thinking. When I get strange stuff like this at work I am often able to trace it back to attacks by my own security people trying to break in. They do so many probes at once it amounts to a denial of service attack. But hey, they're SECURITY, so it is ok. (:-> On 4/18/07, Erik Forsberg wrote: > > Erik Forsberg added the comment: > > I'm beginning to think that this problem is caused not by a faulty template (the > complaints are from the meta tracker, on issue.index, from what I can see. > AFAIK, we haven't done any changes there), but instead from some kind of spam or > virus trying to abuse the system. > > Therefore, some resistance code in roundup is probably the way to go to avoid > error messages to the administrators. > > _______________________________________________________ > Meta Tracker > > _______________________________________________________ > _______________________________________________ > Tracker-discuss mailing list > Tracker-discuss at python.org > http://mail.python.org/mailman/listinfo/tracker-discuss > _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Apr 21 18:53:39 2007 From: metatracker at psf.upfronthosting.co.za (Erik Forsberg) Date: Sat, 21 Apr 2007 16:53:39 -0000 Subject: [Tracker-discuss] [issue113] Isolation-related tracebacks Message-ID: <1177174419.17.0.0364230666728.issue113@psf.upfronthosting.co.za> New submission from Erik Forsberg: We're getting the error discussed on http://thread.gmane.org/gmane.comp.bug-tracking.roundup.user/7135. I've created a ugly patch to fix this and applied it to our copy of roudup, but it should really be fixed in roundup upstream, and in a better way. http://sourceforge.net/tracker/index.php?func=detail&aid=1703116&group_id=31577&atid=402788 is the bug entry on roundup. ---------- assignedto: forsberg messages: 621 nosy: forsberg priority: bug status: resolved title: Isolation-related tracebacks topic: roundup_deviation _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Apr 21 18:59:15 2007 From: metatracker at psf.upfronthosting.co.za (Erik Forsberg) Date: Sat, 21 Apr 2007 16:59:15 -0000 Subject: [Tracker-discuss] [issue111] Roundup not fault tolerant enough about duplicate form values. Message-ID: <1177174755.03.0.818105765205.issue111@psf.upfronthosting.co.za> Erik Forsberg added the comment: I've commited a fix for this to our roundup. Let's see if it gives the desired effect. ---------- assignedto: richard -> forsberg nosy: +forsberg topic: +roundup_deviation _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Apr 21 19:44:36 2007 From: metatracker at psf.upfronthosting.co.za (Erik Forsberg) Date: Sat, 21 Apr 2007 17:44:36 -0000 Subject: [Tracker-discuss] [issue101] importer: merge old Python versions in "version" field Message-ID: <1177177476.66.0.264357636772.issue101@psf.upfronthosting.co.za> Erik Forsberg added the comment: This has now been implemented. No new import has been done on bugs.python.org, which means the result will be shown after the next import. ---------- assignedto: -> forsberg nosy: +forsberg status: chatting -> resolved _______________________________________________________ Meta Tracker _______________________________________________________ From brett at python.org Sat Apr 21 21:05:43 2007 From: brett at python.org (Brett Cannon) Date: Sat, 21 Apr 2007 12:05:43 -0700 Subject: [Tracker-discuss] 2.5.1 out the door; time to start thinking about a switch-over date Message-ID: Anthony Baxter just unfroze the 2.5 maintenance branch. That means we should discuss a switch-over date and really lock down the transition procedures as laid out at http://wiki.python.org/moin/TrackerTransition . It looks like we only have 2 urgent issues and 2 bug issues. How long do people think it will take to get those closed? I am thinking we get all of the important issues closed first. Then we start following the transition doc (whose next step is to negotiate a switch-over date with python-dev). -Brett From forsberg at efod.se Sat Apr 21 21:21:30 2007 From: forsberg at efod.se (Erik Forsberg) Date: Sat, 21 Apr 2007 21:21:30 +0200 Subject: [Tracker-discuss] 2.5.1 out the door; time to start thinking about a switch-over date In-Reply-To: (Brett Cannon's message of "Sat, 21 Apr 2007 12:05:43 -0700") References: Message-ID: <87647pleit.fsf@uterus.efod.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Brett Cannon" writes: > It looks like we only have 2 urgent issues and 2 bug issues. How long > do people think it will take to get those closed? Regarding issue111, you'll have to ask "SF.net Site Enhancement" :-(. \EF - -- Erik Forsberg http://efod.se GPG/PGP Key: 1024D/0BAC89D9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ iD8DBQFGKmQ5rJurFAusidkRAlUVAKCSZBsg45rq4ChiqmdZ/OCGq4413wCgr5da NW5v5hqdoSirWaS1WAFptdY= =AQcA -----END PGP SIGNATURE----- From brett at python.org Sun Apr 22 01:51:07 2007 From: brett at python.org (Brett Cannon) Date: Sat, 21 Apr 2007 16:51:07 -0700 Subject: [Tracker-discuss] 2.5.1 out the door; time to start thinking about a switch-over date In-Reply-To: <87647pleit.fsf@uterus.efod.se> References: <87647pleit.fsf@uterus.efod.se> Message-ID: On 4/21/07, Erik Forsberg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > "Brett Cannon" writes: > > > It looks like we only have 2 urgent issues and 2 bug issues. How long > > do people think it will take to get those closed? > > Regarding issue111, you'll have to ask "SF.net Site Enhancement" :-(. > Damn. Can we resurrect Fredrik's tool if SF doesn't get off their ass and fix the export? -Brett From forsberg at efod.se Sun Apr 22 06:29:26 2007 From: forsberg at efod.se (Erik Forsberg) Date: Sun, 22 Apr 2007 06:29:26 +0200 Subject: [Tracker-discuss] 2.5.1 out the door; time to start thinking about a switch-over date In-Reply-To: (Brett Cannon's message of "Sat, 21 Apr 2007 16:51:07 -0700") References: <87647pleit.fsf@uterus.efod.se> Message-ID: <87vefp58wp.fsf@uterus.efod.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Brett Cannon" writes: > On 4/21/07, Erik Forsberg wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> "Brett Cannon" writes: >> >> > It looks like we only have 2 urgent issues and 2 bug issues. How long >> > do people think it will take to get those closed? >> >> Regarding issue111, you'll have to ask "SF.net Site Enhancement" :-(. >> > > Damn. Can we resurrect Fredrik's tool if SF doesn't get off their ass > and fix the export? Well.. I'm sure it can be done, but I'm also sure it will take quite some time to get it working again. Also, the xml-based importer is much faster as it doesn't have to download everything piece by piece, compensating for sf's surge protection along the way. Some friendly feedback on https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1687916&group_id=1 from somebody else than me to show that more than one person is interested in a solution might help. Perhaps we should avoid mentioning that the reason we want a complete backup is to be able to move away from sf - that might disturb their view of the importance of the problem.. \EF - -- Erik Forsberg http://efod.se GPG/PGP Key: 1024D/0BAC89D9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ iD8DBQFGKuSlrJurFAusidkRAlB6AJ9RgV1giQjXsyy6Ih1zMLU9ZlBU3QCgvdGB WUVL7wPAZjph9XP5/8alNd0= =K3Xw -----END PGP SIGNATURE----- From brett at python.org Sun Apr 22 20:47:49 2007 From: brett at python.org (Brett Cannon) Date: Sun, 22 Apr 2007 11:47:49 -0700 Subject: [Tracker-discuss] 2.5.1 out the door; time to start thinking about a switch-over date In-Reply-To: <87vefp58wp.fsf@uterus.efod.se> References: <87647pleit.fsf@uterus.efod.se> <87vefp58wp.fsf@uterus.efod.se> Message-ID: On 4/21/07, Erik Forsberg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > "Brett Cannon" writes: > > > On 4/21/07, Erik Forsberg wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> "Brett Cannon" writes: > >> > >> > It looks like we only have 2 urgent issues and 2 bug issues. How long > >> > do people think it will take to get those closed? > >> > >> Regarding issue111, you'll have to ask "SF.net Site Enhancement" :-(. > >> > > > > Damn. Can we resurrect Fredrik's tool if SF doesn't get off their ass > > and fix the export? > > Well.. I'm sure it can be done, but I'm also sure it will take quite > some time to get it working again. Also, the xml-based importer is > much faster as it doesn't have to download everything piece by piece, > compensating for sf's surge protection along the way. > > Some friendly feedback on > https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1687916&group_id=1 > from somebody else than me to show that more than one person is > interested in a solution might help. Perhaps we should avoid > mentioning that the reason we want a complete backup is to be able to > move away from sf - that might disturb their view of the importance of > the problem.. > I will try to get around to this. Obviously everyone else is welcome to bug SF as well. =) -Brett From metatracker at psf.upfronthosting.co.za Sun Apr 22 21:39:54 2007 From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 22 Apr 2007 19:39:54 -0000 Subject: [Tracker-discuss] [issue114] Cannot reach bugs.python.org Message-ID: <1177270794.37.0.166032417226.issue114@psf.upfronthosting.co.za> New submission from Martin v. L?wis: I have difficulties connecting to bugs.python.org from my home machine, for several weeks now. It's not clear whether the problem is on my ISP's side (Freenet) or on Roche's/Hetzner's, so I'd like to request that Roche analyzes it and determines whether they drop packets. Here is a tracerout output: traceroute to 88.198.142.26 (88.198.142.26), 30 hops max, 40 byte packets 1 * * * 2 G5-0.bln2-g2.mcbone.net (62.104.208.6) 52.659 ms 52.874 ms 53.275 ms 3 L0.bln2-g.mcbone.net (62.104.191.139) 52.680 ms 56.962 ms 52.380 ms 4 lo0-0.lpz2-j2.mcbone.net (62.104.191.208) 57.864 ms 58.941 ms 58.792 ms 5 lo0-0.lpz2-j.mcbone.net (62.104.191.207) 58.528 ms 58.656 ms 56.668 ms 6 ge-0-0-0-0.nbg2-j2.mcbone.net (62.104.200.136) 63.018 ms 61.864 ms 62.694 ms 7 ge-0-1-0-0.nbg2-j.mcbone.net (62.104.200.134) 62.085 ms 60.736 ms 62.145 ms 8 GigE-0.Hetzner.DHK.N-IX.net (195.85.217.16) 63.993 ms 64.378 ms 61.473 ms 9 hos-bb1.juniper3.rz4.hetzner.de (213.239.240.234) 63.436 ms 70.102 ms 67.753 ms 10 et.2.16.rs3k6.rz5.hetzner.de (213.239.244.101) 64.493 ms 62.727 ms 63.468 ms 11 * * * ---------- assignedto: roche messages: 624 nosy: izak, loewis, roche priority: urgent status: unread title: Cannot reach bugs.python.org _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sun Apr 22 22:53:36 2007 From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Roch=C3=A9_Compaan?=) Date: Sun, 22 Apr 2007 20:53:36 -0000 Subject: [Tracker-discuss] [issue114] Cannot reach bugs.python.org In-Reply-To: <1177270794.37.0.166032417226.issue114@psf.upfronthosting.co.za> Message-ID: <1177275304.19269.76.camel@kwaatjie> Roch? Compaan added the comment: On Sun, 2007-04-22 at 19:39 +0000, Martin v. L?wis wrote: > New submission from Martin v. L?wis: > > I have difficulties connecting to bugs.python.org from my home machine, for > several weeks now. It's not clear whether the problem is on my ISP's side > (Freenet) or on Roche's/Hetzner's, so I'd like to request that Roche analyzes it > and determines whether they drop packets. Here is a tracerout output: > > traceroute to 88.198.142.26 (88.198.142.26), 30 hops max, 40 byte packets > 1 * * * > 2 G5-0.bln2-g2.mcbone.net (62.104.208.6) 52.659 ms 52.874 ms 53.275 ms > 3 L0.bln2-g.mcbone.net (62.104.191.139) 52.680 ms 56.962 ms 52.380 ms > 4 lo0-0.lpz2-j2.mcbone.net (62.104.191.208) 57.864 ms 58.941 ms 58.792 ms > 5 lo0-0.lpz2-j.mcbone.net (62.104.191.207) 58.528 ms 58.656 ms 56.668 ms > 6 ge-0-0-0-0.nbg2-j2.mcbone.net (62.104.200.136) 63.018 ms 61.864 ms 62.694 ms > 7 ge-0-1-0-0.nbg2-j.mcbone.net (62.104.200.134) 62.085 ms 60.736 ms 62.145 ms > 8 GigE-0.Hetzner.DHK.N-IX.net (195.85.217.16) 63.993 ms 64.378 ms 61.473 ms > 9 hos-bb1.juniper3.rz4.hetzner.de (213.239.240.234) 63.436 ms 70.102 ms > 67.753 ms > 10 et.2.16.rs3k6.rz5.hetzner.de (213.239.244.101) 64.493 ms 62.727 ms 63.468 ms > 11 * * * I can confirm that it is reachable for me. The fact that it is reaching the Hetzner data centre seems suspect. Martin what is your source IP? Izak can you check if the firewall isn't blocking IP ranges that are now acceptable that were previously considered unroutable? ---------- status: unread -> chatting _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sun Apr 22 23:08:19 2007 From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 22 Apr 2007 21:08:19 -0000 Subject: [Tracker-discuss] [issue114] Cannot reach bugs.python.org In-Reply-To: <1177275304.19269.76.camel@kwaatjie> Message-ID: <462BCEC2.6080502@v.loewis.de> Martin v. L?wis added the comment: > I can confirm that it is reachable for me. The fact that it is reaching > the Hetzner data centre seems suspect. Martin what is your source IP? At the moment, it's 77.128.21.125 (although it is dynamically assigned, so it may change soon). Regards, Martin _______________________________________________________ Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Mon Apr 23 08:37:30 2007 From: metatracker at psf.upfronthosting.co.za (Izak Burger) Date: Mon, 23 Apr 2007 06:37:30 -0000 Subject: [Tracker-discuss] [issue114] Cannot reach bugs.python.org In-Reply-To: <462BCEC2.6080502@v.loewis.de> Message-ID: <462C5416.2010509@upfrontsystems.co.za> Izak Burger added the comment: >> I can confirm that it is reachable for me. The fact that it is reaching >> the Hetzner data centre seems suspect. Martin what is your source IP? > > At the moment, it's 77.128.21.125 (although it is dynamically assigned, > so it may change soon). Bingo! Right on the money again. We've had a lot of these lately. The firewall product we use has the ability to drop unroutable ip's. In the beginning I thought this was just 192.168/16, 172.16/12 and 10/8 but I soon found out it also includes a list of ip's that is marked as reserved by IANA. http://www.iana.org/assignments/ipv4-address-space 77.0.0.0/8 and 78.0.0.0/8 was reassigned last year, but I think the ISP only recently started assigning them to clients. We actually had similar problems from our side when our local ISP started assigning ip's from 42.0.0.0/8 which was formerly reserved. In any case, it is fixed now. regards, Izak _______________________________________________________ Meta Tracker _______________________________________________________ From izak at upfrontsystems.co.za Mon Apr 23 08:37:10 2007 From: izak at upfrontsystems.co.za (Izak Burger) Date: Mon, 23 Apr 2007 08:37:10 +0200 Subject: [Tracker-discuss] [issue114] Cannot reach bugs.python.org In-Reply-To: <462BCEC2.6080502@v.loewis.de> References: <462BCEC2.6080502@v.loewis.de> Message-ID: <462C5416.2010509@upfrontsystems.co.za> >> I can confirm that it is reachable for me. The fact that it is reaching >> the Hetzner data centre seems suspect. Martin what is your source IP? > > At the moment, it's 77.128.21.125 (although it is dynamically assigned, > so it may change soon). Bingo! Right on the money again. We've had a lot of these lately. The firewall product we use has the ability to drop unroutable ip's. In the beginning I thought this was just 192.168/16, 172.16/12 and 10/8 but I soon found out it also includes a list of ip's that is marked as reserved by IANA. http://www.iana.org/assignments/ipv4-address-space 77.0.0.0/8 and 78.0.0.0/8 was reassigned last year, but I think the ISP only recently started assigning them to clients. We actually had similar problems from our side when our local ISP started assigning ip's from 42.0.0.0/8 which was formerly reserved. In any case, it is fixed now. regards, Izak From metatracker at psf.upfronthosting.co.za Mon Apr 23 22:27:49 2007 From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 23 Apr 2007 20:27:49 -0000 Subject: [Tracker-discuss] [issue114] Cannot reach bugs.python.org Message-ID: <1177360069.05.0.703479303305.issue114@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Indeed, it's fixed (filling this out through a local Firefox, instead of one that I run remotely over X11). Thanks for your quick response. ---------- status: chatting -> resolved _______________________________________________________ Meta Tracker _______________________________________________________ From amk at amk.ca Tue Apr 24 22:58:38 2007 From: amk at amk.ca (A.M. Kuchling) Date: Tue, 24 Apr 2007 16:58:38 -0400 Subject: [Tracker-discuss] Tracker for web-related issues Message-ID: <20070424205838.GA19531@localhost.localdomain> Did anyone ever create a tracker for issues relating to the Python web site? If not, can we please create a tracker instance for that? --amk From brett at python.org Tue Apr 24 23:09:56 2007 From: brett at python.org (Brett Cannon) Date: Tue, 24 Apr 2007 14:09:56 -0700 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: <20070424205838.GA19531@localhost.localdomain> References: <20070424205838.GA19531@localhost.localdomain> Message-ID: On 4/24/07, A.M. Kuchling wrote: > Did anyone ever create a tracker for issues relating to the Python web > site? Not that I know of. >If not, can we please create a tracker instance for that? Eventually, definitely. Right now, it's up to the admins if they want to tackle that now or wait until after the switch-over. Either way we should probably figure out how best to handle multiple Roundup instances as I am sure the number of projects that want trackers is just going to grow and we will end up with several (meta, python-dev, web, pycon-tech, possibly other ones like Stackless, Roundup itself if they wanted, Jython, etc.). Should probably write down what we require of a group to provide: an admin, we just launch a vanilla instance or do we help them customize, etc. -Brett From seefeld at sympatico.ca Tue Apr 24 23:14:53 2007 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Tue, 24 Apr 2007 17:14:53 -0400 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: References: <20070424205838.GA19531@localhost.localdomain> Message-ID: <462E734D.9020708@sympatico.ca> Brett Cannon wrote: > On 4/24/07, A.M. Kuchling wrote: >> Did anyone ever create a tracker for issues relating to the Python web >> site? > > Not that I know of. > >> If not, can we please create a tracker instance for that? > > Eventually, definitely. Right now, it's up to the admins if they want > to tackle that now or wait until after the switch-over. > > Either way we should probably figure out how best to handle multiple > Roundup instances as I am sure the number of projects that want > trackers is just going to grow and we will end up with several (meta, > python-dev, web, pycon-tech, possibly other ones like Stackless, > Roundup itself if they wanted, Jython, etc.). Should probably write > down what we require of a group to provide: an admin, we just launch a > vanilla instance or do we help them customize, etc. Would tracking the python.org issues require a work-flow different from what we are implementing for python-dev now ? If not, what prevents us from simply adding a new category (component, say) to the existing tracker ? Or would that dilute the focus of the tracker ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... From amk at amk.ca Tue Apr 24 23:21:17 2007 From: amk at amk.ca (A.M. Kuchling) Date: Tue, 24 Apr 2007 17:21:17 -0400 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: <462E734D.9020708@sympatico.ca> References: <20070424205838.GA19531@localhost.localdomain> <462E734D.9020708@sympatico.ca> Message-ID: <20070424212117.GA20152@localhost.localdomain> On Tue, Apr 24, 2007 at 05:14:53PM -0400, Stefan Seefeld wrote: > Would tracking the python.org issues require a work-flow different from what > we are implementing for python-dev now ? If not, what prevents us from simply > adding a new category (component, say) to the existing tracker ? Or would > that dilute the focus of the tracker ? There is no particular workflow for web site issues, so I think a completely generic Roundup instance would be fine. A stock Trac instance was used for a while, but it became plagued by spam and there was no good solution except to shut off registrations -- now you'd have to send e-mail to a person to register. I think the population of admins and developers is different; most Python developers do not maintain the web site, and some web admins do not have Python commit privileges. But even a stock roundup instance is better than a Trac instance that you can't actually register for. --amk From Doug.Napoleone at nuance.com Tue Apr 24 23:24:13 2007 From: Doug.Napoleone at nuance.com (Doug Napoleone) Date: Tue, 24 Apr 2007 17:24:13 -0400 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: <462E734D.9020708@sympatico.ca> References: <20070424205838.GA19531@localhost.localdomain> <462E734D.9020708@sympatico.ca> Message-ID: <2AB5541EB33172459EE430FFB66B1EE904E2DE81@BN-EXCH01.nuance.com> Stefan Seefeld wrote: > Would tracking the python.org issues require a work-flow different from > what > we are implementing for python-dev now ? If not, what prevents us from > simply > adding a new category (component, say) to the existing tracker ? Or would > that dilute the focus of the tracker ? The workflow might be very similar, but it would defiantly dilute the focus of the python-def tracker. The there would need to be multiple python-website categories and what is a code bug, verses a documentation bug, verses style/image would pollute the system. I also do not think there is much overlap between those working on python-dev and those working on the web site. Two mostly disjoint groups using the same tracker could cause issues. -Doug From martin at v.loewis.de Tue Apr 24 23:28:06 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 24 Apr 2007 23:28:06 +0200 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: References: <20070424205838.GA19531@localhost.localdomain> Message-ID: <462E7666.8090109@v.loewis.de> >> Did anyone ever create a tracker for issues relating to the Python web >> site? > > Not that I know of. > >> If not, can we please create a tracker instance for that? > > Eventually, definitely. Right now, it's up to the admins if they want > to tackle that now or wait until after the switch-over. > > Either way we should probably figure out how best to handle multiple > Roundup instances as I am sure the number of projects that want > trackers is just going to grow and we will end up with several (meta, > python-dev, web, pycon-tech, possibly other ones like Stackless, > Roundup itself if they wanted, Jython, etc.). Should probably write > down what we require of a group to provide: an admin, we just launch a > vanilla instance or do we help them customize, etc. I agree that an admin should be necessary. That admin needs to make a number of decisions: - what URL the tracker should be available on? - what mailing list get new issues be sent to? changes to existing issues? - what From address should the tracker use to send such email? - what, if any, email address should the tracker use for incoming email (such as follow-ups to existing issue)? Notice that "None" is an answer that roundup die-hards cannot accept: some people strongly believe that the primary value of roundup originates from the support for email follow-up. - what, if any, changes from the standard schema should be make? - what people fall into the "developers" category? I'd be in favour of getting these steps done for the pydotorg tracker, to see how it works out. I understand that it doesn't have the data migration issues that bugs.python.org has, so it should be easy Regards, Martin From martin at v.loewis.de Tue Apr 24 23:28:45 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 24 Apr 2007 23:28:45 +0200 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: <462E734D.9020708@sympatico.ca> References: <20070424205838.GA19531@localhost.localdomain> <462E734D.9020708@sympatico.ca> Message-ID: <462E768D.1090501@v.loewis.de> > Would tracking the python.org issues require a work-flow different from what > we are implementing for python-dev now ? If not, what prevents us from simply > adding a new category (component, say) to the existing tracker ? Or would > that dilute the focus of the tracker ? I think the email notifications would be different. Martin From brett at python.org Wed Apr 25 01:19:37 2007 From: brett at python.org (Brett Cannon) Date: Tue, 24 Apr 2007 16:19:37 -0700 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: <462E7666.8090109@v.loewis.de> References: <20070424205838.GA19531@localhost.localdomain> <462E7666.8090109@v.loewis.de> Message-ID: On 4/24/07, "Martin v. L?wis" wrote: > >> Did anyone ever create a tracker for issues relating to the Python web > >> site? > > > > Not that I know of. > > > >> If not, can we please create a tracker instance for that? > > > > Eventually, definitely. Right now, it's up to the admins if they want > > to tackle that now or wait until after the switch-over. > > > > Either way we should probably figure out how best to handle multiple > > Roundup instances as I am sure the number of projects that want > > trackers is just going to grow and we will end up with several (meta, > > python-dev, web, pycon-tech, possibly other ones like Stackless, > > Roundup itself if they wanted, Jython, etc.). Should probably write > > down what we require of a group to provide: an admin, we just launch a > > vanilla instance or do we help them customize, etc. > > I agree that an admin should be necessary. That admin needs to make > a number of decisions: > - what URL the tracker should be available on? > - what mailing list get new issues be sent to? changes to existing > issues? > - what From address should the tracker use to send such email? > - what, if any, email address should the tracker use for incoming > email (such as follow-ups to existing issue)? > Notice that "None" is an answer that roundup die-hards cannot > accept: some people strongly believe that the primary value > of roundup originates from the support for email follow-up. > - what, if any, changes from the standard schema should be > make? > - what people fall into the "developers" category? > Good list. So the admin should be considered point contact and to possibly be called on as needed to help with stuff. Should probably give them admin privileges on the box but obviously told that they should not muck with other people's instances or core box stuff without talking to the key admins and this list as needed. What does everyone else think? I know it has been said it is easy to add another instance, but I want Erik, Stephan, and Paul to agree to this as they would be the first people called upon to put out any fires. > I'd be in favour of getting these steps done for the pydotorg > tracker, to see how it works out. Yeah, pydotorg can be the guinea pig. =) Assuming the core admins agree to this we will end up needing someone to step up for pydotorg to play admin. > I understand that it doesn't > have the data migration issues that bugs.python.org has, so it > should be easy > True. Plus they probably don't need any critical schema changes beyond the default. -Brett From seefeld at sympatico.ca Wed Apr 25 01:31:02 2007 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Tue, 24 Apr 2007 19:31:02 -0400 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: References: <20070424205838.GA19531@localhost.localdomain> <462E7666.8090109@v.loewis.de> Message-ID: <462E9336.4030501@sympatico.ca> Brett Cannon wrote: > What does everyone else think? I know it has been said it is easy to > add another instance, but I want Erik, Stephan, and Paul to agree to > this as they would be the first people called upon to put out any > fires. Here are a couple of points: * I guess it would be nice if any new python tracker would use templates similar to the ones presently in use by the python-dev tracker, and not the vanilla templates that ship with roundup. * It seems the real complexities are in the workflow, which is mostly defined by the set of status enumerators, together with the detectors that enforce constraints on possible state changes. I believe it to be easier to start with a clone of the python-dev tracker and removing unwanted stuff, instead of starting over with a new vanilla tracker and trying to make it look like a python tracker. * Most issues that require continuous attention from admins will probably be security and spam related, things that shouldn't vary much between tracker instances (thus another argument to keep trackers close to each other). >> I'd be in favour of getting these steps done for the pydotorg >> tracker, to see how it works out. > > Yeah, pydotorg can be the guinea pig. =) Assuming the core admins > agree to this we will end up needing someone to step up for pydotorg > to play admin. What is the timeframe for this ? Can this wait until the current migration is over ? (In fact, what's the status of the migration now ? Are we only waiting for sf.net to once again fix their data export ? Or is some further work on the tracker needed ?) Oh, and yes, I'd like to offer roundup itself a tracker, too, if that's ok with the server admins. (Though this is just a minor point on my personal wish list :-) ) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... From martin at v.loewis.de Wed Apr 25 07:00:41 2007 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Wed, 25 Apr 2007 07:00:41 +0200 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: <462E9336.4030501@sympatico.ca> References: <20070424205838.GA19531@localhost.localdomain> <462E7666.8090109@v.loewis.de> <462E9336.4030501@sympatico.ca> Message-ID: <462EE079.4000802@v.loewis.de> > * It seems the real complexities are in the workflow, which is mostly > defined by the set of status enumerators, together with the detectors > that enforce constraints on possible state changes. I disagree. The notion of workflow is overrated: it assumes that there is work to flow. In many cases, this is not the case. People want the tracker just to not forget things. > I believe it to be easier to start with a clone of the python-dev > tracker and removing unwanted stuff, instead of starting over with > a new vanilla tracker and trying to make it look like a python tracker. I would say that the admin of the tracker should decide (and he should fully understand that any such decision will have wide-reaching consequences in time, i.e. that it will be very difficult to change and that changes to it will be infrequent). Regards, Martin From pfdubois at gmail.com Wed Apr 25 21:37:07 2007 From: pfdubois at gmail.com (Paul Dubois) Date: Wed, 25 Apr 2007 12:37:07 -0700 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: <462E9336.4030501@sympatico.ca> References: <20070424205838.GA19531@localhost.localdomain> <462E7666.8090109@v.loewis.de> <462E9336.4030501@sympatico.ca> Message-ID: I had some experience with 'me too' instances sharing my server, and I can say that it drove me crazy *unless* they used the same templates, with cosmetic changes like the name only. New versions of Roundup that require changes to the templates, while not that common, require much more effort if the instances are all different. If the vanilla one were acceptable that would be second-best, but I guess we've already found that anything as noticeable as python.org needs changes for evil-doer protection at the least. That said, I'm up for trying it. I'm 'retiring for good' in July so I can attend to basic issues fairly promptly (on the days when I'm not in Paris (:->). On 4/24/07, Stefan Seefeld wrote: > > Brett Cannon wrote: > > > What does everyone else think? I know it has been said it is easy to > > add another instance, but I want Erik, Stephan, and Paul to agree to > > this as they would be the first people called upon to put out any > > fires. > > Here are a couple of points: > > * I guess it would be nice if any new python tracker would use templates > similar to the ones presently in use by the python-dev tracker, and not > the vanilla templates that ship with roundup. > > * It seems the real complexities are in the workflow, which is mostly > defined by the set of status enumerators, together with the detectors > that enforce constraints on possible state changes. > I believe it to be easier to start with a clone of the python-dev > tracker and removing unwanted stuff, instead of starting over with > a new vanilla tracker and trying to make it look like a python tracker. > > * Most issues that require continuous attention from admins will probably > be security and spam related, things that shouldn't vary much between > tracker instances (thus another argument to keep trackers close to each > other). > > >> I'd be in favour of getting these steps done for the pydotorg > >> tracker, to see how it works out. > > > > Yeah, pydotorg can be the guinea pig. =) Assuming the core admins > > agree to this we will end up needing someone to step up for pydotorg > > to play admin. > > What is the timeframe for this ? Can this wait until the current migration > is over ? (In fact, what's the status of the migration now ? Are we only > waiting for sf.net to once again fix their data export ? Or is some > further > work on the tracker needed ?) > > Oh, and yes, I'd like to offer roundup itself a tracker, too, if that's ok > with the server admins. (Though this is just a minor point on my personal > wish list :-) ) > > > Thanks, > Stefan > > -- > > ...ich hab' noch einen Koffer in Berlin... > _______________________________________________ > 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: http://mail.python.org/pipermail/tracker-discuss/attachments/20070425/1bb462a7/attachment.htm From forsberg at efod.se Wed Apr 25 22:30:46 2007 From: forsberg at efod.se (Erik Forsberg) Date: Wed, 25 Apr 2007 22:30:46 +0200 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: (Brett Cannon's message of "Tue, 24 Apr 2007 16:19:37 -0700") References: <20070424205838.GA19531@localhost.localdomain> <462E7666.8090109@v.loewis.de> Message-ID: <87lkgg2o3t.fsf@uterus.efod.se> "Brett Cannon" writes: > What does everyone else think? I know it has been said it is easy to > add another instance, but I want Erik, Stephan, and Paul to agree to > this as they would be the first people called upon to put out any > fires. I do indeed have some comments on how I think this should be handled, but I'm having a busy week, so please have patience - I'll be back with a bunch of comments in a few days. \EF -- Erik Forsberg http://efod.se GPG/PGP Key: 1024D/0BAC89D9 From amk at amk.ca Thu Apr 26 20:42:17 2007 From: amk at amk.ca (A.M. Kuchling) Date: Thu, 26 Apr 2007 14:42:17 -0400 Subject: [Tracker-discuss] Tracker for web-related issues In-Reply-To: <462E9336.4030501@sympatico.ca> References: <20070424205838.GA19531@localhost.localdomain> <462E7666.8090109@v.loewis.de> <462E9336.4030501@sympatico.ca> Message-ID: <20070426184217.GA18838@localhost.localdomain> On Tue, Apr 24, 2007 at 07:31:02PM -0400, Stefan Seefeld wrote: > What is the timeframe for this ? Can this wait until the current migration > is over ? (In fact, what's the status of the migration now ? Are we only > waiting for sf.net to once again fix their data export ? Or is some further > work on the tracker needed ?) There's no particular time frame, but it would be nice to have an tracker for pydotorg bug reports that people can actually use. I was hoping that creating a generic instance, or a copy of the Python instance, would be near-trivial. --amk