[Python-Dev] Patches and checkins for 1.6

[Tim Peters]

[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 <wink>.

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