You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@bloodhound.apache.org by Oscar Edvardsson <os...@monivent.se> on 2015/08/26 13:18:03 UTC
Product / Version strategies
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
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.
Thanks in advance,
Re: Product / Version strategies
Posted by Ryan J Ollos <rj...@apache.org>.
On Wed, Aug 26, 2015 at 4:18 AM, Oscar Edvardsson <os...@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
Re: Product / Version strategies
Posted by Oscar Edvardsson <os...@monivent.se>.
Thank you both for yor kind answers!
I would like to tinker as little as possible to avoid disaster (often happens when I tinker) and help maintenance.
I can now really appreciate the idea of separating by discipline. I will definetly have to think about that.
Off-topic: I never saw what Apache version it was for, I just assumed it was the latest and greatest. :) My bad.
> 26 aug 2015 kl. 23:10 skrev Olemis Lang <ol...@gmail.com>:
>
>> On 8/26/15, Oscar Edvardsson <os...@monivent.se> wrote:
>> Hi all,
>
> Hi !
> :)
>
>> 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.
>
> In my experience sometimes the best way to structure issue tracking is
> by discipline , instead of system's organisation . In a real world
> similarly complex deployment what I did was the following :
>
> Two BH instances , one for each intl branch .
>
> Six domains (mapped 2 to 4 onto BH instances) for each discipline
> (mechatronic , soft eng , automatic control , 3D design ,
> manufacturing , sales/customer support/strategy) . Products names in
> those instances were mapped onto domains by prefix e.g. mech_sensor1
> => mech_sensor1.mech.domain.tld , swe_app1 => swe_app1.swe.domain.tld
> , ...
>
> The separation of domains helped us to deal with authentication ,
> cookies , and alike ... In each case , components + milestones +
> versions .
>
> HTH
>
> [...]
>
> --
> Regards,
>
> Olemis - @olemislc
>
> Apache™ Bloodhound contributor
> http://issues.apache.org/bloodhound
> http://blood-hound.net
>
> Brython committer
> http://brython.info
> http://github.com/brython-dev/brython
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
Re: Product / Version strategies
Posted by Olemis Lang <ol...@gmail.com>.
On 8/26/15, Oscar Edvardsson <os...@monivent.se> wrote:
> Hi all,
>
Hi !
:)
> 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.
In my experience sometimes the best way to structure issue tracking is
by discipline , instead of system's organisation . In a real world
similarly complex deployment what I did was the following :
Two BH instances , one for each intl branch .
Six domains (mapped 2 to 4 onto BH instances) for each discipline
(mechatronic , soft eng , automatic control , 3D design ,
manufacturing , sales/customer support/strategy) . Products names in
those instances were mapped onto domains by prefix e.g. mech_sensor1
=> mech_sensor1.mech.domain.tld , swe_app1 => swe_app1.swe.domain.tld
, ...
The separation of domains helped us to deal with authentication ,
cookies , and alike ... In each case , components + milestones +
versions .
HTH
[...]
--
Regards,
Olemis - @olemislc
Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net
Brython committer
http://brython.info
http://github.com/brython-dev/brython
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article: