[Python-Dev] Workflow proposal

[Jesus Cea]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Most of our problems are related to trying to keep a lineal history, and
races with pull-patch-commit-push cycle. I propose the following workflow.

All branches (except 2.7) MUST be merged to default, all the time. This
must be enforced by the push hook.

The workflow would be something like this:

1. Update the local clone.
2. I patch 3.1. Test the patch locally.
3. Commit the patch locally.
4. Merge the patch to 3.2 locally.
5. Merge the patch to "default" locally.
6. Push.

If there are no other pushes in the meantime, we are done. If there are
other pushes, we will have a "+1 head" and the push is rejected.

Now we have two options.

The easier and "mercurial" way would be:

6. Pull.
7. Merge the two heads.
8. Merge that merge to the other branches, as necessary. Since the two
heads were already merged to other branches, this merge should be trivial.
9. Push.

If we have some other pushes in the meantime, repeat again from 6. You
will eventually win the race :).

This head merging could be "ugly" to some people (not me), so other
approach would be, if the original "merging" is easy:

6. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and
"default". Leave the original commit in "3.1" alone.
7. Pull and rebase your commit to the incoming head. Now your local
history is lineal.
8. Do the merge to "3.2" and "default", locally.
9. Try to push.

If there are more pushes in the meantime, repeat from 6.

This second approach keep a lineal history, but it is more "dangerous"
and can be a pain if the merges to "3.2" and "default" are not trivial,
because you must do them several times.

This workflow works well ONLY if we forbid to have active branches
(except "default" and "2.7"). That is, forbidding having branches not
merged to new versions. That is, 3.1 merged to 3.2 and default, 3.2
merged to default. This should be implemented in the push hook.

If some patches in 3.1 should not be in 3.2/default, we MUST do a null
merge anyway. The "no active branches" must not be broken. It should be
a firm policy enforced by the push hook.

So good so far.

But there is a *legitime* reason for pushing a 3.1 patch without
merging... trying the patch in the buildbots, maybe redoing it a few
times, discussing it bugs.python.org, try several approaches, etc,
before closing the issue and merging to 3.2 and "default". But that is
an artifact of the way we interact with the buildbots. If I could do the
following, it would be AMAZING:

1. Write a patch in my local clone.
2. Commit it locally.
3. Push my clone to a SANDBOX in hg.python.org ("hg push sandbox"). This
sandbox is synchronized with the official HG repository. If my push
create a "+1 head", we have a race. I must pull and merge, and try to
push again.
4. When I get my patch in the sandbox. the sandbox accepts it, generate
a patch relative to current tip from hg.python.org, and strip that
commit. The sandbox must be always synchronized with hg.python.org. Its
only mission is to validate that your patch applies cleanly to current
tip, that you have push permissions (security).
5. The buildbots should checkout hg.python.org and apply your patch over
the working directory. Run the buildbots testing.
6. You wait for the results.
7. If you are not ok with the result, your keep modifying your clone.
When you want to try, you push to the sandbox, for trying.
8. When you are satisfied with the result, you do the merge to the other
branches and push to "hg.python.org".

Several people can use the sandbox at the same time, since it is
synchronized with hg.python.org and it strips your patch inmediatelly,
so nobody will see your patch. In fact, this sandbox could add your
patch automatically to the assigned issue (bugs.python.org).

We already have "cloned in the server" repositories, but I am not sure
how to delete them, how to push them to the buildbots (is it efficient?,
of the buildbots must pull the complete repo each time?), I must care
about pushing it the last changes in hg.python.org, etc.

Ideas?.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYjehJlgi5GaxT1NAQInJAQAn61i1YFwUB/IXkNazJZfRi3dVYVTikbE
t5qBpvFKZKA/s90y6fP6usa09DZVlYXsb95leMIaTc2BjXzgB5qd9I47rFlA+pbk
mjHbVoDmsNcjjI93lRhZV4p7MSeWWSkNDpF/H3qi/bPw3MKqkJFpT9sVkboBs3iO
UbtKE9+Dnno=
=GVMW
-----END PGP SIGNATURE-----