On Saturday 2012-02-25 19:38 +0000, lkcl luke wrote: > now, as it's a small codebase, i'm certain that someone who *does* > know about this "cycle collector", or any other code modifications, > could probably bring pyxpcom up-to-date prior to each xulrunner stable > release in very short order, especially when working alongside someone > like todd who is familiar with the code.
It's not. It's a massive task. (I'd guess it's roughly equivalent in complexity to everything else in PyXPCOM. That is, I'd guess that this would be about half the work of writing PyXPCOM from scratch with it included. That's a very rough guess, though.) > ... but the fact that nobody has even bothered, and has pretty much > abandoned the code, leaves it as worse than useless, and a massive > drain on the time and resources of the free software community, who > have to learn or "re-learn" about each and every single API change, > each and every single mozilla core codebase change each and every > monotonous time *right* before a release. > > that's massively unfair to expect members of the free software > community to do. Why do you consider Mozilla employees different from other members of the software community? Mozilla is paying its employees to be members of the community -- and to perform the tasks where they'd most effectively advance Mozilla's mission ( http://www.mozilla.org/about/manifesto.en.html ). There are other companies who pay people to work on Mozilla code (e.g., in the area of embedding, a number of Linux distributors have at various times). > hence why i have requested - formally on mozilla.governance - for > advice on how to go about making a formal request that the mozilla > foundation a) adopt python-hulahop as a 1st level priority project b) > reinstate pyxpcom as a 1st level priority project - preferably *back* > into mozilla-central. c) introduce unit tests that, if not passed, > will block the release of *any* xulrunner release at the time until > such time as the bugs are fixed and the unit tests pass. Demanding that somebody else do work for you doesn't seem like an approach likely to succeed. > the end result will actually be an *improvement* in the quality of > the xulrunner and the firefox codebase because it will result in a > different kind of testing - from a different angle with different > code-paths of the exact same core components that are utilised in > firefox. That's at least a more reasonable argument. I don't believe it, though. I think any future in our embedding API should be based around APIs designed to be an embedding API, not around a collection of internal functions gathered up and labeled as an API. The problem with the latter is that it's hard to avoid changing them, because they weren't designed to be permanent. You're not going to turn the latter into the former by shaking bugs out through additional testing. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂 _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
