Needing feedback on the Python developer's guide

[Greg Ward]

On 26 February 2011, Antoine Pitrou said:
> However, we have a couple of unresolved questions/issues with workflow
> suggestions:
> 
> - how do we suggest people backport patches from the default branch (which is
> for 3.x development) to the 2.7 maintenance branch? Our branch structure is more
> complex than the traditional stable/default separation, since we have two
> independent maintenance branches (2.7 and 3.2) in addition to the default
> development branch (the future 3.3). Oh, and we already have security fixes-only
> branches (2.5, 2.6, soon 3.1), but let's ignore that for the moment ;)

Backporting is bad.  Merging forward is good.  If it's possible to
arrange things so that there is a natural order of branches (say, 2.5 ->
2.6 -> 2.7 -> 3.1 -> 3.2 -> trunk), that would be good.  That's a long
chain of merges for the rare security fixes on 2.5, but it's a sane and
sensible order.

I've always felt this way about Python's workflow; back when I
occasionally worked on Python, I did my bug fixes on a release branch
and then merged forwards.  It just seemed right, and the normal backport
worfklow seemed wrong.

BTW, the reason *why* backports are bad can be explained in one word:
dependencies.  If I commit a change to trunk or 3.2, it is much more
likely to depend on infrastructure (or even subtle bug fixes) present in
that version.  If I then try to backport it, it's more likely to not
work.  But if I have a working patch on an old version, it's more likely
to keep working as I merge to progressively later branches.

Or at least, that's the theory.  ;-)

        Greg
-- 
Greg Ward                                http://www.gerg.ca/
If you don't have anything nice to say, come sit by me.
     --Dorothy Parker