When do we stop automerging from trunk to py3k?
Pardon my general n00bishness, but I crave knowledge. IIUC currently if you have a checkin in trunk that you *don't* want merged into py3k, you must svnmerge block it in py3k. Otherwise it will be automatically merged at some point.
My question is: when will we stop doing that? I assume that as time
passes trunk and py3k will continue to drift further and further apart.
My guess is that more checkins are blocked than are allowed through. So
when will we stop the automerging?
Or is this question a sign of a more fundamental misunderstanding?
I'm afraid I have to tell you even I really just don't know,
/larry/
Le mardi 27 avril 2010 à 03:23 -0700, Larry Hastings a écrit :
Pardon my general n00bishness, but I crave knowledge. IIUC currently if you have a checkin in trunk that you *don't* want merged into py3k, you must svnmerge block it in py3k. Otherwise it will be automatically merged at some point.
Your U is not C. Nobody/nothing automerges. On the contrary, it is highly recommended that you "svnmerge merge" changes yourself if you want them to be merged (that is, ported).
It is also recommended that you "svnmerge block" changes which you think shouldn't be ported to py3k. That way, it will leave the merge queue clean and short (if it has ever been :-)).
Regards
Antoine.
On 27/04/2010 11:38, Antoine Pitrou wrote:
Le mardi 27 avril 2010 à 03:23 -0700, Larry Hastings a écrit :
Pardon my general n00bishness, but I crave knowledge. IIUC currently if you have a checkin in trunk that you *don't* want merged into py3k, you must svnmerge block it in py3k. Otherwise it will be automatically merged at some point.
Your U is not C. Nobody/nothing automerges. On the contrary, it is highly recommended that you "svnmerge merge" changes yourself if you want them to be merged (that is, ported).
It is also recommended that you "svnmerge block" changes which you think shouldn't be ported to py3k. That way, it will leave the merge queue clean and short (if it has ever been :-)).
Standard library changes are still *largely* amenable to merging.
My guess is that *after* the release of 2.7, and probably also after we switch to mercurial, py3k will become the equivalent of trunk. Of course once we switch to mercurial the use of svnmerge will stop. Bugfixes may still need merging from py3k to 2.7 (and 3.1), but not new features. Allegedly merging between branches will be easier with Mercurial anyway...
All the best,
Michael
Regards
Antoine.
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Michael Foord wrote:
Allegedly merging between branches will be easier with Mercurial anyway...
I hope an Hg expert can show how this can be done...
In particular, we don't want to pull all changes to 2.7 into 3k, and I haven't seen any sane way in Hg to say "just pull this changeset, no others"...
cheers,
Chris
Le mardi 27 avril 2010 à 14:01 +0100, Chris Withers a écrit :
Michael Foord wrote:
Allegedly merging between branches will be easier with Mercurial anyway...
I hope an Hg expert can show how this can be done...
In particular, we don't want to pull all changes to 2.7 into 3k, and I haven't seen any sane way in Hg to say "just pull this changeset, no others"...
Depends what you call "sane". There's the transplant extension, which aims precisely at managing cherry-picked patches. Otherwise, just "hg import" of a patch. Both don't seem more sophisticated/automated than the current workflow.
Regards
Antoine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 27/04/10 15:01, Chris Withers wrote:
Michael Foord wrote:
Allegedly merging between branches will be easier with Mercurial anyway...
I hope an Hg expert can show how this can be done...
In particular, we don't want to pull all changes to 2.7 into 3k, and I haven't seen any sane way in Hg to say "just pull this changeset, no others"...
There are extensions for it.
For instance <http://mercurial.selenic.com/wiki/TransplantExtension>.
Anyway, a possible simple workflow is to write patches for the older supported python version and merge them in newer versions, adjusted or, possibly, "backout"ed.
That is, patch 2.7 and "push" those changes to 3.x, undoing the unnecesary patches with a simple "backout".
This is far more automatic that cherrypicking patches, with the risk of forgeting some.
I can't wait for HG native use, and I am curious about the exact workflow we are going to use.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS9efgplgi5GaxT1NAQIT2QP9FCHzsKkBkZyOdkf5Zydnv65YUhEiVFre tGVMqfuP4XtzLSdGDUHBJYqg1Bw6piuzNtyTOGTvE7J70LfZsdvDOPo7gByKHdXp KkcrFruvqjN/Ff7ozJsnvT0rmBDUjGEt9PjrpTGUd3yMgWq42CJqe1j/KRiMuRRH dXz7UXTBBow= =sO/M -----END PGP SIGNATURE-----
Le mercredi 28 avril 2010 à 04:37 +0200, Jesus Cea a écrit :
That is, patch 2.7 and "push" those changes to 3.x, undoing the unnecesary patches with a simple "backout".
Good point. I haven't thought of the possibility of using "hg backout". However, those bugfixes must also be applied (usually) to 3.1, which makes the workflow graph a bit uncertain: (3.1 -> 2.7) and (3.1 -> 3.x)?
Regards
Antoine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 28/04/10 12:17, Antoine Pitrou wrote:
Le mercredi 28 avril 2010 à 04:37 +0200, Jesus Cea a écrit :
That is, patch 2.7 and "push" those changes to 3.x, undoing the unnecesary patches with a simple "backout".
Good point. I haven't thought of the possibility of using "hg backout". However, those bugfixes must also be applied (usually) to 3.1, which makes the workflow graph a bit uncertain: (3.1 -> 2.7) and (3.1 -> 3.x)?
Yes, I would "push":
2.6 -> 2.7 -> 3.1 -> 3.x
Versions in the right must include patches done for the versions in the left. Also, versions more in the left change less.
I am not formally proposing this workflow, but it would leverage the merge excellence of Mercurial.
The bad thing about "backout" is the polution of the repository history. Another option would be to push the change and do a "null merge", were we actually "cancel" the change. But that would "lie" in the history and could require a fake commit in the "tip" to have two heads to merge.
Looking in this way, the "backout" path seems better, because it documents both "we have considered this patch" as the outcome "but we don't need it in this repository".
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS9hp8Jlgi5GaxT1NAQLOzAP+KBx0UIrRtXkPBDMujm3L8pEhGzmBFdAF fIasqcyMMX/Z5ZpNFwIwQ/pcf4vgk8J8fbhV+DUJb4J7dHs8DMf/UZv0Xt/JXl88 IZOC23CwYSTcc3jp69frRdC/KUznmYRWyo5rzJ89R+vl1YDXD5tZPX8djv+6Aoew L8BxKJ9rUvw= =KUEr -----END PGP SIGNATURE-----
On Tue, 27 Apr 2010 03:23:59 -0700, Larry Hastings <larry@hastings.org> wrote:
My guess is that more checkins are blocked than are allowed through. So when will we stop the automerging?
As Antoine said, there is no automerging. As for the number of commits that get ported to py3k, it is almost all of them. Only the ones that are backports from py3k get blocked, and there shouldn't be any more of those now that we are in beta for 2.7. New features only go into py3k at this point (and should get blocked on the 3.1 branch). py3k-only bugs go into py3k and then merged (by hand :) into 3.1. But most bug fixes still go into trunk, and are then merged to 2.6, py3k, and 3.1. So currently almost every commit to trunk should get merged to py3k. (There are a few exceptions where the bug only exists in the 2.x series, or where the merge gets done without using svnmerge for one reason or another.)
-- R. David Murray www.bitdance.com
Pardon my general n00bishness, but I crave knowledge. IIUC currently if you have a checkin in trunk that you *don't* want merged into py3k, you must svnmerge block it in py3k. Otherwise it will be automatically merged at some point.
My question is: when will we stop doing that?
Nobody has really answered this question, so let me try: After 2.7 is released (i.e. within two months), the 2.x branch (i.e. the trunk) will be closed for changes altogether. So merging changes from trunk to the 3.x branch becomes unnecessary, and we can stop doing that (*).
Around the same time, we will also switch to Mercurial, so the point of using svnmerge and blocking changes becomes irrelevant for that reason, also.
So in short: in less than two months.
Regards, Martin
(*) there still might be bug fixes applied to the 2.7 maintenance branch which also apply to the 3.x branch. I would expect that there won't be an automatic migration of all changes in either direction, and that, with Mercurial, migration of selected changes can occur in either direction. In any case, this will not be about the trunk.
participants (7)
-
"Martin v. Löwis" -
Antoine Pitrou -
Chris Withers -
Jesus Cea -
Larry Hastings -
Michael Foord -
R. David Murray