<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 17, 2014 at 1:58 PM, Mike Hoye <span dir="ltr"><<a href="mailto:mhoye@mozilla.com" target="_blank">mhoye@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2014-10-17 11:53 AM, Ehsan Akhgari wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Wouldn't building with --enable-chrome-format=flat give you what you want?  That option at least used to avoid creating the omni.ja package altogether and instead put normal files in your objdir which you could edit and restart Firefox to see the affects of (while of course getting rid of the XUL cache, etc.)<br>
<br>
</blockquote></span>
Getting to the game late here, but: the grand vision (for me at least) is a redistributable version of Firefox that doesn't just let people modify all the parts of Firefox that don't need to be recompiled, but that facilitates the part where they send us back patches.<br>
<br>
Lowering the barrier to participation to the point that you can make a meaningful contribution to the Mozilla codebase with just "Firefox Contributor Edition" and a text editor would be great, and have a couple of nice byproducts for everyone, like a reducing build time to "restart Firefox".<br>
<br>
--enable-chrome-format=flat gets us most of the way there, but I think we're missing a few pieces. The minimum viable civilized experience needs a built-in diff tool, some manifest work and a "get me back to known-clean" button, but probably not much else.<br></blockquote><div><br></div><div>Well, we also need to stop preprocessing things, so that we can actually have some correspondence between the XUL/JS/CSS code that we ship in our product vs the code that we have in the tree, right?  Part of that preprocessing is #include'ing things, which can be handled in a diff tool which knows about that, but it's much harder for the case where we have platform/configuration specific #ifdef's and whatnot.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That gets us most of the way there from the contributor's perspective, I think? It falls over for integrators in a few places where files are preprocessed and omni.ja contents don't match up 1:1 with what's in mercurial, but that seems solvable.<br></blockquote></div><br></div><div class="gmail_extra">How useful do you think those one off patches would be though?  How do we handle for example going from that one patch to making sure that they get reviewed, etc.?  Also (and I know this is a hard question to answer) how do we know that the overhead of downloading and building our code is what prevents a significant amount of contribution to come in, and that facilitating this would remove the barrier to entry?<br clear="all"></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">-- <br><div dir="ltr">Ehsan<br></div>
</div></div>