bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <>
Subject Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Fri, 22 Feb 2013 12:06:07 GMT
You could argue that if you have global wikis, you may want global tickets
to allow for "Update global documentation"-type tickets.

I'm skeptical about both global tickets and global wikis from a UX
perspective as they represent a 'miscellaneous' category, which we should
discourage because they often end up like the attics that no one ever cares
to clean out.

- Joe

On 22 February 2013 10:41, Jure Zitnik <> wrote:

> On 2/22/13 3:03 AM, Branko ─îibej wrote:
>> On 21.02.2013 18:05, Olemis Lang wrote:
>>> On 2/21/13, Jure Zitnik <> wrote:
>>>> On 2/20/13 5:21 PM, Olemis Lang wrote:
>>>>> On 2/20/13, Andrej Golcov <> wrote:
>>>> [...]
>>>> My suggestion is to keep things simple here: if there is already
>>>>>> product named "Default', let's assign global tickets to this product.
>>>>>> There should be reason why this product was called "Default" :)
>>>>>>  -1 ... IMO we the prefix for the global environment should be an
>>>>> empty
>>>>> string (i.e. '') or NULL (/me slightly in favor of the former) . That
>>>>> will allow us to reserve special behavior for that prefix value (if
>>>>> needed) and will not clash with any other valid product prefix since
>>>>> it's a required field in create product web form (... admin command ,
>>>>> ...)
>>>>>  Just to clarify, the prefix of the 'global environment' is an empty
>>>> string (''). This will, at the moment, only be used for permissions.
>>>>  Yes , understood .
>>> ;)
>>>  The 'default' prefix (or 'def') is used for a product to which all the
>>>> tickets that don't have product assigned are migrated to (during the
>>>> database upgrade process). The product itself is automatically added
>>>> during the upgrade/migration process.
>>>>  That's kind of what I was meaning in my reply .
>>>    1. Consider ticket without product before migration to be
>>>        tickets filed against the global environment .
>>>    2. Use gobal env just like any other product env with
>>>        prefix = '' , not just permissions
>>>    3. No need to create 'default' product while on upgrade
>>> PS: In the migration process we should also replicate (i.e. in DB) or
>>> inherit product configs from a single file . I advocate for the later
>>> .
>> I have to say that for once I completely agree with Olemis. NULL table
>> column, and empty UI prefix equals "it all looks exactly like it used to
>> before the migration" and it also can't collide with any existing
>> product names or prefixes.
>> Furthermore, doing it this way, if a user installs Bloodhound but
>> doesn't want to bother with product namespaces, everything will Just Work.
>>  I agree with the 'Just Work' part, I don't agree with tickets in global
> scope.
> My understanding was, based on the mailing list discussions, that we don't
> want tickets in global scope. That is why current implementation creates
> the 'default' product and migrates the tickets. I think that the 'Just
> Work' part is more of the UI/UX issue. I think that each ticket should be
> linked to a product, it's up to the UI to make it easy for the user to use
> environments with only one product (default one). I find tickets in global
> scope confusing as it's not exactly clear what they relate to.
> I would advocate global wikis for example, as it makes more sense.
> Cheers,
> Jure

Joe Dreimann
UX Designer | WANdisco <>
*Transform your software development department. Register for a free SVN
HealthCheck <> *

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