XULRunner Patches Proposal

As many software vendors building a XULRunner application will tell you, they need to build their own version and maintain a set of core patches. These patches might be to fix bugs that are biting them, or add new features.

Under the umbrella of mozpad.org and with the ultimate goal being to “make the platform better”, here is a proposal to get to grips with these patches and make the process easier for developers.

[Below copied from original proposal. Feedback welcome.]

Current Short Description

Compile a list of work on the platform being done by various third parties and Mozilla itself in order to identify areas of overlap and possible cooperation. Gather core changes that have already been implemented, merge them, file bugs and propose patches.

Why

There are a number of reasons for consumers of the platform to cooperate on technical issues, including:
  * Avoid duplication of work
  * Prompt debate on what should and should not be in the platform, i.e. identify niche fixes that are only valuable to a particular application vs. any application
  * Sharing of knowledge and code, in the spirit of the openness of the Mozilla project
  * Putting more weight behind patches in Bugzilla could speed up review/check-in process
  * And ultimately … TO MAKE THE PLATFORM BETTER

How

  – Identify vendors and individuals using XULRunner to develop their applications. Compile a list (such lists exist elsewhere, but are incomplete/outdated).
  – Contact these people (either individually or in a batch) soliciting feedback on this issue and whether they are willing to take part.
  – Possibly provide a forum such as a mailing list, or use existing channels such as the mozilla.dev.platform list. A semi-private forum might help reduce the noise and provide focus for the initial gathering of information.
  – Compile the list of core patches, and what features/bugs they are fixing.
  – Merge (idenitfy overlap) / File Bugs / Attach patches

TODO

  – Identify if the build systems and installers used for these applications is under the remit of this task. Each application has its own deployment needs, so moving towards a single build model on each platform might not be practical.

No comments yet.

Leave a Reply