Fine with me.
-- Michael
Marshall Schor wrote:
One further thought: A lot of projects put the RELEASE NOTES for
particular releases at the "top level" of the dist/ - where the file
name includes the release: for example:
ANT: RELEASE-NOTES-1.7.0.html
HTTPD: CHANGES_2.2.6
Since these will get archived, and redirects can be done for them, their
URLs can be permanent.
To be consistent with this practice, I would like to put our release
notes for display from our web site in a.o/dist/...
They don't need to be signed, because only archives need that; also,
other projects don't sign these kinds of things. Any objections?
-Marshall
Marshall Schor wrote:
Here's an argument for keeping the big things we point to from our
website, like the javaDocs and the 4 books in html form, on the
a.o/dist/incubator/uima site:
It is automatically archived. And, when it's "deleted" from the
mirror, a redirect is put in to the archive spot.
This would be ideal for being able to have older versions kept with
permanent static URLs.
So - upon further reflection - I think I'm changing my mind on this, and
am now in favor of keeping these on the mirroring system.
We can avoid having people who are on our web site and want to view the
documentation, having to check signatures by not using the mirroring
system, but just pointing them to the main a.o/dist location. I'm not
sure if this would be OK in terms of protocol for load balancing, but
I'll set the doc page up this way for now, and we can change it if we
need to.
-Marshall
Michael Baessler wrote:
Fine with me to delete the HTML documentations (manual and javadoc) on
the mirror. I thought we can use it and link them from our website.
As far as I know, there is no script to upload the documentation. I
did it manually.
-- Michael
Marshall Schor wrote:
Here are some examples of large files (or large collections of files
The api java docs;
The api java docs as a zip file
The 4 books in html format
It seems good to put them in
people.a.o/www/incubator.a.o/uima/downloads.
It seems bad to put them in SVN (because there's no need for
"versioning" these - they're generated, and they are big, taking up SVN
space).
Our current strategy is hybrid:
1) for current release only: api java docs and the api java docs.zip
file are put in people.a.o/www/incubator.a.o/uima/downloads, and are
*not* kept in SVN.
2) for current release only: the 4 books in html format are put in SVN
and copied to people.a.o/www/incubator.a.o/uima/downloads with the svn
update command.
I see, in fact that for release 2.2.0, we managed to put the books in
html format into SVN twice - once under
2.2.0-incubating/docs/html, and once under
2.2.0-incubating/html
and of course, on the website, it shows up twice also... not good.
Is there any automated process for getting the files installed on
people.a.o/www/incubator.a.o/uima/downloads? (Has anyone done any
scripts for this)?
Does everyone agree that it's best to keep these out of SVN, and to put
them in the web server spot on
people.a.o/www/incubator.a.o/uima/downloads?
===================
The mirrored distribution spot contains, in addition to /binaries and
/source, a /docs directory with the the following:
<release>/apiDocs.zip , plus the 3 "signing" files [asc, md5, sha1]
<release>/api /.... <-- unzipped set of javaDoc html files, no
signing files
<release>/html/..... <-- set of 4 books as html files, no signing
files
<release>/pdf/..... <-- set of 4 books as pdfs, no signing files
I think everything that's put onto the mirroring system is supposed to
be signed, because Apache doesn't "control" what goes on at the mirrors
(e.g., they could be "hacked").
Currently, our download page is slient about the existance of these.
I think we should delete these on the mirroring distribution system.
Assuming we followed the top part of this note, we would have everything
(except the pdf form of the 4 books) on the UIMA website, directly (not
going thru a mirror).
Other opinions?
-Marshall
