From IcedTea

Jump to: navigation, search

If you wish to make changes to this page, please first discuss them on the Discussion page or mailing list

Commit rights to the IcedTea repositories are usually given after a couple of patches have been successfully submitted, but the decision is ultimately left to the discretion of current IcedTea developers. With great power comes great responsibilities. If there is a general consensus that a contributor is not yet ready for commit rights, then they will not be given. Equally, commit rights may be rescinded if there is a general consensus that they are being repeatedly abused.

With or without commit rights, patches should first be posted to the mailing list as described below. In most cases, the contributor should then wait for a review of the patch from at least one developer before committing either by themselves or by proxy. The following cases are exempt from review:

  • Trivial fixes
    • Typos, spelling mistakes
    • Forgetting to add a required file in a previous commit
  • Commits to IcedTea6 HEAD (for legacy reasons)
  • Commits to IcedTea7 HEAD / forest prior to 2.0

For the latter two cases, we strongly recommend that reviews are requested, even though they are not required at present. In contrast, commits to any of the following require review:

  • Any release branch (IcedTea6, IcedTea7, IcedTea-Web, VisualVM Harness)
  • IcedTea7 HEAD / forest post 2.0
  • IcedTea-Web
  • VisualVM Harness

The review process should continue until all parties are happy with the patch. Unless otherwise stated by the reviewer, it should be assumed that the final version of the patch should be posted and an acknowledgement acquired before the patch is committed.

We feel reviews form an important part in improving the quality of IcedTea. Although the process may feel unnecessarily stringent at times, we feel it is an acceptable tradeoff, based on past experience of maintaining IcedTea.

Please be patient, though feel free to politely ping the list if there has been no reply in two or three working days. In most cases, it is simply the case that your patch may be have been missed or others have just not found time to review it yet. We prefer to take time and increase quality, rather than act in haste.

All developers can and are expected to help with reviewing patches, though please be explicit if you feel you lack the correct expertise to comment fully on a patch.


1 Posting Your Patch

Patches should be posted to the list as plain text attachments. Please include an explanation of the patch so it can be reviewed, and use the subject of the e-mail as appropriate to designate the project to which it applies (e.g. '[icedtea-web]') and whether you expect comments ('RFC') or not ('FYI').

IcedTea maintains a ChangeLog which should be updated as part of your commit, but should not form part of the patch. Instead, the ChangeLog should be posted in the body of the mail. This makes it easier for developers to apply your patch locally, even if there have been changes to the ChangeLog (highly likely).

The ChangeLog should take the following format and be as detailed as possible, concerning the changes made, as this serves as a record for future maintenance.

(date in YYYY-MM-DD format)  (name)  (e-mail enclosed in '<' and '>')

       * (filename):
       (change to file)

Please note that all lines except the first one should be indented by <tab> character, not by spaces, so the format is following:

(date in YYYY-MM-DD format)  (name)  (e-mail enclosed in '<' and '>')

<tab>* (filename):
<tab>(change to file)

GNU Emacs provides a mode for editing ChangeLog entries and Vim also contains autocommands for ChangeLog files (syntax highlighting + indenting rules).

It is expected that all patches have been applied and the resulting codebase built. With regard to HotSpot patches, builds should be conducted with both supported versions of HotSpot (see ReleasePolicy). We don't expect every niche option (there are many) to be tested and other developers should be aware of this, and be responsible for maintaining those which interest them.

Below, we list specific criteria which applies to a subset of patches for IcedTea.

1.1 OpenJDK Patches

Many patches to IcedTea will actually be patches to patch OpenJDK. With IcedTea6, this involves a patch which includes a further patch to be applied to the OpenJDK source at build time. With IcedTea7 onwards, patches are applied to our own forest.

In IcedTea6, patches for OpenJDK should be stored in the patches subdirectory. If the patch is a direct backport of a fix from OpenJDK7, it should be placed in patches/openjdk and named using the following format: (bug-id)-(summary).patch, where summary is a (appropriately shortened) version of the summary field from the patch. Discretion may be applied in naming the patch if the summary field is unhelpful; this is something to be discussed in the review process. Please 'do not significantly alter backported patches or add additional changes to them as the patches in patches/openjdk are used as an effective TODO list for patches to be upstreamed and will be removed when the corresponding bug ID is available upstream.

In IcedTea7, patches for OpenJDK are applied directly to our OpenJDK forest. Again, when conducting backports, use exact patches (via hg export/import) and do not mix in additional changes.

IcedTea-Web code changes/new feature should be accompanied with appropriate tests (JUnit class and/or reproducer). If no tests are added/modified, changes should be accompanied with an explanation as to why.

1.2 Security Patches

An inevitable issue with dealing with security issues is that patches have to be applied in secret and then only released post-embargo. This means that they will not undergo the same rigorous review process as normal patches. Please be accepting of this and don't flame the person who releases the security patches if something breaks as a result. Extensive testing is performed for security patches, but it will not cover niche options (Zero, Shark, CACAO, JamVM).

2 Freeze Periods

The HEAD or trunk branches are always open for business. Release branches are closed for very brief periods (hours rather than days) to allow the designated maintainer (see ReleasePolicy) to perform the release. During the freeze, the maintainer and only the maintainer is allowed to make basic commits (updating and NEWS, tagging) to perform the release.

Personal tools