Re: Web site update

[Hernan Cunico]

I'll take on the samples. Who can take on the "Testsuite"

Cheers!
Hernan

Donald Woods wrote:
Looks good.  Maybe we can create a "How to contribute to Samples" and 
"Testsuite" at some point, as we need more users helping us with those



-Donald


Hernan Cunico wrote:

Hi All,
I added a section to the "Getting Involved" page. The idea is to 
explain how easy is to contribute to the project's documentation.

http://cwiki.apache.org/GMOxSITE/get-involved.html

I also added a very similar page to the wiki front page 
http://cwiki.apache.org/geronimo/how-to-contribute-to-the-projects-documentation.html 



Pls let me know what you think and how we can make it better.

Cheers!
Hernan

Re: Web site update

[Donald Woods]

Looks good.  Maybe we can create a "How to contribute to Samples" and 
"Testsuite" at some point, as we need more users helping us with those



-Donald


Hernan Cunico wrote:

Hi All,
I added a section to the "Getting Involved" page. The idea is to explain 
how easy is to contribute to the project's documentation.

http://cwiki.apache.org/GMOxSITE/get-involved.html

I also added a very similar page to the wiki front page 
http://cwiki.apache.org/geronimo/how-to-contribute-to-the-projects-documentation.html 



Pls let me know what you think and how we can make it better.

Cheers!
Hernan



smime.p7s
Description: S/MIME Cryptographic Signature

Re: web site update

[Jason Dillon]

On May 2, 2007, at 7:34 PM, Hernan Cunico wrote:

Jason Dillon wrote:
Also, why are the release notes using closer.cgi?  Its a PITA when  
you want to go look at these small text files to see what they  
have to use this mirror redirector, which is intended for larger  
downloads :-(


The way we download the files is the same way we have been using  
since the very beginning, long before the first face lift. Not sure  
why you bring this up just now !?


Because I finally got annoyed enough to mention it. :-P


I see so you just left one box logo on the downloads page then?   
Not the direction I would have hopped... and its still got that  
ugly border... :-(


I didn't attach any new images, however I did fix the border  
problem earlier today.


Yay.


It was you who added the 1.1 image in first place on the download  
page (Mar 26, 2007 14:52 - Jason Dillon: Add the nice box, using  
svn url at the moment, should change). I then changed it with a  
smaller jpg version for faster rendering.


Aight, as long as only one page (ie. the downloads.html) page has the  
images attached, and you link the release pages to those images (and  
not attach them to the release page) then we are sorted.



Either way, that image refers to 1.1, that's why I asked for one  
without any version specific info so we can add it to the "general"  
download page. FWIW we are also missing 1.0 and 1.1.1 boxes so we  
can add to each download page the corresponding image.


You'd have to ask Hiram for that.  Personally, I like the version,  
and it would be nice to see the box on each release page, as the AMQ  
releases are for their 4.1.x stuff.


--jason

Re: web site update

[Hernan Cunico]

Jason Dillon wrote:
Also, why are the release notes using closer.cgi?  Its a PITA when you 
want to go look at these small text files to see what they have to use 
this mirror redirector, which is intended for larger downloads :-(


The way we download the files is the same way we have been using since the very 
beginning, long before the first face lift. Not sure why you bring this up just 
now !?



--jason


On May 2, 2007, at 2:49 PM, Jason Dillon wrote:

I see so you just left one box logo on the downloads page then?  Not 
the direction I would have hopped... and its still got that ugly 
border... :-(


I didn't attach any new images, however I did fix the border problem earlier 
today.

It was you who added the 1.1 image in first place on the download page (Mar 26, 
2007 14:52 - Jason Dillon: Add the nice box, using svn url at the moment, 
should change). I then changed it with a smaller jpg version for faster 
rendering.

Either way, that image refers to 1.1, that's why I asked for one without any version 
specific info so we can add it to the "general" download page. FWIW we are also 
missing 1.0 and 1.1.1 boxes so we can add to each download page the corresponding image.

WRT http://cwiki.apache.org/GMOxSITE/downloads.data/geronimo-box-1.1-small.jpg 
I mentioned in the other thread you replied:


This is the same box logo which I'm talking about.

I thought I had explained this already...

I give up.  You do it how you want and if you end up copying the image over and 
over I'll try to explain again later why duplicating is bad.


*geronimo-box-1.1-small.jpg* is not the same image as 
*geronimo-box-1.2-small.jpg* which is not the same image as 
*geronimo-box-2.0-small.jpg* ..., so what is it I am duplicating?

Cheers!
Hernan



--jason



On May 2, 2007, at 2:32 PM, Jason Dillon wrote:


On May 2, 2007, at 8:09 AM, Hernan Cunico wrote:

just to be sure, what is the "logo" you are talking about?

I'm talking about the Geronimo boxes as in 
http://cwiki.apache.org/GMOxSITE/downloads.data/geronimo-box-1.1-small.jpg, 
this is a unique image that is to be used only for the 1.1 release 
in this case. Each image would be used only once, I can't see why 
attaching that unique image file to a unique page is such a bad thing.


This is the same box logo which I'm talking about.

I thought I had explained this already...

I give up.  You do it how you want and if you end up copying the 
image over and over I'll try to explain again later why duplicating 
is bad.


--jason



If the images are attached to confluence and we export the space, 
all the content gets exported. Hence we have a self contained copy 
of the web site with very limited external dependencies, that is for 
the actual downloads.


Even if we serve those images from svn we would still have to copy 
every single one from site/trunk/art to site/trunk/docs/images


One additional tiny benefit on the attachment approach is that the 
image served from confluence is approx 4 times smaller in size 
compared to the one we have on svn. I know, I did that to make the 
rendering a bit faster but my point is that we will still have to do 
some additional steps either way, not only svn cp.


Now, if we want to serve all the static content from all our the 
cwiki spaces directly from svn that's a different story.


Cheers!
Hernan

Jason Dillon wrote:

On May 2, 2007, at 7:01 AM, Hernan Cunico wrote:

Jason Dillon wrote:

Um... why?
That mens for each release we have a duplicate image?  That is crazy
not really, wasn't your point to have a unique image for each 
release page? maybe I didn't understand
No, I want to have one box image in 
http://geronimo.apache.org/images/ per version, and have each 
release page reference it (like a normal web page would do).
man.  Thats like saying that each page has the banner image 
attached to it, though admittedly that is much worse, but its 
along the same lines as what you are suggesting.


right, there is no point in copying the very same image over and 
over again, so there is clearly a misunderstanding here.

Um... I'm confused... you said:

I think we should be consistent in the way we manage the 
attachments with confluence.

I rather have them attached to corresponding release page.
There are not that many to copy over anyway.

I read this as you want to have the images of the box log attached 
to the corresponding release page, meaning each page has a separate 
copy of the same logo.  I'm not sure how I could have read it any 
differently :-(
If we are going to use just one image (independent of the Geronimo 
version) on each release page then we definitively point to the 
same spot where we have the banners and logos on the repo.
However, if we want to have for each release page a new Geronimo 
box with a matching version number, then we should to attach each 
of those images to the corresponding release page. This is the 
approach I thought we were talking about. If we go this way then 
we need to come 

Re: web site update

[Jason Dillon]

Also, why are the release notes using closer.cgi?  Its a PITA when  
you want to go look at these small text files to see what they have  
to use this mirror redirector, which is intended for larger  
downloads :-(


--jason


On May 2, 2007, at 2:49 PM, Jason Dillon wrote:

I see so you just left one box logo on the downloads page then?   
Not the direction I would have hopped... and its still got that  
ugly border... :-(


--jason



On May 2, 2007, at 2:32 PM, Jason Dillon wrote:


On May 2, 2007, at 8:09 AM, Hernan Cunico wrote:

just to be sure, what is the "logo" you are talking about?

I'm talking about the Geronimo boxes as in http:// 
cwiki.apache.org/GMOxSITE/downloads.data/geronimo-box-1.1- 
small.jpg, this is a unique image that is to be used only for the  
1.1 release in this case. Each image would be used only once, I  
can't see why attaching that unique image file to a unique page  
is such a bad thing.


This is the same box logo which I'm talking about.

I thought I had explained this already...

I give up.  You do it how you want and if you end up copying the  
image over and over I'll try to explain again later why  
duplicating is bad.


--jason



If the images are attached to confluence and we export the space,  
all the content gets exported. Hence we have a self contained  
copy of the web site with very limited external dependencies,  
that is for the actual downloads.


Even if we serve those images from svn we would still have to  
copy every single one from site/trunk/art to site/trunk/docs/images


One additional tiny benefit on the attachment approach is that  
the image served from confluence is approx 4 times smaller in  
size compared to the one we have on svn. I know, I did that to  
make the rendering a bit faster but my point is that we will  
still have to do some additional steps either way, not only svn cp.


Now, if we want to serve all the static content from all our the  
cwiki spaces directly from svn that's a different story.


Cheers!
Hernan

Jason Dillon wrote:

On May 2, 2007, at 7:01 AM, Hernan Cunico wrote:

Jason Dillon wrote:

Um... why?
That mens for each release we have a duplicate image?  That is  
crazy
not really, wasn't your point to have a unique image for each  
release page? maybe I didn't understand
No, I want to have one box image in http://geronimo.apache.org/ 
images/ per version, and have each release page reference it  
(like a normal web page would do).
man.  Thats like saying that each page has the banner image  
attached to it, though admittedly that is much worse, but its  
along the same lines as what you are suggesting.


right, there is no point in copying the very same image over  
and over again, so there is clearly a misunderstanding here.

Um... I'm confused... you said:

I think we should be consistent in the way we manage the  
attachments with confluence.

I rather have them attached to corresponding release page.
There are not that many to copy over anyway.

I read this as you want to have the images of the box log  
attached to the corresponding release page, meaning each page  
has a separate copy of the same logo.  I'm not sure how I could  
have read it any differently :-(
If we are going to use just one image (independent of the  
Geronimo version) on each release page then we definitively  
point to the same spot where we have the banners and logos on  
the repo.
However, if we want to have for each release page a new  
Geronimo box with a matching version number, then we should to  
attach each of those images to the corresponding release page.  
This is the approach I thought we were talking about. If we go  
this way then we need to come up with a kind of standard way to  
create that image, today we are missing 1.0 and 1.1.1.
Right, I don't think we need to have an image that matches the  
exact version.  I think that 1.1, 1.1.1, 1.1.2, etc... all use  
the 1.1 logo, 2.0, 2.0.1, 2.0.2, etc. all use the 2.0 logo, and  
so on.

Ask Hiram to whip up a 1.0 version, he said it was relatively easy.
I don't think we want to have separate images for 2.0-m5, 2.0- 
m6, 2.0-m99, 2.0.1, etc, basically one image per major branch...  
else we'd be asking Hiram to make new images all of the time ;-)

--jason

Re: web site update

[Jason Dillon]

I see so you just left one box logo on the downloads page then?  Not  
the direction I would have hopped... and its still got that ugly  
border... :-(


--jason



On May 2, 2007, at 2:32 PM, Jason Dillon wrote:


On May 2, 2007, at 8:09 AM, Hernan Cunico wrote:

just to be sure, what is the "logo" you are talking about?

I'm talking about the Geronimo boxes as in http://cwiki.apache.org/ 
GMOxSITE/downloads.data/geronimo-box-1.1-small.jpg, this is a  
unique image that is to be used only for the 1.1 release in this  
case. Each image would be used only once, I can't see why  
attaching that unique image file to a unique page is such a bad  
thing.


This is the same box logo which I'm talking about.

I thought I had explained this already...

I give up.  You do it how you want and if you end up copying the  
image over and over I'll try to explain again later why duplicating  
is bad.


--jason



If the images are attached to confluence and we export the space,  
all the content gets exported. Hence we have a self contained copy  
of the web site with very limited external dependencies, that is  
for the actual downloads.


Even if we serve those images from svn we would still have to copy  
every single one from site/trunk/art to site/trunk/docs/images


One additional tiny benefit on the attachment approach is that the  
image served from confluence is approx 4 times smaller in size  
compared to the one we have on svn. I know, I did that to make the  
rendering a bit faster but my point is that we will still have to  
do some additional steps either way, not only svn cp.


Now, if we want to serve all the static content from all our the  
cwiki spaces directly from svn that's a different story.


Cheers!
Hernan

Jason Dillon wrote:

On May 2, 2007, at 7:01 AM, Hernan Cunico wrote:

Jason Dillon wrote:

Um... why?
That mens for each release we have a duplicate image?  That is  
crazy
not really, wasn't your point to have a unique image for each  
release page? maybe I didn't understand
No, I want to have one box image in http://geronimo.apache.org/ 
images/ per version, and have each release page reference it  
(like a normal web page would do).
man.  Thats like saying that each page has the banner image  
attached to it, though admittedly that is much worse, but its  
along the same lines as what you are suggesting.


right, there is no point in copying the very same image over and  
over again, so there is clearly a misunderstanding here.

Um... I'm confused... you said:

I think we should be consistent in the way we manage the  
attachments with confluence.

I rather have them attached to corresponding release page.
There are not that many to copy over anyway.

I read this as you want to have the images of the box log  
attached to the corresponding release page, meaning each page has  
a separate copy of the same logo.  I'm not sure how I could have  
read it any differently :-(
If we are going to use just one image (independent of the  
Geronimo version) on each release page then we definitively  
point to the same spot where we have the banners and logos on  
the repo.
However, if we want to have for each release page a new Geronimo  
box with a matching version number, then we should to attach  
each of those images to the corresponding release page. This is  
the approach I thought we were talking about. If we go this way  
then we need to come up with a kind of standard way to create  
that image, today we are missing 1.0 and 1.1.1.
Right, I don't think we need to have an image that matches the  
exact version.  I think that 1.1, 1.1.1, 1.1.2, etc... all use  
the 1.1 logo, 2.0, 2.0.1, 2.0.2, etc. all use the 2.0 logo, and  
so on.

Ask Hiram to whip up a 1.0 version, he said it was relatively easy.
I don't think we want to have separate images for 2.0-m5, 2.0-m6,  
2.0-m99, 2.0.1, etc, basically one image per major branch... else  
we'd be asking Hiram to make new images all of the time ;-)

--jason

Re: web site update

[Jason Dillon]

On May 2, 2007, at 8:09 AM, Hernan Cunico wrote:

just to be sure, what is the "logo" you are talking about?

I'm talking about the Geronimo boxes as in http://cwiki.apache.org/ 
GMOxSITE/downloads.data/geronimo-box-1.1-small.jpg, this is a  
unique image that is to be used only for the 1.1 release in this  
case. Each image would be used only once, I can't see why attaching  
that unique image file to a unique page is such a bad thing.


This is the same box logo which I'm talking about.

I thought I had explained this already...

I give up.  You do it how you want and if you end up copying the  
image over and over I'll try to explain again later why duplicating  
is bad.


--jason



If the images are attached to confluence and we export the space,  
all the content gets exported. Hence we have a self contained copy  
of the web site with very limited external dependencies, that is  
for the actual downloads.


Even if we serve those images from svn we would still have to copy  
every single one from site/trunk/art to site/trunk/docs/images


One additional tiny benefit on the attachment approach is that the  
image served from confluence is approx 4 times smaller in size  
compared to the one we have on svn. I know, I did that to make the  
rendering a bit faster but my point is that we will still have to  
do some additional steps either way, not only svn cp.


Now, if we want to serve all the static content from all our the  
cwiki spaces directly from svn that's a different story.


Cheers!
Hernan

Jason Dillon wrote:

On May 2, 2007, at 7:01 AM, Hernan Cunico wrote:

Jason Dillon wrote:

Um... why?
That mens for each release we have a duplicate image?  That is  
crazy
not really, wasn't your point to have a unique image for each  
release page? maybe I didn't understand
No, I want to have one box image in http://geronimo.apache.org/ 
images/ per version, and have each release page reference it (like  
a normal web page would do).
man.  Thats like saying that each page has the banner image  
attached to it, though admittedly that is much worse, but its  
along the same lines as what you are suggesting.


right, there is no point in copying the very same image over and  
over again, so there is clearly a misunderstanding here.

Um... I'm confused... you said:

I think we should be consistent in the way we manage the  
attachments with confluence.

I rather have them attached to corresponding release page.
There are not that many to copy over anyway.

I read this as you want to have the images of the box log attached  
to the corresponding release page, meaning each page has a  
separate copy of the same logo.  I'm not sure how I could have  
read it any differently :-(
If we are going to use just one image (independent of the  
Geronimo version) on each release page then we definitively point  
to the same spot where we have the banners and logos on the repo.
However, if we want to have for each release page a new Geronimo  
box with a matching version number, then we should to attach each  
of those images to the corresponding release page. This is the  
approach I thought we were talking about. If we go this way then  
we need to come up with a kind of standard way to create that  
image, today we are missing 1.0 and 1.1.1.
Right, I don't think we need to have an image that matches the  
exact version.  I think that 1.1, 1.1.1, 1.1.2, etc... all use the  
1.1 logo, 2.0, 2.0.1, 2.0.2, etc. all use the 2.0 logo, and so on.

Ask Hiram to whip up a 1.0 version, he said it was relatively easy.
I don't think we want to have separate images for 2.0-m5, 2.0-m6,  
2.0-m99, 2.0.1, etc, basically one image per major branch... else  
we'd be asking Hiram to make new images all of the time ;-)

--jason

Re: web site update

[Hernan Cunico]

just to be sure, what is the "logo" you are talking about?

I'm talking about the Geronimo boxes as in 
http://cwiki.apache.org/GMOxSITE/downloads.data/geronimo-box-1.1-small.jpg, 
this is a unique image that is to be used only for the 1.1 release in this 
case. Each image would be used only once, I can't see why attaching that unique 
image file to a unique page is such a bad thing.

If the images are attached to confluence and we export the space, all the 
content gets exported. Hence we have a self contained copy of the web site with 
very limited external dependencies, that is for the actual downloads.

Even if we serve those images from svn we would still have to copy every single 
one from site/trunk/art to site/trunk/docs/images

One additional tiny benefit on the attachment approach is that the image served 
from confluence is approx 4 times smaller in size compared to the one we have 
on svn. I know, I did that to make the rendering a bit faster but my point is 
that we will still have to do some additional steps either way, not only svn cp.

Now, if we want to serve all the static content from all our the cwiki spaces 
directly from svn that's a different story.

Cheers!
Hernan

Jason Dillon wrote:

On May 2, 2007, at 7:01 AM, Hernan Cunico wrote:

Jason Dillon wrote:

Um... why?
That mens for each release we have a duplicate image?  That is crazy
not really, wasn't your point to have a unique image for each release 
page? maybe I didn't understand


No, I want to have one box image in http://geronimo.apache.org/images/ 
per version, and have each release page reference it (like a normal web 
page would do).



man.  Thats like saying that each page has the banner image attached 
to it, though admittedly that is much worse, but its along the same 
lines as what you are suggesting.


right, there is no point in copying the very same image over and over 
again, so there is clearly a misunderstanding here.


Um... I'm confused... you said:


I think we should be consistent in the way we manage the attachments 
with confluence.

I rather have them attached to corresponding release page.
There are not that many to copy over anyway.


I read this as you want to have the images of the box log attached to 
the corresponding release page, meaning each page has a separate copy of 
the same logo.  I'm not sure how I could have read it any differently :-(



If we are going to use just one image (independent of the Geronimo 
version) on each release page then we definitively point to the same 
spot where we have the banners and logos on the repo.
However, if we want to have for each release page a new Geronimo box 
with a matching version number, then we should to attach each of those 
images to the corresponding release page. This is the approach I 
thought we were talking about. If we go this way then we need to come 
up with a kind of standard way to create that image, today we are 
missing 1.0 and 1.1.1.


Right, I don't think we need to have an image that matches the exact 
version.  I think that 1.1, 1.1.1, 1.1.2, etc... all use the 1.1 logo, 
2.0, 2.0.1, 2.0.2, etc. all use the 2.0 logo, and so on.


Ask Hiram to whip up a 1.0 version, he said it was relatively easy.

I don't think we want to have separate images for 2.0-m5, 2.0-m6, 
2.0-m99, 2.0.1, etc, basically one image per major branch... else we'd 
be asking Hiram to make new images all of the time ;-)


--jason

Re: web site update

[Jason Dillon]

On May 2, 2007, at 7:01 AM, Hernan Cunico wrote:

Jason Dillon wrote:

Um... why?
That mens for each release we have a duplicate image?  That is crazy
not really, wasn't your point to have a unique image for each  
release page? maybe I didn't understand


No, I want to have one box image in http://geronimo.apache.org/ 
images/ per version, and have each release page reference it (like a  
normal web page would do).



man.  Thats like saying that each page has the banner image  
attached to it, though admittedly that is much worse, but its  
along the same lines as what you are suggesting.


right, there is no point in copying the very same image over and  
over again, so there is clearly a misunderstanding here.


Um... I'm confused... you said:


I think we should be consistent in the way we manage the attachments  
with confluence.

I rather have them attached to corresponding release page.
There are not that many to copy over anyway.


I read this as you want to have the images of the box log attached to  
the corresponding release page, meaning each page has a separate copy  
of the same logo.  I'm not sure how I could have read it any  
differently :-(



If we are going to use just one image (independent of the Geronimo  
version) on each release page then we definitively point to the  
same spot where we have the banners and logos on the repo.
However, if we want to have for each release page a new Geronimo  
box with a matching version number, then we should to attach each  
of those images to the corresponding release page. This is the  
approach I thought we were talking about. If we go this way then we  
need to come up with a kind of standard way to create that image,  
today we are missing 1.0 and 1.1.1.


Right, I don't think we need to have an image that matches the exact  
version.  I think that 1.1, 1.1.1, 1.1.2, etc... all use the 1.1  
logo, 2.0, 2.0.1, 2.0.2, etc. all use the 2.0 logo, and so on.


Ask Hiram to whip up a 1.0 version, he said it was relatively easy.

I don't think we want to have separate images for 2.0-m5, 2.0-m6, 2.0- 
m99, 2.0.1, etc, basically one image per major branch... else we'd be  
asking Hiram to make new images all of the time ;-)


--jason

Re: web site update

[Hernan Cunico]

Jason Dillon wrote:

Um... why?

That mens for each release we have a duplicate image?  That is crazy 

not really, wasn't your point to have a unique image for each release page? 
maybe I didn't understand

man.  Thats like saying that each page has the banner image attached to 
it, though admittedly that is much worse, but its along the same lines 
as what you are suggesting.


right, there is no point in copying the very same image over and over again, so 
there is clearly a misunderstanding here.

If we are going to use just one image (independent of the Geronimo version) on 
each release page then we definitively point to the same spot where we have the 
banners and logos on the repo.
However, if we want to have for each release page a new Geronimo box with a 
matching version number, then we should to attach each of those images to the 
corresponding release page. This is the approach I thought we were talking 
about. If we go this way then we need to come up with a kind of standard way to 
create that image, today we are missing 1.0 and 1.1.1.

Cheers!
Hernan


If you recall I originally setup this image to pull from a URL and not 
from an attachment... and I think it should make its way back to that.


--jason


On May 2, 2007, at 6:40 AM, Hernan Cunico wrote:

I think we should be consistent in the way we manage the attachments 
with confluence. I rather have them attached to corresponding release 
page. There are not that many to copy over anyway.


Cheers!
Hernan

Jason Dillon wrote:
We should just add these to the static files we put into the site and 
use an http link here.  Especially if we are going to have 
per-release pages, we don't want to duplicate those images over and 
over.
Should just svn cp them from site/trunk/art into 
site/trunk/docs/images...

--jason
On May 2, 2007, at 6:12 AM, Hernan Cunico wrote:
yeah, that is the autoexported version, the one on confluence (the 
source!?) looks fine. The autoexport plugin doesn't see attachment 
updates so those files need to be deleted manually
I already opened a JIRA (INFRA-1226) to remove that file so I can 
export manually the space and finally get that image updated.


Cheers!
Hernan

Jason Dillon wrote:
Hey, I just noticed that the box has some weird looking border on 
the top+left... any idea where that came from?

--jason
On May 1, 2007, at 1:53 PM, Hernan Cunico wrote:

Let's do it!

I'll start moving some pages around. Do we have a "Geronimo Box" 
without any specific version? 
(http://geronimo.apache.org/downloads.data/geronimo-box-1.1-small.jpg) 



Cheers!
Hernan

Sachin Patel wrote:

+1.
-sachin
On May 1, 2007, at 4:21 PM, Jason Dillon wrote:
I'd still like to see things organized in the same way that 
AcitveMQ does:

Re: web site update

[Jason Dillon]

Um... why?

That mens for each release we have a duplicate image?  That is crazy  
man.  Thats like saying that each page has the banner image attached  
to it, though admittedly that is much worse, but its along the same  
lines as what you are suggesting.


If you recall I originally setup this image to pull from a URL and  
not from an attachment... and I think it should make its way back to  
that.


--jason


On May 2, 2007, at 6:40 AM, Hernan Cunico wrote:

I think we should be consistent in the way we manage the  
attachments with confluence. I rather have them attached to  
corresponding release page. There are not that many to copy over  
anyway.


Cheers!
Hernan

Jason Dillon wrote:
We should just add these to the static files we put into the site  
and use an http link here.  Especially if we are going to have per- 
release pages, we don't want to duplicate those images over and over.
Should just svn cp them from site/trunk/art into site/trunk/docs/ 
images...

--jason
On May 2, 2007, at 6:12 AM, Hernan Cunico wrote:
yeah, that is the autoexported version, the one on confluence  
(the source!?) looks fine. The autoexport plugin doesn't see  
attachment updates so those files need to be deleted manually
I already opened a JIRA (INFRA-1226) to remove that file so I can  
export manually the space and finally get that image updated.


Cheers!
Hernan

Jason Dillon wrote:
Hey, I just noticed that the box has some weird looking border  
on the top+left... any idea where that came from?

--jason
On May 1, 2007, at 1:53 PM, Hernan Cunico wrote:

Let's do it!

I'll start moving some pages around. Do we have a "Geronimo  
Box" without any specific version? (http://geronimo.apache.org/ 
downloads.data/geronimo-box-1.1-small.jpg)


Cheers!
Hernan

Sachin Patel wrote:

+1.
-sachin
On May 1, 2007, at 4:21 PM, Jason Dillon wrote:
I'd still like to see things organized in the same way that  
AcitveMQ does:

Re: web site update

[Hernan Cunico]

I think we should be consistent in the way we manage the attachments with 
confluence. I rather have them attached to corresponding release page. There 
are not that many to copy over anyway.

Cheers!
Hernan

Jason Dillon wrote:
We should just add these to the static files we put into the site and 
use an http link here.  Especially if we are going to have per-release 
pages, we don't want to duplicate those images over and over.


Should just svn cp them from site/trunk/art into site/trunk/docs/images...

--jason


On May 2, 2007, at 6:12 AM, Hernan Cunico wrote:

yeah, that is the autoexported version, the one on confluence (the 
source!?) looks fine. The autoexport plugin doesn't see attachment 
updates so those files need to be deleted manually
I already opened a JIRA (INFRA-1226) to remove that file so I can 
export manually the space and finally get that image updated.


Cheers!
Hernan

Jason Dillon wrote:
Hey, I just noticed that the box has some weird looking border on the 
top+left... any idea where that came from?

--jason
On May 1, 2007, at 1:53 PM, Hernan Cunico wrote:

Let's do it!

I'll start moving some pages around. Do we have a "Geronimo Box" 
without any specific version? 
(http://geronimo.apache.org/downloads.data/geronimo-box-1.1-small.jpg)


Cheers!
Hernan

Sachin Patel wrote:

+1.
-sachin
On May 1, 2007, at 4:21 PM, Jason Dillon wrote:
I'd still like to see things organized in the same way that 
AcitveMQ does:

Re: web site update

[Jason Dillon]

We should just add these to the static files we put into the site and  
use an http link here.  Especially if we are going to have per- 
release pages, we don't want to duplicate those images over and over.


Should just svn cp them from site/trunk/art into site/trunk/docs/ 
images...


--jason


On May 2, 2007, at 6:12 AM, Hernan Cunico wrote:

yeah, that is the autoexported version, the one on confluence (the  
source!?) looks fine. The autoexport plugin doesn't see attachment  
updates so those files need to be deleted manually
I already opened a JIRA (INFRA-1226) to remove that file so I can  
export manually the space and finally get that image updated.


Cheers!
Hernan

Jason Dillon wrote:
Hey, I just noticed that the box has some weird looking border on  
the top+left... any idea where that came from?

--jason
On May 1, 2007, at 1:53 PM, Hernan Cunico wrote:

Let's do it!

I'll start moving some pages around. Do we have a "Geronimo Box"  
without any specific version? (http://geronimo.apache.org/ 
downloads.data/geronimo-box-1.1-small.jpg)


Cheers!
Hernan

Sachin Patel wrote:

+1.
-sachin
On May 1, 2007, at 4:21 PM, Jason Dillon wrote:
I'd still like to see things organized in the same way that  
AcitveMQ does:

Re: web site update

[Hernan Cunico]

yeah, that is the autoexported version, the one on confluence (the source!?) 
looks fine. The autoexport plugin doesn't see attachment updates so those files 
need to be deleted manually
I already opened a JIRA (INFRA-1226) to remove that file so I can export 
manually the space and finally get that image updated.

Cheers!
Hernan

Jason Dillon wrote:
Hey, I just noticed that the box has some weird looking border on the 
top+left... any idea where that came from?


--jason


On May 1, 2007, at 1:53 PM, Hernan Cunico wrote:


Let's do it!

I'll start moving some pages around. Do we have a "Geronimo Box" 
without any specific version? 
(http://geronimo.apache.org/downloads.data/geronimo-box-1.1-small.jpg)


Cheers!
Hernan

Sachin Patel wrote:

+1.
-sachin
On May 1, 2007, at 4:21 PM, Jason Dillon wrote:
I'd still like to see things organized in the same way that AcitveMQ 
does:

Re: web site update

[Jason Dillon]

Hey, I just noticed that the box has some weird looking border on the  
top+left... any idea where that came from?


--jason


On May 1, 2007, at 1:53 PM, Hernan Cunico wrote:


Let's do it!

I'll start moving some pages around. Do we have a "Geronimo Box"  
without any specific version? (http://geronimo.apache.org/ 
downloads.data/geronimo-box-1.1-small.jpg)


Cheers!
Hernan

Sachin Patel wrote:

+1.
-sachin
On May 1, 2007, at 4:21 PM, Jason Dillon wrote:
I'd still like to see things organized in the same way that  
AcitveMQ does:

Re: web site update

[Jason Dillon]

On May 1, 2007, at 1:53 PM, Hernan Cunico wrote:

Let's do it!

I'll start moving some pages around. Do we have a "Geronimo Box"  
without any specific version? (http://geronimo.apache.org/ 
downloads.data/geronimo-box-1.1-small.jpg)


No, but we have versions for 1.1, 1.2 and 2.0:

http://svn.apache.org/repos/asf/geronimo/site/trunk/art/

--jason

Re: web site update

[Hernan Cunico]

Let's do it!

I'll start moving some pages around. Do we have a "Geronimo Box" without any 
specific version? (http://geronimo.apache.org/downloads.data/geronimo-box-1.1-small.jpg)

Cheers!
Hernan

Sachin Patel wrote:

+1.

-sachin


On May 1, 2007, at 4:21 PM, Jason Dillon wrote:

I'd still like to see things organized in the same way that AcitveMQ 
does:

Re: web site update

[Sachin Patel]

+1.

-sachin


On May 1, 2007, at 4:21 PM, Jason Dillon wrote:

I'd still like to see things organized in the same way that  
AcitveMQ does:

Re: web site update

[Jason Dillon]

I'd still like to see things organized in the same way that AcitveMQ  
does:


http://activemq.apache.org/download.html

A page per release, w/ jira list, etc.

--jason


On May 1, 2007, at 5:58 AM, Hernan Cunico wrote:


Hi Folks,
Looking at the download page (http://geronimo.apache.org/ 
downloads.html) I was wondering if it actually wouldn't be better  
to have all the downloads for one specific release together.
Today we have 2 sections, that is Binaries and Sources. I propose  
we get rid of those 2 sections and consolidate all the downloads  
grouped by release under the new section "Available Releases".


If nobody disagree I will go ahead and make this change. New ideas  
also welcome!


Cheers!
Hernan

Re: Web site update

[Hernan Cunico]

We now have the web site updated with the content from the trunk so the merge 
is behind.

I have a question though, we did not have branches for the web site before, just a "main" trunk. 
What would be the criteria from now on to update the web site? There were updates to the web site 
directly on the trunk while I was updating the branch may2006.


Not sure I understand why we need branches to maintain the web site now. We did the big "face lift" 
and some reorg when we updated the look and feel and we only used trunk. Thoughts?


Cheers!
Hernan

Aaron Mulder wrote:

I think this is complicated by the fact that we split out the trunk
and branch after the fact (basically moved trunk to branch and
recreated trunk by copying from a previous revision.

I think the way to do the merge would be to generate a diff between
the revision we copied to trunk (I forget which but it said in the
commit message when I did it) and the tip of the branch.  I think it
would be important to use that exact revision number as the "before"
point in generating the diff or doing the merge.

Thanks,
   Aaron

On 6/21/06, Jeremy Whitlock <[EMAIL PROTECTED]> wrote:


Hernan,
Glad to hear you got it working.  As for the command-line way:

svn merge [EMAIL PROTECTED]
[EMAIL PROTECTED]
PATH_TO_WORKING_COPY_YOU_WISH_TO_MERGE_CHANGES_INTO

Sorry for the weird looking command but I tried to put some useful 
tidbits

into the command.  ;)

Take care,

Jeremy


On 6/21/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> Hi Jeremy,
> I was using a graphical tool to do the merge. The dry run would show 
all

the files that would be
> updated but when I ran it "for real" nothing really changed on my 
working,

local trunk, copy.
>
> I did an svn stat and saw no changes, did an svn up and it failed. 
Can't

remember exactly the error
> msg but was something about not a working directory or can not run from
the same directory.
>
> I ended up doing a new svn co from the trunk, updated the project files
and xdocs, rebuilding and
> committing. I couldn't find any other way to do it, then I updated 
the web

site from the trunk.
>
> What would the "svn command line" way be for merging the branch into 
the

trunk?
>
> Thanks
>
> Cheers!
> Hernan
>
> Jeremy Whitlock wrote:
> > Hernan,
> > Can you paste the command that you are trying to use?  Merging is
> > the proper approach for this type of thing.  With the merge 
command, you

> > can create a patch using the unified-diff output and piping it to a
> > file.  If I can see your command, I can hook you up.
> >
> > Take care,
> >
> > Jeremy
> >
> > On 6/20/06, *Hernan Cunico* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Merging isn't working, I don't see anything being updated into
trunk.
> > How do I create a patch if my local working copy is fully in sync
> > with the branch, not the trunk.
> >
> > Is there a way to copy/move the content of the branch and 
overwrite

> > the trunk?
> >
> > Thanks
> >
> > Hernan
> >
> > David Blevins wrote:
> >  > On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote:
> >  >
> >  >> Hi All,
> >  >> I'm a bit lost with the two branches we have now to manage 
the

web
> >  >> site.  I have the .../site/branches/may2006 branch updated
> > and  ready
> >  >> to go live, it already includes that last two changes  
(updated

> > events
> >  >> and added book to documentation).
> >  >>
> >  >> What would be the next step? replacing the content of 
.../site/

> > trunk
> >  >> and then commit to the live site from the updated trunk? 
how  do

I
> >  >> replace it the content in .../site/trunk with the may2006
branch?
> >  >
> >  >
> >  > Typically, you'd merge over your changes.  Could use the 'svn
merge'
> >  > command.  Or you could create a patch file and apply it to 
trunk.

 I
> >  > like to use the graphical diff tool in Visual SlickEdit, but
> > that's  not
> >  > free.
> >  >
> >  > -David
> >  >
> >  >
> >
> >
>

Re: Web site update

[Aaron Mulder]

I think this is complicated by the fact that we split out the trunk
and branch after the fact (basically moved trunk to branch and
recreated trunk by copying from a previous revision.

I think the way to do the merge would be to generate a diff between
the revision we copied to trunk (I forget which but it said in the
commit message when I did it) and the tip of the branch.  I think it
would be important to use that exact revision number as the "before"
point in generating the diff or doing the merge.

Thanks,
   Aaron

On 6/21/06, Jeremy Whitlock <[EMAIL PROTECTED]> wrote:

Hernan,
Glad to hear you got it working.  As for the command-line way:

svn merge [EMAIL PROTECTED]
[EMAIL PROTECTED]
PATH_TO_WORKING_COPY_YOU_WISH_TO_MERGE_CHANGES_INTO

Sorry for the weird looking command but I tried to put some useful tidbits
into the command.  ;)

Take care,

Jeremy


On 6/21/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> Hi Jeremy,
> I was using a graphical tool to do the merge. The dry run would show all
the files that would be
> updated but when I ran it "for real" nothing really changed on my working,
local trunk, copy.
>
> I did an svn stat and saw no changes, did an svn up and it failed. Can't
remember exactly the error
> msg but was something about not a working directory or can not run from
the same directory.
>
> I ended up doing a new svn co from the trunk, updated the project files
and xdocs, rebuilding and
> committing. I couldn't find any other way to do it, then I updated the web
site from the trunk.
>
> What would the "svn command line" way be for merging the branch into the
trunk?
>
> Thanks
>
> Cheers!
> Hernan
>
> Jeremy Whitlock wrote:
> > Hernan,
> > Can you paste the command that you are trying to use?  Merging is
> > the proper approach for this type of thing.  With the merge command, you
> > can create a patch using the unified-diff output and piping it to a
> > file.  If I can see your command, I can hook you up.
> >
> > Take care,
> >
> > Jeremy
> >
> > On 6/20/06, *Hernan Cunico* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Merging isn't working, I don't see anything being updated into
trunk.
> > How do I create a patch if my local working copy is fully in sync
> > with the branch, not the trunk.
> >
> > Is there a way to copy/move the content of the branch and overwrite
> > the trunk?
> >
> > Thanks
> >
> > Hernan
> >
> > David Blevins wrote:
> >  > On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote:
> >  >
> >  >> Hi All,
> >  >> I'm a bit lost with the two branches we have now to manage the
web
> >  >> site.  I have the .../site/branches/may2006 branch updated
> > and  ready
> >  >> to go live, it already includes that last two changes  (updated
> > events
> >  >> and added book to documentation).
> >  >>
> >  >> What would be the next step? replacing the content of .../site/
> > trunk
> >  >> and then commit to the live site from the updated trunk? how  do
I
> >  >> replace it the content in .../site/trunk with the may2006
branch?
> >  >
> >  >
> >  > Typically, you'd merge over your changes.  Could use the 'svn
merge'
> >  > command.  Or you could create a patch file and apply it to trunk.
 I
> >  > like to use the graphical diff tool in Visual SlickEdit, but
> > that's  not
> >  > free.
> >  >
> >  > -David
> >  >
> >  >
> >
> >
>

Re: Web site update

[Jeremy Whitlock]

Hernan,    Glad to hear you got it working.  As for the command-line way:svn merge [EMAIL PROTECTED] [EMAIL PROTECTED] PATH_TO_WORKING_COPY_YOU_WISH_TO_MERGE_CHANGES_INTO
Sorry for the weird looking command but I tried to put some useful tidbits into the command.  ;)Take care,JeremyOn 6/21/06, Hernan Cunico
 <[EMAIL PROTECTED]> wrote:Hi Jeremy,
I was using a graphical tool to do the merge. The dry run would show all the files that would beupdated but when I ran it "for real" nothing really changed on my working, local trunk, copy.I did an svn stat and saw no changes, did an svn up and it failed. Can't remember exactly the error
msg but was something about not a working directory or can not run from the same directory.I ended up doing a new svn co from the trunk, updated the project files and xdocs, rebuilding andcommitting. I couldn't find any other way to do it, then I updated the web site from the trunk.
What would the "svn command line" way be for merging the branch into the trunk?ThanksCheers!HernanJeremy Whitlock wrote:> Hernan,> Can you paste the command that you are trying to use?  Merging is
> the proper approach for this type of thing.  With the merge command, you> can create a patch using the unified-diff output and piping it to a> file.  If I can see your command, I can hook you up.
>> Take care,>> Jeremy>> On 6/20/06, *Hernan Cunico* <[EMAIL PROTECTED]> [EMAIL PROTECTED]
>> wrote:>> Merging isn't working, I don't see anything being updated into trunk.> How do I create a patch if my local working copy is fully in sync> with the branch, not the trunk.
>> Is there a way to copy/move the content of the branch and overwrite> the trunk?>> Thanks>> Hernan>> David Blevins wrote:>  > On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote:
>  >>  >> Hi All,>  >> I'm a bit lost with the two branches we have now to manage the web>  >> site.  I have the .../site/branches/may2006 branch updated
> and  ready>  >> to go live, it already includes that last two changes  (updated> events>  >> and added book to documentation).>  >>>  >> What would be the next step? replacing the content of .../site/
> trunk>  >> and then commit to the live site from the updated trunk? how  do I>  >> replace it the content in .../site/trunk with the may2006 branch?>  >>  >
>  > Typically, you'd merge over your changes.  Could use the 'svn merge'>  > command.  Or you could create a patch file and apply it to trunk.  I>  > like to use the graphical diff tool in Visual SlickEdit, but
> that's  not>  > free.>  >>  > -David>  >>  >>>

Re: Web site update

[Hernan Cunico]

Hi Jeremy,
I was using a graphical tool to do the merge. The dry run would show all the files that would be 
updated but when I ran it "for real" nothing really changed on my working, local trunk, copy.


I did an svn stat and saw no changes, did an svn up and it failed. Can't remember exactly the error 
msg but was something about not a working directory or can not run from the same directory.


I ended up doing a new svn co from the trunk, updated the project files and xdocs, rebuilding and 
committing. I couldn't find any other way to do it, then I updated the web site from the trunk.


What would the "svn command line" way be for merging the branch into the trunk?

Thanks

Cheers!
Hernan

Jeremy Whitlock wrote:

Hernan,
Can you paste the command that you are trying to use?  Merging is 
the proper approach for this type of thing.  With the merge command, you 
can create a patch using the unified-diff output and piping it to a 
file.  If I can see your command, I can hook you up.


Take care,

Jeremy

On 6/20/06, *Hernan Cunico* <[EMAIL PROTECTED] 
> wrote:


Merging isn't working, I don't see anything being updated into trunk.
How do I create a patch if my local working copy is fully in sync
with the branch, not the trunk.

Is there a way to copy/move the content of the branch and overwrite
the trunk?

Thanks

Hernan

David Blevins wrote:
 > On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote:
 >
 >> Hi All,
 >> I'm a bit lost with the two branches we have now to manage the web
 >> site.  I have the .../site/branches/may2006 branch updated
and  ready
 >> to go live, it already includes that last two changes  (updated
events
 >> and added book to documentation).
 >>
 >> What would be the next step? replacing the content of .../site/
trunk
 >> and then commit to the live site from the updated trunk? how  do I
 >> replace it the content in .../site/trunk with the may2006 branch?
 >
 >
 > Typically, you'd merge over your changes.  Could use the 'svn merge'
 > command.  Or you could create a patch file and apply it to trunk.  I
 > like to use the graphical diff tool in Visual SlickEdit, but
that's  not
 > free.
 >
 > -David
 >
 >

Re: Web site update

[Jeremy Whitlock]

Hernan,    Can you paste the command that you are trying to use?  Merging is the proper approach for this type of thing.  With the merge command, you can create a patch using the unified-diff output and piping it to a file.  If I can see your command, I can hook you up.
Take care,JeremyOn 6/20/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
Merging isn't working, I don't see anything being updated into trunk.How do I create a patch if my local working copy is fully in sync with the branch, not the trunk.Is there a way to copy/move the content of the branch and overwrite the trunk?
ThanksHernanDavid Blevins wrote:> On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote:>>> Hi All,>> I'm a bit lost with the two branches we have now to manage the web
>> site.  I have the .../site/branches/may2006 branch updated and  ready>> to go live, it already includes that last two changes  (updated events>> and added book to documentation).>>
>> What would be the next step? replacing the content of .../site/ trunk>> and then commit to the live site from the updated trunk? how  do I>> replace it the content in .../site/trunk with the may2006 branch?
>>> Typically, you'd merge over your changes.  Could use the 'svn merge'> command.  Or you could create a patch file and apply it to trunk.  I> like to use the graphical diff tool in Visual SlickEdit, but that's  not
> free.>> -David>>

Re: Web site update

[Hernan Cunico]

Merging isn't working, I don't see anything being updated into trunk.
How do I create a patch if my local working copy is fully in sync with the 
branch, not the trunk.

Is there a way to copy/move the content of the branch and overwrite the trunk?

Thanks

Hernan

David Blevins wrote:

On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote:


Hi All,
I'm a bit lost with the two branches we have now to manage the web  
site.  I have the .../site/branches/may2006 branch updated and  ready 
to go live, it already includes that last two changes  (updated events 
and added book to documentation).


What would be the next step? replacing the content of .../site/ trunk 
and then commit to the live site from the updated trunk? how  do I 
replace it the content in .../site/trunk with the may2006 branch?



Typically, you'd merge over your changes.  Could use the 'svn merge'  
command.  Or you could create a patch file and apply it to trunk.  I  
like to use the graphical diff tool in Visual SlickEdit, but that's  not 
free.


-David

Re: Web site update

[David Blevins]

On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote:


Hi All,
I'm a bit lost with the two branches we have now to manage the web  
site.  I have the .../site/branches/may2006 branch updated and  
ready to go live, it already includes that last two changes  
(updated events and added book to documentation).


What would be the next step? replacing the content of .../site/ 
trunk and then commit to the live site from the updated trunk? how  
do I replace it the content in .../site/trunk with the may2006 branch?


Typically, you'd merge over your changes.  Could use the 'svn merge'  
command.  Or you could create a patch file and apply it to trunk.  I  
like to use the graphical diff tool in Visual SlickEdit, but that's  
not free.


-David

Re: Web Site Update Please

[Aaron Mulder]

Ah, thanks!  I had missed that.

Aaron

On 1/8/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On 1/8/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>
> > There are some instructions in the site directory to do the update.  I 
> > think the
> > file is called UPDATE.txt or something like that.
>
> It's actually NOTES.txt and it's here:
>
> https://svn.apache.org/repos/asf/geronimo/site/NOTES.txt
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)[EMAIL 
> PROTECTED]&5R\"F)R=6-E+G-N>61E );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
>

Re: Web Site Update Please

[Bruce Snyder]

On 1/8/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

> There are some instructions in the site directory to do the update.  I think 
> the
> file is called UPDATE.txt or something like that.

It's actually NOTES.txt and it's here:

https://svn.apache.org/repos/asf/geronimo/site/NOTES.txt

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Castor (http://castor.org/)

Re: Web Site Update Please

[Matt Hogstrom]

Aaron,

There are some instructions in the site directory to do the update.  I think the 
file is called UPDATE.txt or something like that.


Aaron Mulder wrote:

I checked in a page that lists and links to all the schemas used by
Geronimo 1.0.  I was going to leave this for later, but I keep having
to look up the stupid namespace URIs, so now there's a nice place to
look (the "XML Schemas" link on the left sidebar, and /schemas.html).

Could someone update the live web site from SVN?

Thanks,
Aaron

Re: Web Site Update Please

[Bruce Snyder]

On 1/7/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> I checked in a page that lists and links to all the schemas used by
> Geronimo 1.0.  I was going to leave this for later, but I keep having
> to look up the stupid namespace URIs, so now there's a nice place to
> look (the "XML Schemas" link on the left sidebar, and /schemas.html).
>
> Could someone update the live web site from SVN?

Done.

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Castor (http://castor.org/)

Re: Web Site update please

[Sachin Patel]

done
- sachin



On Jan 6, 2006, at 9:53 AM, Aaron Mulder wrote:


Could someone please update the web site?  I just checked in a few
changes.  I'm not sure what the procedure is to update the real site
with the updated SVN content.

Also, the links to the signature files for the 1.0 source code
downloads are broken.  I'm not sure if the links are pointing to the
wrong place or the files just haven't been uploaded.

Thanks,
Aaron