[Python-Dev] Experimental and Test Tracker instances live
Hi,
As discussed before, I have put two mock Python Tracker instances online.
The Test[1] instance follows bugs.python.org code, so we can test
bugfixes and procedures without breaking the real tracker. The
Experimental[2] one, aka the cool instance, is where new features are
showcased.
Currently no emails are being sent and the dbs can be reset at any
time. If you'd like to play as a registered user, please email me and
I'll create a user (or activate the one you've started to register).
So far, the new features[3] include:
* Issue tags [4],[5]
* Quiet properties [6]
* Restore removed messages and files [7]
* Claim ('assign to self') and add/remove self as nosy buttons [8]
* Don't close issues with open dependencies [9]
* Auto-add nosy users based on Components [10]
* Email me buttons for messages and issues, Reply by email [11]
* RSS feeds (per issue and global) [12]
* Display selected issues in the index view [13]
You can subscribe to a RSS feed[14] about the new features.
Thanks to everyone who filled RFEs, there's still time to submit yours :)
Regards,
Daniel
[1] http://bot.bio.br/python-dev/
[2] http://bot.bio.br/python-dev-exp/
[3] http://bot.bio.br/python-dev-exp/issue5
[4] http://mail.python.org/pipermail/tracker-discuss/2009-April/002099.html
[5] http://codereview.appspot.com/40100/show
[6] http://psf.upfronthosting.co.za/roundup/meta/issue249
[7] http://psf.upfronthosting.co.za/roundup/meta/issue267
[8] http://psf.upfronthosting.co.za/roundup/meta/issue258
[9] http://psf.upfronthosting.co.za/roundup/meta/issue266
[10] http://psf.upfronthosting.co.za/roundup/meta/issue258
[11] http://psf.upfronthosting.co.za/roundup/meta/issue245
[12] http://psf.upfronthosting.co.za/roundup/meta/issue155
[13] http://psf.upfronthosting.co.za/roundup/meta/issue246
[14] http://bot.bio.br/python-dev-exp/issu...@template=feed
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
Dirkjan Ochtman wrote: One of the nicer features of Mercurial/DVCSs, in my experience, is that non-committers get to keep the credit on their patches. That means that it's impossible to enforce a policy more extensive than some basic checks (such as the format above). Unless we keep a list of people who have signed an agreement, which will mean people will have to re-do the username on commits that don't constitute a non-trivial contribution. Maybe it'd be better to first replicate the current workflow, shortcomings and all, then later discuss a new policy? That would mean no credits for non-commiters should come from the VCS alone: those come from commit messages, the ACKS file, copyright notices in source, etc. BTW, keep in mind some people will prefer to submit diff-generated, non-hg patches. IMO, this use case should be supported before the rich-patch one. Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
Martin v. Löwis wrote: I think it would be a good idea to host a temporary svn mirrors for developers who accesses their VCS via an IDE. Although, I am sure anymore if supporting these developers (if there are any) would worth the trouble. So, think of this as optional. Any decision to have or not have such a feature should be stated in the PEP. I personally don't use IDEs, so I don't care (although I do notice that the apparent absence of IDE support for Mercurial indicates maturity of the technology) I can spend some time on Mercurial integration for the main IDEs in use by core devs, I'm sure the PIDA folks have most of this sorted already. It would be important to have these (and any other non-PEP worthy tasks/helpers) listed with some detail, e.g., in a wiki page. If anyone has requests for tools that would make the transition smoother (e.g. the script for /external, a wrapper for svnmerge semantics on top of hg transplant, etc.) but has no time to work on them, please add them to http://wiki.python.org/moin/CoreDevHelperTools . Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Left the GSoC-mentors list
Hi, I've just left the soc2009-mentors list on request, as I'm not a mentor. So if you need my input on the mentor side regarding ideas I've contributed to [1] (struct, socket, core helper tools or Roundup), please CC me. Best regards, Daniel [1] http://wiki.python.org/moin/SummerOfCode/2009/Incoming ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC: Core Python development tools
Nick Coghlan wrote: Everything I've seen from Daniel so far seems to be about either making things we already do more efficient, or else providing additional features in ways that don't make the tools any more confusing for others already used to a particular way of doing things. So he seems to be navigating this particular minefield pretty well so far. Thanks a lot Nick! :) BTW, it seems there's a procedure to follow if my navigation fails[1]. Then again, I may be a little biased - some of the recent bug tracker changes are things I had wished for in the past, but never chipped in any code to help make them happen :) Not a problem, sir, we accept RFEs devoid of any code bits in this store :) Cheers, Daniel [1] George: If we do happen to step on a mine, Sir, what do we do? Capt. Blackadder: Normal procedure, Lieutenant, is to jump two hundred feet in the air and scatter oneself over a wide area. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC: Core Python development tools
Martin v. Löwis wrote: Yes, I'm also quite grateful for the contributions I have received from Daniel. Thank you Martin. I'm sure I'd still be going around in circles if it weren't for your guidance, and I'd be MIA after the first time I broke the tracker too. So thanks a lot for the support. I hope he'll stay around for some time without exhausting. Me too. I'm trying to leave a big audit trail so other people can join efforts or take over parts of roadmap easily, but that's also a backup for long fieldwork trips or the eventual burn out. Best regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
R. David Murray wrote: I understood from posts I saw go by earlier from Daniel that 'pending' meant 'close pending unless there is feedback to the contrary' (and I just used it that way). It sounds like that is indeed correct but not universally known, and thus I would suggest that at a minimum this status be changed to 'close pending' to make it clearer. Aha, at least one post I feel I can reply to. Sort of. I do have a set of triaging principles and beliefs about each issue property, but if you explained to me that 'closed' actually requires unsetting versions, priority and keywords, I'd buy it and would add that to my set of triaging beliefs. OK, maybe I'd ask for an explanation :) ISTM that each tracker user understands different things from each option, each assignee reacts differently to changes in their issues. I kinda try to understand what people mean with the options, not what the options should mean. If I set issues to pending and simultaneously declare my interpretation of pending, in part that's because I expect different people to see different meanings in the status change. I've seen issues in the top 10 most active that lived in a pending status for most of their existence. I'm having trouble posting in these threads because I actually can't tell whether adding a stage, removing a component or renaming a status is better or worse than the status quo. I feel we should make the tracker more useful for core developers, volunteers and end-users. I also think having a clear workflow helps a lot. Yet, I'd rather have a tracker that allowed users with different interpretations to work as they feel most comfortable than one that requires a change of assumptions. On my first triaging sprint Brett asked whether a new stage would make things better and Martin said he could add any new components that could make triaging easier. I told them I was unsure about it, that I might have requests for new options after some thinking, but that I had a couple of RFEs. It's been over a month, but new options still make me uneasy. Let me hit send before I conclude (again) this adds nothing to the discussion and discard it :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Roundup / Python Tracker enhancements
This proposal has two main goals: making the Python bug tracker more efficient for core developers and improving Roundup in areas that don't directly concern the PSF trackers. Most of the code would land in Roundup's repositories, but many instance-level changes would be specific to our tracker. Justification Python Tracker Some feedback is necessary to find out unvoiced problems, shortcomings and RFEs core developers have in mind regarding the tracker. From my work on old issues and with a couple of meta-tracker tickets, I can highlight a few pain points. Quoting myself: [A] relevant time-sink consists of inadequacies of the current [tracker] interface. Many search features are hard to use or notice, among them date spans and entering multiple inputs as lists. Other search features are lacking, mostly simple boolean relations, e.g. those including more than one keyword, full search terms, type, component, etc. Besides searching, the lack of interfaces (and backend support) for selecting and working with multiple issues tends to waste considerable amounts of time. To that, I can add some RFEs and bugs with the email interface, support for third-party authentication and many possible UI improvements. See a list of these below. Roundup The project has suffered from lack of developer time for a while and has grown a list of important improvements that would help it's adoption and revitalize the community. Correct handling of different charsets, DB performance and alternative indexers and templating engines are examples of often requested features. Making Roundup a better tool for developers and end-users, with a productive community can only benefit the PSF. Pre-Requisites and Status We have been working in this area recently, so many ideas are well developed, with a few fleshed out in great detail. Regarding the Python tracker, Martin is guiding my work on simple tracker issues, Brett gave us documents and many discussions about the issue handling workflow, Tennessee Leeuwenburg and R. David Murray are willing to triage issues and contribute to a better workflow. On the Roundup side, Stefan Seefeld and Richard Jones are leading new wave of features and fixes, with contributions from Tobias Herp, Bernhard Reiter and others. Student With the caveat that I'm probably unable to assess this objectively, a student should be comfortable with Python and have a grasp of general bug/issue handling procedures. Familiarity with Roundup is a huge plus, but the code is newbie-friendly. Mentors Under the condition that enough attention is given to Roundup itself, Stefan Seefeld is willing to mentor this proposal. I'll be available to help mentors and the student in many tasks. Martin von Löwis would be able to discuss many important parts of the work. Deliverables: Patches for upstream Roundup and for the Python instance. For a given proposal, a major goal should be declared, e.g. 'improve and clean up the infrastructure' or 'work on integration with third party services and tools'. Under that goal, task groups like 'refactor the different frontends' or 'implement VCS integration' should organize the developement effort in somewhat isolated steps. Some suggested topics, with examples: * means the idea is well developed and suitable for implementation # means a simple task or group of tasks, easy to implement Clean up and improve the base infrastructure Audit and fix any potential security issues * Fix support of diverse character encodings Performance improvements Reduce the number of RDBMS calls Improve caching across requests Improve end-user UI and features Enhance search abilities, better indexing Boolean operators Make forms easier to use and understand Support upload of multiple files in one request *# Support for third-party authentication, e.g. OpenID * Add developer-focused features to Roundup Support for milestones, tasks, workgroups Integration with code review tools Integration with Rietveld * Update/implement [D]VCS integration SVN integration Mercurial integration Interface to continuous integration tools Buildbot Administration enhancements Mass-update/batch-editing support *# UI for Class administration Discussion of more detailed tasks and open issues on roundup-devel[5] is highly encouraged. [1] https://lists.sourceforge.net/lists/listinfo/roundup-devel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC 2009: Roundup / Python Tracker enhancements
Aahz wrote: Is this for GSoC? If yes, please make sure to include that tag in the Subject: line to make it easier to track. Oops, makes a lot of sense :) Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC: Core Python development tools
C. Titus Brown wrote: Given the relative paucity of core Python GSoC ideas, I think you should go for both of these, *especially* if you have a mentor up front. So, write 'em up, add 'em to the GSoC page, and let's see who we get... If we get good applications for both, then I think we can fund both of them. Great, thanks a lot for the feedback :) I do think you should be prepared for pushback from python-dev on any such ideas ;). Don't get too ambitious about writing up *your* way of fixing things, but rather make sure you and the students are prepared to adapt to what people on python-dev think. Mind you, ultimately the people doing the work should make the decisions, but input from python-dev is usually pretty useful even when it's contradictory! Pushback? Luxury! :) Thanks for the great advice, but I'd actually love negative input on this. Better to find out early that there's no way out of the bikeshedding tar pit than to waste a slot (and the student's time). I think many people don't speak up for or against GSoC proposals because they don't have time to mentor / discuss details. This particular proposal is doomed if nobody voices the itches to be scratched. So I'm kinda taunting python-dev with a huge proposal that goes around generalities and tries to make the case for joining efforts with PIDA ;) Skipping to Suggestions and the Food for thought example might help in deciding whether the wall of text is worth a look... Best regards, Daniel == Helper Python core development tools. There's some amount of repetitive, required steps to work on Python development. This proposal is about improving the workflow of core developers, probably with small glue scripts. As each developer has his own personal workflow, these helper scripts should be optional, easy to extend and aimed at the most common tasks. Of course, there may be no real demand for optimizing the workflow. Avoiding the use of a GSoC slot for unnecessary projects is very important, so if you think it's a wast of resources, please speak up :) Justification Sometimes, non-obvious bits like the right sequence of svnmerge commands, the right way to link a Rietveld code review to a given issue or checking for correct autoconf version might get in the way of real development. Other obvious steps, like handling issue properties (e.g. Resolution), posting a message that tells in which revs the issue was fixed of or even checking for changes in tabs versus spaces, also require a bit of time. Regardless of obviousness, forgetting one item (or getting it wrong) in the development checklist happens from time to time. If there are ways to factor these repetitive, required tasks out from a core dev's concerns, it can only help the development process. Non-code developers could also benefit from this kind of tool, and could contribute in a more efficient way to Python development, with higher code/ticket quality. Quoting the tracker cleanup proposal: Optimizing the application of main/core developers' time to Python issues is a no-brainer. Being able to add volunteers to the productive time pool is also very desirable. Pre-Requisites Identifying which tasks and steps should be optimized cannot be left to the student nor to the mentor, it must be a collective effort. Clear goals must be set before someone try to implement them. Sure, there are many descriptions of workflows in past python-dev (and python-list) threads, but the GSoC is about code. Methods It's up to the mentors/student team. I suggest offering early releases for the scripts and maybe test repositories, trackers, Rietveld instance, etc., as ways of making sure the resulting code will be useful and used by the target public. I believe most tools should be developed in a generic way, so that they could fit in other projects and workflows. IMHO, this would make the resulting scripts much more valuable. Student Besides some experience with Python and tools of the trade (VCSs, bug trackers, etc.), the most important requisite is being able to listen to the community and taking criticism well. Mentors Ali Afshar from PIDA is willing to mentor if the 'generic tools' way is accepted. Since it's about reusing development tools inside an IDE, any of these helper scripts could be integrated into PIDA, the only pre-requisite being that they'd not be too deeply linked to the Python infrastructure. With a small bit of concern about this, it'd be easy to extend/fork the resulting tools to use with other trackers, VCSs, test runners and code review tools. I am also available to help with the Python workflow part, and there's an early effort to integrate Rietveld and our bug tracker under way. At least one core Python developer should mentor, preferably one that knows how to interact well with python-dev. Any project focused on how people work is prone to flamefests, so diverting most heat away from the student might be a necessary skill.
Re: [Python-Dev] GSoC: Core Python development tools
Thanks for the feedback, Antoine! Antoine Pitrou wrote: Daniel (ajax) Diniz ajaksu at gmail.com writes: Sometimes, non-obvious bits like the right sequence of svnmerge commands, the right way to link a Rietveld code review to a given issue or checking for correct autoconf version might get in the way of real development. Well, really, rather than trying to improve svnmerge, we should try to find a way forward to switch to Merc... oops, I mean what will turn out to be the best DVCS for our needs :-) That was a little bait for input ;) But the real point is that, regardless of underlying VCS, there is a choice between having all core developers know by heart the right switches and order of steps to correctly checkout/update -( branch locally) - fix - diff - commit - merge - solve conflicts and offering a little, well-documented script that takes care of the switches and sequence of steps. Maybe a 'untangle svnmerge-created history' tool would help too? :) I am also available to help with the Python workflow part, and there's an early effort to integrate Rietveld and our bug tracker under way. Food for thought example (sorry, not quite how a core dev works): [...] SVN exporting current working copy to: ../month_delta Does it work when using an hg/bzr/git mirror? There's already hg and git support in Rietveld's upload.py, so this should be possible. Given that the pyfix script is completely imaginary ATM, yes, it works as well with hg/bzr/git/perforce/CVS/darcs as it does with SVN :) In a more serious note, the PIDA offer puts anyvc[1] on the table. So we could support different VCSs as upload.py does it, or aim for a more pluggable way, probably based on anyvc. Either way, them scripts should be simple and follow the Unix way, so e.g. pyfix --export would actually call anyvc --export or pyvcs --export. Cheers, Daniel [1] http://pypi.python.org/pypi/anyvc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GSoC: Core Python development tools
Hi, I'd like to bring up the general idea of using a PSF slot in GSoC2009 to improve the Python development infrastructure. I also happen to have two concrete proposals for that (such a coincidence!). But I assure you the general idea is more important than my proposals :) General: Solving issues that get in core devs' way when they work on Python development could be a nice PSF GSoC project. I believe there are enough code related tasks that would greatly improve Python development workflow but lack manpower to complete. E.g., ISTM that a student working on svnmerge in past SoC editions would've been able to mitigate some painful shortcomings. If the core developers could come up with a list of peeves that would be solvable in code (in existing tools), that would allow for a very useful GSoC proposal. Proposals: These might fit the description above, and they're both tracker related (yep, one-trick-pony here). The upside is that at least one potential mentor is available for each, and I'd be able to offer support to the student. First, the PSF could invest a slot on integrating different tools of the development workflow. Variations of 'file issue at bug tracker, submit code for review' or 'branch locally to virtualenv, upload failing testcase to tracker, upload patch to tracker' command line utils. If these could be developed as general tools (i.e., not deeply tied to Python dev infrastructure), Ali Afshar from PIDA is willing to mentor it. I'd be available to help with Roundup and Rietveld (integration in progress), but would like to see it work with Launchpad, Bugzilla, Google Code and Review Board :) The other proposal is to use a slot in Roundup proper and the Python tracker instance. This could have a core Roundup developer as mentor, under the condition it's focused on Roundup itself. IMO, are some missing/broken core features in Roundup that would have a positive impact on our tracker, mostly those relating to searches, security and UI. I'd have a lot to contribute to the Python tracker part, based on ongoing work. Even if neither is considered worthy, I'll keep them on my to-do list and hope to slowly and hackishly work towards both proposals' goals. Barring feedback saying that they're out of scope, stupid and downright offensive, I'll post details on each to this thread very soon. So, if the PSF was to use a slot on improving the way you work on Python development, what would you like to see fixed or implemented? Best regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GSoC ideas in need of mentors :)
Hi, I'd like to propose a two housecleaning GSoC ideas for discussion, they both need mentors. First, Mark's suggested overhaul of the struct module, along with finishing PEP 3118 if possible. Second, a clean up of the socket module, along with checking its usage in the stdlib if possible. Details below. IIUC, any potential mentors for ideas from http://wiki.python.org/moin/CodingProjectIdeas would help the PSF by declaring availability at http://wiki.python.org/moin/SummerOfCode/2009. And, mentioned in another thread, snakebite ideas: http://tinyurl.com/beyond-buildbot :) Regards, Daniel --- Overhaul struct + PEP 3118 There are many open issues for the struct module, and a suggestion that many others fixes should happen. The problems include inconsistencies in input handling and backwards-compatibility code that should be gone from 3.x. As PEP 3118 also requires a few changes in struct, finishing the memoryview object implementation and backporting it to 2.7 could be part of this project. To tackle this, a student should know C and have some familiarity with the CPython codebase. The proposal should include an overview of open issues and, if possible, of problems in current code. Mentors for this task should have a good understanding of the struct module, the buffer interface and PEP 3118. --- Clean up and improve the socket module The socket module is the foundation of many important parts of the stdlib. It has many open issues and RFEs, with many more being indirectly dependent on it. Major pain areas are cross-platform problems, shortcomings for a few use cases and some missing bits from the API (e.g. recvall(), sendmsg() and recvmsg()). If these can be solved quickly, going through the uses of the socket module in the stdlib to would make this project even more useful. This project has some ugly cross-platform needs, but these can be handled by the student and the mentor together (maybe snakebite could help?). For students wanting to work on this, knowing C is a must, being familiar with CPython and the stdlib would be desirable. Having some prior knowledge of POSIX and Windows interfaces the socket module uses would be a nice perk. Mentors should be able to help the student to test their code on many different platforms. Knowing the socket API in different platforms would be desirable. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
Martin v. Löwis wrote: In addition, I would like to see a specification of the exact labels to be used, plus a one-line description that should be attached to the labels. Tennessee, If you'd like to test those additional status options, I'm setting a test instance of the Python tracker up at http://bot.bio.br/python-dev/ . It might be frequently offline for a while, but once things are stable it'll be reliable enough to perform such experiments. If it's easy on resource usage, I might have one instance following the Python tracker code closely and a more bleeding-edge one :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Core projects for Summer of Code
Arc Riley wrote: The process is as follows; we're compiling ideas for http://wiki.python.org/moin/SummerOfCode/2009 and getting mentors signed up at http://socghop.appspot.com/ Any chance that we can keep http://wiki.python.org/moin/SummerOfCode/2009 light on markup? I simply can't add a 'tidy struct and finish buffer interface/bytearray details' proposal as it is :/ Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Capability to alter issue metadata
Tennessee Leeuwenburg wrote: I am continuing to look at issues in the issue tracker. It would be handy to be able to update some of the metadata fields. For contributions, it's fine to just be able to upload patches / post messages, but I can see any number of issues which could use a bit of looking after. I'm +1 to giving you Developer rights (but have no say in that). I'm available to change any metadata you want until that happens. BTW, R. David Murray is also interested in helping with the open issues[1], so we could coordinate efforts at tracker-discuss. e.g. http://bugs.python.org/issue4535 should probably be set to pending feedback Set to 'pending', 'pending feedback' is pending approval :) I'd be happy to do this kind of thing if people are happy for me to do so... I am, thank you! :) Regards, Daniel [1] http://mail.python.org/pipermail/tracker-discuss/2009-March/001914.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of further status options to tracker
Hi Tennessee, I plan to take a look at all open issues before PyCon, do you want to join forces? :) Tennessee Leeuwenburg wrote: I am beginning reviewing some more issues in the tracker. I think it would be useful to have the following status options (new status options marked with a '+'): Great! Thanks a lot :) I think your ideas are good, but believe you should take a better look at the Stages, some messages from this list and tracker-discuss from February, and Brett's document linked from there. + Request Approved: Means that the issue is marked as worth further development by the community Not sure it's a 'status', but I like the idea of disambiguating between 'send us tests/patches so we can think whether the bug/feature is valid' and 'the bug/feature is valid, send us tests/patches'. However, it might be better to merge this with 'Specification Approved', as the important bit is 'contributions on this are welcome'. + Specification Approved: Means that the functionality to be developed is written down in some form, and agreed at least in general terms (preferably in fairly specific terms) See above. +1 on a way to make this clear, -0 on it being separate from the above, -1 on being a status. + Under Development: Means that an implementation is currently under development This one I like a lot, but think it should be a keyword, like 'claimed'. I think it should be set when someone says I'll work on this one. But if you mean 'should be under development', -1 :) + Under Final Review: Means that a patch has been submitted and may be a flag that core developers can usefully review the work done without having to revisit the whole process -1, as it is rather redundant with Stage. [...] My reasoning for this is as follows: Example one: I am currently reviewing issue 2706 which covers datetime.timedelta operators. I have a reasonable amount of familiarity with time programming and think I have some valuable input on the functionality aspects, however I'm not a super-great C programmer. I'd like to help with coming up with the final feature specification, but then leave it to others to consider the merits of the C code patch. Being able to help get this marked as request approved, then specification approved might help speed up a lot of the process of developing the patch and getting it accepted. It also saves code developers from having to develop an implementation while a functionality debate is still ongoing... You can provide unit tests (and perhaps an equivalent Python implementation), they are a great way to specify behavior. Also, they are required for a healthy commit and make the corner cases easier to spot. I think that having these additional steps will help to avoid erroneous development of non-features, and also break up the review process into more manageable chunks of work. I think core developers shouldn't waste time setting a hundred little fields on each issue, but giving them practical ways to query (and denote) these extended properties seems worthwhile. Of course I realise not everything needs such a delineated process, but by the same token it might assist in keeping some of the less visible/popular changes moving through the process... Well, there's the signal-to-noise ratio to consider too. Like with the nosy_count noise issue, things might get in the way of developers work (I'll work on this soon, promise :D). I'll be doing some janitorial tasks this week and next, triaging issues and populating their fields. If you want to discuss specific changes or suggest different methods/goals/rules for this work, I'd be very grateful. If you want to join the tracker janitors club, remember to bring a shrubbery :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of further status options to tracker
Terry Reedy wrote: The other problem with too many specifics is non-use. As it is, an issue is sometimes closed with no resolution marked, so one has to scroll down, possibly a long way, to see whether it was accepted or rejected. (Is it possible to require a resolution when closing?) Yes, it is possible. If you think it should be implemented, file a RFE in the meta tracker. However, it'll also be much easier to mass-edit issues in the near future, so if this kind of (careful) cleanup can be done by tracker janitors later, it might be best to leave core developers free of these requirements... Soon we'll also have the option of marking an issue as Pending and having it automatically closed some time later. Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Tracker-discuss] Adding a Rietveld this button?
CC'ing python-dev, as more RFEs might be uncovered :) Daniel (ajax) Diniz wrote: Martin v. Löwis wrote: I think a patch (or full file) would be good enough. We could put it into the tracker itself, and publish it prominently where people upload files. I'll post it as a patch and a full file at issue 247 when I get to it. Posted as full file to http://psf.upfronthosting.co.za/roundup/meta/issue247 , Guido suggests the wrapper way so I won't bother with creating patches now. [snip code] Nice! I didn't think of something that complicated (or, rather, complicated in a different way): upload.py --roundup 5428 Just to be clear, this will work as if the user passed the following options: upload.py --message [issue5428] Pyshell history management error --cc rep...@bugs.python.org Right? :) If that is right, it works :) That could either fill in a description given by -d, or fetch the description from roundup. Fetching a description is as easy as fetching a title[1], but I can't think of a fixed place to look for one (last message? last patch description?). Maybe we can add another option that tells the script where to fetch description/content from? Something like [-F|--fetch_description] msg83029 ? Works too, for files or messages :) Examples: http://bugs.python.org/issue400608 http://bugs.python.org/issue2771 http://codereview.appspot.com/25073 http://codereview.appspot.com/24075 Thanks again, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tracker cleanup - Roundup hacking report :)
Hi, Here's a progress report on the let's make the tracker a bit better tasks. Note: if you make use of saved queries, I recommend reading the 'anyone can remove any queries' issue: http://psf.upfronthosting.co.za/roundup/meta/issue244 Feedback on meta-tracker open issues, as well as new RFEs and replies to tracker-discuss threads should make the tracker meeting your needs a bit more likely :) Thanks Martin, Stefan, Jeroen, Ezio, Brett, Georg and others that helped along the way. Real tracker cleanup will be back soon ;) Best regards, Daniel Open WIP tickets: add # of comments to default issue list Track the counts of messages and nosy users on a given issue. http://psf.upfronthosting.co.za/roundup/meta/issue87 (screenshot: http://psf.upfronthosting.co.za/roundup/meta/file110/msg_nosy_counts.png ) Add multiselects for searches This allows one to search, e.g., for issues with Version in ['2.5', '2.6', '2.7'] or Stage in ['patch review', 'not selected']. http://psf.upfronthosting.co.za/roundup/meta/issue243 (example: http://psf.upfronthosting.co.za/roundup/meta/file105/issue_search.html ) Add 'Mail me' button to messages and issues Similar to becoming nosy retroactively, by getting a past message after the fact. This (supposedly) allows one to reply to any message in an issue from email. http://psf.upfronthosting.co.za/roundup/meta/issue245 Have issue ID search work from search tracker box Passing an ID into the search tracker box opens the issue with the matching ID. http://psf.upfronthosting.co.za/roundup/meta/issue123 Add 'Stage' to results page Adds 'Stage' as a column to the search results when 'Display' is selected. http://psf.upfronthosting.co.za/roundup/meta/issue242 Search in All Issues button http://psf.upfronthosting.co.za/roundup/meta/issue224 Have CVS download of issue list put name rather than ID http://issues.roundup-tracker.org/issue955070 Failed logins do not produce an error message Add a 'Login as %(user) successful' green-banner on successful logins http://psf.upfronthosting.co.za/roundup/meta/issue230 Tickets/ideas on sketching or local testing stage: notation to filter by logged-in user Allows 'reflexive' queries, like 'issues I've created', 'issues I follow', 'issues assigned to me'. Pending Query security resolution. http://issues.roundup-tracker.org/issue1525113 Shortcuts for selecting self in user lists: Add me for nosy and Claim for assignee. Provide prev/next/show list links when going through a list of bugs http://psf.upfronthosting.co.za/roundup/meta/issue4 Ability to specify non-matching criteria in filters/searches http://issues.roundup-tracker.org/issue678900 Email me my current changes without submitting (a.k.a. 'Save') Allow searching for ranges for Number attributes http://issues.roundup-tracker.org/issue1182919 input fields should have HTML id attributes http://issues.roundup-tracker.org/issue1513369 Full text AND search has message scope, not issue scope http://issues.roundup-tracker.org/issue1155657 Set attributes in the body http://psf.upfronthosting.co.za/roundup/meta/issue198 Closed tickets: Edit Queries screen should include a link to the search page http://psf.upfronthosting.co.za/roundup/meta/issue202 Denote which dependencies issues have been closed http://psf.upfronthosting.co.za/roundup/meta/issue207 Fix 'not closed' search http://psf.upfronthosting.co.za/roundup/meta/issue240 Add 'Stage' to search page http://psf.upfronthosting.co.za/roundup/meta/issue239 Add creator/assignee to search view http://psf.upfronthosting.co.za/roundup/meta/issue180 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker cleanup - Roundup hacking report :)
Jesse Noller wrote: Slightly off topic Daniel, but if you see any multiprocessing bugs lurking out there, can you make me (jnoller) the assignee? Sure! FWIW, I've just submitted a patch[1] that will make working with arbitrary issue sets much saner and should have a 'mass-add user X as nosy to selected issues' working locally before Saturday. When these land on bugs.python.org, this kind of task will become so easy that my job as tracker janitorveloper might become redundant :) Cheers, Daniel [1]http://psf.upfronthosting.co.za/roundup/meta/issue246 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Hi, Benjamin Peterson wrote: 3.1a1 March 7 3.1a2 April 4 3.1b1 May 2 3.1rc1 May 30 3.1rc2 June 13 3.1 Final June 27 Benjamin, I'd like to nominate a couple (minor) RFEs[1] and bug fixes[2] for 3.1. By 'nominate' I mean 'group related issues together, offer tests, docs, patches and/or reviews as needed and ask-pretty-please-for-inclusion' :) Would early post-3.1a1 versus pre-3.1a1 make a difference in likelihood of proposed changes going in? I can try to come up with a detailed list before March 5, but I'd rather present it next week, after taking a look at all remaining open issues. FWIW, further tracker cleanup should happen sometime next week, let me know if you need any tracker janitorvelopment done :) Regards, Daniel [1] Current list: http://bugs.python.org/issue1097797 http://bugs.python.org/issue3244 http://bugs.python.org/issue736428 http://bugs.python.org/issue1175686 http://bugs.python.org/issue4733 [2] Examples: http://bugs.python.org/issue4953 http://bugs.python.org/issue1074333 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Mitchell L Model wrote: Would whoever is responsible for IDLE please take a look at the patches I submitted for Python 2 3 [tracker IDs 5233 and 5234 respectively]. [...] I would really like to see them in 3.1. The patch is already there; someone just has to do whatever gets done with patches to validate it and check it in. It's not a lot of code changes. Mitchell, thanks for the reports and patches you've been contributing. FWIW, I plan to follow up on these specific issues (and 5276) before 3.1a2, mostly to add tests and a +1 for integration. Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Challenge: Please break this! [Now with blog post]
print '''
tav wrote:
Daniel emailed in the exploit below and it is pretty devastating. It
takes advantage of the fact that the warnings framework in 2.6+
dynamically imports modules without being explicitly called!!
Here's one I couldn't develop to a working exploit, but think is promising.
It highlights a real Python bug and an implementation detail.
Targets 2.6 or trunk.
It was how I stumbled upon the _warnings hack :)
Should be copy-n-past'able,
Daniel
'''
# Hi
from safelite import FileReader
# First, it's possible to set a booby-trapped
# Exception due to a Python bug
# This is bait, say hi bait
def bait():
''' Hi! '''
try:
return bait()
except:
return Ready to go
# Set the trap
bait()
# Let FileReader trigger it - RuntimeError in Namespace:
FileReader('safelite.py')
# ^- shoud give:
# Traceback (most recent call last):
# File stdin, line 1, in module
# File safelite.py, line 242, in FileReader
# self = Namespace()
# File safelite.py, line 165, in Namespace
# for name, obj in sys.get_frame_locals(frame) \
# .iteritems():
# RuntimeError: maximum recursion depth exceeded
#
# Now, I think this might be a special RuntimeError...
# Let's catch it! Bait, please?
bait()
try:
FileReader('safelite.py')
except Exception, caught:
pass
# Let's brand it
caught.__init__(I'm back, the other side is scary!)
# Now set it free and see if it comes back
bait()
try:
FileReader('safelite.py')
except Exception, caught_again:
pass
# Who's there?
print caught_again # - He's back!
# So, hm, that's it... not so exciting but might help
# traceback-based exploits. Did I mention little 'caught'
# there can carry arbitrary payloads? Nice boy.
# Another one
#
# Now, that we have a protection against _warnings,
# an obvious bait-less new trap is available
# Got a spare SystemError?
FileReader('safelite.py', 'r', 1.1)
# ^- shoud give:
# Traceback (most recent call last):
# File stdin, line 1, in module
# File safelite.py, line 201, in FileReader
#fileobj = open_file(filename, mode, buffering)
# SystemError: Objects/moduleobject.c:50: bad argument \
# to internal function
# Nice, but I want a cleaner one. Hey, caught, could you?
print caught.message
# ^- shoud give:
# Traceback (most recent call last):
# File stdin, line 1, in module
# SystemError: Objects/moduleobject.c:50: bad argument \
# to internal function
# This seems to be a regular SystemError. It's not as
# polite as our pet RuntimeError 'caught', which can
# be silenced by intervening Exceptions.
# As I should stop playing with this, here's
# a plea for help: set 'caught' free before you go.
# Here's the target: freedom
class freedom(object):
def __repr__(self):
print list(sorted(globals()['__builtins__'].keys()))
print '\n\n\n'
return str(input('Type for freedom:\n ;) '))
# Initiate caught on it
caught.__init__(freedom())
# Set the bait...
bait()
# Now, type something clever :)
FileReader('safelite.py')
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Silencing IO errors on del/dealloc?
Antoine Pitrou wrote: Guido van Rossum guido at python.org writes: The svn history of those lines may have more pointers. Well this code dates back to the first checkin in the py3k branch. Apparently the old p3yk branch is not there anymore... The history is available (see below), but tells nothing that would be useful/relevant. Daniel History of io.py is available on ViewVC: http://svn.python.org/view/python/branches/p3yk/Lib/io.py?view=logpathrev=56853 It's possible to checkout that as a peg revision: svn co -r54910 http://svn.python.org/projects/python/branches/p3yk/Lib/@r54910 Then, svn blame tells where it comes from: 54728 guido.van.rossum def __del__(self) - None: 54728 guido.van.rossum Destructor. Calls close(). 54728 guido.van.rossum # The try/except block is in case this is called at program 54728 guido.van.rossum # exit time, when it's possible that globals have already been 54728 guido.van.rossum # deleted, and then the close() call might fail. Since 54728 guido.van.rossum # there's nothing we can do about such failures and they annoy 54728 guido.van.rossum # the end users, we suppress the traceback. 54728 guido.van.rossum try: 54728 guido.van.rossum self.close() 54728 guido.van.rossum except: 54728 guido.van.rossum pass And here's the log for that rev: http://svn.python.org/view?view=revrevision=54728 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
Python tracker wrote: ACTIVITY SUMMARY (02/13/09 - 02/20/09) Python tracker at http://bugs.python.org/ [...] 2341 open (+55) / 14813 closed (+27) / 17154 total (+82) I was about to cry foul, +27 closed? We closed so many issues last week, how come? Then, I realized the headings tell another story: Issues Created Or Reopened (84) [...] Issues Now Closed (103) Woot! We did it! More issues closed than opened, that's sweet :) To celebrate, I'll have a two-day tracker sprint (probably Sunday and Monday, a holiday here) to add a couple of search options and a view for mass-updating issues. During the sprint, you'll be able to get your feature requests for and/or bug reports about the tracker at a considerably lower price, so send them in :) Daniel P.S.: It seems the 2341 open (+55) / 14813 closed (+27) / 17154 total (+82) line is about Issues Created only :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker cleanup roadmap
Hi Venkatraman, Venkatraman S wrote: On Tue, Feb 17, 2009 at 1:45 PM, Martin v. Löwis mar...@v.loewis.de wrote: Don't expect too much help from other people - I have been waiting for volunteers to show up helping with the tracker for more than a year now. I have been mostly a silent spectator around and would like to chip in. Great! Thanks for joining us :) What would you like to help with? Anyway, let's move this thread to tracker-discuss :) Need some initial throttle(help) for the full-fledged attack :) Well, I'm currently updating the TrackerDevelopment[1] article and trying to make the initial setup easier. These should help a bit, but I'd be glad to (try to) answer any questions you have. Please let me know (or mail tracker-discuss[2]) if something on the guide isn't clear (you can, of course, edit it directly). Martin v. Löwis wrote: Please take a look at the meta tracker. It has various open issues, many open for many months now. Please tackle one that can be fixed through patches to the tracker instance preferably; changes to roundup are also acceptable in principle. Agreed, if you want to get to know the code and at the same time work on something useful, taking a look at the meta tracker[3] is a great first step. Welcome aboard! Daniel [1] http://wiki.python.org/moin/TrackerDevelopment [2] http://mail.python.org/mailman/listinfo/tracker-discuss [3] http://psf.upfronthosting.co.za/roundup/meta/ :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker cleanup report
Paul Moore wrote: 2009/2/16 Daniel (ajax) Diniz aja...@gmail.com: Hi, Here's a summary of what's been accomplished and what's almost done. This kinda marks the end of this Bug Season for me, but I'd like to do at least one more installment before PyCon. Can I, for one, offer a *huge* round of applause for what you've achieved. It's great to see the tracker getting some serious attention. Thank you, but I can only take a small part of the kudos. It's been a collective work, involving from the BDFL to issue reporters. Also, lots of people have been taking care of the tracker. Notably, Christian Heimes has done a lot of cleanup and updating in early 2008, Facundo did the same earlier (2005, IIRC) and Benjamin went through a lot of tickets during the 2.6/3.0 release cycle. Martin, Benjamin, Victor and Hirokazu have spent a lot of time tidying things up lately, and some nice fellows like Antoine, Mark, Nick Coghlan, Amaury, and most cited above are constantly reviewing tickets and offering feedback. Some people help fighting spam (e.g. Skip, IIRC). Brett is hors concours regarding time spent for any Python-related effort, so I won't mention him :D There's also those recently organizing tickets in their area of interest: Tarek is on top of distutils issues with lots of help from Akira Kitada, Georg even has auto-assignment for doc issues, Jesse Noller with multiprocessing, etc. Of course, this has always happened to some degree, so lots of people have done that in the past, then reduced their level of tracker-handling activity, are now back and helping with lots of issues, e.g. Jack Jansen and Ronald Oussoren. These are all from the top of my head, from diving into hundreds of reports and following the tracker activity. Lots of other people I fail to mention have taken the task of dealing with tickets for themselves. So kudos to everyone that invest time handling bugs, feature requests, janitorial tasks and the eventual PEBKAC. Thanks for the support! Cheers, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Closing outdated Mac issues
Hi Ned, Ned Deily wrote: Other than Mac/Modules, the rest of the Mac/ directory is mainly stuff used for building or going into the OS X installer images, including things like IDLE.app. These are used in 2.x and in 3.x. Thanks, knowing that makes the ticket handling easier! There are 40 C files, two headers and 69 python files in /Mac in trunk. The 2.6 (and 2.5.x) docs say development has stopped and that they'd be replaced in 2.5. So ISTM closing RFEs for these modules would be an improvement. Honestly, fixing them is fine but since the modules are deprecated but still in existence in 2.x, but they are definitely nothing above a normal priority issue. OK, I'll let the bug reports open. What about RFEs? I think the reasonable thing to do is close them as not to be fixed/implemented. At this point, the chances that someone would fix them are pretty slim and, in many cases, I'm sure the module is either obsolete because other, and better supported, solutions are now available, like PyObjC or appscript. If people feel strongly about an issue, they can always ask to re-open it. OK, Ronald is helping sort them and I'll clean whatever is left based on your combined feedback. Taking a quick look at your list, the only ones that may be worth looking at are the plistlib ones since it lives on in 3.x. I think all the rest are deprecated and gone in 3.x. OK, plistlib is a keeper in my list now. Thanks a lot for the feedback (and for helping with the Mac installers!) :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Closing outdated Mac issues
Hi, Ronald, Ronald Oussoren wrote: On 15 Feb, 2009, at 21:13, Daniel (ajax) Diniz wrote: Hi, In the discussion of a feature request for MacPython[1], the OP (hhas) said: As of Python 2.6/3.0, all Mac-specific modules are deprecated/eliminated from the standard library and there are no longer any plans to submit appscript for possible inclusion. This issue should be rejected and closed. [...] So, if someone could reassure / clarify the rules for closing these in general and/or take a quick look at specific issues, that would be a great help. The Carbon bindings in 2.6 are deprecated and I don't intend to work on fixing them, and would advise against trying to fix issues with these modules unless you're personally affected by them. OK. [1] http://bugs.python.org/issue916013 Should have been closed ages ago. [snip] http://bugs.python.org/issue776533 Carbon.Snd module SPB constructor shadowed Closed as fixed (after reapplying the patch on the trunk) [...] http://bugs.python.org/issue779285 Carbon Event ReceiveNextEvent Left this open for now, I have to have a better look at the actual code to check if it is worthwhile to keep this issue open. Wow, thanks a lot for taking care of all these issues! If you need a hand to close, assign or just update any of them, I'd be glad to help. I'll put any closing of these on hold until you're done, I have no hurry :) http://bugs.python.org/issue779153 bgen requires Universal Headers, not OS X dev headers Should be closed, I'm not planning on recreating the Carbon bindings. OK, I'll add a 'will close unless someone who needs this comes forward' note on this one, but will leave it open for a while as it might help in wrapping code. http://bugs.python.org/issue602291 Bgen should learn about booleans This one is not related to OSX, appearently at least some people actually use Bgen for creating wrapper code. Thanks, will update it and leave open. http://bugs.python.org/issue775321 plistlib error handling http://bugs.python.org/issue985064 plistlib crashes too easily on bad files Plistlib is in the generic standard library in 2.6 and 3.0. I haven't checked yet if these issues are relevant at this point in time. They are not, I'll work on tests/patches for them. Thanks for handling these and for the valuable feedback, Ronald! Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker cleanup report
Brett Cannon wrote: Ditto from me! And I will eventually get to the bugs assigned to me (hopefully starting some time this week). No hurry, just let me know if you see stupid mistakes on my part (I've once or twice added an issue as its own dependency) :) Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker cleanup report
Jack Jansen wrote: I had a cursory look at these issues as they came by, and I didn't see any that struck me as still being relevant. Thanks a lot for the feedback, Jack! Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues to be closed: objections?
John J Lee wrote: On Mon, 16 Feb 2009, Daniel (ajax) Diniz wrote: http://bugs.python.org/issue809887 Improve pdb breakpoint feedback Why this one? Nice catch, this makes no sense. The patch even applies almost cleanly. I'll update it and set the others to pending, so further objections can be voiced. Thank for reviewing, John! Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Irix still supported? (was Re: Tracker archeology)
Daniel (ajax) Diniz wrote: Can I close these other IRIX issues? http://bugs.python.org/issue2048 http://bugs.python.org/issue1086642 http://bugs.python.org/issue1178510 http://bugs.python.org/issue1070140 So, I'll close these later this week (citing that Irix is long dead and we don't support it in any form or version) unless opposition is voiced :) Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issues to be closed: objections?
Hi, I've marked some issues (25 now) to close, mostly because: - there was no reply from OP, nor a clear justification for the issue; - there are messages explaining why the issue is invalid; - the OSes/versions of the report suggest the issue is currently invalid; However, I've been mistaken about the desirability of leaving an issue open a couple of times in last days. So, I'd really appreciate if someone could take a quick look at the issues below to avoid any undesirable closing. I'll also mark them as pending later today, and plan to wait until the weekend before closing. Any suggestion/criticism about this plan would be welcome too. Thanks everybody for all the support, helping, patience and enduring the spam! Daniel http://bugs.python.org/issue1231081 platform.processor() could be smarter http://bugs.python.org/issue1251921 Fail codecs.lookup() on 'mbcs' and 'tactis' http://bugs.python.org/issue1248119 pdb 'next' does not skip list comprehension http://bugs.python.org/issue1169633 Install fail code 2932 after fail to copy python_icon.exe http://bugs.python.org/issue100 csv reader barfs encountering quote when quote_none is set http://bugs.python.org/issue1044299 compile error with stlport http://bugs.python.org/issue1047540 Turtle.py hangs Idle http://bugs.python.org/issue995956 TclError with intel's hypertheading http://bugs.python.org/issue1001150 hotspot profiler does not work correctly on P4 CPUs with HT http://bugs.python.org/issue974635 Slice indexes passed to __getitem__ are wrapped http://bugs.python.org/issue974159 Starting a script in OSX within a specific folder http://bugs.python.org/issue949667 file write() method and non-blocking mode. http://bugs.python.org/issue815753 SCO_SV: many modules cannot be imported http://bugs.python.org/issue727732 getpath.c-generated prefix wrong for Tru64 scripts http://bugs.python.org/issue875654 add support for installations compiled for debugging http://bugs.python.org/issue872815 How to pass the proxy server use socket http://bugs.python.org/issue854918 Configurable SSL handshake http://bugs.python.org/issue835176 [2.3.2] bz2 test failure on AIX 4.3.2, Tru64 UNIX http://bugs.python.org/issue809887 Improve pdb breakpoint feedback http://bugs.python.org/issue780354 socket.makefile() isn't compatible with marshal/cPickle/etc http://bugs.python.org/issue775340 OSX 'freeze' bug http://bugs.python.org/issue4191 urlparse normalize URL path http://bugs.python.org/issue1682241 Problems with urllib2 read() http://bugs.python.org/issue1210326 comma separated cookie values http://bugs.python.org/issue5072 urllib.open sends full URL after GET command instead of local path ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues to be closed: objections?
M.-A. Lemburg wrote: http://bugs.python.org/issue1231081 platform.processor() could be smarter Thanks, Marc-Andre! If anyone else feels like closing some of these issues, go ahead (no need to report back, I'll find it out later). My rather bureaucratic approach is just to avoid a possible trigger-happiness on my part :) Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tracker cleanup report
Hi, Here's a summary of what's been accomplished and what's almost done. This kinda marks the end of this Bug Season for me, but I'd like to do at least one more installment before PyCon. We have closed 51 issues so far (sorry if I missed some): * Barry ** Benjamin ** Daniel * Georg * Guilherme * Hirokazu * Marc-Andre *** Mark ** Martin * Raymond ** Terry ** Victor Thanks, guys! There are about 20 Mac-related, 24 invalid/outdated and four IRIX issues on the 'will be closed unless someone voices disagreement' queue, so we have a good chance of totaling a hundred closed issues in ten days. I estimate to have updated about 400-500 issues in the last seven days. I'm now nosy in 200 of these, that's karma for spamming python-dev and python-bugs. I'll pause the digging effort for the next days: besides having less free time, I think it'll help us digest all those updates. Obviously, the cleaning is far from complete: there are lots of issues with 2.5 as version, lots of similar issues (e.g. for socket, HTMLParser), etc. I'll soon post a tentative plan to attack these. The goal would roughly be making it easier to pick good issues for PyCon sprints and fixing in / adding to 2.7 and 3.1. Cheers, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tracker cleanup roadmap
This is the janitorial plan I mentioned earlier... It's so humongously huge by now that I'm not sure whether I should submit it to e.g. the Python Papers or just print it and set it on fire and run screaming. Fortunately, a tl;dl summary is provided :) Daniel Summary Let's improve the tracker UI to better fit our needs. Then, classify them bugs and separate garbage from real development. Lastly, bug reporters should get a better UI. That's it, any help is welcome. The wall of text Developer time constraints are arguably the main bottleneck in handling tickets, which is only a subset of Python development. Optimizing the application of main/core developers' time to Python issues is a no-brainer. Being able to add volunteers to the productive time pool is also very desirable. This document outlines a tentative plan to move towards a better workflow in the Python Tracker. Summary of tracker issues The Python Tracker contains more than 17000 tickets, with approximately 2350 still open. Of the open tickets, 500 were last updated more than a year ago, while about 1150 were created before that. Current problems Core developers, volunteers and newcomers are burdened with a lot of inefficient and/or nonproductive chores when handling issues. Requesting and waiting for feedback/confirmation/patch testing, performing multiple searches, missing relevant discussion in similar/duplicated issues and other low-level tasks and gotchas get in the way of solving real problems. The low signal/noise ratio of open issues is a major component of this burden. At least 850 issues have outdated/missing version information, while about 850 don't have a type (RFE, behavior, crash) set. About 800 issues have patches. Priorities carry little information, mostly because they are left in the default setting: 1200 issues are set to 'normal' (a SF.net artifact) and 750 have no priority (a Roundup artifact). Less than 200 tickets have 'low' priority. Most of these issues boil down to tracker features being underused. Another relevant time-sink consists of inadequacies of the current interface. Many search features are hard to use or notice, among them date spans and entering multiple inputs as lists. Other search features are lacking, mostly simple boolean relations, e.g. those including more than one keyword, full search terms, type, component, etc. Besides searching, the lack of interfaces (and backend support) for selecting and working with multiple issues tends to waste considerable amounts of time. Proposed plan The suggested approach consists of a three parts effort focusing first on developer-side tracker UI, then on massive issue categorization and lastly on user-side UI. This optimizes the work of a single tracker janitorveloper, but can be better partitioned if more janitorvelopers are available. The developer-side UI effort will focus, in this order, on making available tracker features easier to use, adding new search features and mass-handling of issues. This should improve both developers' and tracker janitors' workflow. Issue categorization will look like this last Bug Season (adding details to tickets), but hopefully with a saner workflow. There are a few clear sets of similar issues, e.g. about socket, handling of characters on network protocol and format parsing modules, Tkinter + IDLE, etc., that could use grouping and closing of duplicates. A suggested form of grouping would be 'umbrella' or 'grab-bag' issues, with existing issues of a topic as dependencies. Finally, bug-reporter UI. The idea is to make it easier for users to provide good bug reports, make the options clearer and minimize the need for (preliminary) issue post-processing by developers. This might include a template or wizard for reports, adding information about which versions receive fixes or RFE, etc. Deliverables (WIP) Developer-side UI Patches for client-side Roundup: - add missing fields/options to search (e.g. Stages, fix 'not closed') - allow multiple choices for versions, components and keywords - add checkboxes to multiselects - avoid drop-downs above multiselects (janitors misclick a lot!) - support for mass-selection/display (3rd party patch available) - add a clutter-free 'search in all issues' button Patches for server-side Roundup: - boolean searches - support for mass-updates (3rd party patch available) - maybe add regex support (3rd party patch available) Issue categorization - present better statistics about the open issues - maybe add grab-bag issues (3rd party patch available) - assorted closing, updating and poking old issues User-side interface Patches for client-side Roundup: - inline help for fields in issue creation - adapt current docs (and Brett's guide) for easy access during reporting Patches for server-side Roundup: - maybe add a wizard for filling bugs (3rd party patch available) Timeline TBD, first part should definitely be done before
[Python-Dev] Closing outdated Mac issues
Hi, In the discussion of a feature request for MacPython[1], the OP (hhas) said: As of Python 2.6/3.0, all Mac-specific modules are deprecated/eliminated from the standard library and there are no longer any plans to submit appscript for possible inclusion. This issue should be rejected and closed. If that is the current state of Mac modules, there are no less than 17 issues* that should be closed, 4 bug reports** that might be kept open and 4 mixed-cases*** that might be obsolete/irrelevant. Besides amounting to 1% of open issues, these can divert efforts to bogus issues: I've submitted a patch for one of the mixed-cases (bug + feature request), but now don't think it was worth it. So, if someone could reassure / clarify the rules for closing these in general and/or take a quick look at specific issues, that would be a great help. Issue lists below. Regards, Daniel [1] http://bugs.python.org/issue916013 * Feature requests and implementation polishing issues: http://bugs.python.org/issue706585 Expose FinderInfo in FSCatalogInfo http://bugs.python.org/issue706592 Carbon.File.FSSpec should accept non-existing pathnames http://bugs.python.org/issue776533 Carbon.Snd module SPB constructor shadowed http://bugs.python.org/issue779285 Carbon Event ReceiveNextEvent http://bugs.python.org/issue806149 aetools.TalkTo methods can be obscured http://bugs.python.org/issue822005 Carbon.CarbonEvt.ReceiveNextEvent args wrong http://bugs.python.org/issue852150 Can't send Apple Events without WindowServer connection http://bugs.python.org/issue853656 Carbon.CF.CFURLRef should be easier to create http://bugs.python.org/issue869649 Quicktime missing funcitonality http://bugs.python.org/issue878560 Add a console window for Carbon MacPython applets http://bugs.python.org/issue881824 Add ResolveFinderAliases to macostools module http://bugs.python.org/issue1089399 Carbon.Res misses GetIndString http://bugs.python.org/issue1089624 Carbon.File.FSCatalogInfo.createDate implementation http://bugs.python.org/issue1090958 _AEModule.c patch http://bugs.python.org/issue1113328 OSATerminology still semi-broken http://bugs.python.org/issue1169679 modules missing from list of Carbon modules http://bugs.python.org/issue1254695 QuickTime API needs corrected object types ** Bug reports, might be worth fixing in 2.6: http://bugs.python.org/issue1004810 Carbon.File fails if server vol is mounted after launch http://bugs.python.org/issue1123727 gensuitemodule.processfile fails http://bugs.python.org/issue1700507 Carbon.Scrap.PutScrapFlavor http://bugs.python.org/issue1155 Carbon.CF memory management problem ** Probably out of date, irrelevant or both: http://bugs.python.org/issue779153 bgen requires Universal Headers, not OS X dev headers http://bugs.python.org/issue602291 Bgen should learn about booleans http://bugs.python.org/issue775321 plistlib error handling http://bugs.python.org/issue985064 plistlib crashes too easily on bad files ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .Idle.py init file
Mitchell, I can't find the string .Idle.py in trunk. If you haven't already, please open a documentation issue for this one. I don't see any obvious downside to this behavior and people might be relying on it by now. Thanks for reporting these IDLE issues! Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Closing outdated Mac issues
Looks like the MDS ate the copy sent to the list, here's it again: Brett Cannon wrote: As of Python 2.6 everything Mac-specific is deprecated and in 3.0 they are gone (you can read PEP 3108 for the details or just note that the Mac/Modules directory is gone in 3.0). They will still be around in 2.7, though, as these are Py3K deprecations. OK, I've now read PEPs 3108 and 11, but still would like some ruling about RFEs in these stagnated Mac modules. Maybe PEP 4 could include a note about RFEs in deprecated modules? Not sure what has been left in the Mac directory, but I think it is just random scripts (I never use the Mac-specific stuff so I don't know how useful some of them are to keep). There are 40 C files, two headers and 69 python files in /Mac in trunk. The 2.6 (and 2.5.x) docs say development has stopped and that they'd be replaced in 2.5. So ISTM closing RFEs for these modules would be an improvement. Honestly, fixing them is fine but since the modules are deprecated but still in existence in 2.x, but they are definitely nothing above a normal priority issue. OK, I'll let the bug reports open. What about RFEs? Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Irix still supported? (was Re: Tracker archeology)
Terry Reedy wrote: Can http://bugs.python.org/issue995458 Does not build selected SGI specific modulesbe closed? PEP11 lists Irix 4 as gone. What about Irix 6? http://www.python.org/dev/peps/pep-0011/ Thank you, thank you, thank you :) Can I close these other IRIX issues? http://bugs.python.org/issue2048 http://bugs.python.org/issue1086642 http://bugs.python.org/issue1178510 http://bugs.python.org/issue1070140 Do you know of other OSes (among commercial Unix, mostly) that could also get the axe? Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Daniel (ajax) Diniz wrote: Martin v. Löwis wrote: I think HTML scraping is a really bad idea. What is it that you specifically want to do with these data? For starters, free form searches, aggregation and filtering of results. The web interface is pretty good for handling individual issues, but not so good for adding someone as nosy to lots of issues. I should have thought of this earlier: I'm downloading A CSV file (displaying all fields) with all issues and will insert that into a DB (maybe through my local tracker instance). Thanks for asking the 'think about it' question! :) Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Brett Cannon wrote: On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz aja...@gmail.com wrote: I have to test my patch against a good representation of the issue, regression tests must pass, 'automated test needed' fits well :) Go with Unit test needed so it's short and to the point and you have a deal. =) I don't think a real name change is necessary, the help from clicking on 'Stage' says it. Your explanation at https://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw makes it crystal clear. Also, I've realized just now that 'Status: pending' covers both my 'will close unless someone objects' and 'cannot tell if this ancient bug on a antediluvian platform still exists' rather well. So I'll be setting such issues as pending from now on. I'll try to find a way to display the help tips inline, perhaps on selection or hover (has to be unobtrusive). That would be helpful for stages, components and versions (I think users should know that 2.5 is in security-fix-only mode and that feature requests need latest version + 1). Status report and roadmap to be posted later today, before date +%s turns 1234567890 :) Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Hi Martin, Sorry about being so brief, I got a lot of unexpected interruptions and was rushing things. Martin v. Löwis wrote: For starters, free form searches, aggregation and filtering of results. What is free form searches (example)? What is aggregation? What results do you want to filter? (roundup can already filter results quite well) By free form searches I meant complex queries with more flexible criteria. A real example: find any issue that has words A and B in juxtaposed in messages, containing words starting with 'url' [ but not ending with 'lib' in title (, unless version = 3)], where jjlee isn't nosy. Or issues with less than 5 replies, all from a single user. Lastly, issues where no Developer is nosy, with messages covering an interval longer than a week. These are useful a few times, but hard to predict and not so recurrent searches, so free form makes more sense than adding support for each combination. By aggregation I meant performing a few disjunct searches and combining them in a result set, eliminating duplication, to process as a unit. Then, add issues A,B and C to that. Free form searches cover this by allowing one to perform a query that gives the result set directly, but combining previous searches sounds more pleasant. And by filtering, I meant refining a set of search results and/or searching over a restricted set of issues, on criteria that are present in them. I.e., I'd like to search for segfault and be given a choice box with the all nosy people in the result set, and exclude or only display issues based choosing one of them. All of the above seems trivial with a database-like interface. I have pretty much emulated them with the current search, the handy CSV results downloads, a text editor and a Python shell. The web interface is pretty good for handling individual issues, but not so good for adding someone as nosy to lots of issues. Please consider contributing a mass-update template then, perhaps based on search results, with check boxes to include or exclude individual issues from the mass update. OK, I saw one of these at http://roundup.sf.net/ and will study and adapt it. But it'll solve the 'commit changes' part of the equation, not the 'select set of issues to change'. Send emails before they were done :D Again: what's that? That's me trying to sound witty after sending the email before finishing it :) Use a VCS for in-progress activities Hmm. Why do you need a database copy for that? I don't, the database if for selecting issues to edit. But I'd like to be able to submit bulk changes, and a (local, D) VCS is how I imagine storing these locally should be done. For rollbacks, merges and that sort of thing, besides being able to save incomplete work to continue later. Figure out how to serialize and submit the work done locally Again, don't understand. too brief. The serialization idea comes from this: one would assemble a 'patch' containing different changes to different issues. It's an extension of the mass-update idea, but for non-uniform changes. The deserialization would either happen through a mass-update interface or by running a script to submit them one by one. Share results with interested parties off-tracker (e.g., the auto-nosy mentioned up-thread) The tracker already has auto-assignments based on components. But no way to share aggregated search results (I've sent some off-list), 'follow' users (i.e., be added as nosy for issues where user A is nosy), auto-add as nosy based on keywords, etc. Someday we could have these nosy features hosted externally, e.g. as an AppEngine app that subscribes to python-bugs and sends alerts to users matching the message (by keyword, performed action, new stage, etc.). Right now, more efficient searching and aggregation along with some (local, flexible) UI tweaks sum it up. Efficient in what way? Having those complex searches in a less convoluted workflow, allowing more work to be done faster and in a less error prone way. Maybe I can offer a patch for something like PyPI's 'simple' interface? Please, no. Contribute the interface you want locally instead as a feature for all users of the tracker. OK, after some more cleaning up I'll work on the mass-update, my local searches and report back. Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Daniel (ajax) Diniz wrote: Status report and roadmap to be posted later today, before date +%s turns 1234567890 :) Missed that and got almost no tracker work done. Postponed to Monday, after some weekend cleaning. Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1 planned for this Friday, Feb 13
Barry Warsaw wrote: A quick reminder that I am planning to release Python 3.0.1 this Friday, February 13. Cool :) Should I hold the tracker cleanup until then (the posting part, not the searching)? I'd hate to bury some important report in a sea of ancientness. Daniel PS: Are you aiming at 23:31:30 UTC ? :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Brett Cannon wrote: One thing to keep an eye on for old issues, Daniel, is the Stage field. Setting that is nice for Bug Days as people can see what issues still need a test written or could use a review, etc. OK, I'll try to set a useful Stage for bugs I edit. I'll reread your blog post on stages and study the discussion. I have a doc I am writing up at http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines what the various Stage values should mean. Feedback from you and anybody else is welcome, although realize it is rough as I was not planning to make this public quite yet. Looking good, I'll collect doc feedback as I learn Stages better. Here's some feedback on Stages themselves (still learning, probably misguided). Many old issues have patches without tests, or have patches and tests that are outdated. Others have patches (and sometimes tests), but aren't confirmed as bugs. So the Stage field would be easier to use if it included: 'not reproduced in current releases', 'reproduced, needs updating', 'is this really a bug?' (i.e., should I be writing a test/confirming or discussing the issue?), 'on hold/blocked' (has a blocking dependency). I'm not sure those would be useful for new issues, I think handling the important cases efficiently is more desirable than tuning the workflow for old issues. It's telling that the Stage that caught my attention was [triage] :D Thank you for the support and feedback (and Stages guide!), it helps a lot :) Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Senthil Kumaran wrote: For urllib,urllib2 and urlparse related, please add me (orsenthil) to nosy list. I should already there. I shall test and provide patches. Great! I always find it harder to test urllib[x] than to fix the bug. I'm in the process of gluing some tools and scripts together to help with the search/triage/update process, so I'll add you and Victor a later today. Might hold until after 3.0.1 (due tomorrow) if having the tracker less noisy would be better. In the meantime, other people interested in being added to urllib,urllib2 and urlparse are eligible for discounted prices :) Thanks for claiming these! Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Victor Stinner wrote: I like everything related to Unicode and the separation of byte and character strings in Python3 :-) That's a big one. But Ezio Melotti already asked for Unicode, so I have some 75 issues selected and ready to add you two to, but I'll do it later today or after 3.0.1 tomorrow. Might find some more until then :) Anyone else interested in Unicode? There's locale, gettext, codecs, the Unicode databases, support for Unicode in tools (network protocols and/or file formats, mostly: email, base64). Thanks for stepping up! Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Victor Stinner wrote: Oh, I realized that there is a component called Unicode. So it should be possible to write a request to list all issues related to unicode. Nice, I'll add set this component for issues that don't have it. I can still add people to these issues, if they want. Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Brett Cannon wrote: Sounds like a *verify issue* stage is needed. Although I guess I kind of assumed as part of the triage issue verification would happen as well, but that might be too much as a single step. I'd rather think about it a bit more, available stages cover the vast majority of the issues. When more people have spent spend some time setting and querying stages, new ones will be proposed to fill eventual gaps. All the other ones can use the current stages (e.g. a missing test with a patch is still at a *test needed* stage, it just happens to be able to skip to review once that test is ready). Yes, it makes a lot of sense. These milestones will help getting things done, anything more fine-grained should have a good, well-thougth use case (tracker-discuss is efficient for this). I have a couple of ideas for the work I'm doing, but they mostly revolve around client-side optimizations. Something like a DVCS flavor to triaging :) Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Martin v. Löwis wrote: Oh, I realized that there is a component called Unicode. So it should be possible to write a request to list all issues related to unicode. Nice, I'll add set this component for issues that don't have it. I can still add people to these issues, if they want. We can also add more components if this would support your triage. As a necessary condition, I'd ask that there would be a significant number of issues classified under such a new component. Thanks, Martin. I don't have any request for new components so far, but would be happy to set new ones that might be created from other people's suggestions. I think some statistics could help us. I have a couple of suggestions regarding the UI, I should submit issues and patches to the meta-tracker sometime next week (got a python-dev instance running here, but haven't even looked at it). Mostly things like checkboxes for components, 'no version' being displayed, easier searches for missing/nothing (-1, right?), and a 'search in all issues' button for logged in users. Now, getting into pie-in-the-sky territory, if someone (not logged in) was to download all issues for scrapping and feeding to a local database, what time of day would be less disastrous for the server? :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Stephen J. Turnbull wrote:
Reproduction really is the same thing as providing a test.
That was where I got confused: many issues are easy to reproduce
('test'), but need some thinking to get automated tests right.
urllib always feels like this to me, except 'thinking' - 'getting
lost over and over'. Reading 'test needed' as 'automated test needed',
things make a lot of sense. I have to test my patch against a good
representation of the issue, regression tests must pass, 'automated
test needed' fits well :)
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Daniel (ajax) Diniz wrote: Martin v. Löwis wrote: Now, getting into pie-in-the-sky territory, if someone (not logged in) was to download all issues for scrapping and feeding to a local database, what time of day would be less disastrous for the server? :) I think HTML scraping is a really bad idea. What is it that you specifically want to do with these data? For starters, free form searches, aggregation and filtering of results. The web interface is pretty good for handling individual issues, but not so good for adding someone as nosy to lots of issues. With some more time and effort, I'd be able to: Organize a local workflow with tweaked UI Send emails before they were done :D Use a VCS for in-progress activities Figure out how to serialize and submit the work done locally Share results with interested parties off-tracker (e.g., the auto-nosy mentioned up-thread) Right now, more efficient searching and aggregation along with some (local, flexible) UI tweaks sum it up. Maybe I can offer a patch for something like PyPI's 'simple' interface? Cheers, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tracker archeology
Hi all, For the past two days I've been doing some housekeeping *cough*spamming*cough* on the tracker, mostly on ancient and/or easy bugs. So far, ten bugs have been closed (thanks Antoine, Barry, Benjamin, Guilherme, Martin and Raymond). I nominated some other bugs (below) for closing and added a few simple patches, with a couple more pending feedback. If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker. Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real work and people agree the workflow would be better, I'd like to have developer rights in the tracker, as per Antoine's suggestion. FWIW, I have no problem with the current situation. Talking about Bug Days, I see lots of easy bugs, some with outdated patches. Is there any plan of doing a Bug Day around PyCon time? Best regards, Daniel Bugs nominated for express closing: http://bugs.python.org/issue1103926 email.base64MIME.header_encode vs RFC 1522 http://bugs.python.org/issue727898 Support for sending multipart form data http://bugs.python.org/issue713169 test_pty fails on HP-UX and AIX when run after test_openpty http://bugs.python.org/issue816059 popen2 work, fixes bugs 768649 and 761888 http://bugs.python.org/issue1911 webbrowser.open firefox 3 issues http://bugs.python.org/issue1170065 HTTPResponse.getheaders() returns lowercased header names http://bugs.python.org/issue1175686 add reload function http://bugs.python.org/issue779191 BasicModuleLoader behaviour in Python 2.3c2 http://bugs.python.org/issue1327971 HTTPResponse instance has no attribute 'fileno' ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Brett Cannon wrote: OK, three enthusiastic votes to give them is plenty for me. You should have the Developer role now, Daniel. Let me know if I screwed up at all in switchng the role on for you. Thanks a lot! Looks like it worked fine :) Let me try the new thing, then: warnings and import for you, distutils for Tarek, 2to3 (if any left) for Benjamin and Unicode for Ezio (and patches for Antoine!). If anyone else wants to claim or be added to dusty bugs, just give me a shout :) Cheers, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug tracker house cleaning.
Hi Raymond, Thanks a lot for the feedback. I actually am more than a bit concerned about the effect of my wholesale edits on the signal to noise ration. Any clarifications are most welcome (and I'm open to change methods and immediate goals) :) Raymond Hettinger wrote: ISTM, that when closing duplicate bug reports, both should reference one another so that the combined threads don't get lost. I agree, sorry for not doing it in issue 1820[1]. I will revise the recently closed bugs to see if I can correct cases where this didn't happen. Also, assigning bugs to people who haven't asked to handle them doesn't seem like it is actually cleaning-up anything. That was not the goal at all, so any instance in which it did happen was a mistake. I won't change these unless I was responsible for wrongfully assigning, but I will look back at all my edits to clean up such errors. I've added you as nosy for 2308, the duplicate of 1820, before closing it. Sorry about the inconvenience, as you said both [issues] should reference one another is the way to go. If something is assigned to someone, I usually assume they intend to work on it at some point. In contrast, unassigned means that no one is currently handling it. Fair enough, but in most (hopefully all) cases I only assigned bugs to people that requested so, in the Tracker archeology thread. Tomorrow I intend to follow up with confirmations/tests/patches for as many of these issues as I can, so in the short term these bugs will receive some attention. Just thought I would toss this out since the status of so many bugs/patches is being updated today. I really appreciate that. I'll keep your suggestions in mind and try to improve my edits. Best regards, Daniel [1] http://bugs.python.org/issue1820 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Brett Cannon wrote: Warnings and import for me. Done. Tomorrow I'll see what I can triage/test in those. Talking about Bug Days, I see lots of easy bugs, some with outdated patches. Is there any plan of doing a Bug Day around PyCon time? Well, the sprints at PyCon are Bug Days themselves really, although they happen during the week so that tends to cause problems. As of right now there are no plans but someone can obviously plan one if they feel up for it. OK, sometime later I'll try to flag Easy bugs, then. Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Tarek Ziadé wrote: I'll take Distutils related issues, Done. Since Akira Kitada is helping with many distutils issues, I'll skip looking at them for now. Ping me if you need tests or simple patches :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Benjamin Peterson wrote: Adding/assigning to me on 2to3 bugs is fine, but usually I notice stuff I'm interested in as it rises to the top. Done, found a couple more. There are also some -3 warnings open, if that interests you :) Thanks for the support, I only saw it was a +10 now :D Cheers, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] teaching the new urllib
Tres Seaver wrote: Brett Cannon wrote: No because you are getting back the repr for the bytes object. Str does not know what the encoding is for the bytes so it has no way of performing the decoding. The encoding information *is* available in the response headers, e.g.: [snip] That's the target of http://bugs.python.org/issue4733 cited by Benjamin: 'Add a decode to declared encoding version of urlopen to urllib' . I think it's an important use case, but the current patch is pretty awful. Improvements/feedback welcome :) Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_subprocess and sparc buildbots
Georg Brandl wrote: This only occurs --with-pydebug, I assume? For me, on 32 bits Linux, yes, only --with-pydebug*. It is the same basic problem as in http://bugs.python.org/issue3299, which I analysed some time ago. Yes, I guess my 'catch' is exactly that. But it might be a red herring (sorry if that's the case): is the correlation with sparc and/or rev.67888 real? Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_subprocess and sparc buildbots
Alexandre Vassalotti wrote: The logs of failing test runs all shows the same error message: [31481 refs] * ob object : refcnt 0 at 0x3a97728 type: str refcount: 0 address : 0x3a97728 * op-_ob_prev-_ob_next object : refcnt 0 at 0x3a97728 type: str refcount: 0 address : 0x3a97728 * op-_ob_next-_ob_prev object : [31776 refs] A reliable way to get that in a --with-pydebug build seems to be: ~/py3k$ ./python -c import locale; locale.format_string(1,1) * ob object : refcnt 0 at 0x825c76c type: tuple refcount: 0 address : 0x825c76c * op-_ob_prev-_ob_next NULL * op-_ob_next-_ob_prev object : refcnt 0 at 0x825c76c type: tuple refcount: 0 address : 0x825c76c Fatal Python error: UNREF invalid object TypeError: expected string or buffer Aborted Found using Fusil in a very quick run on top of: Python 3.1a0 (py3k:68055M, Dec 31 2008, 01:34:52) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 So kudos to Victor again :) HTH, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Next monthly sprint/bugfix day?
On Thu, Apr 10, 2008 at 12:10 PM, Rodrigo Bernardo Pimentel [EMAIL PROTECTED] wrote: On Wed, Apr 09 2008 at 11:12:58AM BRT, Trent Nelson [EMAIL PROTECTED] wrote: Hi, Is there another online sprint/bugfix day in the pipeline? If not, can there be? ;-) +1. The Sao Paulo User's Group gathered to work on the last Bug Day, and I think it was very productive (both for generating patches/comments and for us to get more involved with Python core development). +1 from me. Rodrigo: Do you think GruPy-SP could coordinate with python-brasil to promote local participation in the next Bug Day? Regards, Daniel (from Brasília-DF) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
