Re: [python-committers] improving our code quality [my summary of the "PQM" thread]
Jesse> Would it be possible / make sense to tie this more tightly to the Jesse> code review application guido put together? Drifting a bit far afield, but are we using Guido's tool (Rietveld)? If not, maybe the BDFL should put his BBDF (Big Benevolent Dictator's Foot) down and decree no more releases until it's part of the Python development tool chain. <0.5 wink> Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] improving our code quality [my summary of the "PQM" thread]
Fredrik> I would still like to hear from someone who's used both Fredrik> Rietveld and the older (and from what I can tell more widely Fredrik> used) Review Board. Good point. A bit to Python-focused in my note. Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] broken arm
Jesus> I just have broken my left arm last saturday (sliding swimming Jesus> pools are dangerous :)). I will be barely online for the next 6 Jesus> weeks. I will try to keep email backlog under control, but Jesus> single-hand typing is a nightmare. Jesus> I will be "slow" but available, anyway. Ouch... Dragon NaturallySpeaking, perhaps? http://www.nuance.com/naturallyspeaking/ Hope you feel better soon. Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] 3.0rc2 schedule
Martin> I propose that the release of 3.0rc2 is deferred until all Martin> release blockers have been resolved (either by actually fixing Martin> them, or by carefully considering that they shouldn't actually Martin> block the release). +1. Even though it's not 3.0-specific, I think the highest priority problem which should be resolved ASAP is the 403 Forbidden which essentially all doc pages return right now. Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] RELEASED Python 3.0 final
Ronald> * An Intel Mac running 10.4.x Brett> That requirement right there take me out for being able to to do Brett> the binary. Jesse> I could do binaries for 10.5 and forward. I've got a few macs at Jesse> my disposal I thought the PSF had a 10.4 XServe box. Is it gone? Was it a G4 perhaps? Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] RELEASED Python 3.0 final
Skip> I thought the PSF had a 10.4 XServe box. Is it gone? Martin> Yes, it's broken. Skip> Was it a G4 perhaps? Martin> I've now turned it off, so I can't find out anymore. Jesse> My 10.5 buildbot should still be active at very least. I was thinking that maybe it could serve as a machine to build Mac installers. Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Luke Kenneth
Guido> It'll be difficult -- he's already trying to make us feel guilty Guido> for not supporting free software enough. Arguing with him is like Guido> getting involved with quicksand, so let's just all ignore him, Guido> and it will tide over. It's open source. If he's so all-fired determined the current developers are doing everything wrong he's obviously welcome to fork the project. LPython anyone? Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] I've got a surprise for you!
Trent> Ten months, seven trips to MSU, six blown fuses and about Trent> $60,000 later, I'm proud to introduce you all to Snakebite: Trent> The Open Network! A network of around 37-ish servers of all Trent> different shapes and sizes, spread over three sites, Trent> specifically geared towards the needs of open source projects Trent> like Python. Wow! A great resource no doubt. I do notice that there is no Apple hardware or Mac OS X running on anything. Any chance of adding a XServe or something? -- Skip Montanaro - [email protected] - http://smontanaro.dyndns.org/ ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Survey about DVCSs compared to svn
Martin> My own personal experience tells me git and bzr are much worse Martin> than subversion (each in different respects). Perhaps you could relay these shortcomings to Brett or edit them into the PEP directly. Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Python 2.6.4?
Antoine> Perhaps we should leave a one-week delay between rc and final Antoine> next time, so that this kind of late-minute issues have an Antoine> opportunity to be discovered ? Yeah, I was a little surprised the final release followed rc1 so quickly. We were working through some problems on Solaris at work (I submitted several bugs as a result), but couldn't pump them out fast enough to get them seen before the final release went out. Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Python 2.6.4?
Barry> But no release blockers in that set of bugs? I've no idea. By the time I could submit the reports the final release was out so I didn't even consider whether they would have been release blockers or not. Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] On track for Python 2.6.4 final this Sunday?
>> We don't need to wait too long for 2.6.5 though. A few months would be >> appropriate. MAL> Would it be reasonable to shorten that period, if the fix for the MAL> mentioned problem gets ready for prime time earlier ? I think it would be worthwhile to prioritize all outstanding bugs which have been mentioned in the context of 2.6.[345] and run a bug day with the top priority being to fix those bugs. If that task is completed, then move onto other stuff. Once those primary bugs are tackled schedule a 2.6.5 release. Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Commit access for David Malcolm
Jeffrey> David Malcolm is the Fedora maintainer for the Python package Jeffrey> and has written a gdb plugin to replace and dramatically Jeffrey> improve our old Misc/gdbinit file using the new python Jeffrey> scripting support in gdb-7 I'm fine with adding such a plugin as long is Misc/gdbinit isn't replaced. Not everyone runs gdb 7. Also, since it's support code and not part of Python proper adding such a plugin before it's nice and stable is no big deal. (Maybe it belongs in Tools/gdb, not Misc?) Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PEP checkin process
>>>> Just run 'make' in the peps checkout directory. >>> >>> That doesn't work for me by default since I don't have python2.5 >>> installed (although it does turn out it can be made to work by >>> overriding PYTHON as Benjamin suggests). Not only that, but the >>> makefile builds all the PEPs when I generally only care about the PEP >>> I'm working on and PEP 0. >> >> The "make" should include dependency information to only rebuild the >> changed documents. :-?. Martin> And indeed, it does. Following up on Martin's comment, note that you are not required to make all PEP outputs. Just make the one(s) you care about at the moment: % make pep-0008.html pep-0008.txt (text/plain) -> pep-0008.html Skip ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] changing the python version on the 2.7 branch
On Wed, Apr 1, 2015 at 2:05 PM, Matthias Klose wrote: > Suggesting to push the following patch to the 2.7 branch. LGTM. I actively use 2.7 at work so should be able to at least put it through its normal paces. Will be interesting to see if any of our internal software (which is generally fairly agnostic about Python) cringes at the site of a two-digit micro. We do have an internal make wrapper written in Python as well. Developers are expected to know every arcane nook and cranny of C++, but can't possibly master authorship of Makefiles. :rollseyes: Skip ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Weak SSH keys
On Tue, Jun 2, 2015 at 10:19 AM, A.M. Kuchling wrote: > Should we check everyone's SSH > keys? > Makes sense to me. Probably worth doing for all the *.python.org hosts, not just the commit boxes like hg.p.o. Skip ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Weak SSH keys
On Tue, Jun 2, 2015 at 11:28 AM, Benjamin Peterson wrote: > Also, everyone should use ed25519 keys now. :) For people like myself who are behind the curve, can someone point me to a primer on generating new, more secure SSH keys? Skip ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Weak SSH keys
On Wed, Jun 3, 2015 at 9:59 AM, Benjamin Peterson wrote: > I'm not sure how the order is determined; it's probably arbitrary for OpenSSH. Certainly you wouldn't want it to offer a key generated by a system it knows to be weaker before one generated by a known stronger system? I would hope the OpenSSH authors had some idea which were relatively stronger, so it could offer them first. Skip ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
