Re: [Python-Dev] hg conversion: tags

2010-09-30 Thread M.-A. Lemburg 
"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 will keep the
> subversion repository data "forever".

Fair enough.

> If you want the CVS repository from the day when it was converted
> to subversion, you can still get it from
> 
> http://svn.python.org/snapshots/python-cvsroot-final.tar.bz2
> 
> (Created 27-Oct-2005 04:34, FWIW, so we are close to 5 years
> into subversion usage. Given that the "public" usage of the CVS
> started in 2000, we should start to look into the hg successor
> around 2013, for a switchover in Oktober 2015 :-).

Good idea :-)

I suppose we'll have CVCSes by then - cloud version control systems.

Let's reserve cloud number 9 for use by Python (cumulonimbus is
too hard to remember) :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 30 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread 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 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 majority of our code reviews.

Rambling thoughts about some of the things mentioned in this thread.

I think hg-review looks interesting, though it may not (yet) have the
level of sophistication of Rietveld. (Public test instance at
http://review.stevelosh.com/.)

It might be interesting to integrate Rietveld uploads in a Mercurial
extension, particularly if it gets integrated with mq somehow.

Email reviews seem to actually work really well for Mercurial (using
the patchbomb extension to send out patches to mailing lists); the
only problem we run into is that we can't keep track of things that
have been submitted and reviewed. But it makes commenting inline
effortless and provides a familiar interface for everyone.

For the imparting wisdom thing, I think that's more a culture thing
than a tool thing. If reviews happen in public as a standard part of
the process, then it probably won't appear judgmental or overbearing
either in a tool or in email (or issue tracker).

I hope people will discover and like mq, which makes it easy to keep
together a coherent series of patches.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Laurens Van Houtven 
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 be too
difficult to use properly for a big dev team like Python's with many people
reading code reviews (hg-review stores reviews in the repository) -- there's
no real canonical way AFAIK of saying "give me all pending reviews
everywhere in the codebase", like you would have with a centralized place to
publish patches vs a specific revision.

(I *am* going to use hg-review personally for my startup, I'm not saying
it's a bad tool at all! Just that it's not very good for big teams yet,
because there's no real sensible way of getting a centralized UI for both
publishing and reviewing suggested patches.)

3. FWIW, I agree Rietveld's a better tool than ReviewBoard, and I'm not
attached to either of the authors, so Rietveld +1

cheers
lvh
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Stephen J. Turnbull 
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 mean they must be part of the DAG).  Named
branches used to have some inconvenient aspects relevant to standalone
branches (they could be fairly confusing to other users if pushed
before being merge to mainline).

It's not obvious to me that Mercurial style named branches would work
well here ... it would take a little thought to design an appropriate
workflow, anyway.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Toshio Kuratomi 
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 it talks to. While we tend to be
> >> conservative in these changes (because we don't control what version
> >> of upload.py people use) it would be a pain to maintain backwards
> >> compatibility with a version that was distributed in Misc/ two years
> >> ago -- that's kind of outside our horizon.
> >
> > 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 lucky if they send you a diff from a clean copy.
> 
> But maybe with Hg it's less of a burden to ask people to use a checkout.
> 
> > 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 crop of core developers is though, so maybe my gut
> feelings here are outdated.
> 
When helping out on a Linux distribution, dealing with patches against the
latest tarball is a fairly frequent occurrence.  The question would be
whether these patches get filtered through the maintainer of the package
before landing in roundup/rietveld and whether the distro maintainer is
sufficiently in tune with python development that they're maintaining both
patches against the last tarball and a checkout of trunk with the patches
applied intelligently there.

A few other random thoughts:

* hg could be more of a burden in that it may be unfamiliar to the casual
  python user who happens to have found a fix for a bug and wants to submit
  it.  cvs and svn are similar enough that people comfortable with one are
  usually comfortable with the other but hg has different semantics.
* The barrier to entry seems to be higher the less well integrated the tools
  are.  I occassionally try to contribute patches to bzr in launchpad and
  the integration there is horrid.  You end up with two separate streams of
  comments and you don't automatically get subscribed to both.  There's
  several UI elements for associating a branch with a bug but some of them
  are buggy (or else are very strict on what input they're expecting) while
  other ones are hard to find.  Since I only contribute a patch two or three
  times a year, I have to re-figure out the process each time I try to
  contribute.
* I like the idea of patch complexity being a measure of whether the patch
  needs to go into a code review tool in that it keeps simple things simple
  and gives more advanced tools to more advanced cases.  I dislike it in
  that for someone who's just contributing a patch to fix a problem that
  they're encountering which happens to be somewhat complex, they end up
  having to learn a lot about tools that they may never use again.
* It seems like code review will be a great aid to people who submit changes
  or review changes frequently.  The trick will be making it
  non-intimidating for someone who's just going to contribute changes
  infrequently.

-Toshio


pgpaYtl9m5J7d.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Senthil Kumaran 
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 using Rietveld.

I think, Martin already indicated that Roundup can post to Rietveld
instance. That should really be helpful.

I imagine a work-flow like this.

1. Contributor creates a patch and uploads to Roundup tracker.
2. If the patch is very small or does not require review, the
committer can just commit it.
3. If the patch does review review, one can click a link to do
"Patch Review" wherein only at the moment, the Patch is POSTed the
rietveld instance and is available for review.


-- 
Senthil

"I went to the museum where they had all the heads and arms from the
statues that are in all the other museums."
-- Steven Wright
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Stephen J. Turnbull 
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 world just to try out a patch.
 > 
 > In Mercurial these are called "named branches", and they are
 > repo-local (by which I mean they must be part of the DAG).  Named
 > branches used to have some inconvenient aspects relevant to standalone

s/relevant/relative/

 > branches (they could be fairly confusing to other users if pushed
 > before being merge to mainline).
 > 
 > It's not obvious to me that Mercurial style named branches would work
 > well here ... it would take a little thought to design an appropriate
 > workflow, anyway.
 > ___
 > Python-Dev mailing list
 > [email protected]
 > http://mail.python.org/mailman/listinfo/python-dev
 > Unsubscribe: 
 > http://mail.python.org/mailman/options/python-dev/stephen%40xemacs.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-30 Thread anatoly techtonik 
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 not).
>>>
>>> But that can't work: then off-site links into either wiki break.
>>
>> Why -- they can be redirected easily.
>
> Ok, so please be more specific: what exactly should the new structure
> look like?

From http://wiki.python.org/moin/SiteImprovements

* Shorten URLs - remove /moin/ prefix from
http://wiki.python.org/moin/SiteImprovements#Wiki
  * This requires moving Jython wiki from
http://wiki.python.org/jython/ to http://wiki.jython.org/ and placing
a temporary redirect on the previous places. -- ?techtonik 2010-03-16
08:39:34

Expanding:
1. Move http://wiki.python.org/moin/ to http://wiki.python.org/
2. Setup 301 redirect from http://wiki.python.org/moin/(.*) to
http://wiki.python.org/$1
3. Setup 301 redirect from http://wiki.python.org/jython/(.*) to
http://wiki.jython.org/$1
(optional tasks below)
4. Setup Analytics account to track sources of redirection to the old
pages and make this list public
5. Crowdsource changing source links
6. Drop redirection after redirected hits drop below 5% (even for 5%
new page can be looked up through Google)

-- 
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] API for binary operations on Sets

2010-09-30 Thread Daniel Stutzbach 
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

tuple, range, and str types  all register as following the Sequence ABC.
list and bytearray types register as following the MutableSequence ABC,
which is a subclass of the Sequence ABC.

-- 
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Resource leaks warnings

2010-09-30 Thread Floris Bruynooghe 
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 convenience.
>
> The os module would seem to be the place to enable/disable tracking of
> OS level resource leaks (i.e. file descriptors and possible HANDLES on
> Windows).

Heh, I was expecting the sys module to be the natural choice because
this would be changing interpreter behaviour.  It's just random
bikeshedding at this point however.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] API for binary operations on Sets

2010-09-30 Thread Nick Coghlan 
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
> "other" argument to a binary set operator.  This choice is not entirely
> backwards compatible because it would break code depending on being able run
> __ror__, __rand__, etc after a NotImplemented value is returned.  That being
> said, I think it unlikely that such code exists.  The real disadvantage is
> that it replicates the problems with list.__add__ and Guido has said before
> that he doesn't want to do that again.

> I was leaning towards #1 or #1a and the guys on IRC thought #2 would be
> better.  Now I'm not sure and would like additional input so I can get this
> bug closed for 3.2.  Any thoughts on the subject would be appreciated.
> Thanks,

My own inclination would be to go with #1a, *unless* Guido chimes in
to say he's OK with having the set operators accept arbitrary
iterators.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Barry Warsaw 
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:
> > 
> >  > 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 mean they must be part of the DAG).  Named
> > branches used to have some inconvenient aspects relevant to
> > standalone
>
>s/relevant/relative/
>
> > branches (they could be fairly confusing to other users if pushed
> > before being merge to mainline).
> > 
> > It's not obvious to me that Mercurial style named branches would
> > work well here ... it would take a little thought to design an
> > appropriate workflow, anyway.

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 deal.

I do like having the choice of being able to colocate or not, based on my own
workflow preferences.  But I suppose with Mercurial I can just have multiple
copies of the same branch in different directories, and just start out with
"hg update -C foo"

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Jesse Noller 
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 should get out of the stone age and start
> using a tool for the majority of our code reviews.
>
> 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, has several non-Googler maintainers, and can be run
> outside App Engine as well.
>
> But I do think that using a specialized code review tool rather than
> unstructured email plus a general-purpose issue tracker can hugely
> improve developer performance and also increase community
> participation. (A code review tool makes it much more convenient for a
> senior reviewer to impart their wisdom to a junior developer without
> appearing judgmental or overbearing.)
>
> See also this buzz thread:
> http://www.google.com/buzz/115212051037621986145/At6Rj82Kret/When-will-the-Python-dev-community-start-using
>
> --
> --Guido van Rossum (python.org/~guido)
>

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 idea that there is special treatment occurring.
Additionally, a lot of people are terrified of code reviews as they
view it as a "public flogging" - holding everyone to the same
standards, and showing this is not the case helps fight this
perception.

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.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread exarkun 

On 02:47 pm, [email protected] 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 cons to
each) but I do think we should get out of the stone age and start
using a tool for the majority of our code reviews.

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, has several non-Googler maintainers, and can be run
outside App Engine as well.

But I do think that using a specialized code review tool rather than
unstructured email plus a general-purpose issue tracker can hugely
improve developer performance and also increase community
participation. (A code review tool makes it much more convenient for a
senior reviewer to impart their wisdom to a junior developer without
appearing judgmental or overbearing.)

See also this buzz thread:
http://www.google.com/buzz/115212051037621986145/At6Rj82Kret/When- 
will-the-Python-dev-community-start-using


--
--Guido van Rossum (python.org/~guido)


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 idea that there is special treatment occurring.


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 am strongly in favor of this, but I don't think many core committers 
are.)


Jean-Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Jesse Noller 
On Thu, Sep 30, 2010 at 10:52 AM,   wrote:
> On 02:47 pm, [email protected] 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 cons to
>>> each) but I do think we should get out of the stone age and start
>>> using a tool for the majority of our code reviews.
>>>
>>> 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, has several non-Googler maintainers, and can be run
>>> outside App Engine as well.
>>>
>>> But I do think that using a specialized code review tool rather than
>>> unstructured email plus a general-purpose issue tracker can hugely
>>> improve developer performance and also increase community
>>> participation. (A code review tool makes it much more convenient for a
>>> senior reviewer to impart their wisdom to a junior developer without
>>> appearing judgmental or overbearing.)
>>>
>>> See also this buzz thread:
>>> http://www.google.com/buzz/115212051037621986145/At6Rj82Kret/When-
>>> will-the-Python-dev-community-start-using
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>
>> 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 idea that there is special treatment occurring.
>
> 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 am strongly in favor of this, but I don't think many core committers
> are.)
>
> Jean-Paul
>

I'll propose it, knowing full well I won't win. Code reviews have
saved my bacon on numerous occasions. The best unit tests on the
planet won't protect you against a fundamentally bad assumption or
logic error. Like I said - I think it helps "equalize" things. YMMV.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Guido van Rossum 
On Thu, Sep 30, 2010 at 7:52 AM,   wrote:
> On 02:47 pm, [email protected] 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 idea that there is special treatment occurring.
>
> 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 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.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Antoine Pitrou 
On Thu, 30 Sep 2010 14:52:18 -
[email protected] 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 idea that there is special treatment occurring.
> 
> 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 am strongly in favor of this, but I don't think many core committers 
> are.)

While I agree with non-trivial patches being *posted* for review, I
don't agree that an actual review should happen in order for a patch to
be committed. That's unless we get 10x the number of reviewers we
currently have.

(and you certainly know by experience that I would be glad to have
reviews on my patches, especially the network-related ones ;-))

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Daniel Stutzbach 
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 ;) ) additional review of
their code.

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).

-- 
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread 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 accepted?

For large patches it is good idea. But enforcing it for smaller
patches may cost us more time for each commit.


-- 
Senthil

Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Martin v. Löwis 
> 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, and also require that
you can't commit unless you have reviewed somebody else's changes.

So if you do 10 reviews, you are entitled to 10 commits...

Of course, that would put more burden on those people who already
do all the work.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Martin v. Löwis 
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 accepted?
> 
> For large patches it is good idea. But enforcing it for smaller
> patches may cost us more time for each commit.

I think the supporters of code review readily accept that: in return
for the higher effort, they say, we also get more quality.

So it's really a quality vs. quantity thing. It would be easy to just
commit all patches that are uploaded to roundup, but of course, it
would horribly break Python. With mandatory code review, even less
patches get reviewed than today.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Daniel Stutzbach 
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" scheme would work better.  Track and publicize
patch submissions, reviews, and the review/patch ratio, but do not enforce
any particular ratios.  Perhaps provide a roundup query showing patches
awaiting review sorted by the patch submitter's review/patch ratio? (in
descending order)

Obviously there would be many non-trivial details to work out.  I'm just
brainstorming.

-- 
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Georg Brandl 
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 (slightly) different patch formats.
> It would take a fair bit of AI to get this right.
> 
> The recommended way to work with Rietveld is to use a checkout
> (fortunately with Hg this will become easier to do) and use the
> "upload.py" script that you can download from Rietveld (log in and
> click on the Create link).

Then could we do it the other way round and let (our) upload.py open
an issue with the patch automatically (after querying for information
not already given to rietveld)?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Barry Warsaw 
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, I completely agree.

Many projects that I contribute to have policies such as "nothing lands
without reviewer approval".  For some that means one reviewer must approve it,
for others two +1s and no -1s, or a coding approval and a ui approval, etc.

When I was the review team lead on Launchpad, I had a goal that every
developer would also eventually be a reviewer.  We started with a small number
of experienced developers, then ran a mentor program to train new reviewers
(who we called "mentats").  A mentat approval was not enough to land a branch,
but the mentor could basically say "yes, i agree with the review" and it would
land.  Eventually, by mutual consent a mentat would graduate to full
reviewership (and hopefully be a mentor to new reviewers).

This was hugely successful among many dimensions.  It got everyone on the same
page as to coding standards, it equalized the playing field, it got everyone
to think collaboratively as a team, folks learned about parts of the system
they didn't have day-to-day intimate knowledge about, and it got changes
landed much more quickly.

Here are a few things we learned along the way.  Their applicability to Python
will vary of course, and we need to find what works for us.

* Keep branches *small*.  We had a limit of 800 lines of diff, with special
  explicit permission from the person reviewing your change to exceed.  800
  lines is about the maximum that a person can review in a reasonable amount
  of time without losing focus.

* The *goal* was 5 minutes review, but the reality was that most reviews took
  about 15-20 minutes.  If it's going longer, you weren't doing it right.
  This meant that there was a level of trust between the reviewer and the dev,
  so that the basic design had been previously discussed and agreed upon (we
  mandated pre-implementation chats), etc.  A reviewer was there to sanity
  check the implementation, watch for obvious mistakes, ensure test coverage
  for the new code, etc.  If you were questioning the basic design, you
  weren't doing a code review.  It was okay to reject a change quickly if you
  found fatal problems.

* The primary purpose of a code review was to learn and teach, and in a sense,
  the measurable increase in quality was a side-effect.  What I mean by that
  is that the review process cannot catch all bugs.  It can reduce them, but
  it's much more valuable to share expertise on how to do things.  E.g. "Did
  you know that if X happens, you won't be decref'ing Y?  We like to use goto
  statements to ensure that all objects are properly refcounted even in the
  case of exceptional conditions."  That's a teaching moment that happens to
  improve quality.

* Reviews are conversations, and it's a two way street.  Many times a dev
  pushed back on one of my suggestions, and we'd have weekly reviewer meetings
  to hash out coding standards differences.  E.g. Do you check for empty
  sequences with "if len(foo) == 0" or "if not foo"?  The team would make
  those decisions and you'd live by them even if you didn't agree.  It's also
  critical to document those decisions, and a wiki page style guide works very
  well (especially when you can point to PEP 8 as your basic style guide for
  example).

* Reviews are collaborations.  You're both there to get the code landed so
  work together, not at odds.  Try to reach consensus, and don't be afraid to
  compromise.  All code is ultimately owned by everyone and you never know who
  will have to read it 2 years from now, so keep things simple, clear, and
  well commented.  These are all aesthetics that a reviewer can help with.

* As a reviewer ASK QUESTIONS.  The best reviews were the ones that asked lots
  of questions, such as "have you thought about the race conditions this might
  introduce?" or "what happens when foo is None?"  A reviewer doesn't
  necessarily have to guess or work out every detail.  If you don't understand
  something, ask a question and move on.  Let the coder answer it to your
  satisfaction.  As a reviewer, once all your questions are answered, you know
  you can approve the change.

* Keep reviews fast, easy, and fun.  I think this is especially true for
  Python, where we're all volunteers.  Keeping it fast, easy, and fun greatly
  improves the odds that code will be reviewed for the good of the project.

* Have a dispute resolution process.  If a reviewer and coder can't agree,
  appeal to a higher authority.  As review team leader, I did occasionally
  have to break ties.

* Record the reviewer in the commit messages.  We had highly structured commit
  messages that included the reviewer name, e.g.

  % commit -m"[r=barry] Bug 12345; fix bad frobnification

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread geremy condra 
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 never considered.
>>I sort of drank the kool-aid.
>
> Tools aside, I completely agree.
>
> Many projects that I contribute to have policies such as "nothing lands
> without reviewer approval".  For some that means one reviewer must approve it,
> for others two +1s and no -1s, or a coding approval and a ui approval, etc.
>
> When I was the review team lead on Launchpad, I had a goal that every
> developer would also eventually be a reviewer.  We started with a small number
> of experienced developers, then ran a mentor program to train new reviewers
> (who we called "mentats").  A mentat approval was not enough to land a branch,
> but the mentor could basically say "yes, i agree with the review" and it would
> land.  Eventually, by mutual consent a mentat would graduate to full
> reviewership (and hopefully be a mentor to new reviewers).
>
> This was hugely successful among many dimensions.  It got everyone on the same
> page as to coding standards, it equalized the playing field, it got everyone
> to think collaboratively as a team, folks learned about parts of the system
> they didn't have day-to-day intimate knowledge about, and it got changes
> landed much more quickly.
>
> Here are a few things we learned along the way.  Their applicability to Python
> will vary of course, and we need to find what works for us.
>
> * Keep branches *small*.  We had a limit of 800 lines of diff, with special
>  explicit permission from the person reviewing your change to exceed.  800
>  lines is about the maximum that a person can review in a reasonable amount
>  of time without losing focus.
>
> * The *goal* was 5 minutes review, but the reality was that most reviews took
>  about 15-20 minutes.  If it's going longer, you weren't doing it right.
>  This meant that there was a level of trust between the reviewer and the dev,
>  so that the basic design had been previously discussed and agreed upon (we
>  mandated pre-implementation chats), etc.  A reviewer was there to sanity
>  check the implementation, watch for obvious mistakes, ensure test coverage
>  for the new code, etc.  If you were questioning the basic design, you
>  weren't doing a code review.  It was okay to reject a change quickly if you
>  found fatal problems.
>
> * The primary purpose of a code review was to learn and teach, and in a sense,
>  the measurable increase in quality was a side-effect.  What I mean by that
>  is that the review process cannot catch all bugs.  It can reduce them, but
>  it's much more valuable to share expertise on how to do things.  E.g. "Did
>  you know that if X happens, you won't be decref'ing Y?  We like to use goto
>  statements to ensure that all objects are properly refcounted even in the
>  case of exceptional conditions."  That's a teaching moment that happens to
>  improve quality.
>
> * Reviews are conversations, and it's a two way street.  Many times a dev
>  pushed back on one of my suggestions, and we'd have weekly reviewer meetings
>  to hash out coding standards differences.  E.g. Do you check for empty
>  sequences with "if len(foo) == 0" or "if not foo"?  The team would make
>  those decisions and you'd live by them even if you didn't agree.  It's also
>  critical to document those decisions, and a wiki page style guide works very
>  well (especially when you can point to PEP 8 as your basic style guide for
>  example).
>
> * Reviews are collaborations.  You're both there to get the code landed so
>  work together, not at odds.  Try to reach consensus, and don't be afraid to
>  compromise.  All code is ultimately owned by everyone and you never know who
>  will have to read it 2 years from now, so keep things simple, clear, and
>  well commented.  These are all aesthetics that a reviewer can help with.
>
> * As a reviewer ASK QUESTIONS.  The best reviews were the ones that asked lots
>  of questions, such as "have you thought about the race conditions this might
>  introduce?" or "what happens when foo is None?"  A reviewer doesn't
>  necessarily have to guess or work out every detail.  If you don't understand
>  something, ask a question and move on.  Let the coder answer it to your
>  satisfaction.  As a reviewer, once all your questions are answered, you know
>  you can approve the change.
>
> * Keep reviews fast, easy, and fun.  I think this is especially true for
>  Python, where we're all volunteers.  Keeping it fast, easy, and fun greatly
>  improves the odds that code will be reviewed for the good of the project.
>
> * Have a dispute resolution process.  If a reviewer and coder can't agree,
>  appeal to a higher authority.  As review team leader, I did occasionally
>  have to break ties.
>
> * Record the revie

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Jesse Noller 
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 have
>>>otherwise known about or approaches to a problem I'd never considered.
>>>I sort of drank the kool-aid.
>>
>> Tools aside, I completely agree.
>>
>> Many projects that I contribute to have policies such as "nothing lands
>> without reviewer approval".  For some that means one reviewer must approve 
>> it,
>> for others two +1s and no -1s, or a coding approval and a ui approval, etc.
>>
>> When I was the review team lead on Launchpad, I had a goal that every
>> developer would also eventually be a reviewer.  We started with a small 
>> number
>> of experienced developers, then ran a mentor program to train new reviewers
>> (who we called "mentats").  A mentat approval was not enough to land a 
>> branch,
>> but the mentor could basically say "yes, i agree with the review" and it 
>> would
>> land.  Eventually, by mutual consent a mentat would graduate to full
>> reviewership (and hopefully be a mentor to new reviewers).
>>
>> This was hugely successful among many dimensions.  It got everyone on the 
>> same
>> page as to coding standards, it equalized the playing field, it got everyone
>> to think collaboratively as a team, folks learned about parts of the system
>> they didn't have day-to-day intimate knowledge about, and it got changes
>> landed much more quickly.
>>
>> Here are a few things we learned along the way.  Their applicability to 
>> Python
>> will vary of course, and we need to find what works for us.
>>
>> * Keep branches *small*.  We had a limit of 800 lines of diff, with special
>>  explicit permission from the person reviewing your change to exceed.  800
>>  lines is about the maximum that a person can review in a reasonable amount
>>  of time without losing focus.
>>
>> * The *goal* was 5 minutes review, but the reality was that most reviews took
>>  about 15-20 minutes.  If it's going longer, you weren't doing it right.
>>  This meant that there was a level of trust between the reviewer and the dev,
>>  so that the basic design had been previously discussed and agreed upon (we
>>  mandated pre-implementation chats), etc.  A reviewer was there to sanity
>>  check the implementation, watch for obvious mistakes, ensure test coverage
>>  for the new code, etc.  If you were questioning the basic design, you
>>  weren't doing a code review.  It was okay to reject a change quickly if you
>>  found fatal problems.
>>
>> * The primary purpose of a code review was to learn and teach, and in a 
>> sense,
>>  the measurable increase in quality was a side-effect.  What I mean by that
>>  is that the review process cannot catch all bugs.  It can reduce them, but
>>  it's much more valuable to share expertise on how to do things.  E.g. "Did
>>  you know that if X happens, you won't be decref'ing Y?  We like to use goto
>>  statements to ensure that all objects are properly refcounted even in the
>>  case of exceptional conditions."  That's a teaching moment that happens to
>>  improve quality.
>>
>> * Reviews are conversations, and it's a two way street.  Many times a dev
>>  pushed back on one of my suggestions, and we'd have weekly reviewer meetings
>>  to hash out coding standards differences.  E.g. Do you check for empty
>>  sequences with "if len(foo) == 0" or "if not foo"?  The team would make
>>  those decisions and you'd live by them even if you didn't agree.  It's also
>>  critical to document those decisions, and a wiki page style guide works very
>>  well (especially when you can point to PEP 8 as your basic style guide for
>>  example).
>>
>> * Reviews are collaborations.  You're both there to get the code landed so
>>  work together, not at odds.  Try to reach consensus, and don't be afraid to
>>  compromise.  All code is ultimately owned by everyone and you never know who
>>  will have to read it 2 years from now, so keep things simple, clear, and
>>  well commented.  These are all aesthetics that a reviewer can help with.
>>
>> * As a reviewer ASK QUESTIONS.  The best reviews were the ones that asked 
>> lots
>>  of questions, such as "have you thought about the race conditions this might
>>  introduce?" or "what happens when foo is None?"  A reviewer doesn't
>>  necessarily have to guess or work out every detail.  If you don't understand
>>  something, ask a question and move on.  Let the coder answer it to your
>>  satisfaction.  As a reviewer, once all your questions are answered, you know
>>  you can approve the change.
>>
>> * Keep reviews fast, easy, and fun.  I think this is especially true for
>>  Python, where we're all volunteers.  Keeping it fast, easy, and fun greatly
>>  improves the odds that code will be reviewed for the good of the project.
>>
>> * Have a dispute resolut

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Brian Curtin 
On Thu, Sep 30, 2010 at 10:31, Daniel Stutzbach <
[email protected]> 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?
>>
>
> I think most would welcome (or at least tolerate ;) ) additional review of
> their code.
>
> 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).
>
> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC 
>

I definitely welcome additional, or in some cases, *any* review. Looking for
reviews of Windows features/bugs sometimes equates to looking in a ghost
town, but I have the self-inflicted problem of using Windows in the first
place ;)

Anyways, a big +1 to expanding review, especially incorporating something
like Rietveld. Although I'm replying out of order, Barry's big response lays
out a lot of good ideas that I think we can use.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Brett Cannon 
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?
>
> I think most would welcome (or at least tolerate ;) ) additional review of
> their code.
> 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).

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).

As for needing some point system or incentive to drive people to do
it, I don't think that would be necessary. We are lucky to have a dev
team that is friendly and respectful. I suspect that e.g., if Nick
started doing reviews of importlib patches I would reciprocate the
favour by reviewing runpy patches. Those of us who don't do reviews
would most likely then just end up with patches sitting in the tracker
waiting for a review.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Brett Cannon 
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 correctly -- not
>> to mention that there are so many (slightly) different patch formats.
>> It would take a fair bit of AI to get this right.
>>
>> The recommended way to work with Rietveld is to use a checkout
>> (fortunately with Hg this will become easier to do) and use the
>> "upload.py" script that you can download from Rietveld (log in and
>> click on the Create link).
>
> Then could we do it the other way round and let (our) upload.py open
> an issue with the patch automatically (after querying for information
> not already given to rietveld)?

Don't see why not, but those of us who use OpenID would need to start
caring about a password which would be unfortunate.

-Brett

>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Martin Geisler 
"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 branches", and they are
> repo-local (by which I mean they must be part of the DAG).

Think of it this way: you can have several clones and when you make
different commits in each, they naturally begin to diverge:

  clone 1: ... [X] --- [A] --- [B]

  clone 2: ... [X] --- [R]

  clone 3: ... [X] --- [U] --- [V]

Though you cannot see it yet, you have created branches in the history.
If you pull one clone 2 into clone 1, then the branch suddenly becomes
visible in that clone -- you have two "heads" (B and R):

  clone 1: ... [X] --- [A] --- [B]
  \
   [R]

You can of course pull in clone 3 as well:

  clone 1: ... [X] --- [A] --- [B]
| \
|  [R]
 \
  [U] --- [V]

You can now use 'hg update' to switch between these three anonymous
branches. You can find the three heads by using 'hg heads' or you can
use the bookmarks extension to assign labels to them. These labels will
move forward when you commit, just like you move a bookmark forward in a
book when you read through it.

Btw, you can separate such a repository again with 'hg clone -r' which
lets you ask for a clone containing just a subset of another repository.
You can of course also split off named branches (see below) in this way.

> Named branches used to have some inconvenient aspects relevant to
> standalone branches (they could be fairly confusing to other users if
> pushed before being merge to mainline).

Now, "named branches" is sort of an extension of the above scenario.
Along with the commit message, date, username, etc..., each changeset in
Mercurial contains a label that tells us which "named branch" it belongs
to. By default, changesets are on the branch called, well, "default".

Named branches allow you to group or namespace your changesets. For
Mercurial itself, we use two named branches: default and stable.
Bugfixes go on the stable branch and we do our development on the
default branch.

Though a named branch is a collection of changesets, you often refer to
a named branch in a context where you need just a single changeset. It
is then interpreted as the tip-most changeset with that branch name. So

  $ hg update stable

will checkout the latest (tip-most) changeset on the stable branch. If
you now commit a bugfix, then that changeset will also be on the stable
branch since the branch name is inherited from the parent changeset.

In Mercurial we then merge the stable branch back into the default
branch:

  # fix bug
  $ hg commit -m 'Fixed issue 123'
  $ hg update default
  $ hg merge stable
  $ hg commit -m 'Merged in fix for issue123'

I've written a guide to such a workflow here:

  http://mercurial.aragost.com/kick-start/tasks.html

> It's not obvious to me that Mercurial style named branches would work
> well here ... it would take a little thought to design an appropriate
> workflow, anyway.

Yeah, you guys should try it out first -- it's easy to introduce named
branches later if you want.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/


pgpRzl80o4Dzb.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Nick Coghlan 
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 object (but only slightly).

I think one of the privileges/responsibilities that goes with commit
access is the ability to make the call between:
- "this is a simple change/fix, I'll just check it in with possible
post hoc review via python-checkins"
- "I want feedback on the idea and/or details before I commit this,
I'll post a patch for review to the tracker"
- "I may want help in getting this working and/or this may take a
while to get right, so I'll create a branch for it"

(with the balance between 2 and 3 apparently shifting more in favour
of 3 once we have hg to play with)

Particularly for user visible API changes, I think getting a sanity
check from at least one other dev before committing is a good idea.
For smaller stuff, I think python-checkins after the fact reviews are
enough to cover it (particularly now that one person asking a question
will kick the entire diff over to python-dev for broader review).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Celebrating issue #10000

2010-09-30 Thread Martin v. Löwis 
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 infrastructure, both
from individuals and software projects, but I'd like to single
out two of them which have I also appreciate very much:
the folks at Upfront Hosting have helped a lot to keep the system
running, and the PostgreSQL database has really validated it's
own claim of being the world's most advanced open source
database.

Kind regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Docs rebuild

2010-09-30 Thread 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?

Thank you,

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Celebrating issue #10000

2010-09-30 Thread Ben Finney 
"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 us
> here.

Yes, thanks to all those involved in moving to a free issue tracker for
Python and maintaining it past the initial stages.

I'm glad Roundup and PostgreSQL are both up to the task and, by Martin's
account, good to use.

> There are many contributions to this infrastructure, both from
> individuals and software projects, but I'd like to single out two of
> them which have I also appreciate very much: the folks at Upfront
> Hosting have helped a lot to keep the system running

Yay! Donating resources to free software projects *and* allowing
administrative control over the software is really valuable.

-- 
 \  “It's up to the masses to distribute [music] however they want |
  `\… The laws don't matter at that point. People sharing music in |
_o__)their bedrooms is the new radio.” —Neil Young, 2008-05-06 |
Ben Finney

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Branching without losing your build products [was: We should be using a tool for code reviews]

2010-09-30 Thread Stephen J. Turnbull 
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 deal.

Note that once you have a branch with all of Python built, for any of
hg, git, bzr you may prefer to clone the branch/repo with "cp -r" or
"rsync" rather than "$VCS clone".  The reason for doing it with "$VCS
clone" is to get a pristine workspace without any cruft like editor
backups or build products.  If you *want* a crufty workspace (and in
this case some people do), a recursive copy is a better tool.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs rebuild

2010-09-30 Thread Georg Brandl 
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 have a look at it.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Celebrating issue #10000

2010-09-30 Thread Georg Brandl 
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, and would
> like to thank Ka-Ping Yee, Richard Jones, and Erik Forsberg
> for getting us here.
> 
> There are many contributions to this infrastructure, both
> from individuals and software projects, but I'd like to single
> out two of them which have I also appreciate very much:
> the folks at Upfront Hosting have helped a lot to keep the system
> running, and the PostgreSQL database has really validated it's
> own claim of being the world's most advanced open source
> database.

I'd like to add my thanks.  Where would we be without the tracker?
Probably in holidays...

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Georg Brandl 
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 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 majority of our code reviews.
> 
> Rambling thoughts about some of the things mentioned in this thread.
> 
> I think hg-review looks interesting, though it may not (yet) have the
> level of sophistication of Rietveld. (Public test instance at
> http://review.stevelosh.com/.)
> 
> It might be interesting to integrate Rietveld uploads in a Mercurial
> extension, particularly if it gets integrated with mq somehow.

That would be totally awesome!

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

2010-09-30 Thread Andi Albrecht 
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 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 majority of our code reviews.
>> 
>> Rambling thoughts about some of the things mentioned in this thread.
>> 
>> I think hg-review looks interesting, though it may not (yet) have the
>> level of sophistication of Rietveld. (Public test instance at
>> http://review.stevelosh.com/.)
>> 
>> It might be interesting to integrate Rietveld uploads in a Mercurial
>> extension, particularly if it gets integrated with mq somehow.
>
> That would be totally awesome!

The Go (the language) project has a Mercurial extension that integrates
Rietveld. It seems to provide a few commands for both directions:
uploading changelists to a review server and for the reviewer
downloading from the server and applying the changelists to a working
copy. I never used this extension myself so I can't tell anything about
the workflow introduced by these commands.

The sources for this extension are here:
http://code.google.com/p/go/source/browse/lib/codereview/codereview.py

Andi

>
> Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com