Mailing List Archive

Rob wrote:
> I'm pretty new to trac so if I'm asking something that's been asked
> before...
>
> I have a couple of questions after playing around with trac for a bit:
> 1. What is the preferred way of handling ticket dependencies?
> I'm referring to a bugzilla-type "Bug 1 [depends on| blocks]" relation.
>
I was informed off-list that it's not yet possible to record these
dependencies.
After some more poking around I found ticket #226 related to my
question. It's targetted towards MS 2.0, I would like to have this
feature sooner rather than later.

What are the chances of this getting added to trac, if an someone
contributes code?

Cheers,
Rob

I have some working code for the ticket dependency thing I asked about
it earlier.

First some questions:
- Would you be interested in this code? (provided I clean it up and you
feel it can at leadt pass as somewhat decent code)
- Can anyone give me some feedback on the code as is? (I'd like to know
if you can agree on the general direction I'm taking this.)
- I could use some advice on how/where best to store the new bits info
in the hdf.
- If you want patches do I generate them against 0.7.1 or the trunk?


What does it do:
1. Enables displaying of Tickets blocking or blocked by the current
ticket on the 'View Ticket' page.
2. Enables editing of this information on the 'View Ticket' page.

What it doesn't do:
Lots, basically I just wanted something that works and show where I
woudl like to go with this, a proof-of-concept really.

1. Reopen depending Tickets when the a Ticket it depends on gets Reopened.
2. Disallow closing of a Ticket when a Ticket it depends on is still Open.
3. Automatically update DB schema. ( I just added the table manually
myself.)
4. Display ticket dependencies more than one level deep (Not sure if
that's such a hot idea to begin with. )


If this is something you are interested in I could finish it/ clean it
up and submit a patch.


Cheers,
Rob

hi,

You can send me a patch against trunk, i will try it on a dev server and
send you feedback.

thanks

Francois Harvey
fharvey@securiweb.net
uto* on #trac

Rob wrote:
> I have some working code for the ticket dependency thing I asked about
> it earlier.
>
> First some questions:
> - Would you be interested in this code? (provided I clean it up and you
> feel it can at leadt pass as somewhat decent code)
> - Can anyone give me some feedback on the code as is? (I'd like to know
> if you can agree on the general direction I'm taking this.)
> - I could use some advice on how/where best to store the new bits info
> in the hdf.
> - If you want patches do I generate them against 0.7.1 or the trunk?
>
> What does it do:
> 1. Enables displaying of Tickets blocking or blocked by the current
> ticket on the 'View Ticket' page.
> 2. Enables editing of this information on the 'View Ticket' page.
>
> What it doesn't do:
> Lots, basically I just wanted something that works and show where I
> woudl like to go with this, a proof-of-concept really.
>
> 1. Reopen depending Tickets when the a Ticket it depends on gets Reopened.
> 2. Disallow closing of a Ticket when a Ticket it depends on is still Open.
> 3. Automatically update DB schema. ( I just added the table manually
> myself.)
> 4. Display ticket dependencies more than one level deep (Not sure if
> that's such a hot idea to begin with. )
>
>
> If this is something you are interested in I could finish it/ clean it
> up and submit a patch.
>
>
> Cheers,
> Rob
>
> _______________________________________________
> Trac mailing list
> Trac@lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac

Rob wrote:

Hi Rob

> I have some working code for the ticket dependency thing I asked about
> it earlier.
>
> First some questions:
> - Would you be interested in this code? (provided I clean it up and you
> feel it can at leadt pass as somewhat decent code)

The official reason why Trac currently doesn't have any explicit
"dependency support" is because most people don't need it.
You get pretty far just by writing stuff like:

"This ticket depends on: #123, #456"

in the description or comment fields. Then it's pretty easy to see the
dependencies, especially with
the new feature in trunk where you can tell if the tickets are new, open
or closed just by looking at the links. Of course this system isn't able
to do fancy stuff like display dependency diagrams or enforce these
dependencies by refusing to carry out actions that violate these
dependencies. But you get pretty far just by using this system.

This was also decided to keep down the overall complexity of the system
at an early stage of the development.

But sure, if people still feel the need for this kind of explicit
"dependency support" I'm not against adding it as long as it doesn't
force people to start using Trac in a different way. It also doesn't
hurt if the implementation is nice and straightforward. :)


> - Can anyone give me some feedback on the code as is? (I'd like to know
> if you can agree on the general direction I'm taking this.)

I believe that utopiste volunteered to take a look at the code, but it's
always a good idea to attach the patch to the ticket as well.

> - I could use some advice on how/where best to store the new bits info
> in the hdf.

I'm not exactly sure what you mean but it generally doesn't matter
exactly where you store store the info. It can always be changed later.

> - If you want patches do I generate them against 0.7.1 or the trunk?
all new development should be against trunk.

>
>
> What does it do:
> 1. Enables displaying of Tickets blocking or blocked by the current
> ticket on the 'View Ticket' page.
> 2. Enables editing of this information on the 'View Ticket' page.
>
> What it doesn't do:
> Lots, basically I just wanted something that works and show where I
> woudl like to go with this, a proof-of-concept really.
>
> 1. Reopen depending Tickets when the a Ticket it depends on gets Reopened.
> 2. Disallow closing of a Ticket when a Ticket it depends on is still Open.

I guess we need to update the trac-pre/post-commit scripts in the
contrib directory as well then...

> 3. Automatically update DB schema. ( I just added the table manually
> myself.)

That's easy. We probably have to do some schema changes for Trac 0.9
anyway.

> 4. Display ticket dependencies more than one level deep (Not sure if
> that's such a hot idea to begin with. )
>
I have no idea about this one.
>
> If this is something you are interested in I could finish it/ clean it
> up and submit a patch.

Sure, send the patch to utopiste and attach it to #226.

http://projects.edgewall.com/trac/ticket/226

/ Jonas
--
Jonas Borgstr?m | Edgewall Software
jonas@edgewall.com | Professional GNU/Linux & Open Source Consulting.
| http://www.edgewall.com/

Jonas Borgstr?m wrote:
> Rob wrote:
<snip>
>> - Would you be interested in this code? (provided I clean it up and
>> you feel it can at leadt pass as somewhat decent code)
>
>
> The official reason why Trac currently doesn't have any explicit
> "dependency support" is because most people don't need it.
> You get pretty far just by writing stuff like:
>
> "This ticket depends on: #123, #456"
>
> in the description or comment fields.
I see your point, allthough scanning the comments gets harder when the
number of comments gets larger.

> Of course this system isn't able
> to do fancy stuff like display dependency diagrams
I don't care much for those, but I can see how it could be usefull on
large projects.
> or enforce these
> dependencies by refusing to carry out actions that violate these
> dependencies.
The automatic reopening is actually the reason why I want/need this.

<snip>
> But sure, if people still feel the need for this kind of explicit
> "dependency support" I'm not against adding it as long as it doesn't
> force people to start using Trac in a different way.
I you don't fill out the depends on/ blocks fields you won't even know
it's there.

> It also doesn't
> hurt if the implementation is nice and straightforward. :)
Wether it's nice, I'll leave for you guys to judge. But I can assure you
that it's pretty straightforward. I havem't coded anything in python
before, so it has to be.

>
>
>> - Can anyone give me some feedback on the code as is? (I'd like to
>> know if you can agree on the general direction I'm taking this.)
>
>
> I believe that utopiste volunteered to take a look at the code, but it's
> always a good idea to attach the patch to the ticket as well.
I did speak to him, but didn't actually ask him to take a look yet.
>
>> - I could use some advice on how/where best to store the new bits info
>> in the hdf.
> I'm not exactly sure what you mean but it generally doesn't matter
> exactly where you store store the info. It can always be changed later.
I'm unfamiliar with Clearsilver and am the solution I chose doesn't feel
quite right to me.
Apart from that I think some of the code in Ticket.py could probably be
handled cleaner. ( It's easier to explain what I mean once I've posted
the patch)

>
>> - If you want patches do I generate them against 0.7.1 or the trunk?
>
> all new development should be against trunk.
I just pulled the trunk and noticed I have some work to do to get it to
work.

>
<big snip>
>
> Sure, send the patch to utopiste and attach it to #226.
Will do, I'll ping the list once I do. I have to update it to get it to
work against the trunk. I worked with 0.7.1 :-(


Cheers,
Rob

Re-sending from registered adres, sorry about spemming the list
Jonas Borgstr?m wrote:
> Rob wrote:
<big snip>
> Sure, send the patch to utopiste and attach it to #226.
>
> http://projects.edgewall.com/trac/ticket/226
Done,
Comment posted with the patch.

>
> / Jonas