You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Peter Koželj <pe...@digiverse.si> on 2013/02/01 08:59:36 UTC
Re: Proposal: Ticket relations
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 <ry...@wandisco.com> wrote:
> On Thu, Nov 15, 2012 at 3:09 AM, Peter Koželj <pe...@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
>
Re: [BEP-0006] Ticket relations
Posted by Ryan Ollos <ry...@wandisco.com>.
On Mon, Feb 11, 2013 at 11:55 AM, Branko Čibej <br...@wandisco.com> wrote:
> [...]
> With my user hat on: I disagree. IMO it's better to have different
> relation types than to confuse the meaning of "dependency" or "child".
> E.g., Jira as "is-related-to" for this purpose, and also differentiates
> between "depends-on" and "is-blocked-by".
>
That sounds reasonable. I incorporated the suggestions as clarifications in
the BEP.
Re: [BEP-0006] Ticket relations
Posted by Branko Čibej <br...@wandisco.com>.
On 11.02.2013 15:43, Ryan Ollos wrote:
> Constraints that are implemented by the current plugins are "parent
> can't be closed if one or more child tickets is open", "blocker can't
> be closed if a dependency is open". These could be even be implemented
> as options for the user defining the relations.
With my user hat on: I disagree. IMO it's better to have different
relation types than to confuse the meaning of "dependency" or "child".
E.g., Jira as "is-related-to" for this purpose, and also differentiates
between "depends-on" and "is-blocked-by".
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [BEP-0006] Ticket relations
Posted by Ryan Ollos <ry...@wandisco.com>.
On Mon, Feb 11, 2013 at 6:18 AM, Matevž Bradač <ma...@gmail.com> wrote:
> Hi,
>
> I created an initial draft for BEP-0006: Ticket Relations[1] to continue
> this discussion.
> It doesn't currently contain any implementation details, as the feature
> requirements haven't
> been finalized yet.
>
> [1] https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0006
>
> --
> matevz
>
It looks great, thanks for moving this forward. We may want to consider
implementing graph visualization in the user interface. MasterTickets and
ChildTicketsPlugin currently have this, though we could probably provide a
more impressive and dynamic presentation than they provide.
Constraints that are implemented by the current plugins are "parent can't
be closed if one or more child tickets is open", "blocker can't be closed
if a dependency is open". These could be even be implemented as options for
the user defining the relations.
- Ryan
[BEP-0006] Ticket relations
Posted by Matevž Bradač <ma...@gmail.com>.
Hi,
I created an initial draft for BEP-0006: Ticket Relations[1] to continue this discussion.
It doesn't currently contain any implementation details, as the feature requirements haven't
been finalized yet.
[1] https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0006
--
matevz
On 4. Feb, 2013, at 6:21, Ryan Ollos wrote:
> On Thu, Jan 31, 2013 at 11:59 PM, Peter Koželj <pe...@digiverse.si> wrote:
>
>> [...]
>> 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)
>>
>
> (1) and (2) sound fine. Regarding (3):
>
> The SubticketsPlugin provides parent-child relations. The
> MasterTicketsPlugin provides blocker-blocked relations. I worked up a few
> patches for the SubticketsPlugin and they were never integrated by the
> author so I moved on.
>
> I'm maintaining the MasterTicketsPlugin now and I was working on adding
> parent-child relations support as well. I lost a few patches in my working
> copy when my VM became corrupt earlier this month, but I'll work to get
> those recreated and push out a new version of MasterTicketsPlugin that has
> some critical fixes and parent-child relation support. I see no problem
> with adding multi-product awareness to the plugin in a way similar to what
> Olemis did for TracPastePlugin.
Re: Proposal: Ticket relations
Posted by Branko Čibej <br...@wandisco.com>.
On 05.02.2013 11:25, Gary Martin wrote:
> On 04/02/13 19:24, Branko Čibej wrote:
>> On 04.02.2013 20:06, Ryan Ollos wrote:
>>> On Sun, Feb 3, 2013 at 11:06 PM, Branko Čibej <br...@wandisco.com>
>>> wrote:
>>>> Just a suggestion, of course; there can be any number of valid reasons
>>>> to reject it.
>>>>
>>> I have some more questions on how this would work, but let me give
>>> it some
>>> more thought while I check whether the original author would support
>>> the
>>> idea.
>> Also consider that if the license is a problem, it's conceivable that it
>> could be released dual-licensed, e.g., ALv2 and BSD.
>>
>> -- Brane
>>
>>
>
> I was under the impression that the ASF doesn't do dual-licensing. If
> the code is to be donated to the ASF, wouldn't it have to be put under
> the Apache License, version 2?
That does not prevent the author from publishing another, identical copy
under a different license. A grant to the ASF is a license grant, not a
copyright assignment.
Obviously that situation is to be avoided, but it's an option.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Proposal: Ticket relations
Posted by Gary Martin <ga...@wandisco.com>.
On 04/02/13 19:24, Branko Čibej wrote:
> On 04.02.2013 20:06, Ryan Ollos wrote:
>> On Sun, Feb 3, 2013 at 11:06 PM, Branko Čibej <br...@wandisco.com> wrote:
>>> Just a suggestion, of course; there can be any number of valid reasons
>>> to reject it.
>>>
>> I have some more questions on how this would work, but let me give it some
>> more thought while I check whether the original author would support the
>> idea.
> Also consider that if the license is a problem, it's conceivable that it
> could be released dual-licensed, e.g., ALv2 and BSD.
>
> -- Brane
>
>
I was under the impression that the ASF doesn't do dual-licensing. If
the code is to be donated to the ASF, wouldn't it have to be put under
the Apache License, version 2?
Cheers,
Gary
Re: Proposal: Ticket relations
Posted by Branko Čibej <br...@wandisco.com>.
On 04.02.2013 20:06, Ryan Ollos wrote:
> On Sun, Feb 3, 2013 at 11:06 PM, Branko Čibej <br...@wandisco.com> wrote:
>> Just a suggestion, of course; there can be any number of valid reasons
>> to reject it.
>>
> I have some more questions on how this would work, but let me give it some
> more thought while I check whether the original author would support the
> idea.
Also consider that if the license is a problem, it's conceivable that it
could be released dual-licensed, e.g., ALv2 and BSD.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Proposal: Ticket relations
Posted by Ryan Ollos <ry...@wandisco.com>.
On Sun, Feb 3, 2013 at 11:06 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 04.02.2013 06:21, Ryan Ollos wrote:
> > I'm maintaining the MasterTicketsPlugin now and I was working on
> > adding parent-child relations support as well. I lost a few patches in
> > my working copy when my VM became corrupt earlier this month, but I'll
> > work to get those recreated and push out a new version of
> > MasterTicketsPlugin that has some critical fixes and parent-child
> > relation support. I see no problem with adding multi-product awareness
> > to the plugin in a way similar to what Olemis did for TracPastePlugin.
>
> How about donating the MasterTicketsPlugin to the ASF, as part of the
> Bloodhound project? This depends of course on a) whether you want to,
> and b) whether you /can/ (e.g., you'd have to get permission from all
> the contributors in order to re-license the code).
>
That is an interesting idea. I'm certainly not against it. There is only
one other author besides myself. I've been in touch with him recently and
from another discussion I can say that he is fine with the Apache license.
He moved the plugin from trac-hacks over to GitHub, presumably because he'd
rather work with Git than SVN, but since he's not actively developing it
anymore then it probably won't be a factor.
I'll get in touch with him and perhaps even pull him in to the discussion
in this thread.
That way, you'd get the best of both worlds -- the plugin can remain
> stand-alone in the sense that it can be used without BH, yet we'd have
> enough control (and enough coders) to make it the sort of comprehensive
> ticket relations thing that BH needs.
>
I can also add additional contributors to the project on GitHub, or we can
pull it back to Trac-Hacks, so one way or another we'll find a way to get
additional contributors on the project. So if anyone wants immediate access
just let me know, and in parallel we can continue to pursue this idea of
moving the project to Apache.
> Just a suggestion, of course; there can be any number of valid reasons
> to reject it.
>
I have some more questions on how this would work, but let me give it some
more thought while I check whether the original author would support the
idea.
Thanks!
Re: Proposal: Ticket relations
Posted by Branko Čibej <br...@wandisco.com>.
On 04.02.2013 06:21, Ryan Ollos wrote:
> I'm maintaining the MasterTicketsPlugin now and I was working on
> adding parent-child relations support as well. I lost a few patches in
> my working copy when my VM became corrupt earlier this month, but I'll
> work to get those recreated and push out a new version of
> MasterTicketsPlugin that has some critical fixes and parent-child
> relation support. I see no problem with adding multi-product awareness
> to the plugin in a way similar to what Olemis did for TracPastePlugin.
How about donating the MasterTicketsPlugin to the ASF, as part of the
Bloodhound project? This depends of course on a) whether you want to,
and b) whether you /can/ (e.g., you'd have to get permission from all
the contributors in order to re-license the code).
That way, you'd get the best of both worlds -- the plugin can remain
stand-alone in the sense that it can be used without BH, yet we'd have
enough control (and enough coders) to make it the sort of comprehensive
ticket relations thing that BH needs.
Just a suggestion, of course; there can be any number of valid reasons
to reject it.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Proposal: Ticket relations
Posted by Ryan Ollos <ry...@wandisco.com>.
On Thu, Jan 31, 2013 at 11:59 PM, Peter Koželj <pe...@digiverse.si> wrote:
> [...]
> 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)
>
(1) and (2) sound fine. Regarding (3):
The SubticketsPlugin provides parent-child relations. The
MasterTicketsPlugin provides blocker-blocked relations. I worked up a few
patches for the SubticketsPlugin and they were never integrated by the
author so I moved on.
I'm maintaining the MasterTicketsPlugin now and I was working on adding
parent-child relations support as well. I lost a few patches in my working
copy when my VM became corrupt earlier this month, but I'll work to get
those recreated and push out a new version of MasterTicketsPlugin that has
some critical fixes and parent-child relation support. I see no problem
with adding multi-product awareness to the plugin in a way similar to what
Olemis did for TracPastePlugin.