Remove app name completely

Bug #737649 reported by Anthony Lenton
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ratings and Reviews server
Fix Released
Medium
Michael Nelson

Bug Description

Having per application reviews (as opposed to per package) only benefits corner-case packages with more than one application, and bring quite a few complications and pains (no proper way to validate which applications belong to a package, no way to handle when an app within a package is renamed, extra load calculating and transmitting aggregated stats).

So, we'll move to a per-package review model. This change should be backwards compatible, or at least not make the current client fail miserably.

Related branches

tags: added: kb-improvement
Changed in rnr-server:
importance: Undecided → Medium
Revision history for this message
Michael Nelson (michael.nelson) wrote :

So depending on discussions with mvo and achuni, we can choose to land the first 2 branches or all three, depending on whether we want to:

1) Just update so that statistics are now for packages only (no app_name in statistics results either), and we verify all package_names in repositories with LP (this is the first two branches),
2) We also update the get_reviews api call to ignore app_names and just return all reviews for the specified package (branch 3).

Changed in rnr-server:
assignee: nobody → Michael Nelson (michael.nelson)
Revision history for this message
Michael Nelson (michael.nelson) wrote :

Note: I updated the second branch so that an empty app_name is included in the stats, just to avoid any unnecessary key errors on the USC client.

Changed in rnr-server:
status: New → Fix Committed
Revision history for this message
Michael Nelson (michael.nelson) wrote :
Revision history for this message
Michael Nelson (michael.nelson) wrote :
Revision history for this message
Michael Nelson (michael.nelson) wrote :
Revision history for this message
Michael Nelson (michael.nelson) wrote :
Revision history for this message
Michael Nelson (michael.nelson) wrote :
Revision history for this message
Michael Nelson (michael.nelson) wrote :
Revision history for this message
Michael Nelson (michael.nelson) wrote :

QA notes: (no, I won't be doing this for each bug I QA, this one was just quite important)

The details are attached to the bug. The following 12 software items were identified beforehand as items which would be deleted on the daily server by querying for software items without related reviews (https://pastebin.canonical.com/45013/):

stellarium
calibre (2x with different app names)
pdfmod
fretsonfire
tuxpaint
gimp
p7zip-full
arista
armagetronad
webservice-office-zoho
aclock.app

The migration result shows that only ten were deleted, the
exceptions being:

p7zip-full
aclock.app

===============================
Calculating the number of items
===============================

This is because these packagenames had multiple software items
(as can be seen in the review_stats_all_before.json), and only
one of those had no associated reviews (p7zip-full had 3 entries,
and aclock.app only 2.). When the duplicate software items were
reconciled, we expect p7zip-full to go from 3 records to 1, and
aclock.app to go from 2 to 1.

So regarding the number of items:
Before: 60
After: 47

which is correct as:

60 - 10 (deletions due to no reviews) - 2 (2 redundant pk7zip-full) - 1 (redundant aclock.app) = 47

Stats: Once the items without reviews for pk7zip-full and aclock.app were removed, the re-calculated stats also work out correctly:

p7zip-full: 3 (4.33) + 3 (3.00) = 6 (3.67)

Revision history for this message
Dave Morley (davmor2) wrote :

I can't find mention of the appname anymore.

Changed in rnr-server:
status: Fix Committed → Fix Released
Changed in rnr-server:
milestone: none → 11.03
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.