
Can someone remind me which branches regular (non-security) bug fixes go to these days? See <http://bugs.python.org/issue23600> for context.

On Sun, 27 Sep 2015 21:08:02 -0400, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
Can someone remind me which branches regular (non-security) bug fixes go to these days? See <http://bugs.python.org/issue23600> for context.
3.4, 3.5, and default. (3.4 for only another few weeks.) --David

On Sun, Sep 27, 2015 at 9:12 PM, R. David Murray <rdmurray@bitdance.com> wrote:
remote has heads on branch '3.4' that are not known locally: 46aaff5e8945 remote has heads on branch '3.5' that are not known locally: 0d3b64bbc82c remote has heads on branch 'default' that are not known locally: 48943533965e abort: push creates new remote head ff68705c56a8 on branch '3.4'!

On 9/27/2015 10:05 PM, Alexander Belopolsky wrote:
3.4.4rc1 is due out next Sunday. Only emergency patches after that.
Thanks. Maybe you can help me to make hg cooperate. I made commits to 3.4, 3.5, and default and tried to push, but hg complains:
See the python-checking list, which you should be reading. You neglected to forward merge a 3.4-3.4 merge and a 3.5-3.5 merge. I failed to notice the first and added a commit, and then backed it out, when I could not merge forward due to merge conflicts with your commits. Perhaps you just need to null-merge the 3.4 commits into 3.5, but I do not really know how to make the repository usable again.
-- Terry Jan Reedy

On 28/09/2015, Terry Reedy <tjreedy@udel.edu> wrote:
Hopefully I have fixed this for you. My technique is below. I first tried with Mercurial 2.7, but updated to 3.5 which apparently grew some support for “criss-cross” merges, and this helped a lot with the second merge. hg update 3.5 hg merge 3.4 # NEWS and Argument Clinic files conflict hg revert -r . Misc/NEWS Modules/clinic/_datetimemodule.c.h python Tools/clinic/clinic.py --make # Verify both Alexander and Serhiy’s entries already in NEWS hg diff -p # No file changes to 3.5 branch hg resolve -m hg commit -m "Merge from 3.4 into 3.5; no file changes" hg update default hg merge 3.5 # No conflicts; 3 × “ambiguous merge - picked m action” hg diff -p # Duplicate NEWS entry hg revert -r . Misc/NEWS hg diff -p # No changes hg commit -m "Merge from 3.5; no file changes" Summary of what I think was going on: Serhiy made some changes quite a few hours ago to do with readline.set_completer_delims(). Meanwhile, Alexander made some tzinfo.fromutc() commits based on revisions before Serhiy’s changes. A couple comments on Alexander’s commits: ff68705c56a8: Initial 3.4 patch has a trailing space in NEWS c706c062f545: Initial merge into 3.5 removes this trailing space cbcf82f92c25: Looks like a second version of the original patch (ff68705c56a8), except without the extra space. I guess you got confused, but it would have been better to not push this commit :) Also @Terry, not sure on your workflow, but you might have been able to avoid pushing your 3.4 commits. You might have been able to remove it locally by using “hg strip” or deleting your local repository. Or just leave it locally until the other branches got sorted out. Notice that the 3.4 branch still has your backout commit at the top. For what it’s worth, I have more faith in Git for merging stuff like this smoothly. But today I learnt that the newer Mercurial version does behave a bit better than it used to.

On 9/28/2015 2:56 AM, Martin Panter wrote:
Also @Terry, not sure on your workflow,
Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6, except I do it with TortoiseHG Workbench GUI.
I need to look into that.
or deleting your local repository.
I have 1 clone for default/3.6 and 3 shares with working directory only for 3.5, 3.4, and 2.7. I believe that deleting 3.4 working directory would have no effect as it would be regenerated from default clone.
Or just leave it locally until the other branches got sorted out.
Then I risked having to do a head merge in 2.7 or head merge + forward merges in 3.4,5,6 is someone else pushed before I got back to this, which I know was going to be several hours, after returning from rushing off to work on another project.
Notice that the 3.4 branch still has your backout commit at the top.
Your merges merged my commit and revert forward. I could have left just the commit, but they whoever would have had to decide what to do with it. I though it easier for me to just start over, which I will try now. -- Terry Jan Reedy

On Mon, Sep 28, 2015 at 4:13 AM, Terry Reedy <tjreedy@udel.edu> wrote:
Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6,
That's exactly what I did at fist, but apparently while I was doing this, another commit was pushed to all three branches. To recover, I did a series of hg update 3.x; hg merge dances fighting with Misc/NEWS on every turn.

See http://bugs.python.org/issue18967 if you want to join the discussion on how to solve Misc/NEWS potentially in the short term (long term we have a plan once someone has time to hack on the issue tracker). On Mon, 28 Sep 2015 at 10:12 Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

On 9/28/2015 1:12 PM, Alexander Belopolsky wrote:
You lost a push race. To minimize to possibility of that, I get everything ready so that I can commit and merge with under 15 (or 20) mouse clicks, without editing anything, after a final pull that does not pull anything. (Sunday, I left out the 'clean repository' check and the the final 'nothing found' pull. I have a .bat file to pull into default and update all 4 working directory branches.) With everything set up, I can commit to 2.7 and 3.4 and merge into 3.5 and 3.6 in under a minute. This means having no merge conflicts or having them 'pre-resolved' -- see below.
To recover, I did a series of hg update 3.x; hg merge dances fighting with Misc/NEWS on every turn.
Hg almost never merges Idle news items correctly, even when there is no real conflict, and even when it says there was no conflict. In the latter case, it may have merged in the wrong place, such as putting a things into the 3.5.1 section of 3.6 NEWS, which should not be there. So I assume that NEWS merges will always be wrong. After what I hope will be the next to last pull, when everything else is done, I open 2.7, 3.4, 3.5, and 3.6 NEWS on separate tabs (of Notepad++), edit 2.7 and save, copy-paste to 3.4 news and save, then copy-paste into 3.5 and 3.6 WITHOUT saving. After merging into 3.5, before commiting, I revert NEWS to local, switch to Notepad++, being sure to click [No] File changed, reload?, save the correct 3.5 NEWS, mark resolved, and commit. Ditto for 3.6. (I do this in batches, when no one else seems active.) -- Terry Jan Reedy

On 28 September 2015 at 22:31, Terry Reedy <tjreedy@udel.edu> wrote:
. . . it may have merged in the wrong place, such as putting a things into the 3.5.1 section of 3.6 NEWS, which should not be there.
Since you mentioned this and I also noticed this, can I ask why the 3.5.1 section is there, if it isn’t meant to be? There are also other sections, going back to 3.4.0. They have been there for a while. Is it just that nobody removed it when it was inherited from 3.5 and 3.4? When I have merged bug fixes into the default 3.6 branch I have sometimes let the NEWS entries be automatically be merged into the 3.5.1 section, without updating the 3.6.0 section, after I noticed other people doing this. Perhaps we should get rid of the old pre-3.6 sections (perhaps after adding any missing entries to the 3.6 section)? Otherwise I imagine some release manager might come along and chop them all out without adding anything to the 3.6 section.

It used to be tradition to keep old news sections. Looks like the last time we cleared it out was for 3.4.0. But it's suspicious there's no section for 3.6 at all. Unless... 3.6 has nothing new yet, it's all just bugfixes ported from 3.5? On Mon, Sep 28, 2015 at 4:05 PM, Martin Panter <vadmium+py@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)

On 9/28/2015 7:05 PM, Martin Panter wrote:
I believe it should not be there and that everything in there should be moved to the 3.6.0a1 section (if not already there). (I already did that for IDLE.) Every commit* to a particular branch should be in the NEWS section for the next release of that branch. The purpose of the M.N.Pa section is to record commits to the M.N branch that will appear in the M.N.Pa release. AFAIK, this has always been the policy until this bogus 3.5.1 section was added to 3.6 NEWS. *Multiple commits for what is conceptually the one patch for one issue may get folded together into one NEWS entry, but that does not change the gist of the claim. In 3.5 NEWS, the 3.5.0a1 section follows 3.4.0 (final). There are no 3.4.1 etc sections. All the commits to 3.5 that appeared in 3.5.0a1, which branched off from 3.4 at the final release or a bit sooner, are in the 3.5.0a1 section.
There are also other sections, going back to 3.4.0.
There are from before the 3.6 branch was separated from 3.5 (or vice versa, if you prefer). In other words, before there was a 3.6.0a1 to commit to. Whether NEWS should be cumulative or not is a different issue.
If I am correct as to the intent of each section, this is a mistake. I always revert NEWS merges and then save the separately edited file for the branch, because hg routinely either creates a (incorrect) conflict (for Idle items)* or now, with the incorrect 3.5.1 section in 3.6 NEWS, puts things in that incorrect place. *My guess is that this results from hg merge considering both context match and offset when picking the 'best' merge. For items after the Library section, the offset of a correct merge can be 100s of lines. -- Terry Jan Reedy

On Sun, 27 Sep 2015 21:08:02 -0400, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
Can someone remind me which branches regular (non-security) bug fixes go to these days? See <http://bugs.python.org/issue23600> for context.
3.4, 3.5, and default. (3.4 for only another few weeks.) --David

On Sun, Sep 27, 2015 at 9:12 PM, R. David Murray <rdmurray@bitdance.com> wrote:
remote has heads on branch '3.4' that are not known locally: 46aaff5e8945 remote has heads on branch '3.5' that are not known locally: 0d3b64bbc82c remote has heads on branch 'default' that are not known locally: 48943533965e abort: push creates new remote head ff68705c56a8 on branch '3.4'!

On 9/27/2015 10:05 PM, Alexander Belopolsky wrote:
3.4.4rc1 is due out next Sunday. Only emergency patches after that.
Thanks. Maybe you can help me to make hg cooperate. I made commits to 3.4, 3.5, and default and tried to push, but hg complains:
See the python-checking list, which you should be reading. You neglected to forward merge a 3.4-3.4 merge and a 3.5-3.5 merge. I failed to notice the first and added a commit, and then backed it out, when I could not merge forward due to merge conflicts with your commits. Perhaps you just need to null-merge the 3.4 commits into 3.5, but I do not really know how to make the repository usable again.
-- Terry Jan Reedy

On 28/09/2015, Terry Reedy <tjreedy@udel.edu> wrote:
Hopefully I have fixed this for you. My technique is below. I first tried with Mercurial 2.7, but updated to 3.5 which apparently grew some support for “criss-cross” merges, and this helped a lot with the second merge. hg update 3.5 hg merge 3.4 # NEWS and Argument Clinic files conflict hg revert -r . Misc/NEWS Modules/clinic/_datetimemodule.c.h python Tools/clinic/clinic.py --make # Verify both Alexander and Serhiy’s entries already in NEWS hg diff -p # No file changes to 3.5 branch hg resolve -m hg commit -m "Merge from 3.4 into 3.5; no file changes" hg update default hg merge 3.5 # No conflicts; 3 × “ambiguous merge - picked m action” hg diff -p # Duplicate NEWS entry hg revert -r . Misc/NEWS hg diff -p # No changes hg commit -m "Merge from 3.5; no file changes" Summary of what I think was going on: Serhiy made some changes quite a few hours ago to do with readline.set_completer_delims(). Meanwhile, Alexander made some tzinfo.fromutc() commits based on revisions before Serhiy’s changes. A couple comments on Alexander’s commits: ff68705c56a8: Initial 3.4 patch has a trailing space in NEWS c706c062f545: Initial merge into 3.5 removes this trailing space cbcf82f92c25: Looks like a second version of the original patch (ff68705c56a8), except without the extra space. I guess you got confused, but it would have been better to not push this commit :) Also @Terry, not sure on your workflow, but you might have been able to avoid pushing your 3.4 commits. You might have been able to remove it locally by using “hg strip” or deleting your local repository. Or just leave it locally until the other branches got sorted out. Notice that the 3.4 branch still has your backout commit at the top. For what it’s worth, I have more faith in Git for merging stuff like this smoothly. But today I learnt that the newer Mercurial version does behave a bit better than it used to.

On 9/28/2015 2:56 AM, Martin Panter wrote:
Also @Terry, not sure on your workflow,
Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6, except I do it with TortoiseHG Workbench GUI.
I need to look into that.
or deleting your local repository.
I have 1 clone for default/3.6 and 3 shares with working directory only for 3.5, 3.4, and 2.7. I believe that deleting 3.4 working directory would have no effect as it would be regenerated from default clone.
Or just leave it locally until the other branches got sorted out.
Then I risked having to do a head merge in 2.7 or head merge + forward merges in 3.4,5,6 is someone else pushed before I got back to this, which I know was going to be several hours, after returning from rushing off to work on another project.
Notice that the 3.4 branch still has your backout commit at the top.
Your merges merged my commit and revert forward. I could have left just the commit, but they whoever would have had to decide what to do with it. I though it easier for me to just start over, which I will try now. -- Terry Jan Reedy

On Mon, Sep 28, 2015 at 4:13 AM, Terry Reedy <tjreedy@udel.edu> wrote:
Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6,
That's exactly what I did at fist, but apparently while I was doing this, another commit was pushed to all three branches. To recover, I did a series of hg update 3.x; hg merge dances fighting with Misc/NEWS on every turn.

See http://bugs.python.org/issue18967 if you want to join the discussion on how to solve Misc/NEWS potentially in the short term (long term we have a plan once someone has time to hack on the issue tracker). On Mon, 28 Sep 2015 at 10:12 Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

On 9/28/2015 1:12 PM, Alexander Belopolsky wrote:
You lost a push race. To minimize to possibility of that, I get everything ready so that I can commit and merge with under 15 (or 20) mouse clicks, without editing anything, after a final pull that does not pull anything. (Sunday, I left out the 'clean repository' check and the the final 'nothing found' pull. I have a .bat file to pull into default and update all 4 working directory branches.) With everything set up, I can commit to 2.7 and 3.4 and merge into 3.5 and 3.6 in under a minute. This means having no merge conflicts or having them 'pre-resolved' -- see below.
To recover, I did a series of hg update 3.x; hg merge dances fighting with Misc/NEWS on every turn.
Hg almost never merges Idle news items correctly, even when there is no real conflict, and even when it says there was no conflict. In the latter case, it may have merged in the wrong place, such as putting a things into the 3.5.1 section of 3.6 NEWS, which should not be there. So I assume that NEWS merges will always be wrong. After what I hope will be the next to last pull, when everything else is done, I open 2.7, 3.4, 3.5, and 3.6 NEWS on separate tabs (of Notepad++), edit 2.7 and save, copy-paste to 3.4 news and save, then copy-paste into 3.5 and 3.6 WITHOUT saving. After merging into 3.5, before commiting, I revert NEWS to local, switch to Notepad++, being sure to click [No] File changed, reload?, save the correct 3.5 NEWS, mark resolved, and commit. Ditto for 3.6. (I do this in batches, when no one else seems active.) -- Terry Jan Reedy

On 28 September 2015 at 22:31, Terry Reedy <tjreedy@udel.edu> wrote:
. . . it may have merged in the wrong place, such as putting a things into the 3.5.1 section of 3.6 NEWS, which should not be there.
Since you mentioned this and I also noticed this, can I ask why the 3.5.1 section is there, if it isn’t meant to be? There are also other sections, going back to 3.4.0. They have been there for a while. Is it just that nobody removed it when it was inherited from 3.5 and 3.4? When I have merged bug fixes into the default 3.6 branch I have sometimes let the NEWS entries be automatically be merged into the 3.5.1 section, without updating the 3.6.0 section, after I noticed other people doing this. Perhaps we should get rid of the old pre-3.6 sections (perhaps after adding any missing entries to the 3.6 section)? Otherwise I imagine some release manager might come along and chop them all out without adding anything to the 3.6 section.

It used to be tradition to keep old news sections. Looks like the last time we cleared it out was for 3.4.0. But it's suspicious there's no section for 3.6 at all. Unless... 3.6 has nothing new yet, it's all just bugfixes ported from 3.5? On Mon, Sep 28, 2015 at 4:05 PM, Martin Panter <vadmium+py@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)

On 9/28/2015 7:05 PM, Martin Panter wrote:
I believe it should not be there and that everything in there should be moved to the 3.6.0a1 section (if not already there). (I already did that for IDLE.) Every commit* to a particular branch should be in the NEWS section for the next release of that branch. The purpose of the M.N.Pa section is to record commits to the M.N branch that will appear in the M.N.Pa release. AFAIK, this has always been the policy until this bogus 3.5.1 section was added to 3.6 NEWS. *Multiple commits for what is conceptually the one patch for one issue may get folded together into one NEWS entry, but that does not change the gist of the claim. In 3.5 NEWS, the 3.5.0a1 section follows 3.4.0 (final). There are no 3.4.1 etc sections. All the commits to 3.5 that appeared in 3.5.0a1, which branched off from 3.4 at the final release or a bit sooner, are in the 3.5.0a1 section.
There are also other sections, going back to 3.4.0.
There are from before the 3.6 branch was separated from 3.5 (or vice versa, if you prefer). In other words, before there was a 3.6.0a1 to commit to. Whether NEWS should be cumulative or not is a different issue.
If I am correct as to the intent of each section, this is a mistake. I always revert NEWS merges and then save the separately edited file for the branch, because hg routinely either creates a (incorrect) conflict (for Idle items)* or now, with the incorrect 3.5.1 section in 3.6 NEWS, puts things in that incorrect place. *My guess is that this results from hg merge considering both context match and offset when picking the 'best' merge. For items after the Library section, the offset of a correct merge can be 100s of lines. -- Terry Jan Reedy
participants (7)
-
Alexander Belopolsky
-
Brett Cannon
-
Eric V. Smith
-
Guido van Rossum
-
Martin Panter
-
R. David Murray
-
Terry Reedy