Retagging candidates

[IzzySoft]

As our "leftovers" are spread across multiple PRs (most of them closed now), let's consolidate them in an issue (which then can be dealt with / closed via another PR):

• da;Appbrain;http://www.appbrain.com/ (com/appbrain) should probably be:
  ad;AppBrain SDK;https://www.appbrain.com/info/help/sdk/index.html (ref)
• da;javax; (javax) is much too broad¹
• da;Mozilla;https://www.mozilla.org/ (org/mozilla) is much too broad¹
• da;Polidea;https://www.polidea.com/ (pl/polidea) probably too broad as well¹

¹ ref. We should probably "untag" those (emptying the lib and removing the pn) for now, and tag them appropriately once they turn up in a scan and can be properly identified. Some examples for javax I can already provide:

ut;JavaX Dependency Injection;https://docs.oracle.com/javaee/6/api/javax/inject/package-summary.html (javax/inject)
ut;jmDNS library;https://github.com/jmdns/jmdns (javax/jmdns)
ut;JavaX Servlet API;https://www.jcp.org/en/jsr/detail?id=369 (javax/servlet)

The last two are present in our definitions, so I could retag them properly already (leaving unmatched "javax candidates" untagged).

My suggestions are included above – but I want to hear your opinion first, @pkumza 😸 After having decided, we could proceed as with PRs 30..32: I'd do the retagging on the V1 branch, and you later adopt that (migrate my changes) for V2. Deal? Just give me either…

• a "global OK" (if you agree to all my suggestions)
• separate OKs for what you agree with, and your alternative suggestion for the remains
• requests for clarification where things are unclear (and OKs for where I shall start already)

Update: More candidates:

• com/squareup (tagged pn currently). This prefix is used by a bunch of different libraries like Seismic, Picasso, SQLBrite and more. I've retagged the 2 candidates I was able to identify, and left the remaining alone. We should consider "untagging" them and retagging whenever identified correctly.
• com/facebook is not just sn. It has a bunch of ut packages as well, like Fresco (ugly to tag, because it has a bunch of separate directories directly below com/facebook), Stetho or Rebound. So we should be careful what we tag sn;Facebook (com/facebook) here (and check the existing tags again). This, too, I have corrected where I encountered a candidate.

[IzzySoft]

PS: Just discovered another "group" in our "fallback category": android/content/pm (Android Package Management). That's not really da – but neither ut or anything else existing. I'd suggest sy (System Interface") as a new category. What do you think? Shall I introduce this? I could either include it with my current PR (including the change to Python code), or with a separate PR after you've merged the current one. Just let me know.

[pkumza]

I am very busy these days. I will check your PR before Sat. On 05/25/2017 23:48, Izzy wrote: PS: Just discovered another "group" in our "fallback category": android/content/pm (Android Package Management). That's not really da – but neither ut or anything else existing. I'd suggest sy (System Interface") as a new category. What do you think? Shall I introduce this? I could either include it with my current PR (including the change to Python code), or with a separate PR after you've merged the current one. Just let me know. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[IzzySoft]

No problem, take your time. As you see, I lied again and continued pushing meanwhile 😸 Just now encountered another "too broad" candidate: com/facebook. That's not only sn (which would apply to the "Facebook SDK"), but also a bunch of utilities – see here. Just retagged one of them, not sure if I walk them all…

[IzzySoft]

So what do we do with the remaining candidates, @pkumza ?