bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Chambers <cham...@apache.org>
Subject Re: Dogfooding multi product on i.a.o/bloodhound
Date Mon, 16 Feb 2015 18:55:02 GMT
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.

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.

Cheers

John


On 16 February 2015 at 16:37, Branko ─îibej <brane@wandisco.com> wrote:

> On 16.02.2015 16:25, Olemis Lang wrote:
> > Hi John !
> > :)
> >
> > On 2/16/15, John Chambers <chambej@apache.org> wrote:
> >> I have spent more time on this over the weekend and I now have a copy of
> >> the live site on my local VM.
> > [...]
> >
> > \o/
> >
> >> I already had bloodhound v0.8
> >> installed so it was just a case of replacing the
> >> bloodhound/environments/main with the archived one and restoring the
> >> database. I had to make changes to the base and trac ini files because
> of
> >> path changes and I then had to do a trac-admin upgrade to get the
> database
> >> to the required version.
> >>
> > Database upgrade should not be quite problematic considering that
> > multi-product plugin's columns have not changed since some time and
> > 4.0 includes MP DB structure but not the other aspects , mainly the
> > isolated product envionments developed for BH>=0.6 . Something worth
> > considering is the state of other plugins e.g. relations . Is it
> > enabled and working ?
> >
> >> Now the main problem I have is that the process has created a new @
> >> prefixed default product under which all the old tickets and wiki pages
> can
> >> be found.
> > Would you mind if default product prefix is set to something different
> > , let's say BH ?
> >
> >> However I do not have a WikiStart page defined.
> > I guess you mean in the global environment i.e. at base URL .
> >
> >> So my question is
> >> what should I do?
> > It is possible to create the wiki page and that's it but ...
> >
> >> Bare in mind that I will most likely be doing something
> >> similar with the live i.a.o Bloodhound instance at some point.
> >>
> > ... the question is what's going to happen with all the URLs (e.g. in
> > messages instructions , archive , ...) pointing at i.a.o/bh/... now
> > available at i.a.o/products/PREFIX/... (PREFIX=@ or PREFIX=BH or ...)
> >
> >> 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. They
> should be in the BH/bloodhound product. 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.
>
> 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. Most ASF projects currently use Jira, but some use
> Bugzilla and at least one uses the tracker at tigris.org. If we make
> transition to Bloodhound moderately easy, they may switch (and we may
> convince Infra to provide a more powerful VM for the BH host).
>
> -- Brane
>
>

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