I'm going more in the same direction as Chris Hoess.
I think there are plenty of UI developers around, but almost no
reviewers/superreviewers. There is also a clear lack of UI input on
bugs. I'm not saying the people responsible for it currently don't do
their job -- quite the opposite. It's clearly due to a lack of resources
and time available. Currently I can see three obvious super-reviewers
that have to sr= _all_ the Front End patches: alecf, ben, and blake.
And mpt is the only person I see coming up with a lot of specs, even
though it's clear that he can't handle all the UI specs alone.
In my opinion, that is the problem. Providing an easy tool to create
patches is a good thing, but it won't be of any use if it won't get
reviewed or gets trashed because at the last minute someone comes up
saying it's the wrong design.
Solutions:
1) Give sr powers to more UI people. Even though no name comes directly
to my mind.
2) Find more people who are qualified to give UI reviews on the design
(not on the code) of the feature/bug fix.
-Fabian.
Gervase Markham wrote:
> 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
>
