IPzilla

What is this?

• This is a proposal for providing committer access to the status on their contribution questionnaires.

Please review and comment.

Motivation

There is a strong desire to make it simpler and easier for committers to do two things:

• track the status of their contribution questionnaires (CQs); and
• discover what third-party components have been previously reviewed and approved by the EMO.

It also must be recognized that IP due diligence requires some discretion due to the legalistic nature of the conversations and the sensitivity of the topics being discussed.

Proposal

We would like to propose that we use Bugzilla as the primary mechanism for fostering the visibility and dialogue around the CQs. This would be a separate Bugzilla instance ("IPzilla") which would be reachable by all committers via the "Committer Tools" page. In other words, IPzilla would not be public, and a committer userid and password would be required for access. Logging into IPzilla would require a committer userid and password as well. The expectation is that people would add themselves to the cc list for CQs that they are interested in.

For the sake of consistency and to avoid bogus CQ's, access to the CQ form would also be moved to the Committer Tools page.

When a CQ is created, the revised script would create an IPzilla entry. In the email response sent to the creator the IPzilla number with a link would be included. All of the content of the initial CQ would be included as the initial definition of the bug. ALL interactions regarding the CQ would then take place via IPzilla. The only exception would be where the Foundation's counsel (e.g. Janet Campbell) decides that a conversation needs to be privileged, in which case privileged conversations may take place via email or phone call.

Note that IPzilla would have a larger permitted attachment size than the current Eclipse Bugzilla to hopefully avoid difficulties in attaching the code.

IPzilla would use a different set of resolutions than Bugzilla (see this page for the Bugzilla defaults). This needs to be refined, but an initial resolution list could be {Approved for all projects, Approved for single project, Denied, Withdrawn}. We may also want to use a different list for the status field. An example list could be {New, Under Review, Closed, Reopened}.

Workflow

• The committer who wishes to commit the contribution into Eclipse CVS gets PMC approval for such contribution, as per the relevant project charter.
• A committer completes and submits a CQ form on the "Committer Tools" page. (Note that currently a CQ can contain multiple third party items per CQ.)
• The committer and the EMO will be sent a confirming email which includes the IPzilla numbers, and a link to the IPzilla bugs for each third party item in the CQ.
• Access to the bug will be via the "Committer Tools" page which will include a link to IPzilla, or by using the link provided.
• The committer will go to the bug and attach the source code for the 3rd party code for the bug. IPzilla will be set with an attachment size limit of 20MB. Code for contributions larger than that will be done via a TBD exception mechanism. It is very important that the code attached be the code that the committer is intending to distribute from the Eclipse project. So, for example, if only a few JARs from a complete Apache distribution are going to be used, then only include the code for those JARs. (This is to prevent the situation where the IP due diligence team wastes time reviewing code which the project has no intention of distributing.)
• An EMO staff member will be assigned ownership of the bug and will be responsible for completing the review.
• The EMO reviewer who will be responsible for the review will review the bug for completeness. If any additional information is required, information requests to the the committer will be made via the bug. Once the reviewer is satisfied that all the information has been provided, the bug status will be changed to "Under Review".
• The EMO will use its internal tools to review the code. Again, all information requests to the the committer will be made via the bug.
• The EMO will end its review by closing the bug and either marking the bug as Approved, Denied, or at the request of the originator, Withdrawn.