Ok I think we have a plan. Now I just need to figure out how to implement it ;)
The only thing is I think I am going to have to involve INFRA because I think the only way into our VM is via https://issues.apache.org/bloodhound and I don't think making any config changes to the Apache2 config on the vm will allow external access via another url i.e https://issues.apache.org/bhound. I am going to try and test this by installing a new instance of bloodhound 0.8.0 on the VM and try and access it via the above url. If this is not possible I will raise this with INFRA. They may also be the ones who can setup the redirect from https://issues.apache.org/bloodhound to https://issues.apache.org/bhound/product/BLOODHOUND I will keep you informed. Cheers John On 17 February 2015 at 01:15, Gary Martin <[email protected]> wrote: > On 17 February 2015 at 00:18, Olemis Lang <[email protected]> wrote: > > > On 2/16/15, Ryan J Ollos <[email protected]> wrote: > > > On Mon, Feb 16, 2015 at 10:55 AM, John Chambers <[email protected]> > > 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 > > > > (IMHO) Important resources belonging in global environment : > > > > 1. Repository(ies) > > 2. Wiki pages with guidelines explaining > > * default BH user guide pages > > (i.e. exclude WikiStart , BloodhoundInstall , ...) > > * how to use this i.a.o/bh instance > > * it's relation with other ASF services > > * procedures like *how to setup new BH products* > > * everything about this particular BH instance ... > > 3. A completely new WikiStart > > 4. Global admin panels > > - What to do with plugin install form ? > > > > >> and potentially only tickets about the infrastructure of this > > >> instance of bloodhound (though these could be in a new product as > well). > > >> > > > > should be a separate product , let's say INFRA , BH-SITE ... add your > own > > ;) > > > > >> 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. > > > > +1 > > > > > The WikiStart page in the global wiki could contain some > > > new content, > > > > +1 ... IMO it should be something like https://issues.apache.org/ and > > may be improved with time . Alternately it may look like a dashboard , > > which is what seems to happen in https://issues.apache.org/jira , so > > we could define the global default handler to be the DashboardModule . > > > > > 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 ... > > > > > > > There is a page for that i.e. /products in global environment . > > > > > 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) > > > > Considering BH default URL mapping this should be > > https://issues.apache.org/bloodhound/products/bh > > > > > and have URLs with the base https://issues.apache.org/bloodhound > > rewritten > > > to https://issues.apache.org/bloodhound/bh > > > > > > > HTTP 301 ? I'd rather prefer doing so . In fact > > https://issues.apache.org/jira/ => > > https://issues.apache.org/jira/secure/Dashboard.jspa . Nevertheless > > since there will be still a global env , which URLs should redirect > > user and which ones should not ? > > > > > 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. > > > > > > > +1 > > > > [...] > > > > -- > > Regards, > > > > Olemis - @olemis > > > > > I think we are getting close to the right approach here. > > Yes, it will be good to assume that infrastructure will eventually take > over the global environment. The content until such time as they do take > over could be limited to help pages. We may want to second guess some of > what infra would like in that wiki but we shouldn't go too far without > advice. A simple page listing of the other issue tracker resources and > maybe the contained products might well be enough for the WikiStart. > > I am very happy with the idea of adding a second product alongside our own > that we take on for the purpose of site maintenance. This may be a more > appropriate place to document site setup. I would probably avoid naming it > INFRA as I would like to avoid people mistaking it for the real infra site. > > Ryan pointing out the project keys from the apache jira instance reminded > me that I currently think that long product prefixes may make a bit more > sense in a public facing website. This should avoid inexplicable acronyms > for baffling the uninitiated. This has to be contrasted with the extra > hassle at typing longer names but I suspect it might be worth it. > > The leaves redirection and our base url. Unless we want to list all the > pages we care to redirect (this may be hyperbole.. I may not have > considered this enough) then it seems that we are destined for a change in > the base url. It would be nice if we didn't have to reason through too many > special cases. For the sake of an initial idea, I'm suggesting the > following: > > https://issues.apache.org/bhound > https://issues.apache.org/bhound/product/BLOODHOUND > https://issues.apache.org/bhound/product/BHOUND-INFRA > > The permanent redirects can then for the most part be a simple replacement > of the old base url for the new product: > > https://issues.apache.org/bloodhound => > https://issues.apache.org/bhound/product/BLOODHOUND > > There could be a few special cases that we may care about that are ignored > of course. > > Cheers, > Gary >
