Bugzilla – Full Text Bug Listing
| Summary: | Download statistics for Code Recommenders inconsistent | ||
|---|---|---|---|
| Product: | Community | Reporter: | Andreas Sewe <sewe> |
| Component: | CommitterTools | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, denis.roy, johannes.dorn |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
Andreas Sewe
Moving to CommitterTools Funny, I'm seeing "opposite", but different, result, as of right now. 36 for last 30 days, 0 for last 7 days = = = = = = = = But, this bug caught my eye, because I sometimes have seen inconsistent results too ... but, in a different way. While it is "working" right now, in the past, I have sometime entered jdt.java8patch and gotten "zero" hits, but if I then entered fuller name org.eclipse.jdt.java8patch Then I'd get back some results. But, to repeat, is working right now. (though, I searched first for "fuller name", and then for "shorter name" -- maybe there are "order effects"?). = = = = = [Spoiler: off topic , or different issue:] Am also surprised that adding asterisks to front and back results in zero matches. Such as *org.eclipse.jdt.java8patch* I know the instructions say "they are not necessary" ... but, it seems like should say "they are invalid" or something (or, the underlying code "smart enough" that if an asterisk is already present, it doesn't interpret it literally.) It was this issue with asterisks that made me look closer at this bug ... I was going to ask how they were specifying "partial name" ... but, turns out they were pretty explicit about that and apparently "doing it right". = = = = = = = = Good luck! (In reply to Andreas Sewe from comment #0) Are you sure you didn't touch other fields? I can't seem to reproduce that. (In reply to David Williams from comment #2) > While it is "working" right now, in the past, I have sometime entered It seems to work for me too right now. > [Spoiler: off topic , or different issue:] > Am also surprised that > > adding asterisks to front and back results in zero matches. Such as > *org.eclipse.jdt.java8patch* > > I know the instructions say "they are not necessary" ... but, it seems like > should say "they are invalid" or something (or, the underlying code "smart > enough" that if an asterisk is already present, it doesn't interpret it > literally.) We're using SQL, and SQL wildcards are "%". A star is interpreted as such. Perhaps an enhancement would be to consider a star as a wildcard. (In reply to Denis Roy from comment #3) > > We're using SQL, and SQL wildcards are "%". A star is interpreted as such. > Perhaps an enhancement would be to consider a star as a wildcard. Oh, my mistake. I would have sworn I saw something that said to use '*' as wildcard, but now I see nothing about it at all on that page. And, searching the wiki, I found https://wiki.eclipse.org/Project_Download_Stats where it is quite clear that % is the wild card character. I think that suffices. I confirmed that %org.eclipse.jdt.java8patch% works as expected. I just "got it in my head" wrong -- not for the first (or last :) time, I'm sure. Thanks for your patient, re-explaining. I suppose if anything you could mention right there on https://dev.eclipse.org/committers/committertools/stats.php that '%' is the wildcard character to match anything, and '_' means match any one character. Or, maybe just a link to "see also https://wiki.eclipse.org/Project_Download_Stats" Thanks again, It looks like we can't get any statistics for "stats/recommenders" since this saturday. This may have been going on for longer, the last time i checked before saturday was on monday last week. Doing a search for "stats/recommenders" results in "0 record found", regardless of the date interval picked. Now we do get results, but the numbers are extremely small. File (click for daily stats) Count /stats/recommenders/stable/org.eclipse.recommenders.mylyn.rcp.feature-2.1.0 4 /stats/recommenders/stable/org.eclipse.recommenders.rcp.feature-2.1.0 4 /stats/recommenders/milestones/org.eclipse.recommenders.rcp.feature-2.1.1-SNAPSHOT 3 /stats/recommenders/stable/org.eclipse.recommenders.snipmatch.rcp.feature-2.1.0 3 /stats/recommenders/milestones/org.eclipse.recommenders.snipmatch.rcp.feature-2.1.1-SNAPSHOT 1 /stats/recommenders/milestones/org.eclipse.recommenders.mylyn.rcp.feature-2.1.1-SNAPSHOT 1 6 records found. 16 These are all-time numbers. This looks to me like the number from only the last few hours (or even minutes). I broke the p2 stats when I "fixed" another issue. I'm rebuilding the p2 stats now, and it will take a while... I've recovered about seven days' worth of stats, and new daily stats seem to be appending OK. Is this sufficient for your needs? Since we have logged (approximate) numbers from 2013-12-16 till 2014-06-22 we're only missing statistics from 2014-06-23 till 2014-06-25 which is no big deal at all. It's great to have the luna launch numbers, so thank you! I am not marking this as resolved for now in case you wish to continue recovering stats or the inconsistencies pop up again. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. Closing. -M. |