[guardian-dev] SecureReader - proposed build system

Hans-Christoph Steiner hans at guardianproject.info
Wed Feb 25 04:52:44 EST 2015


Hey Micah,

I'm not on the Secure Reader team, but I'll throw my two bits in. I think your
approach is a good idea.  It'll also make it easier for new contributors to
figure out how to build the various secure reader apps themselves.

.hc

Micah Lucas:
> Hello all,
> 
> My name is Micah Lucas and I've worked with Josh Steiner on Guardian’s
> StoryMaker <https://github.com/guardianproject/storymaker> for almost two
> years.
> 
> We're currently writing an Android app for a media organization focused on
> a Middle Eastern market. Guardian’s SecureReader
> <https://github.com/guardianproject/securereader> (SR) fulfills many of our
> functional requirements, especially with the heavy need for security in
> certain regions, good support for offline/low-availability and
> filtered/highly-monitored internet connections.
> 
> 
> There are currently 7 branches (listed below) of SR on Github. I'm still
> reviewing the differences between these branches, but at first glance it
> looks as though most of the differences could be handled by Gradle’s build
> flavors instead of having separate branches for each version.
> 
> *7 current branches of SR, along with their commits ahead/behind master:*
> 
>    -
> 
>    master (0+, 0-)
>    -
> 
>    courier (44+, 0-)
>    -
> 
>    paik (70+, 0-)
>    -
> 
>    paik_psiphon (73+, 15-)
>    -
> 
>    unicorn (1+, 2-)
>    -
> 
>    yakreader (60+, 10-)
>    -
> 
>    yakreader - with library (0+, 323-)
> 
> 
> I've already migrated SR to use Gradle, and am currently working on a proof
> of concept to show how the Gradle’s product flavors
> <http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-flavors>
> could be used in place of separate repo branches. The main advantages of
> this approach would be maintainability and extensibility.
> 
> Please let me know if you are interested in this new approach. Josh and I
> are willing to do most of the heavy-lifting, but this would be a major
> architectural change and will require communication between contributors as
> well as a thorough understanding of the nuances of the different flavors.
> 
> Thanks,
> Micah
> 
> 
> 
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
> 

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81


More information about the guardian-dev mailing list