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.
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot
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:
http://www.openoffice.org/download/release_matrix.js
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:
http://www.openoffice.org/download/other.html
This is already automated via a few variables from "gloablvars.js".
5) Another download page, on openoffice.apache.org, listing the source
and SDK links, along with hashes:
https://openoffice.apache.org/downloads.html
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:
http://svn.apache.org/repos/asf/openoffice/devtools/aoo-stats/401.lst
7) The XML files used by the upgrade notification server, one XML file
per release:
https://svn.apache.org/repos/asf/openoffice/ooo-site/trunk/content/projects/update38/ProductUpdateService/check.Update
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:
+1
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
http://sourceforge.net/projects/openofficeorg.mirror/files/
Then + VERSION + "/binaries/" + ISO_CODE
b) based URL to where the hashes and signatures live
http://www.apache.org/dist/openoffice/
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.
+1
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.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
