Issue 1015

As this relates to the top level website, 
reassigning to louis 
for ownership 
(to coordinate technical support as required toward resolution). 

Please Accept Issue 
and follow-up as required. 

accepted; will coordinate with project owner to resolve issue.

Please advise us of the specific URL to which you are referring, 
as I do not know what software development kit 1.0 you are trying to download. 

As this relates to the top level website, 
reassigning to louis 
for ownership 
(to coordinate technical support as required toward resolution). 

Please Accept Issue 
and follow-up as required. 

btw, this issue has been already worked on,and is but another artifact of 

the vhosting issue (930). The urls in question: 

http://www.openoffice.org/project/api/downloads.html vs. 

http://api.openoffice.org/5.2/downloads.html. The latter works fine. A 

possible solution suggested on Friday evening was that we might also 

just route the former to the latter; but this is an inadequate solution. I'll 

raise it with Jeff Love and apps to see what the situation is with this and 

with 930.

-louis

Understood. 

BTW ... 
I regret my previous duplicate commit. 

I'm downgrading this to a P2, which is still pretty urgent. I was unable to resolve it 
today due to a lengthy meeting, but will meet with ops and others tomorrow. Possibly, 
this issue will be resolved with scast implementation, but would rather eliminate it 
before then. 
-louis

Kat:
Essentially, there seems to be an issue with vhosting. In some situations, 
the correct page is served up when, for instance, 
http://www.openoffice.org/project/page.html is used; but in other cases, 
we have to use http://project.openoffice.org/page.html to get results. I'm 
tasked with resolving this, and wonder if you can help out. 

When will this be fixed?

Short answer to BR's question: 6/15. My understanding is that this bug will 
disappear with the advent of SourceCast, which as a different architecture. 
Until then, we can urge people to use the URL that does work, unless a 
simple fix is easily available, such as correcting a broken link. We could 
ask the project owner toswitch from relative to absolute urls. I will find out 
by Friday 6/15 what the def. situation/solution is.

Jeff
can we strike this for now? say, put a "remind" on it? My undertstanding is 
that SC eliminates these issues with vhosting.
-louis

Our understanding is that with SC this problem vanishes. for that reason, I am resolving the issue to "later." If it crops up again, we'll reopen.
louis

Solved with SC?

eventually, it will be fixed; but for now, it seems that the api project at least 
has lots of other issues with download links. this requires CollabNet qa 
attention.
louis

new problems crept in while resolving this. To resolove it--once and for 
all--I've filed Collabnet internal issues and assigned them to qa to check 
the links on this and other pages. With SC, tho, this should not occur. 
Areas that need addressing: conformity of relative link writing. Submitted 
the style guide to Jeff Love for final review (it's been reviewed by others) 
and will send it to project leads.
-louis

I was unsure exactly *which* kit was to be downloaded, so spent an enjoyable few 
minutes downloading a slew of them, all successfully. this issue and its brethren 
should be closed.
If this sort crops up again, it's a link problem, as far as I know. that said, one of the 
reasons this works now is because "http://www.openoffice.org/project/api/
downloads.html" is no longer a vaild link. All projects must be entered as 
"projectname.openoffice.org/" I  believe.
louis

As agreed with Louis, we can close all the resolved fixed issues he owns.

As agreed with Louis, we can close all the resolved fixed issues he owns.