This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author chris.jerdonek
Recipients chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan, pitrou, sandro.tosi, terry.reedy, tshepang
Date 2013-01-03.20:03:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1357243415.51.0.806143516887.issue14468@psf.upfronthosting.co.za>
In-reply-to
Content
One thing that occurred to me is that it is often or usually not sufficient to go from 2.7 to 3.2 and on forward because applying a patch made against the default branch loses information if first applied to an earlier branch.  The given workflow assumes no loss of information and so should probably note this constraint.

I usually craft my patch against the default branch.  If applying to 2.7 or 3.2, etc. loses information (which has been more often the case for me), then instead of merging I null-merge and reapply the original patch.  Should the recommended workflow cover this possibility?
History
Date User Action Args
2013-01-03 20:03:35chris.jerdoneksetrecipients: + chris.jerdonek, terry.reedy, ncoghlan, pitrou, ezio.melotti, eric.araujo, sandro.tosi, tshepang
2013-01-03 20:03:35chris.jerdoneksetmessageid: <1357243415.51.0.806143516887.issue14468@psf.upfronthosting.co.za>
2013-01-03 20:03:35chris.jerdoneklinkissue14468 messages
2013-01-03 20:03:35chris.jerdonekcreate