incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
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 07:23:10 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message