>  Folks in another group cite this as a bug.

You are saying that it appears that the trunk has a new bug that was not in
previous versions - but this bug is outside of pyxpcom, correct?

>   I've filed it 
>  with bugzilla... apparently the python extension tests don't 
>  account for the BUILD_ID (which was previously globally 
>  defined, but maybe isn't now?  I don't totally understand, 
>  but the guy I spoke with seemed pretty confident.

I don't understand this, or how it is relevant to your original problem (but
I may well be missing something)

>  I think the mixed checkout option is a good one.  I need the 
>  trunk for fixes to certain bugs in the main core, but for the 
>  python extensions, I can settle for an older stable build.  

No, I'm saying the reverse - that the *rest* of the trunk is likely to
develop bugs, and only once the main code moves to a branch is it likely to
be stable - hence, you are best off using a branch for the rest of the code.

On the other hand, the fact that pyxpcom is not undergoing much change means
that you can stick with the trunk here - particularly if pyxpcom has
enhancements that are *not* on the branch you are using for the rest of the
code - the way to use such enhancements is to use pyxpcom from the trunk (or
a later branch), while the rest of the tree remains on a stable, but older
branch

I fear we are talking about quite different things :)  Do you have any
reason to believe the original problem you mailed about has anything to do
with pyxpcom?  To my eyes it seemed completely unrelated - no doubt a bug,
but *not* a bug in pyxpcom, and hence no reason to not use pyxpcom from the
trunk.  Of course, its quite possible that other changes to the trunk have
broken pyxpcom on the trunk - in which case the only reasonable way forward
is to fix pyxpcom, as any such breakage would also exist for all versions in
the past.

From your second email:
>  On the topic of "pyxpcom isn't actively developed right now" 
>  is there a TODO list somewhere?

Nope - there aren't really any desired features that have been identified.
If there are, they should be listed appropriately in bugzilla.  ActiveState
sometimes come up with new features (eg, Shane's recent work on exception
processing), but these are just dealt with as they identify them.

>  I'm new to the mozilla tree, 
>  but not to development in C or python, so this seems like a 
>  logical place for me to do my good deed for the day.  
>  Accessibility of python through the mozilla suite seems like 
>  such a cool idea, (especially with xulrunner and its kin) 
>  it's kind of startling to me that there aren't teams of 
>  seamonkeys working round the clock to make it happen.  I'd 
>  like to further that cause wherever I can, if there's cause 
>  to be furthered.

By all means, feel free to do whatever tickles your fancy.  Upload any
patches you create to bugzilla and assign them to me.  Then join #pyxpcom
and/or email me to harrass me to look at the patches, and I'll either check
them in or explain in detail why I will not.  The more the merrier, and I
will do everything I can to encourage contributors.

Cheers,

Mark

_______________________________________________
pyxpcom mailing list
pyxpcom@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs