incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
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 08:00:59 GMT


"Peter Koželj" <peter@digiverse.si> wrote:

>On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <olemis@gmail.com> wrote:
>
>> On 10/17/12, Gary Martin <gary.martin@wandisco.com> wrote:
>> > On 17/10/12 17:15, Joe Dreimann wrote:
>> >> On 17 Oct 2012, at 17:00, Peter Koželj <peter@digiverse.si> wrote:
>> >>
>> >>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
>> >>> <gary.martin@wandisco.com>wrote:
>> >>>
>> >>>> On 17/10/12 12:03, Ryan Ollos wrote:
>> >>>> It gets interesting where really you want to raise a bug against
>> >>>> multiple
>> >>>> versions but it is not the end of the world. The main thing is
>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:
>> >> http://harvesthq.github.com/chosen/
>> >>
>> >> - 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: http://simelo-es.blogspot.com/
>> Blog EN: http://simelo-en.blogspot.com/
>>
>> 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


Mime
View raw message