I think the best thing is for Todd to submit these patches, with the end aim
of getting those checkin rights for himself (and obviously anyone else too
is welcome to follow that process).  I'd personally like to have someone
else available for this, and someone who I can use to bounce things around
with.  I expect that all of Todd's patches come from a perfectly valid
premise, so the only real question will be one of implementation.
Ultimately though, looking through the eyes of the user, there should be
*zero* external patches - or any that do exist should only be due to time
constraints in getting those patches in.  In other words, if a patch is
suitable to be applied to the binaries, it must be suitable for applying to
the source tree - it makes no sense that the binary package would include a
patch that the source tree never will (again, other than for practical
considerations such as time)

 

I'm also more than happy to receive gentle reminders via private email
should I drop the ball on this stuff (which does happen from time to time as
I get distracted by other things).

 

Cheers,

 

Mark

 

From: Atul Varma [mailto:varmaa@[...].com] 
Sent: Wednesday, 18 June 2008 10:01 AM
To: Mark Hammond
Cc: Todd Whiteman; pyxpcom@[...].com
Subject: Re: [pyxpcom] Python Mozilla extension (pyxpcomext) updated

 

Mark,

Great points!  I agree with them all, so I guess that brings me back to your
original question about how to deal with Todd's patches, especially the ones
that are related to bundling PyXPCOM as an extension, which may not be fully
appropriate for the Mozilla trunk.  Is it okay for them to stay separate?
And who should review the patches that Todd's submitted--does PyXPCOM
currently have a module owner?

- Atul

On Tue, Jun 17, 2008 at 4:33 PM, Mark Hammond <mhammond@[...].au> 
wrote:

I guess I would need to know exactly who this community who wants full
control is?  How would we determine who has the rights to check stuff in?
Should we take an approach of letting almost anyone who asks, or do we want
to restrict it to ensure quality?  If the only "problem" with the current
situation is that not enough people have checkin permissions to the pyxpcom
tree in Mozilla, I can't see a reason why we don't simply address that?

 

It takes a little work and commitment to get those rights - which is good,
as they aren't handed out willy-nilly.  If anyone from this community had
been submitting high-quality patches to me over the last few years, I would
be happy to vouch for them and to help get them checkin rights to the
pyxpcom tree - but IIRC, the number of patches I have received over the last
5 years can be counted on one hand.  So I'm not quite sure who would be
putting themselves up as someone who should have such rights.  I personally
think having it in the Mozilla tree is a good idea exactly for these reasons
- people can't check stuff in until they have proven themselves, and even
then, they *must* follow certain processes to ensure quality, or they lose
those rights.  I think such processes are valuable.  Further, pyxpcom is
necessarily tied to a specific version of the Mozilla tree - so an external
repository might end up with branches almost exactly mirroring the Mozilla
branches - but we would need to manage those branches manually ourselves.

 

Ignoring this aspect of things, I do agree that getting the community
involved is very important.  Things like these binaries, wiki pages and
samples can all help with that.  Creating an alternate build process to make
it easier to build from the SDK would be nice, as would putting together
"source releases" every now and then to help people get started.  But I'm
not sure that the location of the VCS repository will actually make any
difference to these things (again, assuming we don't want these newly
attracted people to start checking things in!) .  Think of Python itself -
what percentage of users pull Python sources from svn, and what percentage
have checkin rights?  Does the specific location of the Python SVN server
have any impact on these things? However, having said all that, I'm happy to
continue discussing this if people think the location of the VCS really is
such a barrier to entry. 

 

Cheers,

 

Mark

 

From: Atul Varma [mailto:varmaa@[...].com] 
Sent: Tuesday, 17 June 2008 11:08 PM
To: Mark Hammond
Cc: Todd Whiteman; pyxpcom@[...].com
Subject: Re: [pyxpcom] Python Mozilla extension (pyxpcomext) updated

 

Well, one of the things I noticed a few weeks ago when creating my own
SConstruct file for pyxpcom (using the Python-based SCons build tool) was
that everything needed to build, save for a few header files, is contained
in the nightly builds of the XULRunner SDK:

  http://developer.mozilla.org/en/docs/Gecko_SDK

The nice thing about this is that you don't need to compile all of Mozilla
just to make the PyXPCOM binaries.

Mark, I wasn't at your keynote at Pycon, but a friend of mine was and he
mentioned you saying that one of the difficult things about PyXPCOM over the
years is that the Mozilla community thinks PyXPCOM is the Python community's
business, and the Python community thnks it's Mozilla's business.  If
Mozilla thinks that PyXPCOM isn't "theirs", then why not move it out of
mozilla-central and into a separate repository where the PyXPCOM community
has full control over it?  We could decouple its build system from
Mozilla's, making it easier to understand and change (albeit more fragile
too, but it could be worth the tradeoff if it means more participation and
maintainability).  We could even set up a simple buildbot system to
automatically create and test PyXPCOM builds with the latest nightly
XULRunner SDK to be notified of breakages as soon as they happen.

- Atul

On Tue, Jun 17, 2008 at 12:00 AM, Mark Hammond <mhammond@[...].au> 
wrote:

Hi Todd,
 These new releases look great!  I'm wondering what you intend to do re
getting these patches into CVS/Mercurial?  I'm slightly concerned that as
time moves on, the "pyxpcom source code in the Mozilla tree" and the
"pyxpcom binaries" will diverge in non-trivial ways, ultimately causing
confusion for users.  Further, if you include a patch that we ultimately
decide is inappropriate to be checked into the pyxpcom source tree, we may
end up in the position where you are forced to make a fork of pyxpcom just
to retain backwards compatibility with your other releases.

Do you (or anyone!) have any thoughts on this?

Thanks,

Mark.


>  -----Original Message-----
>  From: pyxpcom-bounces@[...].com [mailto:pyxpcom-
>  bounces@[...].com] On Behalf Of Todd Whiteman
>  Sent: Tuesday, 17 June 2008 4:26 PM
>  To: pyxpcom@[...].com
>  Subject: [pyxpcom] Python Mozilla extension (pyxpcomext) updated
> 
>  Hello all,
> 
>  I've updated the Python extension for Mozilla 1.9 builds with the
>  following changes:
>  * now includes PyDOM
>  * windows, Mac OS X and Linux builds available
>  * updated Linux Python builds to use static libraries (fixes problem of
>  missing modules like "ssl", "hashlib")
>  * moved pyxpcom environment setup into a pybootloader stub module
> 
>  Downloads are available here:
>  https://www.mozdev.org/projects/overview/pyxpcomext/
> 
>  The PythonExt build will work in Firefox 3, Songbird and XulRunner 1.9
>  apps.
> 
>  Thanks to Malek (lekma) for reworking the build scripts and bootloader
>  handling.
> 
>  Cheers,
>  Todd
> 
>  _______________________________________________
>  pyxpcom mailing list
>  pyxpcom@[...].com
>  To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

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