bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Date Thu, 18 Oct 2012 12:56:53 GMT
On 18/10/12 13:00, Peter Koželj wrote:
> On Thu, Oct 18, 2012 at 10:00 AM, Gary Martin <>wrote:
>> "Peter Koželj" <> wrote:
>>> On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <> wrote:
>>>> On 10/17/12, Gary Martin <> wrote:
>>>>> On 17/10/12 17:15, Joe Dreimann wrote:
>>>>>> On 17 Oct 2012, at 17:00, Peter Koželj <>
>>>>>>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
>>>>>>> <>wrote:
>>>>>>>> On 17/10/12 12:03, Ryan Ollos wrote:
>>>>>>>> It gets interesting where really you want to raise a bug
>>>>>>>> multiple
>>>>>>>> versions but it is not the end of the world. The main thing
>>> that
>>>>>>>> there
>>>>>>>> is a prompt for a primary version to raise against - further
>>> versions
>>>>>>>> would
>>>>>>>> probably be expected to be noted in the description and those
>>> dealing
>>>>>>>> with
>>>>>>>> the ticket could then determine whether further tickets are
>>> needed.
>>>>>>> I was just thinking about the multiple versions per ticket (bug)
>>>>>>> support.
>>>>>>> This needs to be formal and not just a in-comment or
>>> in-description
>>>> text.
>>>>>>> I
>>>>>>> have some ideas how we could go about this but it is off topic
>>> for this
>>>>>>> ticket. I'll start a separate discussion on the subject at some
>>> point
>>>> in
>>>>>>> the fure (opening multiple unrelated tickets should be good
>>> enough at
>>>>>>> the
>>>>>>> moment).
>>>>>> The most obvious answer or me would be to allow to select multiple
>>>>>> versions in the field, similar to how Multiple Select works in the
>>>> Chosen
>>>>>> plugin:
>>>>>> - Joe
>>>> [...]
>>>>> In my case, I am not so much concerned with how it looks as much as
>>> how
>>>>> it would be supported by the model. Depending on the way things
>>>>> currently work, we might want to use a fresh field rather than
>>> subvert
>>>>> the use of the current version field.
>>>> Two suggestions ...
>>>> 1. custom fields
>>>> 2. keywords ... or something similar ;)
>>>> --
>>>> Regards,
>>>> Olemis.
>>>> Blog ES:
>>>> Blog EN:
>>>> Featured article:
>>> Ticket needs to be resolved for each individual version separately. So
>>> we
>>> would need at least status per version.
>>> And when the solutions for different versions must be different, one
>>> would
>>> also appreciate separate descriptions, comments... (but I am not sure
>>> this
>>> is common enough that it would warent special support).
>>> We could stick to ticket per version (as what you have to do now) but
>>> link
>>> the tickets together with special relation type (when we have ticket
>>> relations going). Basically what Gary is suggesting with subtickets but
>>> build on top of the ticket relation concept (parent/child, duplicate,
>>> version subticket,...) that we need to establish first.
>> >From the UI perspective, we could still allow for bulk create of these
>>> tickets by selecting multiple versions in the version field and provide
>>> the
>>> user with ability of on overview of all the linked tickets. Again, also
>>> built on top of ticket relations.
>>> Personally I am still not decided whether I would rather see multiple
>>> versions per ticket or version specific subtickets. But I do need the
>>> ability to resolve them separately.
>>> Peter
>> For me it would have to be a user choice as to whether a multi version
>> ticket should be split or treated as a single entity. In the latter case I
>> would be happy with a single resolution.
>> Cheers,
>>      Gary
> As we opened this discussion I have been thinking about this some more.
> 1. Supporting per version comments, descriptions and attachments just does
> not seem worth it. It would complicate things technically as well for the
> user for very little benefit.
> 2. Tickets are not necessarily resolved in the versions to which
> they apply (bug for version 1.3 is resolved in 1.4, ticket planned for 1.4
> is sliped to 1.5...). It becomes obvious that we need more then
> one multiversion ticket field
> 3. I still want to be able to plan and track progress. Versions are
> essential here, so I need that resolution per version thing.
>     Taking it all into account we would need 2 multiversion fields (affected
> and planned versions) and resolution per planned version:
>    o A customer/tester will file a ticket about a bug that affects some
> versions.
>    o Project manager will make a plan in which versions a fix is necessary
> (typically next planned release and a hot fix version for whatever customer
> is currently using)
>    o Developers will resolve per version as a solution is being applied
> across all the planned versions.
> It seems that affected versions only apply to bugs and should be the same
> as planned for other ticket types.
> Ticket should be considered resolved only when all planned versions have
> some kind of resolution. It can be the same for all versions or vastly
> different.
> I guess I am leaning toward the multiversion,multiresolution per ticket
> approach. User can still use ticket relations if he has the need to split
> the ticket into ticket/version.
> Peter

Clearly the way that the process works will be somewhat dependent on 
which versions remain supported. Equally it depends on the way that they 
work. A likely scenario is that a solution would first be created on 
trunk for future releases and the fix applied or adapted to other 
supported versions.

I think that multiresolution might be going a bit too far as it is not 
just multiresolution but multiple parallel workflow as a whole. I think 
it is better to model the process on multple tickets instead as the user 
benefits from all the per-ticket behaviour.

So, another alternative would be to see if we can create a combined 
ticket view for tickets in any relationship structure. The nice thing 
about this would that it could benefit more situations than just 
multiple versions.


View raw message