On 18/02/15 13:07, John Chambers wrote:
Hmm not sure what has happened to the start page. I will take a look later
when I get home.
I am still a little unclear on the redirects we need. I assumed that we
would want all existing links to either the wiki or tickets etc to work
without major changes. So I would think any access to
https://issues.apache.org/bloodhound would resolve to the corresponding new
page.
Cheers
John
On 18 Feb 2015 12:19, "Gary Martin" <[email protected]> wrote:
On 18/02/15 02:01, John Chambers wrote:
I have setup the new Bloodhound environment on the i.a.o vm. But like I
thought it is not accessable from the outside world.
I will look at doing what Brane suggests and use apache rewrite rules and
virtual host configurations to test the new setup before I migrate the old
environment and data across.
I am also going to look at providing a holding page so that I can bring
the
service down for maintenance in the future.
I will keep you informed.
Cheers
John
On 18 February 2015 at 01:04, Branko Čibej <[email protected]> wrote:
On 17.02.2015 20:22, Gary Martin wrote:
On 17/02/15 14:28, John Chambers wrote:
Incidentally, I think I specified the wrong redirect in my last
message as we use products rather than product so that redirect should
be:
https://issues.apache.org/bloodhound =>
https://issues.apache.org/bhound/products/BLOODHOUND
We can make the right redirects work without Infra involvement and
without changing the root URL https://issues.apache.org/bloodhound so
something horrible like .../bhound.
All it takes is to have a careful look at the current set of URLs used
for BH stuff and then writing a number of rewrite rules that will catch
only those URLs, but not any new .../bloodhound/pmeantroduct URLs. If that
means we invent a virtual location, e.g., .../bloodhound/main to refer
to the global environment, that's fine, IMO. Better than the current
proposal in any case.
-- Brane
I can understand the dislike of the suggested url. My suggestion came from
an attempt to keep things relatively simple, albeit with INFRA involvement.
It would also minimise the slightly strange situation of one product
appearing to have some sort of special status.
I take it that Brane is not suggesting that we redirect like this:
/bloodhound/(?!main).* to /bloodhound/main/products/BLOODHOUND
It looks to me like a bit of work has been in progress. For some reason we
have a "Welcome to Trac 0.13dev" as our front page at the moment. Not so
great for us!
Cheers,
Gary
John,
OK, going through the basic options:
A) If we are living with /bloodhound as the baseurl without making
/bloodhound/main the global location, I think that this is the basic set
of stuff that probably requires redirecting:
/bloodhound/ticket(.*) -> /bloodhound/products/BLOODHOUND/ticket$1
/bloodhound/milestone(.*) -> /bloodhound/products/BLOODHOUND/milestone$1
/bloodhound/wiki/Bloodhound(.*) ->
/bloodhound/products/BLOODHOUND/wiki/Bloodhound$1
/bloodhound/wiki/Proposals(.*) ->
/bloodhound/products/BLOODHOUND/wiki/Proposals$1
/bloodhound/wiki/Ui(.*) -> /bloodhound/products/BLOODHOUND/wiki/Ui$1
With this scheme we should probably accept that
/bloodhound/wiki/WikiStart and all the equivalents should be left as the
global wiki front page. The same would go for the dashboard.
There are also timeline, roadmap, browser, report and query links that
we could consider but I could see us ignoring those. Perhaps queries
would be the most annoying links to lose of those.
B) Moving the baseurl at all should simplify things and should only
require one redirection rule. Moved down the path, a baseurl of
/bloodhound/main would only require something that avoided an infinite
redirection. So something like:
/bloodhound/(?!main)(.*) to /bloodhound/main/products/BLOODHOUND/%1
might be close to working. Anything other than /bloodhound in the base
would be a little simpler but not hugely; instead it would have the
apparent downside of disturbing INFRA.
Brane might have been pointing to another solution earlier. To be
honest, I don't mind too much what approach we take as long as the
implications are understood and the majority seem happy enough with the
choice.
Cheers,
Gary
