[Project_owners] A MozDev Mission Statement?
GuruJ at mbox.com.au
Wed Sep 17 08:21:06 EDT 2003
Axel Hecht wrote:
> GuruJ wrote:
>> THEY don't care about having access to PyXPCOM, PlXPCOM or Jslib. But
>> WE do!
> I don't. See, it's pretty tricky.
Yes, but we're talking about providing a rich, stable environment for
developers. As far as I can tell, when you're a developer, the more
options you have when programming, the better.
>> 2. Fork Mozilla 1.4.1. MadBird lives!
> Veto. You may wann create a branch. But not a fork. For most of your
> things, you don't even need a branch, but just a build guy.
As noted in other post, 'fork' was too harsh. The ultimate aim is to
provide a downloadable, pre-compiled development environment.
>> (Down the track...)
>> 8. Highlight core inadequacies in the current Mozilla toolkit.
>> Examples might be:
>> - RDF functionality only 80% complete.
> Do me a favour and drop that silly number. The only relevant numbers
> are bug numbers.
> At least my rdf trees show 100%, not 80% ;-).
Sorry, the number was pinched from another e-mail. I have no particular
attachment to it :)
>> - Components and interfaces aren't frozen.
> That may have something to do with, hrm, should I say 80%?
But this has consistently been shown to be the highest barrier to entry
(and reason for exit) for Mozilla developers. I proposed concentrating
on the 1.4 branch because interfaces should remain the same.
If we are to work directly on the Moz trunk (as you suggest), then we
need to do one or more of these things:
* Petition Moz staff to freeze more interfaces.
* Create an implementation wrapper for interfaces that doesn't change
from release to release.
* Implement better component version detection, so that developers can
determine what version of a component is being used and script things
appropriately (macros anybody?)
> All in all, nothing mentioned here can't be done on the trunk. At least
> in times when it isn't frozen. Most of the things mentioned here
> *should* be done on the trunk. Get your editors out, grab bugs and start
> making the world a better place.
The challenge is to create a sustainable and usable development
environment. I think we need to answer the question of whether it is
even *possible* to use non-stable releases of Mozilla for that environment.
More information about the Project_owners