[Python-Dev] Patches and checkins for 1.6 (original) (raw)

Tim Peters tim_one@email.msn.com
Fri, 11 Aug 2000 02:48:56 -0400

[Mark Hammond]

I would like a little guidance on how to handle patches during this 1.6 episode.

My understanding of CVS tells me that 1.6 has forked from the main development tree. Any work done in the 1.6 branch will need to also be done in the main branch. Is this correct?

Don't look at me -- I first ran screaming in terror from CVS tricks more than a decade ago, and haven't looked back. OTOH, I don't know of any work done in the 1.6 branch yet that needs also to be done in the 2.0 branch. Most of what Fred Drake has been doing is in the other direction, and the rest has been fixing buglets unique to 1.6.

If so, it means that all patches assigned to me need to be applied and tested twice, which involves completely refetching the entire tree, and rebuilding the world?

Patches with new features should not go into the 1.6 branch at all! 1.6 is meant to reflect only work that CNRI has clear claims to, plus whatever bugfixes are needed to make that a good release. Actual cash dollars for Unicode development were funneled through CNRI, and that's why the Unicode features are getting backstitched into it. They're unique, though.

Given that 1.6 appears to be mainly an exercise in posturing by CNRI,

Speaking on behalf of BeOpen PythonLabs, 1.6 is a milestone in Python development, worthy of honor, praise and repeated downloading by all. We at BeOpen PythonLabs regret the unfortunate misconceptions that have arisen about its true nature, and fully support CNRI's wise decision to force a release of Python 1.6 in the public interest.

is it reasonable that I hold some patches off while I'm working with 1.6, and check them in when I move back to the main branch?

I really don't know what you're doing. If you find a bug in 1.6 that's also a bug in 2.0, it should go without saying that we'd like that fixed ASAP in 2.0 as well. But since that went without saying, and you seem to be saying something else, I'm not sure what you're asking. If you're asking whether you're allowed to maximize your own efficiency, well, only Guido can force you to do something self-damaging .

Surely no one will stick with 1.6 in the long (or even medium) term, once all active development of that code ceases?

Active development of the 1.6 code has already ceased, far as I can tell. Maybe some more Unicode patches? Other than that, just bugfixes as needed. It's down to a trickle. We're aiming for a quick beta cycle on 1.6b1, and-- last I heard, and barring scads of fresh bug reports --intending to release 1.6 final next. Then bugs opened against 1.6 will be answered by "fixed in 2.0".

Of course, this wouldn't include critical bugs, but no one is mad enough to assign them to me anyway

Confused-and-in-need-of-a-machine-upgrade ly,

And we'll buy you one, too, if you promise to use it to fix the test_fork1 family of bugs on SMP Linux boxes!

don't-forget-that-patches-to-1.6-still-need-cnri-release-forms!- and-that-should-clarify-everything-ly y'rs - tim