Correcting Errors In General

Be looking at an IP Log for a single project (because if there are multiple projects, we can't figure out where to record the corrections)

Have the same email address for your Foundation email and your bugzilla email.

Be logged in to the Eclipse website. The login mechanism uses the Friends of Eclipse login, so when you click "login" in the bottom menu, you will be taken to the Friends of Eclipse login. You do not need to be a Friend to use this login page: use your bugzilla login.

When all of that is true, extra correction form fields will appear on the page along with a "Make These Corrections" submit button at the bottom. Like any html form, fill it out and press the button to save the corrections.

Third-Party Code

The Third-Party Code section of the IP Log shows the approved Contribution Questionnaires from ipzilla. The CQs listed in this table are those that are:

state=approved, or

RESOLVED/FIXED or CLOSED/FIXED (regardless of state)

Correcting Errors

Missing CQ. If a CQ is missing from this list, check its status, resolution, and state: make sure that they match one of the above cases. If not, contact Eclipse Legal.

Extra CQ. If a CQ is listed but does not belong to this project, then contact Eclipse Legal to have the ipzilla database corrected.

Missing or Incorrect License. If a CQ is missing the license information, contact Eclipse Legal to have the correct license information added to the database.

Unused Third-Party Code

If the project has CQs that approve the use of certain third-party code, but that code is not
currently being used for this release, it is listed in the separate Unused Third-Party Code table.
The CQs listed in this table are those that have one of the following keywords:

obsolete - this third-party code was used in previous releases, but it has been superseded or is obsolete and thus is no longer being used in this release and there is no plan to use it in a future release.

unused - the project requested approval of this third-party code in anticipation of using this code, but at this time the project is not using this code in this release. The project reserves the right to use the code in a future release.

withdrawn - the project requested approval of this third-code code but subsequent to receiving approval and prior to using the code, decided not to use said code. This code has not been used in any release, is not being used in this release, and there is no plan to use it in a future release.

Correcting Errors

CQ Is Being Used. If a CQ is listed as unused but is actually being used, contact Eclipse Legal to have the keywords on CQ removed/changed.

CQ Should Be Unused. If a CQ should be in the unused list instead of one of the other lists, contact Eclipse Legal to have the appropriate keyword added.

Works With and Pre-Req Dependencies

If the project has Works With, Pre-Req, or Exempt Pre-Req Dependencies, these will be listed in a separate table. These are also Contribution Questionnaires from ipzilla. These CQs are:

state=exempt_prereq

state=prereq

state=workswith

Correcting Errors

Missing Pre-Req. If an pre-req is missing from this list, first check that to see if there is a CQ for it. If there is no CQ, submit one (using the portal). If there is a CQ, check that its state is "workswith", "prereq", or "exempt_prereq" - if not, contact Eclipse Legal.

Pending Contribution Questionnaires

If the project has any pending and not yet approved or rejected Contribution Questionnaires, these are listed in a separate table. These represent potential IP issues and thus must be considered carefully during a Release Review.

Correcting Errors

Unneeded CQ. If the code represented by a pending CQ is no longer needed by the project, use ipzilla to withdraw the CQ.

Committers

The Committers section of the IP Log uses two information sources to generate the two lists:

The list of all committers who have committed code to any of the source repositories from the Commits Explorer. This is the basis of the "Past and Present" list. The commits explorer list is driven by the project meta data source repository item(s).

The list of all past and present committers from the Foundation's internal database of committers and projects. Committers here but not in in the "Past and Present" list are put on the "Never Active" list.

Correcting Errors

Should Be Active. If a committer is listed as "Never Active" but should be listed in the active "Past and Present" table, then you should check the project meta data via the portal - there are directories missing from the "source repository" item. If the project meta data is correct, you can use the "make active" checkbox to submit a correction.

-or-

Question Mark. If a "xxx???" person is listed as a committer, that means that the unix login "xxx" committed code to the source code repository, but there is no record of "xxx" as having been a committer on the project. This is a potential IP cleanliness problem, so contact the EMO to resolve it (do not just use the "exclude" checkbox correction without understanding why the data is incorrect).

Extra Committer. If someone is listed as a "Never Active" committer, but you know that they were never even a committer at all, then there is an incorrect record in the Foundation database - contact the EMO. On the other hand, if someone is listed as a "Past and Present" committer, but you know that they were never a committer, then something larger is awry because there are source code check-ins by that person. Use the commits explorer to determine what check-ins they made and contact the EMO if there are any errors. In both cases, after resolving the issue with the EMO, use the "exclude" checkbox to correct the IP log.

Missing Committer. If someone who is/was a committer with a unix account and is missing from both the "Past and Present" and the "Never Active" tables, then the first thing to check is the "source repository" project meta data item via the portal - usually the problem is one or more unlisted source directories.

Contributors

The Contributors section of the IP Log uses one information source: bugzilla (driven by the project meta data bugzilla item(s))

all people who were not committers when they attached:

an attachment to a bug

and the attachment is flagged with "iplog+"

and is attached to a RESOLVED/FIXED, VERIFIED/FIXED, or CLOSED/FIXED bug

For example, see bug 69671; the contribution is in a flagged attachment so it shows up in the CDT IP Log.

all people who were not committers when they commented on a bug:

that is flagged with "iplog+"

and RESOLVED/FIXED, VERIFIED/FIXED, or CLOSED/FIXED

For example, see bug 190154 in which the contribution is in comments #0 and #11. Then see the BIRT IP Log. Note that comments #1-10 and #12 were excluded by the project lead using the exceptions mechanism.

In plain English, this means there are two different ways to mark a contribution in bugzilla. If the contribution is an attachment to a bug such as a patch, the attachment itself should be marked with the iplog+ flag. If the contribution is in the form of a comment in the bug, then the iplog+ flag should be set on the bug itself. Since this will mark all non-committers who commented on the bug as contributors, you typically then need to use the exceptions mechanism to exclude comments that are not contributions. Typically these two mechanisms are mutually exclusive: if the contribution is an attachment, you do not also need to set iplog+ flag on the bug itself (unless the bug also has other contributions in the form of comments).

Correcting Errors

No Name. If the contributor record for person X shows an email address but no name, then person X has not entered a name in bugzilla. Have X go to bugzilla Preferences and enter their correct name.

Error Messages. If the tentative IP log shows errors (red error messages) in product name or component name, then the team should check their project meta data via the portal - the product name and (optional) component names must be an exact match with bugzilla, capitalization and all.

Extra Contributor. If a person (person X) is listed as a Contributor but the team knows that their patch was never used/is not currently in use, there are three solutions: (1; preferred) remove the "iplog+" flag from the bugzilla attachment, or (2) use "exclude" correction to modify the IP log (if contributor status is based on a comment instead of an attachment).

-or-

Missing Contributor. If person X should be listed as a Contributor but is not, then be sure that person X has attached a patch to a fixed bug and that patch is flagged with "iplog+". All external code contributions should come through bugzilla patches, so if a code contribution first comes through email, the contribution must also add a patch. Note that person X must add the patch because if person Y adds the patch for person X, then person Y will be listed as the contributor.

Committer is Listed. If committer X is listed as a Contributor, check the following:

First, a committer can be listed as a contributor if he or she was a contributor, contributed some code, and then later became a committer. He/she will be listed as a contributor for the patches he/she submitted before becoming a committer.

Check that person X's email address in bugzilla matches any one of their email addresses on file with the Foundation. Have person X use the the portal to check to verify their email addresses. If their bugzilla address does not match the Foundation committer records, we have no way to associate their bugzilla records with their committer status.

Keeping the IP Log Current

Keeping the automatic IP log current is fairly simple:

Make sure that all third-party code and dependencies are filed as CQs.

If a non-committer patch is accepted, mark it with the iplog+ flag.

If a non-committer bug without a patch is accepted, mark the whole bug with the iplog+ flag and then go to the automatic IP log to exclude the non-contribution comments.

Use the portal to deactivate inactive committers

Choosing the Set of Projects

The simplest case is an IP Log for a single project. However, many project teams work together to create a unified release across a set of project. In this case, the IP Log must also be an aggregated/unified IP Log across the same set of projects. At the bottom left of the IP Log page is a "adjust the set of projects" link. That link leads to the selector page. Use the checkboxes to select a set of projects and generate a unified IP Log for all of those projects.

Submitting the IP Log to Eclipse Legal

Single or unified-multi-project, either way the IP Log can be submitted to Eclipse Legal for review using the link at bottom center of the page. Click that, fill out the reason, and voila, the a frozen copy of the log is sent to Legal.

You must send your IP log to Eclipse Legal at least three weeks in advance of your scheduled Release Review to guarantee your review date. Sending your IP log in late will jeopardize your review date due to Eclipse Legal's workload.

Problems with the IP Log?

If you're having trouble updating the IP log or if the IP log is not showing enough information, please file a bug (use this link) and we'll work hard to make things right.

This page is moderated by Anne Jacko and Bjorn Freeman-Benson (Eclipse Foundation)