Thanks for your input, Jim.
It may well be time to revisit the requirement that the PMC approve CQs (especially with the recent changes to the IP Policy). TBH, I'm concerned that the PMC is not engaging; as part of the project leadership chain, we depend on the PMC to help ensure that project teams are implementing the process.
We've had a streamlined process for version upgrades for some time. We have, however, been wrestling with a bug that's been putting CQs into the wrong state. I'll forward your bug list to the IP team to ask that they process them and then investigate why they're not in the right state.
More generally, recent changes in the IP Policy (at least partially motivated by your experience) is moving us in a direction where hopefully most (in some cases, all) CQs are not required. Rather than CQs being a means of tracking content, we're changing them to be purely concerned with vetting content that has not previously been vetted.
A few weeks ago, I posted on this list about a
tool that we've developed in-house (and are contributing to the Eclipse Dash project) that checks the trusted sources of license information that we have available to us (IPzilla and ClearlyDefined). The tool reports that we have trusted license information for org.apache.accumulo:accumulo-core:2.0.0, org.apache.commons:commons-configuration2:2.5, and org.apache.zookeeper:zookeeper:3.4.14, so (assuming that I've correctly guessed at the right Maven coordinates) three of the CQs that you've listed aren't required (I couldn't map org.apache.htrace:htrace-core:3.2, so that CQ is required).
The tool can be used to test a single CQ, e.g.:
$ echo "org.apache.accumulo:accumulo-core:2.0.0" | java -jar /gitroot/dash/org.eclipse.dash.bom/target/org.eclipse.dash.licenses-0.0.1-SNAPSHOT.jar -
Vetted license information was found for all content. No further investigation is required.
$ _
I ran the tool on your full build (there's instructions for this in the tool's repository's README) and it came back with a pretty big list of content that it couldn't map to trusted license information. I'm pretty sure, however, that we have CQs for most/all of that content, but don't have a mapping between the content Id and corresponding CQ. I'll work through those.
In the meantime, when you do create CQs, it would be helpful if you could use the Maven id/coordinates as the name. With that, we'll have an automatic mapping.
It would helpful if the AC members could test this tool on code bases that they work with and provide feedback (issues on the GitHub repository are welcome).
I'll vent a bit myself... we've been discussing this on calls for some time and I did post about this on the mailing list with a request for assistance to develop this tool into something that can be used to save project teams time. I have stated repeatedly that I owe the community a few blog posts on this topic, but I brought the AC into the loop as far back as when we started drafting edits to the IP Policy.
Wayne