bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: Multi product enhancements
Date Wed, 07 Nov 2012 20:58:15 GMT
On 7 November 2012 09:29, Branko ─îibej <> wrote:

> On 07.11.2012 08:42, Jure Zitnik wrote:
> > Hi all,
> >
> > I was looking into enhancing multi product support within Bloodhound.
> > afaik current multi product support consists of the ability to
> > define/administer product(s) and the ability to assign product to a
> > ticket. What I was thinking of starting with are the following rather
> > simple features/functionalities:
> >
> > 1. product/ticket namespaces - product and ticket ID would form a two
> > dimensional namespace, tickets would in addition to current URL scheme
> > also be addressable through the product URL namespace, namely
> > /ticket/<product>/<id>. Each product would have a separate numberspace
> > for product ticket IDs. The same might also be applied for wikis, not
> > sure about whether it's something that would come handy or not.
> >
> > 2. tickets should be moveable between products, old ticket product IDs
> > (and URLs) should be remembered, making the same ticket accessible
> > through old products namespaces.
> >
> > 3. enhance query to limit the search to specific product
> >
> > Down the line it'd be really useful to have per product permissions,
> > versions, milestones, components, ticket lifecycles, predefined
> > queries, etc., which is a bit more complex part that should be
> > discussed in a separate thread.
> >
> > Any comments/suggestions on this?

I think that this is broadly in line with what we want. I may comment more
in the future on this. But for now, I will just say that I see no reason
why the wiki should be restricted from being contained within a product.

> Gary and I talked about this the a couple days ago at ApacheCon;
> specifically, about whether the product tag (as opposed to the product
> name) should be immutable or not.
> The assumption is that a "product" has two attributes:
>     name: used for user-friendly display
>     tag: shorter string, constrained syntax, unique
> So, you could have a product named "Finnegan's Wake" with tag FW, and
> ticket IDs within that product would have the format FW-123. Later on
> you realize that your product is about the book, not the ballad, and you
> rename it to "Finnegans Wake".
> The some twit comes along and wants to change the tag to FWJOYCE. There
> are conceptually two ways to do that:
>   * Keep tags immutable, "rename" it by creating a new product, move all
>     tickets to it and delete the new product.
>   * Actually allow renaming the tag; a tag rename would still have to
>     maintain the ticket ID history.
> We came to the conclusion that it's best to keep tags immutable.
> Eventually one could add a tag-rename helper to the UI that would do the
> new-product/move-tickets/delete-old-product dance.

I'm not sure whether we had subtly different points of view here. On this
point I was basically thinking that we should avoid making it easy by
default for now, in order to discourage renaming. As Brane suggests, it can
be considered a silly thing to want to do. Although a prefix will probably
initially be chosen as a shortening of the project name, there is no
specific need for this to be the case. Current users of the system will be
used to the original prefix and new users shouldn't find it a particular

All this should be interpreted as me suggesting that, unless there are
compelling reasons to expose a method to help with the new-move-delete
product process to users, it would be better to wait for the demand.

> Another question that popped up was how to maintain eternal historical
> uniqueness of ticket IDs when a tag for a previously deleted product
> gets reused. One option is to never allow reusing historically used tags
> in new products, but that seems a bit too restrictive. We came up with
> this:
>   * along with the tag+number history for each ticket, remember the
>     maximum ticket number per tag
>   * when a tag gets reused, issue new ticket numbers from that
>     remembered value, not from 1
>   * this includes renumbering tickets that already have an ID with the
>     reused tag, because it's never clear that the resurrected tag is
>     used for the same product as before.
>       o this might imply remembering the product name associated with a
>         range of ticket numbers within a tag

Yes, I almost forgot about that part of the conversation. I don't have a
particular problem with disallowing use of old product prefixes actually.
Given that we will be maintaining old links, it would be a bit strange when
the meaning of the namespace changes at a given number. The best excuse for
allowing use is actually that the project returns to its original prefix -
however confusing that is.

There is, of course, another way to look at this. Sorry if anyone else has
already pointed this out but we could just maintain the old prefixes as
synonyms for the current product prefix. The main problem with this would
be that it could encourage people to continue using an old prefix whilst
some colleagues use the new one and potentially could cause more confusion.

Anyway, the discontinuity in numbering is not completely anathema to me but
losing the ability to use a specific prefix is not really the biggest of


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