bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
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 <brane@wandisco.com> 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 .

{{{#!py

    default_product_prefix = Option(
        'multiproduct',
        'default_product_prefix',
        default='@',
        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 .

{{{#!ini

[multiproduct]
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.

+1

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 .

-- 
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Mime
View raw message