On 18/10/12 13:00, Peter Koželj wrote:
On Thu, Oct 18, 2012 at 10:00 AM, Gary Martin <[email protected]>wrote:
"Peter Koželj" <[email protected]> wrote:
On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <[email protected]> wrote:
On 10/17/12, Gary Martin <[email protected]> wrote:
On 17/10/12 17:15, Joe Dreimann wrote:
On 17 Oct 2012, at 17:00, Peter Koželj <[email protected]> wrote:
On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
<[email protected]>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
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.
Cheers,
Gary
