mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
Gecko engine for Wine
ddf9b3c083
Having not configured or out-of-date tools benefits nobody. It slows people down. Version control tools are an integral part of working on Firefox. It is important for version control tools to be configured optimally and to be continuously updated so they stay optimal. The `mach mercurial-setup` command exists to optimally configure Mercurial for working on Firefox and other Mozilla projects. This commit adds a pre-dispatch handler to mach that will verify Mercurial is in a happy state. If `mach mercurial-setup` has never executed, it will complain. If `mach mercurial-setup` hasn't been executed in the past 2 weeks, it will complain. Yes, aborting command execution and forcing people to context switch to run `mach mercurial-setup` is annoying. First, we have carved out several exceptions to this behavior, including detection for running in automation, on the machines of curmudgeons, when Mercurial isn't being used, and from non-interactive processes. Second, I argue that people ignore optional notifications and that having persistently poorly-configured tools is worse than a single context switch at most every 2 weeks. Therefore, the heavyhanded approach is justified. In addition, if we did support a non-fatal notification, we would introduce the problem of extra output from commands. If anyone was e.g. parsing mach output, we could very likely break those systems. These cases should be caught by the isatty() check or be running in a context with MOZ_AUTOMATION set. But you never know. |
||
|---|---|---|
| accessible | ||
| addon-sdk | ||
| b2g | ||
| browser | ||
| build | ||
| caps | ||
| chrome | ||
| config | ||
| db/sqlite3 | ||
| docshell | ||
| dom | ||
| editor | ||
| embedding | ||
| extensions | ||
| gfx | ||
| hal | ||
| image | ||
| intl | ||
| ipc | ||
| js | ||
| layout | ||
| media | ||
| memory | ||
| mfbt | ||
| mobile | ||
| modules | ||
| mozglue | ||
| netwerk | ||
| nsprpub | ||
| other-licenses | ||
| parser | ||
| probes | ||
| python | ||
| rdf | ||
| security | ||
| services | ||
| startupcache | ||
| storage | ||
| testing | ||
| toolkit | ||
| tools | ||
| uriloader | ||
| view | ||
| webapprt | ||
| widget | ||
| xpcom | ||
| xpfe | ||
| xulrunner | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .gdbinit | ||
| .gitignore | ||
| .hgignore | ||
| .hgtags | ||
| .lldbinit | ||
| .ycm_extra_conf.py | ||
| aclocal.m4 | ||
| Android.mk | ||
| AUTHORS | ||
| client.mk | ||
| client.py | ||
| CLOBBER | ||
| configure.in | ||
| GNUmakefile | ||
| LEGAL | ||
| LICENSE | ||
| mach | ||
| Makefile.in | ||
| moz.build | ||
| mozilla-config.h.in | ||
| README.txt | ||
An explanation of the Mozilla Source Code Directory Structure and links to
project pages with documentation can be found at:
https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Structure
For information on how to build Mozilla from the source code, see:
http://developer.mozilla.org/en/docs/Build_Documentation
To have your bug fix / feature added to Mozilla, you should create a patch and
submit it to Bugzilla (https://bugzilla.mozilla.org). Instructions are at:
http://developer.mozilla.org/en/docs/Creating_a_patch
http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree
If you have a question about developing Mozilla, and can't find the solution
on http://developer.mozilla.org, you can try asking your question in a
mozilla.* Usenet group, or on IRC at irc.mozilla.org. [The Mozilla news groups
are accessible on Google Groups, or news.mozilla.org with a NNTP reader.]
You can download nightly development builds from the Mozilla FTP server.
Keep in mind that nightly builds, which are used by Mozilla developers for
testing, may be buggy. Firefox nightlies, for example, can be found at:
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/
- or -
http://nightly.mozilla.org/