bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan J Ollos <rjol...@apache.org>
Subject Re: Dogfooding multi product on i.a.o/bloodhound
Date Mon, 16 Feb 2015 21:50:47 GMT
On Mon, Feb 16, 2015 at 10:55 AM, John Chambers <chambej@apache.org> wrote:

> Brane,
>
> I do like this idea. The way I would see it setup would be that the only
> things in the global environment / base url would be the bloodhound / trac
> wiki pages and potentially only tickets about the infrastructure of this
> instance of bloodhound (though these could be in a new product as well).
>
> We could then have a BH_ISSUES product which would contain all the old
> tickets and attachments.
>

Extrapolating on what Brane said, it seems like everything in the current
Bloodhound instance should go in the BH product, including future tickets
and wiki pages. The WikiStart page in the global wiki could contain some
new content, and ultimately be a placeholder for future use when there are
multiple projects hosted in Bloodhound and we need a global wiki to orient
users to all the projects, provide instruction on how to create new
projects, etc ...

Looking at the ASF Jira instance, the projects have URLs such as:
https://issues.apache.org/jira/browse/FLUME

So I think what we are talking about here is to have the new Bloodhound
project be located at:
https://issues.apache.org/bloodhound/bh (or
https://issues.apache.org/bloodhound/project/bh)
and have URLs with the base https://issues.apache.org/bloodhound rewritten
to https://issues.apache.org/bloodhound/bh

Having a separate project for Bloodhound infrastructure could be useful,
e.g. BH_INFRA. There are probably a half dozen to a dozen open
infrastructure-related tickets that could be copied to the new BH_INFRA
instance.



> But like I said previously I am not an expert in Trac/Bloodhound or Apache
> HTTP. So any help or pointers to documentation would be very gratefully
> received.
>

I'm no expert either, so there could be significant oversights in the"plan"
I've described.

- Ryan

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message