Provide some guidance on granularity of CQs
Submitted by Wayne Beaton @wbeaton
Link to original bug (#500460)
Description
There is some confusion in the committer community regarding the expected granularity for CQs. The IP Policy refers to "Content", but does not (AFAICT) suggest any particular level of granularity.
My understanding is that from the IP team's perspective, the desired granularity is the "library". That the library may manifest has multiple files is not relevant from an IP Due Diligence point of view.
For example, CQs 11879, 11880, 11881, 11882, 11883, 11884, 11885, 11886, 11887, 11888, 11889, 11890, 11891, and 11892 represent AngularJS 1.57 in (I believe) its entirely. All of these CQs point to the same "source URL". In fact, the committer created an "umbrella CQ" for these [1].
My understanding is that one CQ for AngularJS would suffice. That the library may be distributed as multiple individual .js files is irrelevant. Further, it would save both the committer and IP Team time (perhaps just a few minutes for each, but that adds up).
I've seen examples of this with Java libraries as well. One first possible example that I see is the combination of CQs 105 and 106 which represent the Xerces API and Implementation respectively. I believe that these two CQs represent just one library that happens to be distributed as two separate JAR files.
Another example is the difference in the way that Batik 1.6 and 1.7 are represented: there is a single CQ for version 1.6 and multiple CQs for each of the various parts that make up Batik 1.7.
Can we provide a simple definition of a library? e.g.
- All source comes from the same team/repository
- Provides some coherent bit of functionality
- May include separate but interdependent modules
- May manifest in deployment as multiple files
The actual definition is probably fuzzy, so the best that we can likely come up with is some guidance that saves everybody some time.
This probably belongs in the handbook. Maybe we can move it there once we have an answer.
[1] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=11804