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

[Thomas Jollans]

On 07/04/2010 03:53 PM, Tarek Ziadé wrote:
> 
> 
> On Sun, Jul 4, 2010 at 3:23 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> ...
>>
>> Hmm, I don't think I agree on what you're saying.
>>
>> First, a changeset is a changeset is a changeset. If you exchange them as
>> patches or in some other way (by pulling or pushing or whatever) shouldn't
>> really matter. This is one of the things DVCS is good at, you can move csets
>> around different clones in many ways, and all clones are created equal.
> 
> As far as I have experienced, there's a back and forth game between
> the contributor and the commiter, leading to clone hell, unless the
> contributor uses mq, then apply it in his clone
> right before the contributor pulls the changes in.
> 
> Using patches makes changes separated from the history for the time
> being, until they are merged. And are easy to read, review and
> understand.
> 
>> Second, a noisy history is never good. So yes, pulling some kind of messy
>> history and pushing it to a central repo as-is is not a good idea. People
>> should polish their changesets so that each changeset can stand on its own.
> 
> When you work on a feature, how do you polish a changeset without
> polluting your history or doing many clones ? (true question, I've
> been looking for that)

mq is a good method. If a changeset that only exists locally has to be
changed, you can convert it to a patch, make some changes, and
re-commit. If the changesets are relatively clean in the first place,
you can rebase/transplant/strip your way  around too big a mess.

> 
>> So yes, somewhere between it being a messy history of actual development and
>> it going into a central repo, it should be cleaned up. Ideally, the original
>> author should do that, but if he's not in a position to do so, the committer
>> should do it.
> 
> 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!

> 
>>
>> Third, if the result of cleaning up is a single cset, it should probably be
>> rebased before getting pushed to a central repo. If it's two or three csets,
>> rebase it. On the other hand, if it's 10 csets, actually doing an explicit
>> merge makes sense. The idea is not to clutter up the history with a merge
>> every other cset, but if the merge is hard/non-trivial it can make sense to
>> leave it explicit.
>>
>> Fourth, one-patch-per-issue is too restrictive. Small commits are useful
>> because they're way easier to review. Concatenate several small commits
>> leading up to a single issue fix into a single patch and it gets much harder
>> to read. Easy reviews are important, because a lot of valuable time is spent
>> reviewing. The simple example is a chain like refactor-refactor-fix (which
>> is IME quite common). Ideally each stage keeps the test suite passing and is
>> internally consistent, but moving towards a common goal (to fix the issue).
>>
>> So, I find your proposed policy somewhat vague and also not that attractive.
>> Cleaning up the history is certainly a good thing, but I don't think we have
>> to mandate a way for things to get into the repo. Mandating the use of
>> issues as a reference for each fix or enhancement could be useful, but seems
>> unnecessary.
> 
> Yes, it's vague, I don't have a clear idea yet and I am not that
> experienced in hg latest features, so I am probably doing some steps
> wrong or ignore some shortcuts.
> 
> But I have the strong feeling that without patches, we are heading for
> extra work for all parties
> unless we have a strong tutorial on how to contribute with
> hg.python.org, and that is proven to be very simple.
> 
> side note: I am replying to the gname emails but I don't know if this
> works with the mailman thread as well..
> 
> Tarek
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>