ben, thank you for responding, i'm really grateful. i'll keep the message here intact (pyjamasdev requires subscription), again bcc you because lamson doesn't like cc, and also add david too.
[btw, to fully understand what this is all about, may i respectfully request that you install pyjamas-desktop and run some of the examples?] On Fri, Mar 2, 2012 at 4:41 PM, Benjamin Smedberg <[email protected]> wrote: > On 3/2/2012 9:50 AM, lkcl luke wrote: >> >> so i can clearly assess that they're not aware of the implications, >> and don't know how their software can and is being used (successfully, >> for a given value of success i.e. ok with xulrunner 1.9, 7 and 9 >> success but bugger all else success), but the silence has been >> absolutely deafening since i pointed that out. > > Luke, we know that Mozilla code is used in many different ways, including > pyxpcom and hulahop. We also are aware that pyxpcom is a scripting language > and therefore it is less affected by interface revisions. Obviously pyxpcom > itself is still uses some binary interfaces and needs to be recompiled for > each release. yes. ok, good. i believe that we've established that we're on common ground. [the zen "i know that you know, you know that i know etc. etc." thing]. > I am not "pissed" at all. I am merely saying that this usage is not > strategically important to Mozilla. It has never been part of our standard > build/test/release process and there is nothing here which means that we > should impose the burden of maintaining pyxpcom on the core Mozilla > community. ok, then i have a proposal for you. would the mozilla foundation agree to *stall* releases of xulrunner if there are outstanding pyxpcom and hulahop bugs? this is absolutely absolutely crucial. it's simply intolerable to have a version of pyxpcom or hulahop that segfaults with a major release of xulrunner, because there's absolutely no chance of that bug getting fixed. ever. that means that releases go out (xulrunner 2 through 6, and 10 through 12 *so far*) that simply... don't work for one reason or another. we simply cannot build a community if the underlying code is completely unstable! > I don't want to discourage you from maintaining pyxpcom and building a > community around it. the community of users of pyxpcom and hulahop is large, but the community of *developers* of pyxpcom and hulahop can be counted on one hand of a yakuza triad member. ok, that was meant to be funny, hope it's seen as that. but there's more to it than that: the underlying code - which is maintained by the mozilla foundation - *simply doesn't work*. the task of maintaining pyxpcom and hulahop themselves is actually quite straightforward (relatively speaking), but the best i can do is to put in bugreports and help guide mozilla foundation team members to track them down, but i don't believe it's reasonable to expect anyone who *isn't* funded by the mozilla foundation to fix bugs in the core mozilla codebase. so it doesn't matter who actually does the maintenance / upkeep on pyxpcom and hulahop (it's pretty small), but if pyxpcom and hulahop are > Mozilla continues to host the pyxpcom code and it is > still maintained through the Mozilla module ownership system. > > If you have specific technical questions about how to update pyxpcom to stay > current with the Mozilla code, please ask them. well, i'm coping - just, thanks to help from matt and boris (whom i've just annoyed *sigh*). i can compile libxul etc. with debug information, provide stacktrace bugreports etc. but i *can't* afford the time to work actually on fixing the mozilla codebase itself. segfaults when calling XRE_InitEmbedding2 for goodness sake! i don't even know if this bug has been fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=728500 because that bug was relevant in (at least) xulrunner 10.0.2 but haven't been able to check it's still relevant for 13.0a1, because of the bug which is causing segfaults even in calling XRE_InitEmbedding2! so - if you guys can take care of these things, and, crucially, treat them as release-critical, then things will be ok. the gnu/linux distros will have some code that can actually be compiled and go into their releases. > But don't turn this into an > overblown rant about Mozilla's priorities and how we have chosen not to > prioritize this project. i have all the classic symptoms of asperger's. one of them is when faced with conflicting requirements is to go absolutely ape-shit. it's something i'm having difficulty with. my long-term goals were being put in jeapordy: as long as i have a happy pyjamas community where people can use hulahop as a back-end for pyjamas-desktop with a *recent* version of xulrunner, i'll be ok. so... yeah, i apologise for that. and thank you for being much more patient than i can ever be. l.
