gecko-dev/python
Jeff Gilbert 721d8c2e22 Bug 1526509 - Remove lib32-libstdc++5 requirement from mozboot/archlinux.py. r=glandium
lib32-libstdc++5 moved from multilib to AUR, but it seems like we don't
need this anymore anyway.

Differential Revision: https://phabricator.services.mozilla.com/D19276

--HG--
extra : moz-landing-system : lando
2019-02-12 02:49:16 +00:00
..
devtools/migrate-l10n
docs Bug 1490253 - Update documentation on vendoring Python packages based on switch to pip-tools; r=ahal 2018-10-15 13:36:30 +00:00
l10n/fluent_migrations Bug 1519923 - Migrate about:rights to Fluent, r=jaws,flod 2019-02-08 17:36:15 +00:00
mach Bug 1520006 - [mach] Fix bug in 'mach completion', r=nalexander 2019-01-14 21:20:55 +00:00
mozboot Bug 1526509 - Remove lib32-libstdc++5 requirement from mozboot/archlinux.py. r=glandium 2019-02-12 02:49:16 +00:00
mozbuild Bug 1526062 - Improve error reporting by the configure lint. r=nalexander 2019-02-08 22:47:02 +00:00
mozlint Bug 1524444 - Respect -n for linting in py3/py2 and better support it in other linters. r=ahal 2019-02-01 20:39:05 +00:00
mozrelease Backed out 4 changesets (bug 1508381) for multiple Windows build bustages CLOSED TREE 2019-01-31 23:14:11 +02:00
mozterm
mozversioncontrol Bug 1515261 - [mozversioncontrol] Fix unicode env string on Windows, r=sheehan 2019-01-07 16:26:49 +00:00
safety
mach_commands.py bug 1505205 - don't write telemetry for recursive mach command invocations. r=firefox-build-system-reviewers,chmanchester 2018-11-10 19:04:30 +00:00
moz.build Bug 1508248 - Update in-tree bugzilla metadata to use 'Firefox Build System :: Mach Core' for mach files r=froydnj 2018-11-19 13:35:14 +00:00
README

This directory contains common Python code.

The basic rule is that if Python code is cross-module (that's "module" in the
Mozilla meaning - as in "module ownership") and is MPL-compatible, it should
go here.

What should not go here:

* Vendored python modules (use third_party/python instead)
* Python that is not MPL-compatible (see other-licenses/)
* Python that has good reason to remain close to its "owning" (Mozilla)
  module (e.g. it is only being consumed from there).

Historical information can be found at
https://bugzilla.mozilla.org/show_bug.cgi?id=775243
https://bugzilla.mozilla.org/show_bug.cgi?id=1346025