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

[Tarek Ziadé]

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)

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

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