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

[M.-A. Lemburg]

Thomas Jollans wrote:
> On 07/05/2010 09:30 AM, M.-A. Lemburg wrote:
>> 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.
> 
> If the problem is the amount of changesets per "patch", then it has to
> be the responsibility of the person committing - be that a core dev or
> an external contributor - to make sure it's only a single changeset.
> OTOH, I don't think being that strict about it is a good idea - in many
> cases, having a handful of changesets is, IMHO, better, with Mercurial.
> 
> Either way, if there is some sort of policy stating how changes should
> look, I for one would be happy to publish a branch on bitbucket or my
> own hgweb instance in that format. Permitting text patches is a must,
> but requiring text patches when we have actual distributed branching is
> quite the anachronism.

You need those patches anyway, since that's how we review things
on the issue tracker.

The point I wanted to make was that (at least some of) the core
devs do monitor the checkins list for new code and/or changes
to existing code going in. This would not longer reasonably
work, if you start pushing revisions of patches down the list
as well.

The history of those patches is not all that interesting to
Python developers. It's the final outcome, that makes the
difference.

>> 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.
> 
> If the problem is the amount of emails per "patch" then, for god's sake,
> change the script that writes the emails to send a mail per push,
> instead of a mail per commit !
> 
> DVCSs allow one to have small, atomic (but, of course, inter-dependent)
> commits, and push them later. I myself feel that this property should be
> valued, not feared.

This is not a matter of receiving the patch in 10+ emails, or
lumping everything into one email.

I simply don't see any benefit in having to follow the path of
development of a patch. Much to the contrary: it only adds noise
that distracts from the important bits. The discussion of a patch
is recorded on the issue tracker anyway and in a form that is
more easily comprehensible than a set of checkin messages.

>> 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 ?!
> 
> It's all a question of how changes are reviewed and synchronised. Of
> course, the Python subversion model works, no question. The specific
> approach "turn every commit into an email for proof reading" appears to
> work well with it. It may not work as well with hg. It may work better
> if you s/commit/push/ instead of s/commit/changeset/. Other projects
> work in a more distributed fashion, with developers' private
> repositories, changes being reviewed before pulling/merging. Linux is,
> of course, a prominent example. If this approach is for Python, I don't
> know. I doubt it, at least for the time being. But a suitable workflow
> will surely be found.
> 
> 
> Ah well, we'll see what happens.

Certainly.

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