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
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
71 matches
Mail list logo
