On Jan 12, 2012, at 20:56, Craig Treleaven wrote: > At 7:33 PM -0600 1/12/12, Ryan Schmidt wrote: > >> Here is a script that constructs and opens a Trac search page to find issues >> filed against a port (or ports) and optionally any of its recursive >> dependencies, sorted in descending ticket number order (i.e. newest first): >> >> https://trac.macports.org/browser/users/ryandesign/scripts/portissues >> >> Running this script as follows: >> >> portissues --deps mkvtoolnix >> >> The script opens this URL: >> >> https://trac.macports.org/report/16?sort=ticket&asc=0&PORT=(%5E%7C%20%7C,)(mkvtoolnix%7Cruby%7Clibiconv%7Cgperf%7Creadline%7Cncurses%7Cncursesw%7Copenssl%7Czlib%7Cgdbm%7Cgettext%7Cexpat%7Cboost%7Cbzip2%7Cicu%7Cfile%7Cflac%7Clibogg%7Clibvorbis%7Cpkgconfig%7Cglib2%7Cxz%7Clibffi%7Cperl5%7Cperl5.12%7Clzo2%7Cpcre%7Clibedit)($%7C%20%7C,) >> >> There are 58 tickets. Would seeing this list have been helpful? I would >> argue that there are a lot of tickets in that list that are not relevant to >> the issue being experienced -- lots of text to sift through before you find >> what you're looking for. > > Hi Ryan: > > Did you just write that script today?! Wow, I never even considered that > somebody would put together a prototype--let alone that quickly.
I did... the idea has come up before, and I wanted to finally do something about it to see what would happen. For example it's been suggested that, if we had a page for each port on our web site (that's #19300), there could be a link to tickets about the port. And it's been suggested that when you're viewing a ticket about a port, it should show you other tickets about that port, to help you figure out if you might be looking at a duplicate; this would require modifying Trac, which I don't know how to do. I hadn't heard the suggestion before to search for issues for all dependencies too. That's interesting, but I think it's probably more practical to just try to install a port, and if it or one of its dependencies fails, then just search for issues for the one that failed. > I was worried that my idea might be impractical--and in this case with 58 > reported issues--it wouldn't help anyone. Just a couple more thoughts before > abandoning it... > > I'm a very light user of MacPorts; is this case an exception or more typical? > I've normally used MacPorts to install stuff like wget and yasm where the > list of deps is pretty small. Many ports have few or no dependencies. Many ports have many dependencies. :) Some like gimp ports have hundreds of them. > Are there other attributes in the Trac database that could help narrow down > to problems that are potential blockers? I would think that by default > ticket type "Enhancement" could normally be excluded. Yes, if you're just looking for problems, then type=defect is all you really want to look at. > I'm (slightly) more familiar with MythTV where status is changed to Assigned > after ticket-triage to ensure that the issue reported really is a bug and not > just a mis-configuration or user error. I take it you folks don't work that > way? I don't think we have an official policy about that. Also, Trac has some confusing terminology here. Our first step in triaging is to assign the port to its maintainer, if it has one. That sets the Owned By field, and leaves the status at "New". When a ticket is assigned to me, and I agree with the ticket -- I can reproduce the bug, or agree the enhancement should be implemented -- I use the "Accept" function which sets the bug's status to "Assigned". If other assignees would agree to "Accept" tickets they've confirmed, then we could search only for assigned tickets. However, this would not help for ports which have no maintainer, unless the person confirming the issue was also assigning it to themselves in order to fix it. > Finally, MythTV uses a severity field (something like trivial, minor, major, > blocker)--anything like that here? We do have a Priority field, but it's basically not used. The vast majority of tickets are "Normal" priority. "High" priority would only be used if there were a serious bug either in MacPorts or in an extremely commonly-used port which was affecting most users. > Anyway, I'm not trying to push anything...just had an idea and wondered if it > might be useful. I certainly don't have the skills to implement anything > like this and I'm just grateful that you folks who CAN do it are so generous > in sharing your work. _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
