[Python-Dev] check-in policy, trunk vs maintenance branch

[Alex Martelli]

I made a few bugfix check-ins to the 2.3 maintenance branch this weekend and 
Michael Hudson commented that he thinks that so doing is a bad idea, that bug
fixes should filter from the 2.4 trunk to the 2.3 branch and not the other way 
around.  Is this indeed the policy (have I missed some guidelines about it)? 

I guess for this round of fixes I will find the time to forward-port them to 
the 2.4 trunk (in AMPLE time for a 2.4 release -- as 2.3.3 is going to come 
well before 2.4 releases, the other way 'round wouldn't be quite so sure:-),
but what about the future?  Should fixes applicable to both 2.3.* and 2.4
be made [a] always to both trunk and branch, [b] always to the trunk but
to the branch only once one comes around to that, [c] always to the branch but
to the trunk only once one comes around to that, ...?

Oh, incidentally, if it matters -- most were docs issues, including as "docs" 
also some changes to comments that previously were misleading or ambiguous.

I guess that my problem is that I think of 2.3.* fixes as things that will be 
useful to "the general Python-using public" pretty soon, with 2.4 far off in 
the future, so that it appears to me that trying to make 2.3.* as well fixed
as possible has higher priority.  But if that conflicts with policy, I will of 
course change anyway.


Thanks,

Alex