Suggestion on auto ticket filing
talklists at newgeo.com
Tue Dec 1 14:57:27 PST 2009
On Dec 1, 2009, at 2:38 PM, Jeremy Lavergne wrote:
>> Can you tell me more about the gsoc project wrt MacPorts? Where do
>> I find the log? I can force a portfile to fail, or look at some
>> others that have, where do I find those logs?
> It's in the trunk version: when there's an error it'll report where
> it put the log.
Any eta on when this hits the general users hands?
>>> The gsoc logging project assists us in that the log is already
>>> available---no more need to rerun with debug mode.
>>> It also provides the path to the log file (copy/paste into Finder).
>>> As for the port field and ticket owner, we can likely have a
>>> script auto-assign (and CC) the ticket based on the port field,
>>> and we could require the port to be set for ports-based tickets
>>> (the default, type I believe).
>>> These requirements should cause people to read the instructions
>>> since the tickets won't submit without making sure they've added
>>> the port, but it will also remove the need for them to mark the
>>> While we're at it, we might consider logic to test that the
>>> reporter/owner isn't a CC.
>> From what I can gather, your comments below are speaking towards
>> 100% automated ticket submissions on port install error? Or are
>> you saying, that after a failed install, and some general guidance
>> to a wiki/troubleshooting page, that the steps the user take would
>> auto submit a new trac ticket, which in turn, a script could fish
>> out some details and make the ticket more relevant?
> The ticketing process is currently not automated, but my ideas were
> geared toward the creation of such a system. I feel most of the
> information can be gleaned from the server's database and port can
> fire up a terminal window with a specific URL to trigger an auto-
> population of the form (e.g., `openhttp://trac.macports.org/...port=...mpversion=1.8.99
Ok, cool, we are on the exact same page, that was my thinking as well.
> Ultimately, I would like to aim for port to POST the log to trac,
> with a ticket ID returned. Then port will open a URL to trac which
> will display the ticket pre-populated as much as we can and
> referencing that log.
As long as we know the location to that path, I do not see that being
an issue. I am just pretty sure we are going to need either:
1) A local script that interfaces with curl to shove that data off as
a http POST
2) Changes to MP core to so the same as what the above script would do.
>> Sorry, had the flu, and am catching up, and also a little cloudy
>> still, reading over your post, I am not sure I entirely follow what
>> you mean, but would love to work on making this a reality. If you
>> could help bring me up to speed on what you envision, maybe there
>> is a chance my skill set falls in range with the work needed to be
> Basically we need to plan both the server-side URLs and the ability
> to open such URLs directly from MacPorts. It isn't something that
> can be done on one side only.
The pre-population of the form data in trac is going to require the
user have an account, is that correct? Or is there some way of doing
this in a anonymous way, so MacPorts gets the report, but the user
does not hit a barrier?
Of course, logging a general user in via part of this process is an
option, but that account user and pass is then stored somewhere, in
which nefarious things could happen to it. Unless the account was
mode post only, so no deletes or edits are allowed under that account.
I would like to build a small test case, just to see how much pre-
population I am able to achieve, and how the flow of it would all work.
So far, that simple test, http GET does not work to add test to the
field_summary field. I will have to start poking at curl, trac, and
cookies in curl and such to see how to even get to a point where I can
pre-populate that field.
Scott * If you contact me off list replace talklists@ with scott@ *
More information about the macports-dev