bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan J Ollos <rjol...@apache.org>
Subject Re: Product / Version strategies
Date Wed, 26 Aug 2015 20:11:08 GMT
On Wed, Aug 26, 2015 at 4:18 AM, Oscar Edvardsson <oscar@monivent.se> wrote:

> Hi all,
>
> I am about to set up a new Bloodhound server. I have a structure issue
> though.
> We aim at using the wiki and ticket system to manage three different parts
> of our system. Each part may involve software/firmware, hardware and/or
> mechanics, and each of these have different versions. It may look like
> below.
> I am aware that Bloodhound is primarily intended for software development,
> but I think it would fit our issue management neatly.
>
>  System A
>      +------ Part A
>      |         +------ Software
>      |         |          +-------- Version 1
>      |         |          +-------- Version 2
>      |         +------ Hardware
>      |         |          +-------- Version 1
>      |         +------ Mechanical
>      |                    +-------- Version 2
>      +------ Part B
>                +------ Software
>      .                     +------- Version 1
>      .
>      .
>
>
> My initial, and most intuitive, way of structuring this was to have one
> product for each part. Each part/product would then have the components
> Software, Hardware and Mechanics.
> The issue arrived when I realised the version numbering for the components
> does not match. I.e. Software Version 2 may run on Hardware Version 1. One
> workaround would have to list all versions, but then Version 2 for Software
> does not correspond to Version 2 for Hardware. This means that, e.g.
> version description is not really applicable, as a version is actually two
> (or three) different versions. This also matches our directory structure
> most closely.
>
> The next idea was to separate Software, Hardware and Mechanics into
> different products, but I find this less intuitive and there will be an
> even greater issue with versions existing in one of the parts, but not the
> others (i.e. Part A, Version 2 vs. Part B, Version 1.5).
>
> Third idea was to separate the parts into different projects, but then the
> parts are not “grouped”, so if we add a new system there is no way of
> telling which projects belong to which system.
>
> Are there any good approach to fulfil the following:
>  - Separate the three parts
>  - Separate the three different disciplines (Software, Hardware, Mechanics)
>  - Versions are tied to the discipline
>

You could have 3 fields, one for each component version, and show/hide them
based on the Component selection. Or you could hide dynamically modify the
Version field based on the Component selection. Either way, you'd have to
write some JavaScript.

You can look at these Trac plugins for inspiration, though they are
unlikely to work with Bloodhound without modification:
https://trac-hacks.org/wiki/DynamicFieldsPlugin
https://trac-hacks.org/wiki/TracTicketChainedFieldsPlugin



> Very off-topic: Maybe Order deny,allow Allow from all in the Bloodhound
> installation instructions should be changed to Require all granted? I had
> to do that to get the setup to work, thought I’d let you know anyway.
>

The Bloodhound installation instructions are written for Apache 2.2 and
need to be updated for Apache 2.4, for which "Require all granted" is
typically used.

- Ryan

Mime
View raw message