> > > I also like Andrew's idea of making everybody commit their changes in > > > both branches -- to scale the effort of keeping the maintenance branch > > > up-to-date. > > > > For bug fixes, I encourage that. The question will come up whether new > > features also need to be back-ported. > > There's a couple of simple cases: > > . Obvious bugs that should be backported. Where possible, the original > committer should apply this. > > . Obvious new features that introduce new behaviour. This is something > that shouldn't be applied automatically, but _if_ the feature is something > that should be considered for the stable release then that should be > flagged in the comment, but not applied to the branch straight away. I just applied a patch to typeobject.c that makes the x[y] operation three times faster when type(x) is a subclass of list that doesn't override __getitem__. This isn't a bug, so I didn't even think of considering it for 2.2.1 -- but now I'm seriously rethinking that, and it will probably end up in 2.2.2, since it also doesn't introduce any incompatible behavior (assuming there aren't any bugs in the patch :-). But this is a serious amount of extra work -- as part of the change, I refactored some code, etc. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4