Am 02.10.2010 22:42, schrieb Jesus Cea:
> On 30/09/10 22:41, Brett Cannon wrote:
>> Don't see why not, but those of us who use OpenID would need to start
>> caring about a password which would be unfortunate.
>
> +1. OpenID or OAuth is a must.
>
> Moreover, I am a bit worried of needing a google
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/09/10 22:41, Brett Cannon wrote:
> Don't see why not, but those of us who use OpenID would need to start
> caring about a password which would be unfortunate.
+1. OpenID or OAuth is a must.
Moreover, I am a bit worried of needing a google accou
On Sat, Oct 2, 2010 at 2:31 AM, Barry Warsaw wrote:
> Usually rubber stamps are reserved for cases where the fix really is trivial,
> or a change is large but mechanical, or when no reviewer can be found for a
> time-sensitive fix (very rare). You at least need to record the rubber stamp
> in the
Sorry I am not replying to the original thread with the same name.
I've been working on an HG extension for helping with Rietveld code
reviews. The main reason is so that Rietveld can remember state (what issue
id is being used) and handle the uploading and downloading to Rietveld. The
versi
On Fri, Oct 1, 2010 at 12:31 PM, Barry Warsaw wrote:
> I should note one other thing, in reference to my previous posting about
> reviews. Launchpad does have a backdoor for getting changes in without
> formal review. It's called "rubber stamping" and shows up in commit messages,
This makes a l
On Sep 30, 2010, at 01:46 PM, Brett Cannon wrote:
>Once we have a good workflow in place we would have to start shifting
>our development culture towards requiring a review of code no matter
>who the author is (which I support doing).
I should note one other thing, in reference to my previous pos
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
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:
> >
> >
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
Am 30.09.2010 00:12, schrieb Antoine Pitrou:
> On Wed, 29 Sep 2010 23:58:05 +0200
> "Martin v. Löwis" wrote:
>>> That shouldn't be too hard. Someone just has to create an App Engine
>>> project and handle the deployment. I guess the trickiest part is
>>> making sure enough people have admin access
On Wed, Sep 29, 2010 at 3:12 PM, Antoine Pitrou wrote:
> On Wed, 29 Sep 2010 23:58:05 +0200
> "Martin v. Löwis" wrote:
>> > That shouldn't be too hard. Someone just has to create an App Engine
>> > project and handle the deployment. I guess the trickiest part is
>> > making sure enough people hav
On Sep 30, 2010, at 12:04 AM, Antoine Pitrou wrote:
>On Wed, 29 Sep 2010 17:30:10 -0400
>Barry Warsaw wrote:
>> One other thought: IME patches in general are suboptimal to
>> branches, so I think we should be encouraging people to publish
>> their branches publicly for review. A diff is a decent
On Wed, Sep 29, 2010 at 5:57 PM, Nick Coghlan wrote:
> Would it be possible to sync up the reitveld issue numbers with the
> roundup ones if you did that? Or would the fact that a single issue
> can have multiple attached patches prevent that?
Another quirk would be that often several pieces are
On Wed, 29 Sep 2010 23:58:05 +0200
"Martin v. Löwis" wrote:
> > That shouldn't be too hard. Someone just has to create an App Engine
> > project and handle the deployment. I guess the trickiest part is
> > making sure enough people have admin access so multiple people can
> > update the website, e
On Wed, Sep 29, 2010 at 14:58, "Martin v. Löwis" wrote:
>> That shouldn't be too hard. Someone just has to create an App Engine
>> project and handle the deployment. I guess the trickiest part is
>> making sure enough people have admin access so multiple people can
>> update the website, especiall
On Wed, 29 Sep 2010 17:30:10 -0400
Barry Warsaw wrote:
> One other thought: IME patches in general are suboptimal to branches, so I
> think we should be encouraging people to publish their branches publicly for
> review. A diff is a decent way to get feedback about code changes, but that's
> ofte
>> So perhaps we should just run our own Rietveld instance next to Roundup.
>
> Would it be possible to sync up the reitveld issue numbers with the
> roundup ones if you did that?
Most certainly. However, this works fairly well today already. If you
put [issue] into the Rietveld subject, it c
2010/9/29 Guido van Rossum :
> On Wed, Sep 29, 2010 at 1:12 PM, Brett Cannon wrote:
>> How often do we even get patches generated from a downloaded copy of
>> Python? Is it enough to need to worry about this?
>
> I used to get these frequently. I don't know what the experience of
> the current cro
On Thu, Sep 30, 2010 at 7:35 AM, "Martin v. Löwis" wrote:
>> While I would personally love to see Rietveld declared the official
>> core Python code review tool, I realize that since I wrote as a Google
>> engineer and it is running on Google infrastructure (App Engine), I
>> can't be fully object
> That shouldn't be too hard. Someone just has to create an App Engine
> project and handle the deployment. I guess the trickiest part is
> making sure enough people have admin access so multiple people can
> update the website, especially if we run a modified copy so that
> bugs.python.org can pus
On Sep 29, 2010, at 05:22 PM, Alexander Belopolsky wrote:
>> Many times bigger than what? If you mean svn that's not true (the
>> eval of the DVCS pegged Hg at only 50% larger than svn).
>
>My experience was different. I may misremember because I did not try
>to use Hg since about a year ago, but
On Wed, Sep 29, 2010 at 14:35, "Martin v. Löwis" wrote:
>> While I would personally love to see Rietveld declared the official
>> core Python code review tool, I realize that since I wrote as a Google
>> engineer and it is running on Google infrastructure (App Engine), I
>> can't be fully objectiv
On Thu, Sep 30, 2010 at 4:47 AM, Brett Cannon wrote:
> On Wed, Sep 29, 2010 at 11:41, Antoine Pitrou wrote:
>> On Wed, 29 Sep 2010 11:32:19 -0700
>> Guido van Rossum wrote:
>>> I would like to recommend that the Python core developers start using
>>> a code review tool such as Rietveld or Review
> While I would personally love to see Rietveld declared the official
> core Python code review tool, I realize that since I wrote as a Google
> engineer and it is running on Google infrastructure (App Engine), I
> can't be fully objective about the tool choice -- even though it is
> open source, h
One other thought: IME patches in general are suboptimal to branches, so I
think we should be encouraging people to publish their branches publicly for
review. A diff is a decent way to get feedback about code changes, but that's
often only part of the work involved in deciding whether a change sh
On Wed, Sep 29, 2010 at 4:56 PM, Brett Cannon wrote:
> On Wed, Sep 29, 2010 at 13:31, Alexander Belopolsky
> wrote:
>> On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum wrote:
>> ..
>>> But maybe with Hg it's less of a burden to ask people to use a checkout.
>>>
>>
>> I thought with Hg it would
On Wed, 29 Sep 2010 13:56:46 -0700
Brett Cannon wrote:
> On Wed, Sep 29, 2010 at 13:31, Alexander Belopolsky
> wrote:
> > On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum wrote:
> > ..
> >> But maybe with Hg it's less of a burden to ask people to use a checkout.
> >>
> >
> > I thought with Hg i
On 9/29/10 3:33 PM, Guido van Rossum wrote:
On Wed, Sep 29, 2010 at 1:31 PM, Alexander Belopolsky
wrote:
On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum wrote:
..
But maybe with Hg it's less of a burden to ask people to use a checkout.
I thought with Hg it would be more of a burden for c
On Wed, Sep 29, 2010 at 13:43, Antoine Pitrou wrote:
> Le mercredi 29 septembre 2010 à 13:35 -0700, Brett Cannon a écrit :
>>
>> Well, we can start with strongly worded suggestions that patches
>> submitted using Rietveld will typically get priority over patches
>> submitted just to the issue trac
On 29 September 2010 21:12, Brett Cannon wrote:
> How often do we even get patches generated from a downloaded copy of
> Python? Is it enough to need to worry about this?
When I do simple bugfixes of library code, I'll often work from my
"live" Python environment, patch it in place, test and gene
On Wed, Sep 29, 2010 at 1:43 PM, Antoine Pitrou wrote:
> Le mercredi 29 septembre 2010 à 13:35 -0700, Brett Cannon a écrit :
>>
>> Well, we can start with strongly worded suggestions that patches
>> submitted using Rietveld will typically get priority over patches
>> submitted just to the issue tr
On Wed, Sep 29, 2010 at 13:31, Alexander Belopolsky
wrote:
> On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum wrote:
> ..
>> But maybe with Hg it's less of a burden to ask people to use a checkout.
>>
>
> I thought with Hg it would be more of a burden for casual contributors
> to use a checkout
Le mercredi 29 septembre 2010 à 13:35 -0700, Brett Cannon a écrit :
>
> Well, we can start with strongly worded suggestions that patches
> submitted using Rietveld will typically get priority over patches
> submitted just to the issue tracker and that this means doing it from
> a checkout.
But wi
On Wed, Sep 29, 2010 at 13:23, 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 it talks to. W
On Wed, Sep 29, 2010 at 1:31 PM, Alexander Belopolsky
wrote:
> On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum wrote:
> ..
>> But maybe with Hg it's less of a burden to ask people to use a checkout.
>>
>
> I thought with Hg it would be more of a burden for casual contributors
> to use a checkou
> > Well, I would assume people are working from a checkout. Patches from
> > an outdated checkout simply would fail and that's fine by me.
>
> Ok, but that's an extra barrier for contributions. Lots of people when
> asked for a patch just modify their distro in place and you can count
> yourself
On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum wrote:
..
> But maybe with Hg it's less of a burden to ask people to use a checkout.
>
I thought with Hg it would be more of a burden for casual contributors
to use a checkout simply because the checkout is many times bigger.
_
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 it talks to. While we tend to be
>> conservative in these changes (because
On Wed, Sep 29, 2010 at 12:03, Guido van Rossum wrote:
> On Wed, Sep 29, 2010 at 11:47 AM, Brett Cannon wrote:
>> On Wed, Sep 29, 2010 at 11:41, Antoine Pitrou wrote:
>>> On Wed, 29 Sep 2010 11:32:19 -0700
>>> Guido van Rossum wrote:
I would like to recommend that the Python core developer
Guido> I would like to recommend that the Python core developers start
Guido> using a code review tool ...
+1
I've suggested that something like Rietveld be integrated with our Roundup
instance in the past. I suspect there is an open tracker case. Martin will
be better able to find it
On Sep 29, 2010, at 11:32 AM, 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 should ge
Guido, Brett,
On Wed, 29 Sep 2010 11:47:51 -0700
Brett Cannon wrote:
>
> The other option (as discussed on Buzz) is to add Rietveld's upload.py
> to Misc/ and tell people to use that to submit the patch.
It sounds like a good option (or, even better, a customized version as
suggested by Daniel
On Wed, Sep 29, 2010 at 11:47 AM, Brett Cannon wrote:
> On Wed, Sep 29, 2010 at 11:41, Antoine Pitrou wrote:
>> On Wed, 29 Sep 2010 11:32:19 -0700
>> Guido van Rossum wrote:
>>> I would like to recommend that the Python core developers start using
>>> a code review tool such as Rietveld or Revie
On Wed, Sep 29, 2010 at 1:41 PM, Antoine Pitrou wrote:
> He, several of us would like it too (although for short patches it
> doesn't really make a difference), but what's missing is some kind of
> Roundup integration. Something as trivial as a "start review" button in
> front of every uploaded p
On Wed, Sep 29, 2010 at 11:41 AM, Antoine Pitrou wrote:
> On Wed, 29 Sep 2010 11:32:19 -0700
> 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
On Wed, Sep 29, 2010 at 11:41, Antoine Pitrou wrote:
> On Wed, 29 Sep 2010 11:32:19 -0700
> 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 th
On Wed, 29 Sep 2010 11:32:19 -0700
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
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 should get out of the stone age and start
using a tool for the major
73 matches
Mail list logo
