bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: Dogfooding multi product on i.a.o/bloodhound
Date Wed, 18 Feb 2015 15:16:34 GMT
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
> would resolve to the corresponding new
> page.
> Cheers
> John
>   On 18 Feb 2015 12:19, "Gary Martin" <> 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 <> 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:
>>>>> =>
>>>> We can make the right redirects work without Infra involvement and
>>>> without changing the root URL 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


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/wiki/Proposals(.*) -> 
/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 


View raw message