We need to decide on a process for releasing this software. As there seems to be a few ideas around, I want to clarify what I see as the constraints, and obtain any additional ideas, so we can bring this to a smaller group to make the final decision.
Some background ===============Previously, the link clicker UI was in a separate repository, but with the transition to shipping "Loop" as part of Firefox, we have combined the two repositories.
The desktop client and the link clicker UI share common code (browser/components/loop/shared), with some code specific for the link clicker UI (browser/components/loop/standalone).
We combined the two repositories because: * All the code is in one repository, making it easier for developers to find and develop patches for both desktop and link clicker. * We would not have an awkward duplication of the shared code across two repositories, nor needing to include a separate repository for one bit of code. * We can use the Firefox CI system to run our automated tests on the link clicker code for at least Firefox (we haven't thought about/investigated Chrome & others yet). Issues =====There are various things we need to consider in addition to the above (just issues here, not proposals):
* How do we do L10n?
o I see this being driven by a product level decision, rather than
an engineering one, so I'm not expecting specific comments here,
this is for info, to help explain the complexities
o If we operate link-clicker as a "separate" website in L10n
terms, then I've been told we'll only get approx 50% coverage in
terms of total number of locales
o If we handle l10n within mozilla-* repositories then we'll be
able to have the link clicker pages handled as part of the
normal Firefox L10n process.
o This would then limit us to feature releases from
mozilla-release, as L10n wouldn't necessarily be complete before
then.
o Hence, unlike many web projects, new features would have to wait
12-18 weeks for release.
* How do we handle stability/security fixes?
* How do we determine which release is which version(s) of code?
* How do we generate a tarball or RPM for releasing?
* How do we run tests against non-Firefox browsers?
Anything else?
Potential Solutions
===================
Here's a couple of potential solutions. I don't think we should get into
a long debate about pros and cons, but if you have additional options,
ideas or simplifications, please do let us know.
We'd obviously need to talk to different folks in from various groups to get their sign-off, for now, we'll assume we can do anything.
* Everything lives in mozilla-*, l10n in mozilla-*
o This would allow L10n to do their work as part of the FF release
process
o We could potentially ask releng to provide a way of generating a
tarball against releases, which would tie into the L10n process
and get us the correct versions for L10n files.
* Everything lives in mozilla-*, but "released" to a github repository
o This would potentially be slightly easier for stability/security
fixes, as we could branch the github repo, but it may confuse
outsiders as to the authoritative sources.
o This also gives us an option as to where L10n is run from
o We could have non-Firefox browser tests run via travis ci if we
can't include them in the mozilla-central CI.
o We'd obviously need some automation for automatically
transferring the files from mozilla-* to github.
Due to the shared code, I don't see separating the repositories as a
viable option, for the reasons listed need the start.
Please provide feedback & further ideas, I'll give it a couple of days, then take this to the main stakeholders for decisions.
Mark
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
