[Python-Dev] Workflow proposal (original) (raw)

Jesus Cea jcea at jcea.es
Tue Mar 22 18:38:12 CET 2011

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

  1. Pull.
  2. Merge the two heads.
  3. Merge that merge to the other branches, as necessary. Since the two heads were already merged to other branches, this merge should be trivial.
  4. 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:

  1. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and "default". Leave the original commit in "3.1" alone.
  2. Pull and rebase your commit to the incoming head. Now your local history is lineal.
  3. Do the merge to "3.2" and "default", locally.
  4. 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-----

More information about the Python-Dev mailing list