LibRadar
LibRadar copied to clipboard
Retagging candidates
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):
- [x]
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¹ - [x]
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 :smile_cat: 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
(taggedpn
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 justsn
. It has a bunch ofut
packages as well, like Fresco (ugly to tag, because it has a bunch of separate directories directly belowcom/facebook
), Stetho or Rebound. So we should be careful what we tagsn;Facebook (com/facebook)
here (and check the existing tags again). This, too, I have corrected where I encountered a candidate.
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.
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.
No problem, take your time. As you see, I lied again and continued pushing meanwhile :smile_cat: 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…
So what do we do with the remaining candidates, @pkumza ?