openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <>
Subject Re: Automating Error-prone Manual Release-related Files By Using Centralized Release Artifact Metadata
Date Tue, 01 Oct 2013 18:38:03 GMT
Am 10/01/2013 04:17 PM, schrieb Rob Weir:
> Every time we release we need to generate quite a few files related to
> the release.
> Here's the list I know of:
> 1) The ASC/SHA/MD5 hashes and signature files, one for every released file
> 2) A CWiki page listing all the built files with hyperlinks to hashes, etc.
> This is used when voting on a Release Candidate.
> 3) release_matrix.js, used by the download page's logic to decide what
> file to recommend based on user's locale:

Plus the file size for the install files. I get it from the Sourceforge 
master mirror via rsync.

A simplification would be to combine "languages.js" and "release_matrix.js".

> 4) The other.html page that has a table listing all release files:

This is already automated via a few variables from "gloablvars.js".

> 5) Another download page, on, listing the source
> and SDK links, along with hashes:

My opinion is that we don't need this. Everything is already available 
on "other.html". We could reduce the webpage to show general information 
but for the specific release things refer to "other.html".

> 6) A flat list of all download URLs, used by the download stats script:
> 7) The XML files used by the upgrade notification server, one XML file
> per release:
> I imagine this list will grow over time.  Certainly new releases and
> new translations cause us to update these files.  And to the extent
> they are manually created they will contain errors.   Even if created
> by automation, if we don't have a canonical data set that we're all
> working from there is the opportunity for error.
> So the big question: What can we do to improve on this?
> 1) Can we have a single, published, canonical, machine-readable
> description of what is contained in a release, or even what is
> contained in each build:

Yeah, a (so-called) "source of truth" would be great.

For the download website the "globalvars.js" delivers the source data. 
But it needs to be filled with the data.

> a) base URL of where the files live

Then + VERSION + "/binaries/" + ISO_CODE

> b) based URL to where the hashes and signatures live

Then + VERSION + "/binaries/" + NL_LANGUAGE + "/" + FILENAME

a) and b) can be seen as easy or difficult. Depends on your personal 
point of view.

> c) list of all language codes and platforms included in the build
> d) defined rules for creating the full paths and file names given this
> information.
> 2) Have such a data file for every past release, at least back to 3.4.0.


> 3) Write scripts to generate our other files from these canonical files.
> 4) Check this all in to a central place so when a new release comes
> out we can generate these needed files automatically, with much lower
> chance for errors.
> 5) Spend our extra time drinking beer and imagining how rich we'd all
> be if we each received $0.01 for every download of AOO.
> How close are we to this?  Is any part of this automated already today?

The top number #4 is already automated.

But with the bottom #1 - #4 would be an advantage. However, I would be 
satisfied with #1 (source of base data) as everything else is not that 
difficult and time-consuming.

My 2 ct.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message