[Python-ideas] Using only patches for pulling changes in hg.python.org

[M.-A. Lemburg]

Thomas Jollans wrote:
> On 07/04/2010 03:53 PM, Tarek Ziadé wrote:
>>
>> Do you have an easy way to perform this cleanup ? Could you propose a
>> process here ?
>>
>> I am bit skeptical that contributors will do this, whereas a patch
>> policy makes sure we don't have to deal with this, and avoid asking
>> people to have a high mercurial-fu. I am also skeptical that
>> contributors are willing to digg into a clone to get what they want
>> and/or check that it's fine to pull.
>>
>> It seems to me that patches are the universal format to propose a
>> change and are easy to produce and consume. Contributors can use any
>> process they want to create it, even without using mercurial.
> 
> There's no reason to force those of us capable of producing clean hg
> branches back into the world of patches. I can see why you'd want to be
> able to say "no, this repo is a mess. Submit something presentable, like
> a patch." Some "how to contribute" document might recommend using mq,
> but it shouldn't be a requirement - pulling comes naturally with DVCS.
> Python should use it.
> 
> Accept patches - sure - not everyone uses mercurial. Require patches -
> please don't!

I'm with Tarek here: the only way for core developers to be able to
review checkins on the checkins list is by looking at the patches
that go in.

Having to look at 10+ checkin emails for a single "patch" will
break this review process - no-one will be able to follow what
a particular pulled set of changes will do in the end, compared
to what we had in the repo before the pull. As a result, the
review process will no longer be possible.

As example, see Tarek's pull/push of the distutils2 work. Those
checkin email will just rush by and not get a second or third
review.

OTOH, I don't think that requiring to open a ticket on the tracker
for everything is needed either.

Aside 1: Isn't it interesting that the more we actually think about
moving to Mercurial, the more we find that the existing Subversion
model of working is actually a very workable model for a large
open source project ?!

Aside 2: This thread should really be moved to python-dev where
it belongs.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 05 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/
________________________________________________________________________
2010-07-19: EuroPython 2010, Birmingham, UK                13 days to go

::: 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/