"Martin v. Löwis" wrote:
>> I don't know how hg manages this, but can't we preserve the tag
>> information of the tags that you've scheduled to be removed
>> in some place that can easily be pulled in but doesn't
>> affect the main repo size ?
>
> Most certainly, and this is the plan already: we w
On Wed, Sep 29, 2010 at 20:32, Guido van Rossum wrote:
> I would like to recommend that the Python core developers start using
> a code review tool such as Rietveld or Reviewboard. I don't really
> care which tool we use (I'm sure there are plenty of pros and cons to
> each) but I do think we shou
Hi,
On using code review tools: +1, no discussion.
I've recently been doing a bit of research on these as a side effect of
researching continuous deployment, so:
1. Barry is right about Launchpad's merge proposals (unsurprisingly)
2. hg has a review extension called hg-review, but I think it'll
Barry Warsaw writes:
> You can have "co-located" branches[1] which essentially switch
> in-place, so if a branch is changing some .c files, you won't have
> to rebuild the whole world just to try out a patch.
In Mercurial these are called "named branches", and they are
repo-local (by which I m
On Wed, Sep 29, 2010 at 01:23:24PM -0700, Guido van Rossum wrote:
> On Wed, Sep 29, 2010 at 1:12 PM, Brett Cannon wrote:
> > On Wed, Sep 29, 2010 at 12:03, Guido van Rossum wrote:
> >> A problem with that is that we regularly make matching improvements to
> >> upload.py and the server-side code i
On Thu, Sep 30, 2010 at 07:45:52AM +1000, Nick Coghlan wrote:
> Somewhat amusing to get to this thread a few minutes after creating a
> Reitveld issue for the first pass of my urllib.parse patch :)
Hello Nick, could you please point me to that?
Also, in general here are my points on Code Review u
Sorry for following up to myself, but this typo might be very
confusing:
Stephen J. Turnbull writes:
> Barry Warsaw writes:
>
> > You can have "co-located" branches[1] which essentially switch
> > in-place, so if a branch is changing some .c files, you won't have
> > to rebuild the whole
On Sun, Sep 26, 2010 at 2:18 AM, "Martin v. Löwis" wrote:
> Am 26.09.2010 00:48, schrieb Georg Brandl:
>> Am 26.09.2010 00:16, schrieb "Martin v. Löwis":
Redirect wiki.python.org to the Python wiki front page, and put the Jython
wiki somewhere on its own (whether it's wiki.jython.org or
On Wed, Sep 29, 2010 at 11:29 PM, Terry Reedy wrote:
> Does this violate the Sequence ABC (assuming there is one)?
>
There is a Sequence ABC, but it does not define __add__. It only defines
the following methods:
__contains__, __getitem__, __iter__, __len__, __reversed__, count, and index
tupl
On 29 September 2010 22:25, Nick Coghlan wrote:
> On Wed, Sep 29, 2010 at 11:40 PM, Barry Warsaw wrote:
>> I don't think it should be in the gc module, but I would prefer it be enabled
>> and controlled through a separate module, rather than something Python does
>> automatically for your conveni
On Thu, Sep 30, 2010 at 1:50 PM, Raymond Hettinger
wrote:
> 1a. Liberalize setobject.c binary operator methods, restrict SetABC
> methods, and add named methods (like difference, update, etc) that accept
> any iterable.
> 2. We could liberalize builtin set objects to accept any iterable as an
>
The torrential rains are causing havoc with my internet, so apologies for
replying out of sequence.
On Sep 30, 2010, at 07:17 PM, Stephen J. Turnbull wrote:
>Sorry for following up to myself, but this typo might be very
>confusing:
>
>Stephen J. Turnbull writes:
> > Barry Warsaw writes:
> >
> >
On Wed, Sep 29, 2010 at 2:32 PM, Guido van Rossum wrote:
> I would like to recommend that the Python core developers start using
> a code review tool such as Rietveld or Reviewboard. I don't really
> care which tool we use (I'm sure there are plenty of pros and cons to
> each) but I do think we sh
On 02:47 pm, jnol...@gmail.com wrote:
On Wed, Sep 29, 2010 at 2:32 PM, Guido van Rossum
wrote:
I would like to recommend that the Python core developers start using
a code review tool such as Rietveld or Reviewboard. I don't really
care which tool we use (I'm sure there are plenty of pros and c
On Thu, Sep 30, 2010 at 10:52 AM, wrote:
> On 02:47 pm, jnol...@gmail.com wrote:
>>
>> On Wed, Sep 29, 2010 at 2:32 PM, Guido van Rossum
>> wrote:
>>>
>>> I would like to recommend that the Python core developers start using
>>> a code review tool such as Rietveld or Reviewboard. I don't really
On Thu, Sep 30, 2010 at 7:52 AM, wrote:
> On 02:47 pm, jnol...@gmail.com wrote:
>> Regardless of the tool(s) used, code reviews are a fantastic
>> equalizer. If you have long time, experienced developers "submitting"
>> to the same rules that newer contributors have to follow then it helps
>> rem
On Thu, 30 Sep 2010 14:52:18 -
exar...@twistedmatrix.com wrote:
> >
> >Regardless of the tool(s) used, code reviews are a fantastic
> >equalizer. If you have long time, experienced developers "submitting"
> >to the same rules that newer contributors have to follow then it helps
> >remove the id
On Thu, Sep 30, 2010 at 9:52 AM, wrote:
> Of course, this is only true if the core developers *do* submit to the same
> rules. Is anyone proposing that current core committers have all their work
> reviewed before it is accepted?
>
I think most would welcome (or at least tolerate ;) ) additiona
> On Thu, Sep 30, 2010 at 9:52 AM, wrote:
>
> Of course, this is only true if the core developers *do* submit to the
> same
> rules. Is anyone proposing that current core committers have all their
> work reviewed before it is accepted?
For large patches it is good idea. But enforci
> The hard part is encouraging contributors to find the time and
> motivation to thoroughly review code that they aren't personally
> interested in (and perhaps not even familiar with).
Not sure how well 'tit for tat' schemes work - we *could* require
that people don't commit unreviewed changes, a
Am 30.09.2010 17:40, schrieb Senthil Kumaran:
>> On Thu, Sep 30, 2010 at 9:52 AM, wrote:
>>
>> Of course, this is only true if the core developers *do* submit to the
>> same
>> rules. Is anyone proposing that current core committers have all their
>> work reviewed before it is accept
On Thu, Sep 30, 2010 at 10:48 AM, "Martin v. Löwis" wrote:
> Not sure how well 'tit for tat' schemes work - we *could* require
> that people don't commit unreviewed changes, and also require that
> you can't commit unless you have reviewed somebody else's changes.
>
I wonder if a "reputation" sch
Am 29.09.2010 20:49, schrieb Guido van Rossum:
> Unfortunately taking the average patch posted to the tracker and
> importing it in Rietveld is very iffy -- it's very hard to find the
> right branch+rev needed to be able to apply the patch correctly -- not
> to mention that there are so many (slig
On Sep 30, 2010, at 10:47 AM, Jesse Noller wrote:
>Not to mention; there's a lot to be learned from doing them on both
>sides. At work, I learn about chunks of code I might not have
>otherwise known about or approaches to a problem I'd never considered.
>I sort of drank the kool-aid.
Tools aside,
On Thu, Sep 30, 2010 at 9:33 AM, Barry Warsaw wrote:
> On Sep 30, 2010, at 10:47 AM, Jesse Noller wrote:
>
>>Not to mention; there's a lot to be learned from doing them on both
>>sides. At work, I learn about chunks of code I might not have
>>otherwise known about or approaches to a problem I'd ne
On Thu, Sep 30, 2010 at 12:53 PM, geremy condra wrote:
> On Thu, Sep 30, 2010 at 9:33 AM, Barry Warsaw wrote:
>> On Sep 30, 2010, at 10:47 AM, Jesse Noller wrote:
>>
>>>Not to mention; there's a lot to be learned from doing them on both
>>>sides. At work, I learn about chunks of code I might not
On Thu, Sep 30, 2010 at 10:31, Daniel Stutzbach <
dan...@stutzbachenterprises.com> wrote:
> On Thu, Sep 30, 2010 at 9:52 AM, wrote:
>
>> Of course, this is only true if the core developers *do* submit to the
>> same rules. Is anyone proposing that current core committers have all their
>> work r
On Thu, Sep 30, 2010 at 08:31, Daniel Stutzbach
wrote:
> On Thu, Sep 30, 2010 at 9:52 AM, wrote:
>>
>> Of course, this is only true if the core developers *do* submit to the
>> same rules. Is anyone proposing that current core committers have all their
>> work reviewed before it is accepted?
>
>
On Thu, Sep 30, 2010 at 09:19, Georg Brandl wrote:
> Am 29.09.2010 20:49, schrieb Guido van Rossum:
>
>> Unfortunately taking the average patch posted to the tracker and
>> importing it in Rietveld is very iffy -- it's very hard to find the
>> right branch+rev needed to be able to apply the patch
"Stephen J. Turnbull" writes:
> Barry Warsaw writes:
>
> > You can have "co-located" branches[1] which essentially switch
> > in-place, so if a branch is changing some .c files, you won't have
> > to rebuild the whole world just to try out a patch.
>
> In Mercurial these are called "named bran
On Fri, Oct 1, 2010 at 12:56 AM, Guido van Rossum wrote:
>> (I am strongly in favor of this, but I don't think many core committers
>> are.)
>
> Having worked in this style for almost 5 years now, I am also strongly
> in favor. Jesse expressed it better than I could.
I'll be one of those to objec
Amaury just filed issue #1 yesterday; as counting started
with 1000, we are now into 9000 roundup issues.
I have become quite fond of roundup over the years, and would
like to thank Ka-Ping Yee, Richard Jones, and Erik Forsberg
for getting us here.
There are many contributions to this infrast
Hello,
It seems the py3k docs (both dev and 3.1) haven't been rebuilt for a few
days. Is there anything that needs to be done to trigger rebuilding?
Thank you,
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
"Martin v. Löwis" writes:
> Amaury just filed issue #1 yesterday; as counting started with
> 1000, we are now into 9000 roundup issues.
Congratulations!
> I have become quite fond of roundup over the years, and would like to
> thank Ka-Ping Yee, Richard Jones, and Erik Forsberg for getting
Barry Warsaw writes:
> I should note that I don't particularly like colocated/named branches. I
> personally much prefer separate directories for each feature or bug I'm
> working on. It helps me keep track of what I'm doing. I have a fast machine
> so recompiling all of Python is no big de
Am 01.10.2010 03:13, schrieb Antoine Pitrou:
>
> Hello,
>
> It seems the py3k docs (both dev and 3.1) haven't been rebuilt for a few
> days. Is there anything that needs to be done to trigger rebuilding?
Yes, I noticed it in my cronjob email. It seems latex has a problem with
c-api.tex; I'll ha
Am 01.10.2010 01:50, schrieb "Martin v. Löwis":
> Amaury just filed issue #1 yesterday; as counting started
> with 1000, we are now into 9000 roundup issues.
So, nitpickly, it would be 9001. But of course, we're already at
10003 anyway :)
> I have become quite fond of roundup over the years,
Am 30.09.2010 10:22, schrieb Dirkjan Ochtman:
> On Wed, Sep 29, 2010 at 20:32, Guido van Rossum wrote:
>> I would like to recommend that the Python core developers start using
>> a code review tool such as Rietveld or Reviewboard. I don't really
>> care which tool we use (I'm sure there are plenty
Georg Brandl writes:
> Am 30.09.2010 10:22, schrieb Dirkjan Ochtman:
>> On Wed, Sep 29, 2010 at 20:32, Guido van Rossum wrote:
>>> I would like to recommend that the Python core developers start using
>>> a code review tool such as Rietveld or Reviewboard. I don't really
>>> care which tool we u
39 matches
Mail list logo
