> Yes, but you have to Pronounce on which specific bit of text you > want to see. It's going to get much more complicated if we intend > to backport fixes across 2 or 3 years of older releases. I predict > that's not going to work unless we establish an easy-to-update patch > database recording which patches have and haven't been applied to > each old release, which should and shouldn't be applied to each old > release, and everyone is serious about keeping that up to date. I'm > not aware of any commerical organizations with full-time QA > departments that sign up for something so messy, and I'm not > sanguine about our prospects of pulling it off (the older the code, > the more likely "a bugfix" is to create at least as many problems as > it solves; and the more active branches, the more likely fixes to > get dropped on the floor). I've got some half-working tools for working with CVS from Python. Maybe it's time to dust those off and write our own database... > [Martin v. Loewis] > > If I'm going to commit the same patch onto the maintainance branch, I > > usually don't mark it as "bugfix candidate". > > Except that "the" maintenance branch loses clear meaning when there > are multiple maintenance branches. That's why I expect this just > isn't going to work without a patch database: it needs something > independent of scattered checkin messages to correlate a > *conceptual* patch with all the active branches. Or it needs a > truly dedicated person to sign up for each active branch, who > actively worries about every patch that comes by. I expect Neil > spoke for most current developers there: they don't fear current > releases, so won't volunteer for such work (there's no payback for > them -- open source works because developers and users volunteer to > scratch their own *current* itches, and share the relief; the > "maintenance branch" business is unique in that nobody with that > particular itch has volunteered to do anything to scratch it). There are several developers who also have a Python-based business with customers who want stable releases. They should join forces and offer some help here. If they don't, I'm not sure I can afford to be very sympathetic to their cause (well, I can show sympathy anyway, but I won't be able to do anything about it :-). --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