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: Proposal: Ticket relations
Date Fri, 01 Feb 2013 07:59:36 GMT
Yes, we need to evaluate/discuss this plugins.

I like how BEPs turned out so far. I would take the same approach here:
1. Let's create a BEP with requirements and mocks and discuss it on the dev
list
2. Once we know what we want both plugins should be evaluated and results
put in BEP as well
3. Based on 1 and 2 we can decide which plugin to use (presence
or absence of multiproduct awareness
    requirement together with author's willingness to provide it, will
probably be one of the key decision making factors)

Peter



On 31 January 2013 17:40, Ryan Ollos <ryan.ollos@wandisco.com> wrote:

> On Thu, Nov 15, 2012 at 3:09 AM, Peter Koželj <peter@digiverse.si> wrote:
>
> > While we are already in new-fetures-discussion mode I would like to kick
> of
> > another one about ticket relations.
> > Here is my take on the subject:
> >
> > Although links are already possible through wiki formatting they feels
> like
> > an afterthought and most importantly does not enable us to make a first
> > class functionality on top of that. We need first class relations with
> > following capabilities:
> > 1. Relation is defined by source ticket, target ticket and relation type.
> > Source and traget ticket can belong to different products.
> > 2. Provide build in relation types with well defined semantics:
> >   - Duplicate
> >      This should be bound with ticket state/resolution in some way. BH
> > should require the user to eneter the duplicate ticket when resolving as
> > such.
> >   - Parent/child (multiple levels should be supported)
> >   - Blocks/depends
> >     Ticket should no be resolvable until all the tickets that it depend
> on
> > are resolved
> > 3. User can define additional types with no semantic meaning through
> admin
> > interface
> >    There is probably no need to make this product specific
> > 4. On UI ticket page would get a generic "Relations" section where user
> can
> > view and manage existing relations or add new ones.
> >     This would work for build in and user defines types alike
> > 5. Special support for build in types can be added over time:
> >     - duplicate tickets marked specially in search result and reports
> >     - parent/child relations can be presented as a expand button that
> would
> > display entire tree, blocks/depends could follow the same steps
> > 6. Query language will have to be extended so that relations can be used
> > for searching.
> > Actually the query language is due for some overhaul (out of scope for
> this
> > discussion), this might better be added through that effort.
>
>
> I have done some work to bring the MasterTicketsPlugin (1) up to par and
> merge the feature base with the SubticketsPlugin (2), in order to provide a
> plugin that could serve as a starting point for Ticket relations in
> Bloodhound. I will get the rest of that work committed to the repository
> within the next few days and we can see if it will serve as a suitable
> starting point for implementing the other features suggested here.
>
> (1) https://trac-hacks.org/wiki/MasterTicketsPlugin
> (2) http://trac-hacks.org/wiki/SubticketsPlugin
>

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