2010/12/5 "Martin v. Löwis" :
>> I wonder if it's still necessary to provide .tar.bz2 and .tgz source
>> tarballs. If anything, it would be nice to provide .tar.xz in addition
>> to .tar.bz2, which has a nicer compression ratio:
>
> Looking at download statistics, for the 2.7 release, in July, we
2010/12/5 Fred Drake :
> On Sun, Dec 5, 2010 at 12:02 PM, Fredrik Lundh wrote:
>> (btw, someone mentioned bandwidth -- are we paying for bandwidth? what
>> fraction of the python.org traffic is downloads?)
>
> Even if the PSF isn't paying for bandwidth (and I don'
2010/12/5 Georg Brandl :
> Hi,
>
> I wonder if it's still necessary to provide .tar.bz2 and .tgz source
> tarballs. If anything, it would be nice to provide .tar.xz in addition
> to .tar.bz2, which has a nicer compression ratio:
>
> .tgz - 13 MB
> .tar.bz2 - 11 MB
> .tar.xz - 8.6 MB
tgz (and
On Mon, Nov 8, 2010 at 11:03 PM, "Martin v. Löwis" wrote:
> Am 08.11.2010 14:19, schrieb Fredrik Lundh:
>> On Mon, Nov 8, 2010 at 2:17 PM, Antoine Pitrou wrote:
>>> Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
>>>>
>>>>
On Mon, Nov 8, 2010 at 2:17 PM, Antoine Pitrou wrote:
> Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
>>
>> One would have thought that "test cases" referred to test cases, not
>> strings in non-test code, and that the "the stdlib is already
On Mon, Nov 8, 2010 at 1:59 PM, Nick Coghlan wrote:
> On Mon, Nov 8, 2010 at 10:55 PM, Michael Foord
> wrote:
>> On 08/11/2010 12:53, Nick Coghlan wrote:
>>>
>>> [snip...]
>>> Non-breaking spaces are legal in utf-8 encoded Python source files.
>>> While including them accidentally is less than i
2010/11/8 Senthil Kumaran :
> On Mon, Nov 08, 2010 at 11:55:39AM +0100, Łukasz Langa wrote:
>> Even if that commit hook prevents a single wrong commit a year, it's
>> worth it. As unpaid volunteers, we don't have time for hunting the
>> same mistakes twice.
>
> For common mistakes, there are commit
On Tue, Mar 2, 2010 at 5:12 PM, Steve Holden wrote:
> Antoine Pitrou wrote:
>> Le Tue, 02 Mar 2010 10:29:13 -0500,
>> Steve Holden a écrit :
>>> IMHO we got in this mess because we didn't have sufficient involvement
>>> from Windows platform users during the DVCS evaluation - people saw
>>> that
quo" and we move on.
No one is suggesting we accept *less* functionality than subversion: in fact
we're looking at these for *more* functionality.
On Feb 27, 2009 7:04pm, Fredrik Lundh wrote: > > No
need for a long answe...
> On Feb 27, 2009 9:24 PM, "Brett Cannon" br.
What's Hg:s story on Svn integration? To what extent can you use it with a
Svn master repo?
(Btw, I would have said that Git is probably the one that's moving the
fastest right now, and where the most interesting work is being done - but
their Windows story is a tragedy (at least last time I check
is subversion. If you hate DVCes, you mark it
as "same/worse than the status quo" and we move on.
No one is suggesting we accept *less* functionality than subversion: in fact
we're looking at these for *more* functionality.
On Feb 27, 2009 7:04pm, Fredrik Lundh wrote: &g
On the other hand, given how quickly things move in the VC space, we might
as well end up in a situation where we don't need to do anything...
On Feb 27, 2009 11:47 PM, "Georg Brandl" wrote:
Martin v. Löwis schrieb:
>> Could you clarify for me: how binding will your PEP be? ie, will it >> be
tch? At least give me the chance to make a
decision on whether I think it is reasonable to switch and what to switch
to. And then we can have a reasonable conversation where I update the PEP to
address any questions that come up.
-Brett
On Fri, Feb 27, 2009 at 02:59, Fredrik Lundh
On Fri, Feb 27, 2009 at 4:21 AM, Brett Cannon wrote:
>> Right, which is what I was describing... you copy your local trunk
>> copy and then switch that copy to the new branch. If you use cp -al
>> for this, that's a very fast operation on Unixes and avoids
>> most of the network traffic.
>
> What
On Thu, Feb 26, 2009 at 4:15 PM, Fredrik Lundh wrote:
> Better, worse, or equal in what sense? Obviously, *all* of them are
> better in certain senses (patch-oriented instead of revision-oriented
> approach, higher (?) development velocity
to clarify: I meant tool development - espec
Better, worse, or equal in what sense? Obviously, *all* of them are
better in certain senses (patch-oriented instead of revision-oriented
approach, higher (?) development velocity, and not to mention the
oh-shiny factor). However, it's highly questionable if any of them is
better if we take also
On Thu, Feb 26, 2009 at 3:50 PM, Antoine Pitrou wrote:
>> BTW: You can avoid the extra checkout of the branch in Subversion
>> by first locally copying the trunk checkout to a new dir (using e.g.
>> cp -al) and then running a "svn switch" on it.
>
> That means you only work on one feature at a ti
On Thu, Feb 26, 2009 at 3:50 PM, Antoine Pitrou wrote:
> I'm no trying to advocate switching to a DVCS, but really:
>
>> I think that's a much better approach and one that reduces the
>> load on the python.org repo sys-admins.
>
> How does having 4 more-or-less supported VCSes, rather than 1, lig
It's an R rated romantic comedy from the Apatow team, so I guess that
depends on your employer ;-)
On Tue, Jan 27, 2009 at 11:38 AM, Mark Dickinson wrote:
> On Mon, Jan 26, 2009 at 11:32 PM, Trent Nelson
> wrote:
>
>>Nevertheless, I do have a surprise for everyone.
>
> A surprise, indeed!
> How do you create the release tag so that it contains change
> sets A and A+2, but not A+1? (and no, creating a branch just for
> the release is no option, because that means you have to copy all
> the changes you made on the branch back to the trunk)
creating a branch for the release is no opti
>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 de
>> Anyway, if we're going to change policies around submitting code, I
>> would much rather see peer review become a habit than adopt a tool
>> like PQM.
>
> The part where I'm skeptical about such a policy is that there might
> be a shortage of reviewers. What if a patch on Rietvield doesn't find
22 matches
Mail list logo
