Draft Mozilla extension packaging policy

Alexander Sack asac at ubuntu.com
Tue Jun 30 10:26:53 UTC 2009


On Mon, Jun 29, 2009 at 10:09:39PM +0200, Guido Günther wrote:
> Hi Daniel,
> On Sun, Jun 28, 2009 at 04:00:57PM -0400, Daniel Kahn Gillmor wrote:
> [..snip..] 
> > > Does this make sense? If so I'll add this to the wiki as start of an
> > > extensions policy.
> > 
> > This sounds good to me, and maybe it's enough of a change to every
> > single existing package that everyone can be equally grumpy about it ;)
> > The rationale does a good job of outlining the reasons why this
> > standardization would be useful.
> > 
> > I'd say we should start it up on the wiki as a draft of a proposed
> > extensions policy.
> 
> I've added this here:
> 
> http://wiki.debian.org/Teams/DebianMozExtTeam#PolicyforpackagingXULbasedapplications
> 
> > Is there anyone not on this list who we should explicitly ask to look at
> > the draft once it's published in a canonical spot?
> Added as cc: 
> 
> Dear Mozilla maintainers, we'd be happy to get some feedback on the
> above policy draft.

Thanks for bringing this up.

I am a bit confused about the title; you say its about XUL based
Applications, but then the document is about xul based
_extensions_. Maybe change the paragraph title. Do we need a special
packaging policy for xul applications too?

For extensions, I am not sure about the suggested naming convention
"xul-ext..."; problem is that there are extensions for xulrunner
(targetApplication=toolkit at mozilla.org) and extensions that only work
on certain applications (like firefox/iceweasel, etc). So using
xul-ext for firefox/iceweasel-only extensions might be
confusing. Anyway, xul-ext is definitly better than using random
naming, so unless we have more ideas, lets go for that.



Something unrelated: I wanted to mention that the ubuntu mozillateam
has developed some code pieces that - if properly connected and
deployed - would allow to easily auto-sync .xpi's from AMO to packages
for extensions. The idea is to mass maintain extension packages
that have no binary components (and ship a proper license file in top
level directory; which turns out to be something that requires a lot
of evangelism) at some point. If anyone of the debian moz ext team is
interested in driving this further, shoot.

 - Alexander




More information about the pkg-mozilla-maintainers mailing list