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
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
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 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
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
"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
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
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
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
"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 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
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 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 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 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 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,
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 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 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
> 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
> 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
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, 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 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, 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 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 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
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 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
>
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 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 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
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 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
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
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
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
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
"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
39 matches
Mail list logo
