bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Dogfooding multi product on i.a.o/bloodhound
Date Mon, 16 Feb 2015 23:45:08 GMT
On 2/16/15, Branko Čibej <> wrote:
> On 16.02.2015 16:25, Olemis Lang wrote:
>>> The options I can think of are:
>>> 1. Change the setup so that we are using the default product to serve
>>> all
>>> the pages.
>>> 2. Create a new StartWiki page to allow the users to select the product
>>> they want to work with.
>> Considering the answers to questions above I might have another
>> proposal ... which is basically to continue hosting the default
>> product at i.a.o/bh other potential new products at
>> i.a.o/bh/products/PREFIX and global admin at some other
>> non-conflicting URL e.g. i.a.o/bh/global (<= but may a different
>> naming convention be chosen as well)
> I'd really hate having BH tickets etc. in the default product.

JFTR , the default product is just like any other regular product .
Indeed you can run a BH instance and never care about default product
at all .

OTOH by reviewing the code I found this .


    default_product_prefix = Option(
        doc="""Prefix used for default product when migrating single-product
        installations to multi-product.""", doc_domain='multiproduct')


@John , this makes me think that legacy resources should be imported
into BH product if the following option is set in trac.ini prior to DB
upgrade .


default_product_prefix = BH


N.B There is a similar option [ticket] default_product , but it is not
related to the install procedure . Besides I think I should clarify
that the *global* environment is indeed different to any other product
e.g. it supports plugin install , global site admin ...

> They
> should be in the BH/bloodhound product.

I agree . In my previous message I was only talking about
"URL-to-environment mapping" .

> To maintain URL compatibility,
> we can design rewrite rules for the Apache config that make all
> product-scoped tickets, pages, etc. visible at their old locations.

HTTP 301 , isn't it ?

> The reason why it makes sense to scope all BH stuff into its own product
> is that it will then be easier for other projects to adopt BH as their
> issue tracker.


p.s. Now that I take a look it seems that BH=0.4 does not have some MP
changes in product tables at all . I was wrong in my previous message
, sorry .


Olemis - @olemislc

Apache™ Bloodhound contributor

Blog ES:
Blog EN:

Featured article:

View raw message