Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gary.martin@wandisco.com
 designates 209.85.217.175 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: 
 <CAKE9Bs_CGQcR6OwSTt-fmXrmP=DRcB81SkGQL2zqGr4RAcVLLg@mail.gmail.com>
References: <058.8f55f33616a1dbdb006e2764d8403ee8@incubator.apache.org>
 <073.b114c45c60941c739a5e435278c678fc@incubator.apache.org>
 <CAKE9Bs9e6kkfTkxxsRFNG7rydbE+AvJwxxSTq=-dnOoPaoy32A@mail.gmail.com>
 <507D48A1.2090006@wandisco.com>
 <CAPt9QwSEk1CRVjBBjW6gBiaUFXRqKH1UsfmZQ=5q42kVD+nWBQ@mail.gmail.com>
 <507EC1ED.3050409@wandisco.com>
 <CAKE9Bs_poHa8uN=n2hs_TgzS2q7u_t0twPVT0+Oun=+wikNaMQ@mail.gmail.com>
 <2506BA94-C4FC-4E4D-B9A6-6C3696A10039@wandisco.com>
 <507EED75.6050205@wandisco.com>
 <CAGMZAuM8CoHtWun=SQAMEG5UYWW3U+3zoGbf41aRjav7DOf8PA@mail.gmail.com>
 <CAKE9Bs_CGQcR6OwSTt-fmXrmP=DRcB81SkGQL2zqGr4RAcVLLg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: ticket associated with multiple versions (Was: Re: [Apache
 Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
From: Gary Martin <gary.martin@wandisco.com>
Date: Thu, 18 Oct 2012 09:00:59 +0100
To: bloodhound-dev@incubator.apache.org
Message-ID: <6baddcaa-c8e8-4456-a770-dc6325761890@email.android.com>


"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