Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "MicroProfile/3rdPartyDependencyProcess"

(Created page with "== Contribution Questionnaires (CQ) == All software contributed to or used by an Eclipse project needs to be properly [https://www.google.com/url?q=https%3A%2F%2Feclipse.org%...")
 
m (Kwsutter.gmail.com moved page 3rdPartyDependencyProcess to MicroProfile/3rdPartyDependencyProcess: Move to proper wiki)
(No difference)

Revision as of 16:58, 29 June 2017

Contribution Questionnaires (CQ)

All software contributed to or used by an Eclipse project needs to be properly vetted by the Eclipse Intellectual Property Office (IPO). This vetting is initiated by a Contribution Questionnaire. Once a Contribution Questionnaire is created, it is turned into an IPZilla bug tracker. All interaction with the IPO is then done via the associated bug tracker.

As an example, our Initial Contribution to Eclipse was tracked via this CQ.

Source Originality

Whenever a Release is created for one of our components or the overall Microprofile project, an IP review is required. This process should cover any updates required for our Initial Contribution vetting. That is, as a component is developed, all of us need to keep an eye on the source that is being integrated into our product to ensure we understand it's origin and license.

3rd Party Open Source

Many of the open-source packages that MicroProfile utilizes are already vetted and approved by Eclipse (ie. JSR APIs, Apache Commons libraries, etc). In this case, we can piggy-back on top of the work that has already been done. But, a CQ is still required. When creating a CQ for 3rd Party content, you enter the name and version of the software in use. Most times, the software is registered under the Maven artifactId (ie. commons-io or commons-lang3). Once you start typing, Eclipse will be searching for a match. Be creative. If you can't find a match, then you'll have to go through the full CQ process. A piggy-back CQ is very easy to process.

Build and Test Dependencies

All of the build and test dependencies that we use is a special case for the 3rd Party open source. Instead of creating individual CQs for every piece of build and test software (ie. arquillian, maven, hamcrest, etc), we can group the request into a single CQ. This link has a good description of this process.

Since the MicroProfile project is developing individual components (config, fault tolerance, health metrics, etc), the initial set of Build and Test CQs were created on a per-component basis. Here is an example Build and Test CQ.

Type A vs Type B Due Diligence

This CQ Section of our process is a synopsis of a much longer discussion that happened in our Google group and the associated CQs. We learned a great deal during this initial IP vetting process. One of the key items is the use of Type A vs Type B Due Diligence. For our initial efforts, Type A (licensing review) is much easier to process, especially for our preliminary component releases. Type B is a much more thorough review of the material. Once we get through these initial reviews with Type A, we will likely change to Type B. Or, maybe we do Type A reviews for the individual components (config, fault tolerance, etc) and use the Type B review for the MicroProfile project releases. Still working through the details on this...

A flowchart, if you are interested...

Eclipse also provides this flowchart as a guide to help find your way through their IP process... It's not for the faint of heart, but it did help with deciphering some of the ins and outs of the process.

Back to the top