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,...
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
