uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Where to put large generated things for our website to access
Date Sun, 23 Dec 2007 04:05:35 GMT
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
>>>
>>>   
>>>       
>>
>>     
>
>
>
>   


Mime
View raw message