bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: Dogfooding multi product on i.a.o/bloodhound
Date Tue, 17 Feb 2015 01:15:17 GMT
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