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 Tue, 17 Feb 2015 14:28:59 GMT
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 <gary.martin@wandisco.com> wrote:

> On 17 February 2015 at 00:18, Olemis Lang <olemis@gmail.com> wrote:
>
> > On 2/16/15, Ryan J Ollos <rjollos@apache.org> wrote:
> > > 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
> >
> > (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
>

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