Mozilla has a large number of fringe contributors who download the odd build, and do a little QA, but have not made the leap to making patches and fixing bugs. This could be for a number of reasons, but I'm sure that one of them is that the barrier to entry is very high, especially on Windows - where you need MSVC++.
I have been doing some thinking about how to reduce this barrier, and make it so that more people could contribute easier. These thoughts follow: please criticise. It would be great if people could contribute using only a nightly build. A great deal of the barrier to contribution comes with pulling 270Mb of source and installing all the dependencies, finding a way to compile it, and learning all the command-line tools along the way. Particularly on Windows, the OS used by 90%+ of the world. So, how could this be done? A large amount of Mozilla, particularly the UI, is interpreted from XUL, JS and CSS. These files are not modified before they are shipped. So, they are the same in a nightly as they are in a source tree - although their paths are different. It should be possible for someone to unjar their chrome and produce fixes for bugs merely by editing the files in their chrome directory. The class of bugs that could be fixed this way - reasonably simple, polish bugs - is exactly the class that we have a lot of. What would be required for someone to produce patches from a nightly build? 1) On Windows, Cygwin - for useful tools, and diff 2) A script to convert those patches into patches that could be applied to a code tree 3) Perl, for the above script - unless anyone wants to write it in awk and sed Cygwin and Activestate Perl both have graphical installers for Windows, so should not be to hard to get running. Apart from the script, you have all you need on Linux. I have no clue about Mac. How would a script convert the paths in the chrome dir to paths in the code tree? The mapping here is stored in a load of files called jar.mn in the code tree. As part of the build process, we could create a large file containing all the mappings, and ship it in the nightlies. The tool could then pick that up to munge the patches with. Because each nightly would come with the right mapping file, there would be no risk of using the wrong mapping. The user would unjar their chrome (another Perl script), edit it, run diff from the top level chrome dir, munge the patch and attach it to the bug. This could then be reviewed, super-reviewed and checked in in the normal way, without further munging - i.e. keeping the workload on reviewers and super-reviewers as light as possible. If a new patch was required, you would just edit further and repeat the process. If you were working on two patches in the same file, you'd just install two nightlies. The equivalent of a cvs update would be installing and unjarring a new nightly, making a diff and applying it to the new chrome tree. Gerv
