On Mon, Jul 19, 2010 at 9:06 AM, Mark Lawrence <breamore...@yahoo.co.uk> wrote: > Hell, I just wish I was fully healthy and had my MBCS/CEng status back, then > I'd really feel capable of letting fly. Having worked on massive UK MOD > projects (can't say much, Official Secrets Acts and all that stuff) and > knowing a hell of a lot about change control, configuration management, call > it what you like, quite frankly Python is years behind. But there I go > again, can't rock the boat because someone might get upset, to hell with the > poor sods putting in their patches years ago and being completely ignored.
I have worked (and do work) on similar projects and in many ways Python is well ahead of what some large corporations do. In terms of test automation, baseline control, public auditing of the source repository, public communications, the very nature of open source development avoids a lot of the pitfalls private enterprise can fall into. We *have* to document and automate stuff, because you can't just yell over at Bob in the next cubicle to ask "hey, what do I need to install to get [fnord] to build?". We *know* that everything we commit is going to land in the email inbox of a large number of people, so we better give it a reasonable checkin message and include a meaningful comment explaining any apparently-stupid-but-actually-correct code. The fundamental constraint, though, is that the core developers aren't paid specifically to hack on Python. We may use it in our day jobs, and I think some of the folks may get a bit of time to spend on it during their work week, but making the new versions better isn't the primary task for any of us. Large corporations, on the other hand, have a lot more money to throw at things and can pay people to work on the boring stuff rather than relying purely on volunteers. If you get to a feature request, find that it doesn't apply cleanly anymore (or even come close), post a comment to say that. If nobody steps up to modernise the patch, but it isn't a fundamentally bad idea, then it's OK for the tracker issue to remain open indefinitely (e.g. one of mine you commented on recently I had deliberately left open for a long time because I hadn't made up my mind whether I agreed with it or not. There were some comments from earlier this year that I missed at the time, but reading them all now means that I'm inclined to accept the change for 3.2). For bug reports, the basic thing is to see if the issue can be reproduced on currently maintained versions. If it can, update the version applicability accordingly, if it can't, suggest closure as out of date. This isn't a company where the metrics mavens will see a growing count of low priority feature requests and issue reports and demand that they either be accepted or rejected and people will be taken from other tasks and given the responsibility to work through the list. Is it *good* that things are this way? No, not at all. But it isn't likely to change anytime soon, either. Cheers, Nick. P.S. Regarding the version bumps with no other comment: I believe there are some scripts kicking around to bump feature requests up to the new development version after a new release goes into maintenance-only mode. It may be good if any such scripts are updated to also add a comment to that effect, but I don't believe those scripts are centrally controlled anywhere. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
