Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Perhaps there are two separable issues. Many of us see it as extremely important that some IDLE be part of the standard Python distribution ("batteries included"), for the reasons that several people have given. However, there is merit to the suggestion to have an active separate development, with the understanding that periodically this separate development is a candidate for inclusion in the standard distribution, replacing whatever IDLE had been there. In the 2009 Google Summer of Code I was the mentor for a Brazilian student, Guilherme Polo, who completed and extended important improvements to IDLE made during the previous year by David Scherer. Given the somewhat official nature of this work, I assumed that these needed improvements would make it into the standard distribution, but as far as I know that hasn't happened. It would seem that if even this "sponsored" project didn't impact the standard Python distribution, something is broken in the procedures, and probably what is needed is, as Guido says, that someone be given the authority to get improvements to IDLE into the standard distribution. Making a significant change to the update procedures is clearly needed. Even if this needed change is made, there is also merit to Tai's suggestion of creating a separate project, to encourage developers like him to work together to improve IDLE, without having as a first priority to worry about getting it into the standard distribution, but with the clear understanding that this is the place to go for improvements to migrate into the standard distribution. Bruce Sherwood P.S. I'll add that IDLE has been EXTREMELY important for a large population of relatively casual users of Python, the thousands of science and engineering university students enrolled in the "Matter & Interactions" intro physics curriculum developed by Ruth Chabay and me ( matterandinteractions.org). A major feature of this curriculum is a serious introduction to computational modeling, in which students write short Python programs to model physical systems. Computational modeling is now central to all of science and engineering but alas has not made its way into undergraduate curricula in an institutionalized way. A big difficulty is that students come to college knowledgeable about all aspects of computers save one: programming. So the programming environment has to be exceptionally easy to learn and use. Python itself has the necessary properties, and Python+Visual (called VPython, vpython.org) lets the students focus on the physics while VPython generates real-time navigable 3D animations of the computational models, as a side effect of the computational code. IDLE has proved to be the right editing tool for this population, as essentially nothing needs to be learned, and there is near-instantaneous edit/run transitions which encourage rapid testing. In a physics course we have to focus on strict minimalism as far as the programming is concerned. We teach a bare minimum of needed concepts; for example, we introduce while loops but not for loops. We cannot afford to teach about a professional IDE; IDLE is fine and has worked well for us. (We're currently bundling with VPython the Scherer/Polo version of IDLE, which for reasons of clarity we're calling VIDLE.) A final personal note is that while I use Eclipse for working on the Visual module, which is written in C++, I find VIDLE a delightful environment for developing Python programs for physics education.
I don't think so; instead, the perception of authority needs to be adjusted (in the specific case). Guilherme could have committed these changes, but, for whatever reason, decided not to. Nor did his direct mentor (i.e. you) tell him to commit the changes, and neither did I.
Again, Guilherme could commit his changes any time. Regards, Martin
2010/7/11 "Martin v. Löwis" <martin@v.loewis.de>:
I think Martin has always supported me in some way and I really appreciate that. But, maybe because I won commit privileges solely based on GSoC work, I felt other developers wouldn't approve my commits without previous discussion and that is the major reason for not committing most of my patches. -- -- Guilherme H. Polo Goncalves
I'm not blaming you for that; I can fully understand how you feel and how things came about. I was just refuting the claim that something was fundamentally wrong, when, among us three, there was just somebody failing to say "go ahead" (and I'd like to stress that *either* of us three could have said that). So: go ahead. I won't have the time to review your changes in detail, and nobody else will, so just put them in, and we wait for people to complain (in which case I'd hope that you would be around to respond quickly - as you did in the past). If there is also Tk patches involved, please do have them reviewed, though. Regards, Martin
On Mon, Jul 12, 2010 at 11:19 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
+1. Don't be afraid. We are quite good at pointing out mistakes after the fact :)
Just make sure to subscribe to python-checkins and keep an eye out for replies to your commits. Most post hoc review comments come in as replies to the commit notifications :) Hmm, do we mention that part of the process in the dev docs anywhere?... and it turns out we do, as Brett included it in the Intro to Development article. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 15:42, Nick Coghlan wrote:
That mailing list (python-checkins) is way too high traffic for many committers to monitor. I hope people making comments on checkins also email the committer directly. All the best, Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Tue, Jul 13, 2010 at 1:07 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Not normally, no - there's no easy way to connect a checkin message to a committer's email address, so it's usually just a matter of hitting "Reply" and sending the review comment to the list. With a new committer I'll make the effort to cc them directly in case they aren't subscribed yet, but I expect everyone else to be monitor the checkins list. If the list is too high volume, filter it down to just those issues with your checkin name in the "From" or "To" fields (your own checkin messages will have the former, while replies should have the latter, even though the email address in both cases will actually be python-checkins@python.org. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 16:52, Nick Coghlan wrote:
There's a one-to-one mapping somewhere.
Without contacting committers, rather than firing into the black depths of a high traffic list, I strongly suspect that much of the feedback is lost. All the best, Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Am 12.07.2010 23:57, schrieb Benjamin Peterson:
Probably. Also, Dirkjan is maintaining a list for the Mercurial migration. So it is probably the case that one could be constructed if desired. It's just that "we" (the people maintaining the subversion access control) don't have such a list. Regards, Martin
On Tue, Jul 13, 2010 at 00:11, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Indeed: http://hg.python.org/pymigr/file/tip/author-map?style=raw I think I took email addresses from the public key list that Martin maintains for SVN etc and then augmented that with stuff from the mailing list archives and Google. The list is by no means guaranteed to be correct and fully up-to-date, but it's complete (save for maybe new committers from the last few weeks). Cheers, Dirkjan
On 7/12/2010 5:57 PM, Benjamin Peterson wrote:
I put some effort into this a while ago and failed. Not all committers are subscribed, and for those that are we don't have a way of mapping them to names. Ideally I'd like to see a table with tracker id, username, email addresses, real name. But without a way of automatically keeping it up-to-date, I don't think it will happen. Eric.
On Tue, Jul 13, 2010 at 3:39 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
That "somewhere" isn't readily available when I hit reply to the checkin email though (for me, "somewhere" is generally my python-dev archive - I think the actual mapping file is a private one on the SVN server somewhere).
Not that I've noticed. If someone doesn't respond to a comment I've made on python-checkins I'll follow up with them directly and point out that monitoring python-checkins for responses after making a commit is an obligation of making use of commit privileges, just as much as of one as running (at least relevant parts of) the test suite before committing and then checking the buildbots to see you haven't broken anything on other platforms. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 22:52, Nick Coghlan wrote:
Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Michael
Cheers, Nick.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Tue, Jul 13, 2010 at 8:04 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Umm, yeah it is - Brett's Intro to Development *is* the documentation of the workflow procedures, and it says that committers are expected to subscribe to both python-checkins and python-committers. And, as I said, I've been working this way for years, and haven't seen any of my comments or anyone else's made on python-checkins go unaddressed (although we've occasionally had to follow up by finding the committer's email address and adding it directly, that's fairly rare). It *really* isn't very hard to ignore most of the traffic on that list and just look at your own commits (and any responses). (I don't do that myself unless I'm busy, as I quite like doing after the fact reviews of commits) Bringing the whole of python-dev into a python-checkins discussion is only necessary if there are any actual disagreements regarding a commit (99% of what we spot in post review is just typos in documentation, comments and text strings, as well as minor things like poor choices of internal variable names). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 23:48, Eric Smith wrote: traffic here. :-) Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Mon, Jul 12, 2010 at 16:42, Michael Foord <fuzzyman@voidspace.org.uk>wrote:
Or python-committers since this is discussing code already checked in and thus is somewhat committer-specific. This also has the perk of being easier to spot (don't know about the rest of you but my python-committers filter makes those emails much more obvious than python-dev traffic). -Brett
On 7/14/2010 4:21 AM, Georg Brandl wrote:
That's why I think it should go on python-dev. If the code hadn't been checked in and you were asking "what do you think of solving this by using the following code", I think you'd put it on python-dev. I'd want the discussion of an actual checkin to occur in that same venue.
I'm still +1 on the idea though, and +1 on python-committers.
That said, I'm +1 on the idea, but only +0 on python-dev. Eric.
On Wed, Jul 14, 2010 at 01:36, Eric Smith <eric@trueblade.com> wrote:
Actually, I probably wouldn't. =) When it gets to explicit code, a design decision has been made, so I do not need to worry about involving the general public in some low-level technical discussion that won't impact them.
I'd want the discussion of an actual checkin to occur in that same venue.
Right, which is why I want python-committers. Otherwise it's just a glorified commit lock when we are cutting releases.
I'm still +1 on the idea though, and +1 on python-committers.
That said, I'm +1 on the idea, but only +0 on python-dev.
+1 on python-committers, +0 on python-dev.
On Thu, Jul 15, 2010 at 5:22 AM, Brett Cannon <brett@python.org> wrote:
Yep, that's my perspective as well. If my post-commit comments are more significant than typo fixes and internal naming suggestions, I'll take them back to python-dev manually. So for me, +1 on python-committers, +0 on python-dev or the status quo. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Le lundi 12 juillet 2010 à 23:04 +0100, Michael Foord a écrit :
You don't have to receive e-mail from it. Just take a look at the archives from time to time after you have done some commits. In a threaded view, it's easy to spot the few messages which aren't commit notifications, since they are the only one not at the top-level. Regatds Antoine.
Antoine Pitrou writes:
It also is possible to arrange that the author (From field) of the commit message is the author of the commit, rather than the bot. Reply-To could be set to bot plus author. Once the Mercurial transition is done, this would be more useful as "everybody" would have an email address as part of their committer ID. I realize that there is probably good reason for the current approach (including but not limited to lack of real email addresses for some committers), but if people really find it that great an imposition to filter messages themselves with procmail or MUA features, this would make the author view of the archives useful to them. (Although that destroys threading in the summary, you still have links to followups in the message view.)
On Tue, Jul 13, 2010 at 11:05 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I was actually going to suggest something along those lines post transition, since Hg will have an email address for everyone - leave push notifications coming from the bot (so existing filters based on the bot address keep working), but include the push author in the reply-to field. Given its limited remaining lifespan, I don't see any point in messing with the current SVN setup though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
IIRC, you can’t know who pushed without kludgy hackery. Also, the one to push is not necessarily the author of the commit(s). If that was just a braino and you meant setting the committer as reply-to, it seems a good idea. Note that nothing in Mercurial forces you to have a parsable “Name <email>” user name, it’s just a good practice. Dirkjan’s mapping uses a dummy tools@python.org address for unknown IDs, which probably means the other tools he’s writing depend on an email address. That would need to be in the dev policy. Regards
On Jul 13, 2010, at 09:56 PM, Éric Araujo wrote:
Bazaar has a facility for digitally signing commits, which I always enable. While this is a local configuration, some projects I contribute to have merge hooks which check the digital signatures and refuse the push if the revisions are not signed with a known gpg key. Does Mercurial have a similar feature? If so, I would suggest that we enable that and require committers to use registered gpg keys to sign their commits. We'd always have a verifiable chain back to a responsible party, and committers would be responsible for any changes or patches they merge on behalf of others. IME the overhead is pretty trivial, but then I'm quite comfortable with gpg concepts and tools. -Barry
This is getting a little off-topic, but let me just respond to this... On Tue, Jul 13, 2010 at 22:10, Barry Warsaw <barry@python.org> wrote:
I wrote something on Stack Overflow about this today, which I reproduce here: - You could verify that whoever is pushing the cset is also the committer (by matching http or ssh authentication). This is somewhat limiting because it can be useful when people push other developer's changesets. - You could use the pgp extension (from hgext) to explicitly sign changesets after committing, but it's kind of a drag if you want to do it for every changeset. In Mercurial, we only do this for releases. - http://bitbucket.org/mg/commitsigs is another extension, which takes a different tack to signing (I believe it doesn't sign the commit metadata, only the file tree, which lets it sign before the commit is finished, meaning it doesn't take up an extra cset). - Mozilla uses a pushlog which just tracks who pushed what. This lets you look in the commit history on the server (but only there) to see who pushed what group of changesets, giving you a better paper trail than you normally get. This can also be provided by changegroup notifications, if you include the guy who did the push in the email (this is what Python will do once their conversion is done). Note that, if you're going to require that each cset is signed, each non-committer contributor also has to have this facility, which IMO raises the bar significantly. I think I added the pushing user to the commit mails to provide just this kind of paper trail. Given the tamper-proofness of the SHA1 changeset ID's (and yes, hg will move to some newer hash algorithm at some point before SHA1 becomes too easy to crack), I don't think signing each cset adds much value. Cheers, Dirkjan
Dirkjan Ochtman <dirkjan@ochtman.nl> writes:
It does signs the complete changeset hash including the commit message, username, etc, and it does this without creating an extra changeset. This is done by computing what the changeset hash would be without an embedded signature. This hash is then signed and embedded in the changeset. This is similar to how TCP checksums are computed. This increases the size of each changeset by about 2 KB of data which cannot be compressed -- this adds up over time and I would only advice people to use the extension if they are very paranoid or have special legal requirements. -- Martin Geisler Mercurial links: http://mercurial.ch/
Guilherme Polo wrote:
FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's project of the same name, in a sense). The idea was to have a fork of IDLE with new features which need to be tried out by "beta testers" to iron out all of the glitches before making it into the main version, like IDLE-fork back in the beginning of the decade. However I have utterly failed in promoting this project and getting "beta testers" on board, at least partially due to the lack of interest from the community (and admittedly my lack of PR skills). - Tal Einat
I think such a thing must inherently fail - precisely for these reasons. It's much better to release proposed new features along with Python, and wait for feedback. Users won't start trying things out until after the release. This is a general problem, and lead Barry Warsaw to believe that "release candidates" are an utter waste of time. Regards, Martin
On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
That's debatable, and I disagree. IDLE-fork was a great success, for example. If IDLE actually had many users today, certainly some of them would be interested in trying out a version with usability fixes and improvements. Waiting for a new release of Python can take over a year. Furthermore, backwards compatibility issues and support by third party libraries can delay migration to a newer version of Python even further. - Tal Einat
On Mon, Jul 12 2010, Tal Einat wrote:
We had major contributions from David Scherer, Guido, and Stephen Gava. But a key factor in its success was that I took it upon myself to keep IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent merges. Once the project was completed, I arranged with SF to move the IDLEfork repository, including history, back into Python. This was not done with Noam's branch. As a result, it gradually drifted to the point where it became essentially unmergable. Once we switch to Hg, we should be able to use distributed vc and topic branches to facilitate community participation without the need for a separate project. None of this is automatic, of course, it requires diligence, planning, and clean topic patches.
There's no reason why we couldn't release interim IDLE testing packages from somewhere other than python.org (for those that don't want to track IDLE's Hg repo). To do this successfully, we would need to avoid using new Python features being introduced during that development cycle, i.e. IDLE would be compatible with the previous Python release. -- KBK
On Mon, Jul 12, 2010 at 6:11 PM, Kurt B. Kaiser wrote:
Actually, Noam's branch was pretty much merged back as is -- that's where IDLE's auto-completion functionality came from. The later changes he made on that branch were never merged, as you mentioned, because Noam never bothered. I have been maintaining my own fork of IDLE for several years and manually keeping it in sync with IDLE (this was simple). The difference is that there was no single major new feature I was working on, such as the addition of a sub-process in IDLE-fork or Noam's addition of auto-completion. I was mostly making relatively minor fixes and changes which were not interrelated. I saw no reason to have them all merged back at once, so I posted patches as soon as I felt they were ready, and did the best I could to get them accepted. I eventually gave up on this process because every patch took far too long to be addressed and finally accepted or rejected, and I realized that most of the work I had done would never be merged back into the mainstream version of IDLE.
On Mon, Jul 12 2010, Tal Einat wrote:
There were several contributing factors. I decided to stop committing new features in 2.7 and focus on bugs for several reasons. First, IDLE3 needed work to get it running smoothly. Second, committing, forward porting and running the (manual) functional tests on a bunch of small features was a bit of a pain. Third, leaving the new features to IDLE3 was a draw to get people to use the new version. Then, about two years ago, I got buried with PSF/PyCon issues. If you'll look back in the IDLE NEWS, you'll see I was giving your patches quite a bit of attention. So never say never. -- KBK
I don't think so; instead, the perception of authority needs to be adjusted (in the specific case). Guilherme could have committed these changes, but, for whatever reason, decided not to. Nor did his direct mentor (i.e. you) tell him to commit the changes, and neither did I.
Again, Guilherme could commit his changes any time. Regards, Martin
2010/7/11 "Martin v. Löwis" <martin@v.loewis.de>:
I think Martin has always supported me in some way and I really appreciate that. But, maybe because I won commit privileges solely based on GSoC work, I felt other developers wouldn't approve my commits without previous discussion and that is the major reason for not committing most of my patches. -- -- Guilherme H. Polo Goncalves
I'm not blaming you for that; I can fully understand how you feel and how things came about. I was just refuting the claim that something was fundamentally wrong, when, among us three, there was just somebody failing to say "go ahead" (and I'd like to stress that *either* of us three could have said that). So: go ahead. I won't have the time to review your changes in detail, and nobody else will, so just put them in, and we wait for people to complain (in which case I'd hope that you would be around to respond quickly - as you did in the past). If there is also Tk patches involved, please do have them reviewed, though. Regards, Martin
On Mon, Jul 12, 2010 at 11:19 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
+1. Don't be afraid. We are quite good at pointing out mistakes after the fact :)
Just make sure to subscribe to python-checkins and keep an eye out for replies to your commits. Most post hoc review comments come in as replies to the commit notifications :) Hmm, do we mention that part of the process in the dev docs anywhere?... and it turns out we do, as Brett included it in the Intro to Development article. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 15:42, Nick Coghlan wrote:
That mailing list (python-checkins) is way too high traffic for many committers to monitor. I hope people making comments on checkins also email the committer directly. All the best, Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Tue, Jul 13, 2010 at 1:07 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Not normally, no - there's no easy way to connect a checkin message to a committer's email address, so it's usually just a matter of hitting "Reply" and sending the review comment to the list. With a new committer I'll make the effort to cc them directly in case they aren't subscribed yet, but I expect everyone else to be monitor the checkins list. If the list is too high volume, filter it down to just those issues with your checkin name in the "From" or "To" fields (your own checkin messages will have the former, while replies should have the latter, even though the email address in both cases will actually be python-checkins@python.org. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 16:52, Nick Coghlan wrote:
There's a one-to-one mapping somewhere.
Without contacting committers, rather than firing into the black depths of a high traffic list, I strongly suspect that much of the feedback is lost. All the best, Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Am 12.07.2010 23:57, schrieb Benjamin Peterson:
Probably. Also, Dirkjan is maintaining a list for the Mercurial migration. So it is probably the case that one could be constructed if desired. It's just that "we" (the people maintaining the subversion access control) don't have such a list. Regards, Martin
On Tue, Jul 13, 2010 at 00:11, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Indeed: http://hg.python.org/pymigr/file/tip/author-map?style=raw I think I took email addresses from the public key list that Martin maintains for SVN etc and then augmented that with stuff from the mailing list archives and Google. The list is by no means guaranteed to be correct and fully up-to-date, but it's complete (save for maybe new committers from the last few weeks). Cheers, Dirkjan
On 7/12/2010 5:57 PM, Benjamin Peterson wrote:
I put some effort into this a while ago and failed. Not all committers are subscribed, and for those that are we don't have a way of mapping them to names. Ideally I'd like to see a table with tracker id, username, email addresses, real name. But without a way of automatically keeping it up-to-date, I don't think it will happen. Eric.
On Tue, Jul 13, 2010 at 3:39 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
That "somewhere" isn't readily available when I hit reply to the checkin email though (for me, "somewhere" is generally my python-dev archive - I think the actual mapping file is a private one on the SVN server somewhere).
Not that I've noticed. If someone doesn't respond to a comment I've made on python-checkins I'll follow up with them directly and point out that monitoring python-checkins for responses after making a commit is an obligation of making use of commit privileges, just as much as of one as running (at least relevant parts of) the test suite before committing and then checking the buildbots to see you haven't broken anything on other platforms. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 22:52, Nick Coghlan wrote:
Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Michael
Cheers, Nick.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Tue, Jul 13, 2010 at 8:04 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Umm, yeah it is - Brett's Intro to Development *is* the documentation of the workflow procedures, and it says that committers are expected to subscribe to both python-checkins and python-committers. And, as I said, I've been working this way for years, and haven't seen any of my comments or anyone else's made on python-checkins go unaddressed (although we've occasionally had to follow up by finding the committer's email address and adding it directly, that's fairly rare). It *really* isn't very hard to ignore most of the traffic on that list and just look at your own commits (and any responses). (I don't do that myself unless I'm busy, as I quite like doing after the fact reviews of commits) Bringing the whole of python-dev into a python-checkins discussion is only necessary if there are any actual disagreements regarding a commit (99% of what we spot in post review is just typos in documentation, comments and text strings, as well as minor things like poor choices of internal variable names). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 23:48, Eric Smith wrote: traffic here. :-) Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Mon, Jul 12, 2010 at 16:42, Michael Foord <fuzzyman@voidspace.org.uk>wrote:
Or python-committers since this is discussing code already checked in and thus is somewhat committer-specific. This also has the perk of being easier to spot (don't know about the rest of you but my python-committers filter makes those emails much more obvious than python-dev traffic). -Brett
On 7/14/2010 4:21 AM, Georg Brandl wrote:
That's why I think it should go on python-dev. If the code hadn't been checked in and you were asking "what do you think of solving this by using the following code", I think you'd put it on python-dev. I'd want the discussion of an actual checkin to occur in that same venue.
I'm still +1 on the idea though, and +1 on python-committers.
That said, I'm +1 on the idea, but only +0 on python-dev. Eric.
On Wed, Jul 14, 2010 at 01:36, Eric Smith <eric@trueblade.com> wrote:
Actually, I probably wouldn't. =) When it gets to explicit code, a design decision has been made, so I do not need to worry about involving the general public in some low-level technical discussion that won't impact them.
I'd want the discussion of an actual checkin to occur in that same venue.
Right, which is why I want python-committers. Otherwise it's just a glorified commit lock when we are cutting releases.
I'm still +1 on the idea though, and +1 on python-committers.
That said, I'm +1 on the idea, but only +0 on python-dev.
+1 on python-committers, +0 on python-dev.
On Thu, Jul 15, 2010 at 5:22 AM, Brett Cannon <brett@python.org> wrote:
Yep, that's my perspective as well. If my post-commit comments are more significant than typo fixes and internal naming suggestions, I'll take them back to python-dev manually. So for me, +1 on python-committers, +0 on python-dev or the status quo. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Am 13.07.2010 00:48, schrieb Eric Smith:
Somebody correct me if I'm wrong: I think we had this, at one point, and then switched it to the status quo. I can surely try switching it back if desired. Regards, Martin
Le lundi 12 juillet 2010 à 23:04 +0100, Michael Foord a écrit :
You don't have to receive e-mail from it. Just take a look at the archives from time to time after you have done some commits. In a threaded view, it's easy to spot the few messages which aren't commit notifications, since they are the only one not at the top-level. Regatds Antoine.
Antoine Pitrou writes:
It also is possible to arrange that the author (From field) of the commit message is the author of the commit, rather than the bot. Reply-To could be set to bot plus author. Once the Mercurial transition is done, this would be more useful as "everybody" would have an email address as part of their committer ID. I realize that there is probably good reason for the current approach (including but not limited to lack of real email addresses for some committers), but if people really find it that great an imposition to filter messages themselves with procmail or MUA features, this would make the author view of the archives useful to them. (Although that destroys threading in the summary, you still have links to followups in the message view.)
On Tue, Jul 13, 2010 at 11:05 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I was actually going to suggest something along those lines post transition, since Hg will have an email address for everyone - leave push notifications coming from the bot (so existing filters based on the bot address keep working), but include the push author in the reply-to field. Given its limited remaining lifespan, I don't see any point in messing with the current SVN setup though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
IIRC, you can’t know who pushed without kludgy hackery. Also, the one to push is not necessarily the author of the commit(s). If that was just a braino and you meant setting the committer as reply-to, it seems a good idea. Note that nothing in Mercurial forces you to have a parsable “Name <email>” user name, it’s just a good practice. Dirkjan’s mapping uses a dummy tools@python.org address for unknown IDs, which probably means the other tools he’s writing depend on an email address. That would need to be in the dev policy. Regards
On Jul 13, 2010, at 09:56 PM, Éric Araujo wrote:
Bazaar has a facility for digitally signing commits, which I always enable. While this is a local configuration, some projects I contribute to have merge hooks which check the digital signatures and refuse the push if the revisions are not signed with a known gpg key. Does Mercurial have a similar feature? If so, I would suggest that we enable that and require committers to use registered gpg keys to sign their commits. We'd always have a verifiable chain back to a responsible party, and committers would be responsible for any changes or patches they merge on behalf of others. IME the overhead is pretty trivial, but then I'm quite comfortable with gpg concepts and tools. -Barry
This is getting a little off-topic, but let me just respond to this... On Tue, Jul 13, 2010 at 22:10, Barry Warsaw <barry@python.org> wrote:
I wrote something on Stack Overflow about this today, which I reproduce here: - You could verify that whoever is pushing the cset is also the committer (by matching http or ssh authentication). This is somewhat limiting because it can be useful when people push other developer's changesets. - You could use the pgp extension (from hgext) to explicitly sign changesets after committing, but it's kind of a drag if you want to do it for every changeset. In Mercurial, we only do this for releases. - http://bitbucket.org/mg/commitsigs is another extension, which takes a different tack to signing (I believe it doesn't sign the commit metadata, only the file tree, which lets it sign before the commit is finished, meaning it doesn't take up an extra cset). - Mozilla uses a pushlog which just tracks who pushed what. This lets you look in the commit history on the server (but only there) to see who pushed what group of changesets, giving you a better paper trail than you normally get. This can also be provided by changegroup notifications, if you include the guy who did the push in the email (this is what Python will do once their conversion is done). Note that, if you're going to require that each cset is signed, each non-committer contributor also has to have this facility, which IMO raises the bar significantly. I think I added the pushing user to the commit mails to provide just this kind of paper trail. Given the tamper-proofness of the SHA1 changeset ID's (and yes, hg will move to some newer hash algorithm at some point before SHA1 becomes too easy to crack), I don't think signing each cset adds much value. Cheers, Dirkjan
Dirkjan Ochtman <dirkjan@ochtman.nl> writes:
It does signs the complete changeset hash including the commit message, username, etc, and it does this without creating an extra changeset. This is done by computing what the changeset hash would be without an embedded signature. This hash is then signed and embedded in the changeset. This is similar to how TCP checksums are computed. This increases the size of each changeset by about 2 KB of data which cannot be compressed -- this adds up over time and I would only advice people to use the extension if they are very paranoid or have special legal requirements. -- Martin Geisler Mercurial links: http://mercurial.ch/
Guilherme Polo wrote:
FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's project of the same name, in a sense). The idea was to have a fork of IDLE with new features which need to be tried out by "beta testers" to iron out all of the glitches before making it into the main version, like IDLE-fork back in the beginning of the decade. However I have utterly failed in promoting this project and getting "beta testers" on board, at least partially due to the lack of interest from the community (and admittedly my lack of PR skills). - Tal Einat
I think such a thing must inherently fail - precisely for these reasons. It's much better to release proposed new features along with Python, and wait for feedback. Users won't start trying things out until after the release. This is a general problem, and lead Barry Warsaw to believe that "release candidates" are an utter waste of time. Regards, Martin
On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
That's debatable, and I disagree. IDLE-fork was a great success, for example. If IDLE actually had many users today, certainly some of them would be interested in trying out a version with usability fixes and improvements. Waiting for a new release of Python can take over a year. Furthermore, backwards compatibility issues and support by third party libraries can delay migration to a newer version of Python even further. - Tal Einat
On Mon, Jul 12 2010, Tal Einat wrote:
We had major contributions from David Scherer, Guido, and Stephen Gava. But a key factor in its success was that I took it upon myself to keep IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent merges. Once the project was completed, I arranged with SF to move the IDLEfork repository, including history, back into Python. This was not done with Noam's branch. As a result, it gradually drifted to the point where it became essentially unmergable. Once we switch to Hg, we should be able to use distributed vc and topic branches to facilitate community participation without the need for a separate project. None of this is automatic, of course, it requires diligence, planning, and clean topic patches.
There's no reason why we couldn't release interim IDLE testing packages from somewhere other than python.org (for those that don't want to track IDLE's Hg repo). To do this successfully, we would need to avoid using new Python features being introduced during that development cycle, i.e. IDLE would be compatible with the previous Python release. -- KBK
On Mon, Jul 12, 2010 at 6:11 PM, Kurt B. Kaiser wrote:
Actually, Noam's branch was pretty much merged back as is -- that's where IDLE's auto-completion functionality came from. The later changes he made on that branch were never merged, as you mentioned, because Noam never bothered. I have been maintaining my own fork of IDLE for several years and manually keeping it in sync with IDLE (this was simple). The difference is that there was no single major new feature I was working on, such as the addition of a sub-process in IDLE-fork or Noam's addition of auto-completion. I was mostly making relatively minor fixes and changes which were not interrelated. I saw no reason to have them all merged back at once, so I posted patches as soon as I felt they were ready, and did the best I could to get them accepted. I eventually gave up on this process because every patch took far too long to be addressed and finally accepted or rejected, and I realized that most of the work I had done would never be merged back into the mainstream version of IDLE.
On Mon, Jul 12 2010, Tal Einat wrote:
There were several contributing factors. I decided to stop committing new features in 2.7 and focus on bugs for several reasons. First, IDLE3 needed work to get it running smoothly. Second, committing, forward porting and running the (manual) functional tests on a bunch of small features was a bit of a pain. Third, leaving the new features to IDLE3 was a draw to get people to use the new version. Then, about two years ago, I got buried with PSF/PyCon issues. If you'll look back in the IDLE NEWS, you'll see I was giving your patches quite a bit of attention. So never say never. -- KBK
participants (18)
-
"Martin v. Löwis" -
anatoly techtonik -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Bruce Sherwood -
Dirkjan Ochtman -
Eric Smith -
Georg Brandl -
Guilherme Polo -
Kurt B. Kaiser -
Martin Geisler -
Michael Foord -
Nick Coghlan -
Stephen J. Turnbull -
Tal Einat -
Éric Araujo