Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • O org.eclipse.dash.handbook
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 154
    • Issues 154
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 3
    • Merge requests 3
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Eclipse Projects
  • Eclipse Dash
  • org.eclipse.dash.handbook
  • Issues
  • #38

Closed
Open
Created Aug 30, 2016 by Eclipse Webmaster@webmasterOwner

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

Blocking

  • Bug 496959
  • Bug 508206
Assignee
Assign to
Time tracking

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent