On Mon, Mar 21, 2016 at 2:24 PM, Michael Comella < michael.l.come...@gmail.com> wrote:
> Hey Nick and others. > > ---------- Forwarded message ---------- >> From: Nicholas Alexander <nalexan...@mozilla.com> >> >> As consumers, we have hard limitations that make it challenging for us to >> even track upstream, let alone contribute back to upstream. Licensing; a >> desire to build everything from source; hard restrictions on consuming >> projects with Android resources; inability to use Gradle plugins. >> > > Are these requirements set in stone? The active development team is fairly > small [1] and I think we can use any help we can get to move more quickly – > perhaps this is a time to bend the rules. > Totally not set in stone: * Licensing is a hard requirement, for obvious reasons :) * Building from source is a fairly hard requirement, although of course we're not "source originalists": we don't build our own Android toolchain, for example. * Consuming projects with Android resources is hard because our moz.build doesn't really support this; * Building with Gradle will allow us to produce and consume Android libraries in the dominant form they're disseminated. [1]: For comparison's sake, Lyft has 14 devs and I'd argue the scope of > their work isn't any larger than ours. > > >> As producers, we're a joke: I answer a few emails each week explaining >> that we provide no support for GeckoView and will not fund it. And even >> when we can jump the technical hurdles to enable code re-use, we don't have >> support for that really anywhere in the management chain. Mozilla won't >> even commit to providing an externally consumable Gecko-the-platform! >> > > I apologize if I'm interpreting this incorrectly, but I don't think > GeckoView/the platform needs to our only open source contribution. While it > does emanate the manifesto more clearly than an arbitrary Android library, > as I mentioned I think there are benefits to releasing unrelated open > source libraries. > I agree, but we have clear demand for this one library. We have no real demand for these other things. > I think there are a few benefits to releasing libraries separately from >>> the app: >>> * More development help on these libraries, without the need for >>> developers to learn the full Mozilla development process >>> >> >> I don't think this will happen quickly, if at all; and if it does happen, >> we will be forever balancing the need of a library's community with our own. >> > > fwiw, I watched a talk at Droidcon about developing an open source library > and the speaker suggested giving your library a narrow focus to make > community maintenance (e.g. should I accept this pull request?) simpler – > e.g. on Github, Picasso is, "A powerful image downloading and caching > library for Android". If it was, "An library to get pngs from urls and put > them into ImageViews", it's more difficult to scope creep and reduces the > maintenance burdens. > > >> Square, Facebook, and pretty much every other "open source ecosystem" >> participant publishes work but maintains near-complete control of the >> development direction. >> > > Which appears similar to the strategies in use in your comment. > > I would like to see our favicons library separated for testing, which >> could lead to contributions back from the Brave development team. >> > > A neat idea! However, I fear that if it doesn't happen soon, the code will > have diverged too much and it'll be too difficult to merge back in. > >> >> I care about libraries as a way to : >> >> * simplify and improve our architecture, and >> * improving our testing, so that we are more robust. >> > > I'm also glad we agree on these topics! > > In any case, I'd love to reduce the barrier to entry for using and > contributing open source libraries using industry standards (e.g. > maven/ivy, right?) for if (when?) the opportunity presents itself and I > don't have a clear understanding of what the currently existing barriers > are (beyond the brief descriptions mentioned above) – what are the action > items? Is the first step to ship with gradle on release builds? What's next? > Yes, the first step is to use Gradle. (To be intellectually honest: we can either use Gradle, or invest a large amount into doing what we can do with Gradle in our own system. I argue the latter is foolish, and Gradle is functional now, so Gradle it is.) After that, we can start breaking pieces of our code base off into libraries. As a worked example, let's take favicons. For favicons, searching for "import org" reveals quite a lot of utility code and some App-specific tie-ins (see bottom of post). For things like Tab, Tabs, GeckoJarReader, AboutPages, and BrowserDB, we need to separate the library from the consumer. For things like ProxySelector, is this an interface that consumers can provide? Perhaps NonEvictingLruCache is actually /part/ of favicons. Presumably we inline IOUtils and ThreadUtils, to remove extraneous dependencies. At this point the code can be distributed independently of Fennec. It's a decent amount of effort and refactoring, with the promise of a nice encapsulation and easier testing, but very little likelihood of anybody else doing "our work" for us. Happy to discuss this or another example. Best, Nick ./cache/FaviconCache.java:9:import org.mozilla.gecko.favicons.Favicons; ./cache/FaviconsForURL.java:9:import org.mozilla.gecko.gfx.BitmapUtils; ./decoders/FaviconDecoder.java:11:import org.mozilla.gecko.gfx.BitmapUtils; ./decoders/ICODecoder.java:8:import org.mozilla.gecko.favicons.Favicons; ./decoders/ICODecoder.java:9:import org.mozilla.gecko.gfx.BitmapUtils; ./Favicons.java:9:import org.mozilla.gecko.AboutPages; ./Favicons.java:10:import org.mozilla.gecko.GeckoAppShell; ./Favicons.java:11:import org.mozilla.gecko.R; ./Favicons.java:12:import org.mozilla.gecko.Tab; ./Favicons.java:13:import org.mozilla.gecko.Tabs; ./Favicons.java:14:import org.mozilla.gecko.db.BrowserDB; ./Favicons.java:15:import org.mozilla.gecko.favicons.cache.FaviconCache; ./Favicons.java:16:import org.mozilla.gecko.util.GeckoJarReader; ./Favicons.java:17:import org.mozilla.gecko.util.NonEvictingLruCache; ./Favicons.java:18:import org.mozilla.gecko.util.ThreadUtils; ./LoadFaviconTask.java:12:import org.mozilla.gecko.GeckoAppShell; ./LoadFaviconTask.java:13:import org.mozilla.gecko.GeckoProfile; ./LoadFaviconTask.java:14:import org.mozilla.gecko.db.BrowserDB; ./LoadFaviconTask.java:15:import org.mozilla.gecko.favicons.decoders.FaviconDecoder; ./LoadFaviconTask.java:16:import org.mozilla.gecko.favicons.decoders.LoadFaviconResult; ./LoadFaviconTask.java:17:import org.mozilla.gecko.util.GeckoJarReader; ./LoadFaviconTask.java:18:import org.mozilla.gecko.util.IOUtils; ./LoadFaviconTask.java:19:import org.mozilla.gecko.util.ProxySelector; ./LoadFaviconTask.java:20:import org.mozilla.gecko.util.ThreadUtils;
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
