Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
Stephen J. Turnbull wrote: Antoine Pitrou writes: > Terry Reedy udel.edu> writes: > > > > I watched and was greatly impressed by the video demo of Google's new > > Wave collaborative communication system. I believe it would/will help > > with some of the chronic problems we (and others) have. > > I really don't think technical systems are an answer to social > issues. It's a flaw of the engineering mindset. Well, its true that telephones did not cure people of dishonesty, but it did make communication-at-a-distance, truthful or otherwise, easier. That depends on the definition of "problem". For example, if the problem is "half our people detest web interfaces and want to discuss issues by email", then "Roundup: nosy list" *is* a technical system that is an answer. And for me, it is very helpful. I agree that Terry wasn't particularly specific about what impressed him and how it would help for what problem. Right. A quick three lines plus a few more. There were several things that Wave brings together. I will suggest specific experiments when it is actually available for use. > But rather than just say "technology is not a universal answer", we should ask "what problem does this address?" As I said in my response to Ben Finney, two problems addressed are 1. Reading a document that has been edited since you read it last. The old method of in-place deltas -- typically strikeout for deletions and some other special marking for additions -- has stood that test of time. Many word processors do this, but Waves improve on them by individualizing the markings for the particular reader and then removing them once read. 2. Multiple people editing a document. One solution is the "You're it" method, whether informal by passing a doc around either on paper or electronicly or formal by VCS checkout. Another is edit in isolation, merge, and resolve conflicts. Waves allow real-time simultaneous editing and merging via micro-deltas, so conflicts are immediately apparent. This would generally work better with text docs than with code, which needs to be frequently frozen to run, but code might even be workable for side-by-side pair or sprint programming. > (Personally, I'm satisfied from the example Terry gave that he had the "summarizing the opinions of those whose opinions we respect in this domain" problem in mind, and I think there *are* technical solutions to that. Terry?) The current 'summarize opinion' system is somewhat haphazard and informal, with no auto-tabulation. It seems to have broken-down a bit for the ipaddr issue, at least until the last few days when the best solution was to remove and defer. Better would have been either not add and defer or add with generally supported revision. I speculate that if there had been a proto-pep wave (though not then possible) with a vote widget with buttons such as Accept as is, Probably accept after revision, Don't know, and Reject, we might have reached a better outcome sooner. Terry Jan Reedy ___ 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] Google Wave as a developer communication tool
Terry Reedy writes: > Ben Finney wrote: > > I watched [the Google Wave presentation] too. It appears to be > > heavily reliant on *very* fast internet access for participants in a > > wave. That's far from universal in the Python community, let alone > > the internet at large. > > Even a slow connection would make participation in PEPs better than > today. How can you know that? A slow link doesn't punish email or NNTP communication the way an interactive web application does. Why would Google Wave be any less punitive to low-bandwidth users than existing live web applications? I would not want to put money against Google technologists giving lower priority to the needs of the majority of internet users without fast connections. > > It also appears to be heavily reliant on the wave's existence at a > > single point of failure (the hosting server): if that one point > > becomes unreliable, all participants are hosed. > > We have that problem already with the tracker, which does occasionally > go down for a bit. And the svn host? (One reason to move to > distributed system.) Right. These are all reasons for moving toward distributed systems; Python has chosen to do so already with its VCS. Why would the choice of a new communications technology not take this into consideration? > > Neither of these problems exist with email (or NNTP). > > But do for an email list, like this one. Or a wiki. No. None of mailing list, NNTP, or wiki are heavily punitive to low-bandwidth links. -- \ “Creativity can be a social contribution, but only in so far as | `\society is free to use the results.” —Richard Stallman | _o__) | Ben Finney ___ 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] Google Wave as a developer communication tool
Ben Finney writes: > Terry Reedy writes: > > Even a slow connection would make participation in PEPs better than > > today. > > How can you know that? A slow link doesn't punish email or NNTP > communication the way an interactive web application does. Strike that; reverse it. Should be “A slow link is not punished by email or NNTP communication the way it is by an interactive web application”. -- \ “I went over to the neighbor's and asked to borrow a cup of | `\ salt. ‘What are you making?’ ‘A salt lick.’” —Steven Wright | _o__) | Ben Finney ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
Paul Moore wrote: > Mostly, I agree, but I definitely disagree, I'm afraid, on the use of > the tracker for discussions. To keep track of discussions on a ticket, > I have to personally keep a list of the tickets I'm interested in, > check back regularly to see if there's anything new, and keep a mental > note of where I've read up to so I know what's new. Others have already noted that Roundup not only emails you with new comments, but also lets you reply via email. That happens for anyone on the nosy list for an issue (commenting on an issue automatically adds you to the nosy list). In addition, you can fairly easily create a saved query to show you all the open tickets that you are on the nosy list for. (Although I created and saved my query for that so long ago that I don't recall the exact details on how to go about doing that). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
2009/6/4 Nick Coghlan : > Paul Moore wrote: >> Mostly, I agree, but I definitely disagree, I'm afraid, on the use of >> the tracker for discussions. To keep track of discussions on a ticket, >> I have to personally keep a list of the tickets I'm interested in, >> check back regularly to see if there's anything new, and keep a mental >> note of where I've read up to so I know what's new. > > Others have already noted that Roundup not only emails you with new > comments, but also lets you reply via email. That happens for anyone on > the nosy list for an issue (commenting on an issue automatically adds > you to the nosy list). > > In addition, you can fairly easily create a saved query to show you all > the open tickets that you are on the nosy list for. (Although I created > and saved my query for that so long ago that I don't recall the exact > details on how to go about doing that). Agreed, and thanks to all for the pointers to features I wasn't aware of. I could still argue that there are downsides (need to take action to set myself as nosy on an issue, possibly setting up a new mail filter, housekeeping cruft, the fact that people don't quote in the same way on tracker items) that make tracker discussions less attractive to me, but it's very personal things. Let's leave it as merely that I wouldn't have contributed to the ipaddr discussion if it had been solely on the tracker (not even if pointers to and reminders of the tracker item were posted to python-dev). My input wasn't very valuable, so maybe that doesn't matter much. Maybe the key point is that keeping discussion on the tracker introduces a barrier to participation by lurkers, FWIW. Paul. ___ 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] Google Wave as a developer communication tool
On Thu, Jun 04, 2009, Terry Reedy wrote: > > Example: if PEPs were waves, then responses could either be entered as > live edits (with permission) or comments immediately following the > relevant text (as with email/newsgroups) visible to all. Much easier > than current situation. Edits are marked in red shading for those who > have previously seen document. Many have complained that it is hard to > read multiple versions of a PEP since so much is new and there is no > indication of what is new to the particular reader. It sounds like Wave requires a high-powered browser, similar to Google Maps. That makes me -1 because I want to continue using Lynx. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "Given that C++ has pointers and typecasts, it's really hard to have a serious conversation about type safety with a C++ programmer and keep a straight face. It's kind of like having a guy who juggles chainsaws wearing body armor arguing with a guy who juggles rubber chickens wearing a T-shirt about who's in more danger." --Roy Smith, c.l.py, 2004.05.23 ___ 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] Mercurial, linefeeds, and Visual Studio
I just wanted to share my experience with the mercurial checkout. I cloned http://code.python.org/hg/branches/py3k to continue work on http://bugs.python.org/issue1578269 but I found that when I click on PC/VS8.0/pcbuild.sln, nothing happens. This appears to be due to a bug/limitation in vslauncher in that it doesn't recognize LF as a line separator. vslauncher is the default association for sln files and its purpose is to parse out the .sln file and launch it with the appropriate Visual Studio version based on the header. What makes matters worse is if vslauncher fails to recognize the format, it does nothing, so it just appears as if the file fails to launch anything. It seems that within the hg repository, everything has been converted to LF for line endings. I suspect this is because HG provides no integrated support for line-ending conversions and because the hg to svn bridge is probably running on a Unix OS. So converting the pcbuild.sln file to CRLF line endings resolved the problem and the file would launch normally. Also, without conversion, it was possible to open the .sln file in Visual Studio explicitly. I wanted to share this with the community in case anyone else runs into this issue. Also, if there's a recommended procedure for addressing this issue (and others that might arise due to non-native line endings), I'd be interested to hear it. Regards, Jason ___ 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 and linefeeds
On Thu, Jun 04, 2009 at 09:02:53AM -0400, Jason R. Coombs wrote: > It seems that within the hg repository, everything has been converted to LF > for line endings. I suspect this is because HG provides no integrated > support for line-ending conversions and because the hg to svn bridge is > probably running on a Unix OS. http://www.selenic.com/mercurial/wiki/FAQ#FAQ.2BAC8-TechnicalDetails.What_about_Windows_line_endings_vs._Unix_line_endings.3F Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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, linefeeds, and Visual Studio
On Thu, Jun 4, 2009 at 3:02 PM, Jason R. Coombs wrote: > I wanted to share this with the community in case anyone else runs into this > issue. Also, if there's a recommended procedure for addressing this issue > (and others that might arise due to non-native line endings), I'd be > interested to hear it. Mercurial comes with a win32text extension that helps resolve issues like these. It allows you to specify in the .hg/hgrc that .sln files should always be expanded to CRLF. Cheers, Dirkjan ___ 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 and linefeeds
On Thu, 4 Jun 2009 at 17:30, Oleg Broytmann wrote: On Thu, Jun 04, 2009 at 09:02:53AM -0400, Jason R. Coombs wrote: It seems that within the hg repository, everything has been converted to LF for line endings. I suspect this is because HG provides no integrated support for line-ending conversions and because the hg to svn bridge is probably running on a Unix OS. http://www.selenic.com/mercurial/wiki/FAQ#FAQ.2BAC8-TechnicalDetails.What_about_Windows_line_endings_vs._Unix_line_endings.3F Linked from that is: http://www.selenic.com/mercurial/wiki/Win32TextExtension which says: "The filter specification can however not be managed by the repository..." (I'm not clear what is being filtered on, but it looks like it might be the _content_ of the files.) The above statement seems like a really odd design choice, with the potential for causing considerable developer coordination headaches. Any Mercurial boffins want to talk about how this works in practice? --David ___ 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 and linefeeds
On Thu, Jun 4, 2009 at 3:49 PM, R. David Murray wrote: > The above statement seems like a really odd design choice, with the > potential for causing considerable developer coordination headaches. > > Any Mercurial boffins want to talk about how this works in practice? I'm guessing that's just because it uses Mercurial's built-in configuration file chain (.hg/hgrc, ~/.hgrc and /etc/mercurial/hgrc). Those aren't transmitted with repositories because they can contain potentially security-sensitive information (like triggers for executing interesting hooks and information on what users to trust). It would certainly be possible to write a modified win32text-like extension that takes its cues from a versioned file (like the .hgtags and .hgsigs files currently supported). I'm not sure why the original author didn't go that way, though. Cheers, Dirkjan ___ 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, linefeeds, and Visual Studio
2009/6/4 Dirkjan Ochtman : > On Thu, Jun 4, 2009 at 3:02 PM, Jason R. Coombs wrote: >> I wanted to share this with the community in case anyone else runs into this >> issue. Also, if there's a recommended procedure for addressing this issue >> (and others that might arise due to non-native line endings), I'd be >> interested to hear it. > > Mercurial comes with a win32text extension that helps resolve issues > like these. It allows you to specify in the .hg/hgrc that .sln files > should always be expanded to CRLF. Silly question, but given that Mercurial itself does *no* conversion, and CRLF is the only valid form for that file, why shouldn't the file be checked into the repository with CRLF endings, and that's the end of it (apart from misconfigured win32text setups on the client)? Ideally, the history should be imported with CRLF throughout, which is a task for the migration process. If that's too hard because of limitations in the available conversion tools, then maybe the limitation has to be accepted that pre-conversion copies of the file have incorrect line endings and a manual fiox is committed right after the switchover. Doesn't help the current Mercurial mirrors, of course, but at least this report alerts us to a consideration for the final switchover. Essentially, pcbuild.sln is a binary file, and should be treated as such. Maybe it's an error in the Subversion setup that it's treated as text at all... Paul. ___ 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, linefeeds, and Visual Studio
On Thu, Jun 04, 2009 at 03:20:56PM +0100, Paul Moore wrote: > Essentially, pcbuild.sln is a binary file, and should be treated as > such. Maybe it's an error in the Subversion setup that it's treated as > text at all... Subversion has a built-in notion of eol-conversion (don't know if it was used for this particular file). Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
On Thu, Jun 4, 2009 at 6:20 AM, Paul Moore wrote: ... > I could still argue that there are downsides (need to take action to > set myself as nosy on an issue, possibly setting up a new mail filter, > housekeeping cruft, the fact that people don't quote in the same way > on tracker items) that make tracker discussions less attractive to me, > but it's very personal things. How hard would it be to set up a bot that will subscribe to python-dev and archive messages that have [issue] in the subject under appropriate roundup ticket? This way if discussion started on roundup, it would only take adding python-dev in CC to bring it to the larger python-dev audience and adding issue number to the python-dev thread subject will be all it takes to archive new messages on roundup. This would not solve a problem of linking threads that start on python-dev before a ticket is opened, but with some proper conventions this problem can be solved as well. ___ 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, linefeeds, and Visual Studio
On Thu, Jun 4, 2009 at 4:20 PM, Paul Moore wrote: > Silly question, but given that Mercurial itself does *no* conversion, > and CRLF is the only valid form for that file, why shouldn't the file > be checked into the repository with CRLF endings, and that's the end > of it (apart from misconfigured win32text setups on the client)? That's certainly a valid setup, and I wasn't suggesting otherwise. I have no experience with .sln files, and I haven't really used win32text either; I was just commenting on the general facilities of Mercurial wrt these kinds of issues. > Ideally, the history should be imported with CRLF throughout, which is > a task for the migration process. If that's too hard because of > limitations in the available conversion tools, then maybe the > limitation has to be accepted that pre-conversion copies of the file > have incorrect line endings and a manual fiox is committed right after > the switchover. Importing it with CRLF throughout would certainly be possible. I'll add a section to my draft PEP. > Essentially, pcbuild.sln is a binary file, and should be treated as > such. Maybe it's an error in the Subversion setup that it's treated as > text at all... Yes, it certainly seems that way. Cheers, Dirkjan ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
Alternatively, one could create a python-dev profile on roundup and encourage people to add python-dev to the nosy list when discussion needs to be broaden. This way replies to all will be posted in both places. Once discussion gets too specialized, someone can remove python-dev from the "nosies." No new code is required to set this up as far as I can tell. On Thu, Jun 4, 2009 at 11:08 AM, C. Titus Brown wrote: > On Thu, Jun 04, 2009 at 11:03:22AM -0400, Alexander Belopolsky wrote: > -> On Thu, Jun 4, 2009 at 6:20 AM, Paul Moore wrote: > -> ... > -> > I could still argue that there are downsides (need to take action to > -> > set myself as nosy on an issue, possibly setting up a new mail filter, > -> > housekeeping cruft, the fact that people don't quote in the same way > -> > on tracker items) that make tracker discussions less attractive to me, > -> > but it's very personal things. > -> > -> How hard would it be to set up a bot that will subscribe to python-dev > -> and archive messages that have [issue] in the subject under > -> appropriate roundup ticket? This way if discussion started on > -> roundup, it would only take adding python-dev in CC to bring it to the > -> larger python-dev audience and adding issue number to the python-dev > -> thread subject will be all it takes to archive new messages on > -> roundup. This would not solve a problem of linking threads that start > -> on python-dev before a ticket is opened, but with some proper > -> conventions this problem can be solved as well. > > In my experience this kind automated stuff is too fragile to work > reliably & specifically over time, which is what we would want -- "fire > and forget". > > Is there a good python-dev archive search mechanism (other than to > google "python-dev " ;) out there? Wouldn't that help? > > cheers, > --titus > -- > C. Titus Brown, c...@msu.edu > ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
On Thu, Jun 04, 2009 at 11:03:22AM -0400, Alexander Belopolsky wrote: -> On Thu, Jun 4, 2009 at 6:20 AM, Paul Moore wrote: -> ... -> > I could still argue that there are downsides (need to take action to -> > set myself as nosy on an issue, possibly setting up a new mail filter, -> > housekeeping cruft, the fact that people don't quote in the same way -> > on tracker items) that make tracker discussions less attractive to me, -> > but it's very personal things. -> -> How hard would it be to set up a bot that will subscribe to python-dev -> and archive messages that have [issue] in the subject under -> appropriate roundup ticket? This way if discussion started on -> roundup, it would only take adding python-dev in CC to bring it to the -> larger python-dev audience and adding issue number to the python-dev -> thread subject will be all it takes to archive new messages on -> roundup. This would not solve a problem of linking threads that start -> on python-dev before a ticket is opened, but with some proper -> conventions this problem can be solved as well. In my experience this kind automated stuff is too fragile to work reliably & specifically over time, which is what we would want -- "fire and forget". Is there a good python-dev archive search mechanism (other than to google "python-dev " ;) out there? Wouldn't that help? cheers, --titus -- C. Titus Brown, c...@msu.edu ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
> Is there a document which lists these things, and explains how it is > desirable to communicate them? I recently updated Twisted's equivalent > document, adding minutae like which buttons to click on in our issue > tracker, since that seems obvious to me but apparently wasn't obvious to > a lot of new contributors. I'm not quite sure whether this is what you are asking for, but there is http://www.python.org/dev/workflow/ > My reading of it suggests that he was saying "netaddr appears to be > superior in every way, so python should include that instead. But, if > someone is insisting on ipaddr here are the things that could change > about it". The important thing here is that interpretation of the > comment is required, so I can definitely see how you saw it the way you > did. There is no "-1" in his comment, and there's no documentation > (that I'm aware of) which says that a "-1" is required, or how it will > be used or interpreted. Well, there is http://www.python.org/dev/peps/pep-0010/ I personally use them sometimes, but wouldn't insist on others using them. Regards, Martin ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
On Thu, Jun 4, 2009 at 5:08 PM, C. Titus Brown wrote: > In my experience this kind automated stuff is too fragile to work > reliably & specifically over time, which is what we would want -- "fire > and forget". You could a python-dev account in the tracker and allow people to nosy it. > Is there a good python-dev archive search mechanism (other than to > google "python-dev " ;) out there? Wouldn't that help? Like http://python.markmail.org/? Cheers, Dirkjan ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
> Is there a good python-dev archive search mechanism (other than to > google "python-dev " ;) out there? Wouldn't that help? I would add site:mail.python.org into the google query, but apart from that: what's wrong with google search? Regards, Martin ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
Alexander Belopolsky wrote: > Alternatively, one could create a python-dev profile on roundup and > encourage people to add python-dev to the nosy list when discussion > needs to be broaden. This way replies to all will be posted in both > places. Once discussion gets too specialized, someone can remove > python-dev from the "nosies." No new code is required to set this up > as far as I can tell. That would certainly be possible. I'm not sure whether it *should* be done, though. If anybody actually wants that feature, please create a ticket in the meta tracker. Regards, Martin ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
> In addition, you can fairly easily create a saved query to show you all > the open tickets that you are on the nosy list for. (Although I created > and saved my query for that so long ago that I don't recall the exact > details on how to go about doing that). It's fairly easy. Start a search, put your account name into "Nosy list member", and put "My nosy" (or some such) into "Query name**". Then hit search, and watch "My nosy" appear under "Your queries". Regards, Martin ___ 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] Google Wave as a developer communication tool
Ben Finney wrote: Terry Reedy writes: Ben Finney wrote: I watched [the Google Wave presentation] too. It appears to be heavily reliant on *very* fast internet access for participants in a wave. That's far from universal in the Python community, let alone the internet at large. Even a slow connection would make participation in PEPs better than today. How can you know that? A slow link doesn't punish email or NNTP communication the way an interactive web application does. Why would Google Wave be any less punitive to low-bandwidth users than existing live web applications? I am not sure of what 'live web application' you have in mind to compare to ;-). A general answer is text stream versus binary blob stream. A wave is more like a souped-up mailing-list or newsgroup thread or wiki page than an online game. You open your wave client and PEPxxx.wave is marked as having new content. At your leisure, you open it (or perhaps you have marked it 'download updates in background'). That that takes longer with a slow connection is no different than with other text streams. If you type in a comment, even 1200 baud upsteam is fast enough. Where do you get 'punitive' in this? It also appears to be heavily reliant on the wave's existence at a single point of failure (the hosting server): if that one point becomes unreliable, all participants are hosed. We have that problem already with the tracker, which does occasionally go down for a bit. And the svn host? (One reason to move to distributed system.) Right. These are all reasons for moving toward distributed systems; Python has chosen to do so already with its VCS. Why would the choice of a new communications technology not take this into consideration? It should. The wave protocol includes server-to-server mirroring. A wave can be shared across multiple servers. Neither of these problems exist with email (or NNTP). But do for an email list, like this one. Or a wiki. The second of 'these problems' was 'single point of failure'. That *can* apply to email and wiki. No. None of mailing list, NNTP, or wiki are heavily punitive to low-bandwidth links. I would not expect that to be much more true of a text-only wave. It is binary content (and embeded ad links) that made broadband really necessary for web surfing. Terry Jan Reedy ___ 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 improvements use-cases
Hello, in the last few weeks I have been working on defining use-cases which will lead the improvement of the Roundup tracker. As this is very important, I would like your valuable input in form of comments, criticism and advices. Use-cases in-lined: == Daniel is a great hacker, but the only time he has time to hack is when his child is asleep. And his child wakes up every now and then, pretty often actually. So when it starts crying, Daniel commits fix to that silly bug that has been hunting us for ages, but forgets to close down the bug so it stays open. Looking over bug tracker, Jane finds the same bug and starts working on the same bug. Wasted time. Daniel should be able to format commit message in such a way that would automatically close the bug. Maria is a student, and got involved in FOSS recently. With all the studies she has to do, she would prefer not to spend her time changing bug status. She should be able to format commit message in such a way that would change bug status to something other then the current status. Technical talk: USE CASE A: Integrate issue property editing with Mercurial, including: * USE CASE A1: Allow users to close issues via tokens embedded into commit messages. * USE CASE A2: Allow users to change issue status via tokens embedded into commit messages. Ronny is about to fix a torny bug, so he has a public branch for that. He is making great progress, but the issue that tracks the bug only contains a very out-of-date patch, prompting other developers to try to fix the same bug. Ronny should be able to tell Roundup about where his code lives, so users can get up-to-date patches/diffs automatically. This also allows other users to know all the code that changed to fix a given bug. Technical talk: Integrate branch and rich patch handling into Roundup * USE CASE B: Track all changesets that relate to a given issue: o USE CASE B1: Using tokens embedded into commit messages. (Post commit) o USE CASE B2: Using named branches, bookmarks. (Pre or post commit) o USE CASE B3: Using patchsets, bundles or whatchacallit for fat Mercurial patches. (Pre or post commit) Brett wants to fix a couple of related issues and has a local Mercurial branch for that. He would like his commit messages to include useful information for when his patch/branch lands in the Python repository. Besides the Mercurial->Roundup integration, a Roundup->Mercurial one that would allow one to fetch issue details and existing patches/branches with metadata would make Brett's work more valuable. Technical talk: USE CASE C: Add a CLI interface for Roundup so VCSs can query the tracker. * USE CASE C1: Automatically fetch issue data. * USE CASE C2: Pre-format output for greater usefulness in commit messages: o USE CASE C2.1: Setting issue properties. o USE CASE C2.2: Grouping changesets. * USE CASE C3: Fetch branch information for local cloning. * USE CASE C4: Add a Mercurial extension to exercize the CLI client. USE CASE D: Antoine is merging lots of branches and applying lots of patches to his local branch of the Python repository. He goes to each issue with a patch/branch and tells people whether their patches apply cleanly, just to avoid merge issues in the main branch. While he could use Mercurial Patch Queues (mq), Roundup would need to learn to both listen to and to submit patches to mq in order to completely replace Antoine's work with automated tools. Having a quick 'check if this patch applies cleanly' button would make triaging issues much easier. USE CASE E: David is checking the python-commits list for avoiding bad code from landing and nesting in the Python code base. He only sees the patches: while informative, it requires a bit of mental gymanstics to see how it would merge with the surrounding code. Whenever he thinks some code has tabs and spaces or lines that are too long, he runs pylint and reindent.py locally. He can only raise concerns about the code after it lands on the main repository. It should be easier to see the code changes in context. Having a way to check the code for mistakes in the tracker would make David's life a lot easier. USE CASE F: Van Lindberg is concerned about code submissions from non-core developers: how can the PSF re-license this code in the future without talking to each contributor, whether the PSF is safe from litigation based on copyrights of these contributions and related questions are always bugging him. While the PSF has Contributor Agreements exactly for these cases, it would be great to have the issue tracker and the VCS talk to each other, so they could ask contributors to sign (or declare to have already signed) the CAs when necessary. USE CASE G: Use Transplant/Patch Branch to generate patches from branches linked from Roundup. USE CASE J: Integrate the code/commits navigation interface with Roundup, so changesets, branches, etc., can be easily lin
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
Martin v. Löwis wrote: In addition, you can fairly easily create a saved query to show you all the open tickets that you are on the nosy list for. (Although I created and saved my query for that so long ago that I don't recall the exact details on how to go about doing that). It's fairly easy. Start a search, put your account name into "Nosy list member", and put "My nosy" (or some such) into "Query name**". Then hit search, and watch "My nosy" appear under "Your queries". Done. Wow. Thanks. tjr ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
On Thu, Jun 04, 2009 at 05:54:23PM +0200, "Martin v. L?wis" wrote: -> > Is there a good python-dev archive search mechanism (other than to -> > google "python-dev " ;) out there? Wouldn't that help? -> -> I would add site:mail.python.org into the google query, but apart from -> that: what's wrong with google search? It generally points you towards the right messages in the python-dev archives, but those are kept by month and the threading doesn't always work well. Sometimes conversations span many months, and threading can be an immense help for understanding the discussion. Something like MarkMail (as Dirkjan mentioned) may have a better interface. I'll give it a try. thanks, --titus -- C. Titus Brown, c...@msu.edu ___ 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 with process and discussions (Re: Issues with Py3.1's new ipaddr)
In article <20090604173400.gb25...@idyll.org>, "C. Titus Brown" wrote: > Something like MarkMail (as Dirkjan mentioned) may have a better > interface. I'll give it a try. Or http://search.gmane.org/ with group gmane.comp.python.devel -- Ned Deily, n...@acm.org ___ 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] Roundup improvements use-cases
Mario wrote: USE CASE F: Van Lindberg is concerned about code submissions from non-core developers: how can the PSF re-license this code in the future without talking to each contributor, whether the PSF is safe from litigation based on copyrights of these contributions and related questions are always bugging him. While the PSF has Contributor Agreements exactly for these cases, it would be great to have the issue tracker and the VCS talk to each other, so they could ask contributors to sign (or declare to have already signed) the CAs when necessary. +1. This is exactly right. ___ 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] [Roundup-devel] Roundup improvements use-cases
Hi Mario,
thanks for sending these use-cases out. Let me give some feedback:
Mario wrote:
Technical talk: USE CASE A: Integrate issue property editing with
Mercurial, including:
* USE CASE A1: Allow users to close issues via tokens embedded
into commit messages.
* USE CASE A2: Allow users to change issue status via tokens
embedded into commit messages.
This is the most fundamental one, and it is implementable without even
touching Roundup itself. All that is required is a 'post-commit-hook'
(whatever that is spelled for a particular VCS) that sends a mail to a
tracker, if some tokens were found in the commit message. While in
theory this is all up for customization, I think it would be nice to set
up some conventions to guide users in how to do this (the 'token
grammar', mostly), just for convenience.
Ronny is about to fix a torny bug, so he has a public branch for that.
He is making great progress, but the issue that tracks the bug only
contains a very out-of-date patch, prompting other developers to try
to fix the same bug. Ronny should be able to tell Roundup about where
his code lives, so users can get up-to-date patches/diffs
automatically. This also allows other users to know all the code that
changed to fix a given bug.
Technical talk: Integrate branch and rich patch handling into Roundup
* USE CASE B: Track all changesets that relate to a given issue:
o USE CASE B1: Using tokens embedded into commit messages.
(Post commit)
o USE CASE B2: Using named branches, bookmarks. (Pre or post commit)
o USE CASE B3: Using patchsets, bundles or whatchacallit for
fat Mercurial patches. (Pre or post commit)
Hmm, I have difficulties mapping your prosaic description of the use
case above to the 'technical talk'. The latter almost sounds like an
implementation strategy to me.
This is a very interesting use case, driving us at the core of the 'VCS
integration'. We need to customize a schema to provide a notion for
'repository' and 'branch', and also for 'patch'. Then we need to somehow
endow the patch type with knowledge of what it means to be 'applied' to
a branch, etc. (more on this below).
Brett wants to fix a couple of related issues and has a local
Mercurial branch for that. He would like his commit messages to
include useful information for when his patch/branch lands in the
Python repository. Besides the Mercurial->Roundup integration, a
Roundup->Mercurial one that would allow one to fetch issue details and
existing patches/branches with metadata would make Brett's work more
valuable.
Technical talk: USE CASE C: Add a CLI interface for Roundup so VCSs
can query the tracker.
* USE CASE C1: Automatically fetch issue data.
* USE CASE C2: Pre-format output for greater usefulness in commit messages:
o USE CASE C2.1: Setting issue properties.
o USE CASE C2.2: Grouping changesets.
* USE CASE C3: Fetch branch information for local cloning.
* USE CASE C4: Add a Mercurial extension to exercize the CLI client.
This set of use cases ('C') is what I have most difficulties with. It
clearly is about 'VCS <-> Roundup integration', but it's in the other
direction. And thus, this doesn't seem to concern Roundup itself, or
does it ? Presumably, everything needed already exists. We now have an
XMLRPC interface, so it is possible to write (remote) Roundup clients. I
think writing such a 'Roundup client library' would be useful, but I
think somewhat out of scope with respect to this GSoC project.
USE CASE D:
Antoine is merging lots of branches and applying lots of patches to
his local branch of the Python repository. He goes to each issue with
a patch/branch and tells people whether their patches apply cleanly,
just to avoid merge issues in the main branch. While he could use
Mercurial Patch Queues (mq), Roundup would need to learn to both
listen to and to submit patches to mq in order to completely replace
Antoine's work with automated tools. Having a quick 'check if this
patch applies cleanly' button would make triaging issues much easier.
Let's drill down here a little, as this may be more than one use-case:
D1: provide an interface through which users can attempt to apply a
submitted patch to a given branch.
This requires a 'working copy' of the code (Roundup may be
configured to create that if it doesn't exist yet), and a simple
interface to the 'patch' tool. If we create a new 'Patch' type, it may
include metadata that help Roundup to figure out what repo / branch URL
to use to fetch the code from against which the patch is to be applied
against.
D2: While D1 is about applying patches, this may not be enough to figure
out whether the patch is good. The user may also want to attempt to
build the code (and even run tests). While I believe this to be outside
the realm of a bug / patch tracker, I can see good use in integration
with external build tools. In fact, it is a u
Re: [Python-Dev] Google Wave as a developer communication tool
On Thu, Jun 04, 2009 at 01:15:16PM -0400, Terry Reedy wrote: > marked as having new content. At your leisure, you open it (or perhaps > you have marked it 'download updates in background'). That that takes > longer with a slow connection is no different than with other text > streams. If you type in a comment, even 1200 baud upsteam is fast > enough. Where do you get 'punitive' in this? I visited my parents at Christmas. They live in a rural area, don't have great phone lines, and my dad's computer ends up getting about a 21Kb modem connection (not even 38.4!). I discovered that great swaths of the Web 2.0 world were effectively unusable for me; after login, the Twitter home page took 3 minutes to display. Logging into my bank was a tortuous 10 minute process. I never succeeded in getting into Facebook at all. Many pages don't render until they're completely downloaded. The little AJAXy update that adds an extra second or two on a fast connection becomes shockingly painful on a slow connection. The JS files are organized Unless Google Wave is written with attention to such slow connections (which I doubt -- such users are pretty rare, after all), I would assume it will be unusable. The bandwidth is enough for a character by character stream, but web browser apps impose many overheads atop that stream. --amk ___ 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] Google Wave as a developer communication tool
Google Wave is also still in tightly restricted beta. Gmail went through a long invite-only period. Until we have an idea of how long it will be until basically all python developers who want a Wave account can get one, it doesn't make sense to talk about using it for python development, IMO. -jake ___ 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] Google Wave as a developer communication tool
Aahz writes: > It sounds like Wave requires a high-powered browser, similar to Google > Maps. That makes me -1 because I want to continue using Lynx. I'm not sure - I think you can implement your own choices at different points. What's interesting to me so far is less the current UI/flashiness (drag 'n drop photos, real-time keystrokes, etc...) they are showing, than the openness of the protocol and implementation, opening the door to all sorts of potential uses and/or integrations with existing systems. Other than convenience for interactive use, and as a reference client, I'm not sure how critical a browser really is to the system. Fundamentally, wave seems to be rich, versioned (or at least time tracked), content management system with well defined server to server and server to client communication protocols, including conflict resolution. They even brought up VCS-like concepts (currently unimplemented) of having waves branch and evolve independently, fold changes back into a parent wave and then re-distribute down to the other children over time, which points to a reasonable central data structure. For example, if you jump to about 1:08:13 in the presentation you can see a more textual display implemented by an independent wave server/client - almost newsreader like. I presume such a client has to make similar decisions as to display of non-textual data as Lynx has to with the web. Or if you embed the wave in a web page, it could still be handled by text browsers (the blog integration at 20:43 for example) or perhaps with RSS. Server robots could help too - a robot participating in the wave could produce a more text-friendly reader version, perhaps published elsewhere on the web or in a different system. They demoed, for example, integrating with Google Code's bug tracking back end at 1:02:30 where comments in the wave were reflected into the bug comments (though the reverse direction wasn't implemented yet), or even the twitter integration at 57:53. -- David ___ 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] Serious regression in doctest in Py3.1rc1
http://bugs.python.org/issue6195 (with patch) On Wed, Jun 3, 2009 at 8:26 AM, Amaury Forgeot d'Arc wrote: > Hello, > > 2009/6/3 Stefan Behnel : >> Hi, >> >> I can't currently file a bug report on this, but I was told by Lisandro >> Dalcín that there is a serious problem with the doctest module in Py3.1rc1. >> In Cython, we use doctests to test the compiler in that we compile a >> Python/Cython module with doctests into a C module and then run doctest on >> the imported extension module. >> >> >From the error report it seems to me that doctest is now trying to read the >> module itself through linecache for some reason, which horribly fails for a >> binary module. >> >> Could someone please look into this? I'll open up a bug report tomorrow >> unless someone beats me to it. > > I don't have the time either, but the problem looks very similar to > http://bugs.python.org/issue4050 > The fix was to replace: > file = inspect.getsourcefile(object) or inspect.getfile(object) > was replaced with > file = inspect.getsourcefile(object) > > -- > Amaury Forgeot d'Arc > ___ > 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/dalcinl%40gmail.com > -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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] Roundup improvements use-cases
Stefan Seefeld writes: > While in theory [implementing a hook for closing bugs via VCS commit > messages] is all up for customization, I think it would be nice to set > up some conventions to guide users in how to do this (the 'token > grammar', mostly), just for convenience. A reference implementation that I think works quite well is the system used by the Debian project for detecting, from the changelog entries, which bugs to close when a particular release of a package is uploaded. http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-bugfix> Note also that this system doesn't just close the bug, it makrs it as fixed in a specific version of the package: the package version that included the close request in its changelog entry. It would be valuable if analogous behaviour could occur with Roundup, which requires allowing for it in the specification of the workflow. > This is a very interesting use case, driving us at the core of the > 'VCS integration'. We need to customize a schema to provide a notion > for 'repository' and 'branch', and also for 'patch'. Then we need to > somehow endow the patch type with knowledge of what it means to be > 'applied' to a branch, etc. (more on this below). All this would apply to the above workflow for “mark that bug as fixed by this specific branch”. (good sigmonster, have a cookie) -- \ “That's all very good in practice, but how does it work in | `\ *theory*?” —anonymous | _o__) | Ben Finney ___ 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] Roundup improvements use-cases
Stefan Seefeld writes:
> This set of use cases ('C') is what I have most difficulties with. It
> clearly is about 'VCS <-> Roundup integration', but it's in the other
> direction. And thus, this doesn't seem to concern Roundup itself, or
> does it ? Presumably, everything needed already exists. We now have an
> XMLRPC interface, so it is possible to write (remote) Roundup clients. I
> think writing such a 'Roundup client library' would be useful, but I
> think somewhat out of scope with respect to this GSoC project.
Note that there are several attempts in the wild at “BTS database as
versioned data in the VCS repository”, allowing the tightest
integration between the two and ensuring that VCS commits and BTS
updates are inherently tied to each other.
An article at Linux Weekly News http://lwn.net/Articles/281849/>
describes these systems. It might be instructive for those looking to
tightly integrate VCS and BTS to seek inspiration from these designs.
--
\ “The userbase for strong cryptography declines by half with |
`\ every additional keystroke or mouseclick required to make it |
_o__) work.” —Carl Ellison |
Ben Finney
___
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
