bug 1079391 occurred (partly) because it wasn't well known how to retrieve the gecko<->gaia version mappings, so code was written to scrape hgweb output as a proxy. The heuristics used work most of the time, but not during the window immediately preceding every other merge day. Scraping is brittle, especially in context of more frequent upgrades of hgweb server versions. The current mapping of gecko<->gaia versions is also needed by the build farm. At the moment, this is specified for b2g_bumper via per-gaia-version configuration files in: http://hg.mozilla.org/build/mozharness/file/default/configs/b2g_bumper/

I think it's important to note that the choice to scrape hg/ftp to find this information wasn't made in a bubble. I asked for help doing this multiple times directed at multiple people and heard nothing back. My requirements are: Given a branch of Gaia[1], I must have a set of URLs to the latest gecko builds that doesn't change once retrieved[2] for each supported type of gecko build[3]. Only the latest successful gecko build for that gecko branch should be used. The configuration data must be exposed in a machine-readable, exclusively data, non-executable format accessible over HTTP or HTTPS [4]. There must be a constant entry point which may further include configuration files. These paths must not use globbing style syntax [5]. These include paths must be relative and must use unix/browser path relative file semantics[6]. This entry point must have a constant and unchanging address. If this information cannot be provided, the system must provide a mapping between gaia versions and base FTP paths[7] to be consumed by gaia-try. This mapping must be in the same configuration file over HTTP(S) format specified above. [1] e.g. master, v2.1, v2.0 [2] i.e. not using /latest/ because it's racey and doesn't reflect the state of gecko when the pr/push is made if the job is retriggered through tbpl [3] currently, B2G Desktop linux32, linux64, linux64-debug, macosx64 and Firefox linux64 [4] Examples of usable formats: json, yaml, ini [5] i.e. not *, so doing something like {"include": "./master.json"}, not {"include": "./*.json"} [6] i.e. if we have entry.json which includes "./master.json", master.json and entry.json are in the same directory. [7] e.g. must map v2.0 -> https://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-b2g32_v2_0-%(platform)

We have different definitions of "requirements" vs "implementation specification". Let's start with the former -- what you're trying to accomplish. If I'm parsing the above correctly (which I doubt), you want to know: - the URL for the ftp directory, and - the associated gaia revision (if any), For: - a given platform - a given gecko version - that successfully completed compilation (test results don't matter) - most recently finished Is that correct?