Trac ticket mails: default owner for base, ports & www components

[Ryan Schmidt]

On Nov 26, 2007, at 23:10, Juan Manuel Palacios wrote:

> On Nov 27, 2007, at 12:36 AM, Ryan Schmidt wrote:
>
>> On Nov 26, 2007, at 22:06, Juan Manuel Palacios wrote:
>>
>>> 	Now that Trac mailing features are working for us, does it still  
>>> make sense to have this list, dev, as the default owner for the  
>>> base, ports & www components of tickets? As you may have already  
>>> seen, if we keep it like that we're going to start getting a lot  
>>> of mail for a lot of tickets here.
>>>
>>> 	I say we change the default owner to the tickets list for ports  
>>> with no real owners, as activity on them will no longer be lost  
>>> to an eternal black hole. Anyone against it?
>>
>> No comment on that, but what I'd love to see is tickets auto- 
>> assigned to the port maintainer, for ports that have a maintainer.  
>> Reporters frequently don't know they're supposed to do this  
>> manually, and it's a nonzero amount of work for reporters to look  
>> up who a port's maintainer is, and it seems like Trac should be  
>> able to know this.
>
> 	How do you suggest we accomplish that...? From what I'm  
> understanding, it seems like a rather complicated operation to me:

Thanks for thinking it through. You're right, I just mentioned it off  
the top of my head as something that would really help us out, not  
thinking how involved it is. But let's see...

First off, it doesn't have to be in Trac itself. We could have  
another script that we write, which runs after each new ticket is  
submitted. If Trac has a hook for that, we can use that, or we could  
have the script for example monitor the new tickets mailing list, or  
an RSS feed of that list if we have a feed of it. So let's assume we  
can run a script shortly after a new ticket is created then...

> -) we'd have to do stuff like parsing the ticket short summary and/ 
> or full description to try to match a valid port name in our tree  
> (requiring Trac to keep such list handy somewhere...?);

This is a bit I hadn't thought of... that there isn't a well-defined  
place where the portname is. But I'd like to encourage people to put  
the portname as the first word in the summary anyway. So even if we  
just do that, it would catch some of the tickets. And we could write  
into the ticketing guide that people should do this (though the whole  
point of the exercise is to make it so tickets go to the right place  
even if people haven't read the ticketing guide).

> -) then for the result(s) offered we'd have to try and find the  
> maintainer(s) (would Trac have to run "port  
> maintainer:<inferred_port_name>"?); and I say maintainer(s),  
> possibly plural, because we could either have a port with multiple  
> maintainers or our match of the description parsing could be not  
> that accurate (in which case we could have either multiple port  
> entries to look into or none /me remembers singularities in complex  
> calculus);

The script would run "port info --maintainer foo" to find the  
maintainer. If nomaintainer, leave ticket assigned to the default  
address. If a maintainer in the list, assign ticket to that person.  
If multiple maintainers, put additional maintainers in the Cc line.  
Just as an idea.

> -) for the maintainer(s) result(s) offered in the previous  
> operation, which could be anywhere from zero to who-knows-how-many  
> (in any case, easily more than one), we'd have to match the  
> "suggestion" against an address in the "Assign To" menu, taking  
> into consideration that the maintainer might not even be there...

Right, if they're not in the assign-to list, then they go in the Cc  
field.

> 	So, unless I'm missing something incredibly obvious (I can easily  
> claim not enough sleep! :-P), that seems like an overly complex  
> operation to me!

It isn't as simple as one would hope, but it could be doable I think.

> 	I'd be nice though, so please prove me wrong ;-) Regards,...