Index: xdocs/contributors.xml =================================================================== --- xdocs/contributors.xml (revision 485548) +++ xdocs/contributors.xml (working copy) @@ -21,54 +21,220 @@ - Apache Harmony Committers + Apache Harmony Community Harmony Documentation Team -
+

- If you would like to contribute to Harmony, please see the - roadmap list to find areas where you can contribute. + Welcome to the Apache Harmony community! Everyone interested in the project and + aimed at making an impact in its development, can become a member of our + community. + If you would like to contribute to Harmony, please see the + roadmap list to find areas where you can contribute. If there is nothing in there that suits your interest, but you still have ideas, please feel free to suggest them on - the mailing list. + the mailing list. For more information on + committers, contributors and their contributions, refer to the + Contribution Policy page. To figure out + how to resolve conflicts through voting, who is able to vote and make final + decisions, see the Voting page.

+

+ In the community you should distinguish among the following concepts: +

    +
  • Contributors
  • +
  • + Project Management Committee +
  • +
  • Committers
  • - - - - - - - - - - - - - - - - - - - - - -
    NameOrganizationStatus
    Nathan BeyerIndependentA
    Archie CobbsAwarixA
    Oliver DeakinIBM UKA
    Tim EllisonIBM UKA
    George HarleyIBM UKA
    Mark HindessIBM UKA
    (Richard)Yanxuan LiangIBM CNA
    Mikhail LoenkoIntelA
    Dan LydickIndependentA
    Geir Magnusson Jr.IntelA
    Stepan MishuraIntelA
    Nadya MorozovaIntelA
    Alexey PetrenkoIntelA
    Gregory ShimanskyIntelA
    David Tanzer?A
    Alexey VarlamovIntel RussiaA
    Weldon WashburnIntelA
    (Paulex)Pu YangIBM CNA
    Alexei ZakharovIntelA
    +
+

+ +

+ Apache Harmony Contributors are all the volunteers contributing time, + code, documentation, or resources to the Apache Harmony Project. A + contributor that makes sustained, welcome contributions to the project + for over six months is usually invited to become a Committer, though + the exact timing of such invitations depends on many factors. +

+
+ +

The Project Management Committee (PMC) is a group of volunteers + responsible for managing the Apache Harmony Project in the following way: +

    +
  • Decide what is distributed as products of the Project;
  • +
  • Maintain the Project's shared resources;
  • +
  • Speak on behalf of the Project;
  • +
  • Resolve license disputes regarding Apache products;
  • +
  • Nominate new PMC members or committers;
  • +
  • Establish these guidelines.
  • +
+

+

Policy: +

  • Membership in the Apache PMC is by invitation only and must + be approved by consensus of the active Apache PMC members;
  • +
  • A PMC member is considered inactive by their own declaration or by + not contributing in any form to the project for over six months;
  • +
  • An inactive member can become active again by reversing whichever + condition made them inactive, that is by reversing their + earlier declaration or by once again contributing toward the + project's work;
  • +
  • Membership can be revoked by a unanimous vote of + all the active PMC members other than the member in question. +

+ +

Goals: +

    +
  • Every committer willing and interested in the day-to-day + oversight and management of the project will be invited at the right time + to join the PMC;
  • +
  • 100% of the committers on the PMC.

+ + +
+ +

Apache Harmony Committers are a group of volunteers + responsible for the technical aspects of the Apache Harmony + Project. This group has write access to the appropriate source + repositories and these volunteers may cast binding votes on + any technical discussion.

+

Policy: +

  • Membership as a Committer is by invitation only and must + be approved by consensus of the active Apache PMC members.
  • +
  • A Committer is considered inactive by their own declaration or by + not contributing in any form to the project for over six months.
  • +
  • An inactive member can become active again by reversing whichever + condition made them inactive, that is by reversing their + earlier declaration or by once again contributing toward the + project's work.
  • +
  • Membership can be revoked by a unanimous vote of + all the active PMC members (except the member in question if they + are a PMC member).
+

+

Here is the list of present committers:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameOrganizationStatus
Nathan BeyerIndependentA
Archie CobbsAwarixA
Oliver DeakinIBM UKA
Tim EllisonIBM UKA
George HarleyIBM UKA
Mark HindessIBM UKA
(Richard)Yanxuan LiangIBM CNA
Mikhail LoenkoIntelA
Dan LydickIndependentA
Geir Magnusson Jr.IntelA
Stepan MishuraIntelA
Nadya MorozovaIntelA
Alexey PetrenkoIntelA
Gregory ShimanskyIntelA
David Tanzer?A
Alexey VarlamovIntel RussiaA
Weldon WashburnIntelA
(Paulex)Pu YangIBM CNA
Alexei ZakharovIntelA
+

- Status : + Status:

    -
  • R = regular ASF committer status
  • -
  • A = Authorized Contributor - for listed enhanced IP rules modules
  • +
  • R = regular ASF committer status
  • +
  • + A = Authorized Contributor + for listed enhanced IP rules modules +
+
+ +
Index: xdocs/get-involved.xml =================================================================== --- xdocs/get-involved.xml (revision 485548) +++ xdocs/get-involved.xml (working copy) @@ -83,71 +83,108 @@
-

+

One of the best ways to get involved in the Harmony project is to - create patches or additions and contribute them. All contributions - should be made via a new entry in our project + create patches or additions and contribute them. When you propose + a specific change to the software for discussion or voting on the + mailing list, you should present in the form of input to the patch + command. + All contributions should be made via a new entry in our project JIRA.

-

- Here are some basic guidelines and suggestions : -

    -
  • - Once you have completed your changes, please be sure - to test your changes very well. -
  • -
  • - If you are offering a code addition or change, be sure that - the codebase builds cleanly and the full test suite passes - before submitting. Patches that break the - build or break the code will be rejected. -
  • -
  • - If you are offering a change to documentation or the website, - please review the generated output and be sure that it is as you expect. -
  • -
  • - If you are offering a fix to a bug, please provide a testcase and - instructions to help us duplicate the bug, and then test that the bug - is fixed. We will add the testcase to our testsuite. -
  • -
  • - When offering something new, please include the entire file - that you are contributing. -
  • -
  • - When you are offering a change to something that already exists - in the project SVN repository, please submit a patch as outlined below. -
  • -
-

+ +
    -

    - Once you are sure you have tested/reviewed your changes, open a - new JIRA entry. Clearly describe the patch or enhancement, and - provide details, such as how to re-create if a bug, why the - change or enhancement is useful, etc. Then, attach all materials - to the JIRA entry via "Attach File". Please be sure to select - "Grant license to ASF for inclusion in ASF works...". Any patch - without this grant will be rejected. -

    +
  • + Once you have completed your changes, please be sure + to test your changes very well. +
  • +
  • + If you are offering a code addition or change, be sure that + the codebase builds cleanly and the full test suite passes + before submitting. Patches that break the + build or break the code will be rejected. +
  • +
  • + If you are offering a change to documentation or the website, + review the generated output and be sure that it is as you expect. +
  • +
  • + If you are offering a fix to a bug, please provide a testcase and + instructions to help us duplicate the bug, and then test that the bug + is fixed. We will add the testcase to our testsuite. +
  • +
  • + When offering something new, include the entire file + that you are contributing. +
  • +
  • + When you are offering a change to something that already exists + in the project SVN repository, submit a patch as outlined below. +
  • +
+
+ -

- Please use the subversion 'diff' utility to create a patch as follows : - -

-    svn diff file.java > file.patch
-  
- - where 'file' is the filename that you have changed. This will produce a - nice patch file that can be added to the JIRA, which makes it easy for - the project committers to review and possibly accept your patch. -

+

+ Once you are sure you have tested/reviewed your changes, do the following: +

+
    +
  • Open a new + JIRA entry.
  • +
  • Clearly describe the patch or enhancement, and + provide details, such as how to re-create if a bug, why the + change or enhancement is useful, etc.
  • +
  • Use the subversion diff utility to create a patch as follows: +
    svn diff file.java > file.patch
    + where file is the filename that you have changed. This will produce a + nice patch file that can be added to the + JIRA, which makes it easy for + the project committers to review and possibly accept your patch. +
  • +
  • Attach all materials to the JIRA entry via Attach File.
  • +
  • Be sure to select Grant license to ASF for inclusion in ASF works.... + Any patch without this grant will be rejected.
  • + +
- +
+ + If you create a patch to propose any software changes, it should + meeting the following requirements: +
    +
  1. + On the mailing list, start the message subject with + [PATCH] and provide a distinctive one-line summary + corresponding to the action item for that patch. +
  2. +
  3. + Create the patch using the diff -u command from the + original software file(s) to the modified software file(s). +

    Example

    +
    diff -u http_main.c.orig http_main.c >> patchfile.txt
    +

    or

    +
    cvs diff -u http_main.c >> patchfile.txt
    +
  4. +
  5. + Concatenate all patches necessary to address an action item within a + single patch message. If later modification of the patch + proves necessary, you should post the entire new patch, not just + the difference between two patches. +
  6. + +
  7. + The completed patchfile should produce no errors or prompts when you use + the following command in the target repository: +
    patch -s < patchfile
    + +
  8. +
+
+
Index: xdocs/issue_resolution_guideline.xml =================================================================== --- xdocs/issue_resolution_guideline.xml (revision 485548) +++ xdocs/issue_resolution_guideline.xml (working copy) @@ -1,116 +1,257 @@ - - - - - - - Good Issue Resolution Guideline - Harmony Documentation Team - - - - -
-

- This guideline provides step-by-step instructions on reporting, resolving - and closing issues. If you cannot do one of the steps, then write a comment to the issue. -

- - - -
    -
  1. State the expected behavior and the - actual behavior of Harmony code explicitly. Use links to - specifications, references, etc.
  2. -
  3. Create a test case as small as possible. A patch - to test is highly appreciated.
  4. -
  5. Provide maximum information about steps necessary to reproduce the bug. - If a patch for the test has not been supplied, provide as much - diagnostic information about the failure as possible: stack trace, - failure output, expected output, etc.
  6. -
  7. Use issue links if applicable.
  8. -
  9. Check the issue resolution, when it is committed. Add a comment.
  10. -
- -
- - -

To resolve an issue, define its type first.

-

- If the issue is a non-bug difference, not a bug or invalid, - you should do the following:

-
    -
  1. Discuss the issue on the - developer mailing list.
  2. -
  3. Add a link to the discussion thread as a comment to the issue.
  4. -
- -

If the issue is a bug, you should do the following:

: -
    -
  1. - Notify the community that you started investigation by adding - a comment to the issue and send a message to the - developer mailing list. - If you cannot create a patch, add another comment with your - investigation results.
  2. -
  3. If reporter did not provide a patch to test: -
      -
    • Try to create a patch to test.
    • -
    • If you cannot create a patch, write a comment about it.
    • -
    -
  4. -
  5. - Create a patch to fix the issue. If you have any questions, - discuss them on the developer mailing list. - Add a link to the discussion as a comment.
  6. -
  7. All pacthes, such as tests and fixes, should be relative to the directory where - the main build.xml is:
    - https://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk,
    - or to the module root directory.
  8. -
  9. Test and fix patches should be in different files.
  10. -
  11. If the patch requires adding, removing or moving some files in the repository, - provide the appropriate script.
  12. -
  13. Check that all unit tests pass.
  14. -
  15. If the issue is application-oriented, check the application.
  16. -
  17. Use issue links if applicable.
  18. -
- -
- - -

To close an issue, define its type first.

-

- If the issue is a non-bug difference, not a bug or invalid, you should close the issue.

-

If the issue is a bug, you should do the following:

-
    -
  1. If a patch to test is available, apply it.
  2. -
  3. Check that the test fails.
  4. -
  5. Apply the fix for the issue.
  6. -
  7. Check that test succeeds now.
  8. -
  9. Make sure that all unit tests pass.
  10. -
  11. For application-oriented issues, check the application.
  12. -
  13. If there are any problems on previous steps, post a comment to - JIRA and let "resolution provider" resolve them.
  14. -
  15. Make sure that the issue reporter is happy with the resolution.
  16. -
  17. Add revision info into the JIRA issue.
  18. -
- -
-
- -
+ + + + + + + + + When an Issue Occurs + Harmony Documentation Team + + + + + +
+

This page describes types of action items, such as long term plans, + short term plans, a release plan, a release testing, + showstoppers, product changes. The page provides description + of general rules for commiters, information on reporting, resolving and closing issues. + For information on the voting procedure, refer to the + Voting page. +

+ +

Types of Action Items +
+ General Rules for Commiters +
+ Good Issue Resolution Guideline +

+
+

+ Reporting Issues +
+ + Resolving Issues +
+ Closing Issues +

+
+
+
+
+
Long Term Plans
+
Long term plans are simply announcements that group members + are working on particular issues related to the Apache software. + These are not voted on, + but group members who do not agree with a particular plan, + or think an alternate plan would be better, are obligated to + inform the group of their feelings. In general, it is always + better to hear about alternate plans prior to + spending time on less adequate solutions. +
+ +
Short Term Plans
+
Short term plans are announcements that a developer is working on + a particular set of documentation or code files, with the implication + that other developers should avoid them or try to coordinate their + changes. This is a good way to proactively avoid conflict and + possible duplication of work. +
+ +
Release Plan
+
A release plan is used to keep all the developers aware of when a + release is desired, who will be the release manager, when the + repository will be frozen in order to create the release, and + assorted other trivia to keep us from tripping over ourselves + during the final moments. Lazy majority decides each issue in + the release plan. +
+ +
Release Testing
+
After a new release is built, colloquially termed a tarball, it + must be tested before being released to the public. Majority + approval is required before the tarball can be publically released. +
+ +
Showstoppers
+
Showstoppers are issues that require a fix be in place + before the next public release. +
+ +
Product Changes
+
Changes to the Apache products, including code and documentation, + will appear as action items under several categories corresponding + to the change status: +
+
concept/plan
+
An idea or plan for a change. Votes are being requested + early so as to uncover conflicts before too much work is done. +
+
proposed patch
+
A specific set of changes to the current product in the form + of input to the patch command (a diff output). +
+
committed change
+
A one-line summary of a change that has been committed to the + repository since the last public release. +
+
+
+
+
+
+
  • Review-then-commit ideas.
  • +
  • Commit-then-review patches. With a commit-then-review process, + we trust that the developer doing the commit has a high degree of + confidence in the change.
  • +
  • Discuss doubtful changes, new features, and large-scale + overhauls before committing them to a repository. + Any major change must receive consensus approval on the mailing list before + being committed.
  • +
  • Notify the mailing list, when you have + an idea for a new feature or major change to propose for the product. +
    • The distributed nature of the +Apache project requires an advance notice of 48 hours in order to properly +review a major change - consensus approval of either the concept or a +specific patch is required before the change can be committed.
    • +
    • A committer might veto the concept (with an adequate explanation), but later +rescind that veto if a specific patch satisfies their objections. +No advance notice is required to commit singular bug fixes.
    • +
    • + A committed change must be reversed, if it is vetoed by one of the + voting committers and the veto conditions cannot be immediately satisfied by + the equivalent of a "bug fix" commit. The veto must be rescinded before + the change can be included in any public release. +
    • +
    +
  • +
  • Commit related changes as a group, or very closely together.
  • +
  • Half-completed projects should not be committed unless +doing so is necessary to pass the baton to another developer who has +agreed to complete the project in short order.
  • +
  • All code changes must be successfully compiled on the + developer's platform before being committed.
  • +
  • Follow the Apache Harmony procedure for any third-party code +or documentation they commit to the repository. All software committed +to the repository must be covered by the Apache LICENSE or contain a +copyright and license that allows redistribution under the same conditions +as the Apache LICENSE.
  • +
  • The current source code tree should be capable of complete compilation +at all times. However, it is sometimes impossible for a developer on +one platform to avoid breaking some other platform when a change is +committed, particularly when completing the change requires access to +a special development tool on that other platform. If it is anticipated +that a given change will break some other platform, the committer must +indicate that in the commit log.
  • +
+
+
+

+ This guideline provides step-by-step instructions on reporting, resolving + and closing issues. If you cannot do one of the steps, then write a comment to the issue. +

+ +
    +
  1. + State the expected behavior and the + actual behavior of Harmony code explicitly. Use links to + specifications, references, etc. +
  2. +
  3. + Create a test case as small as possible. A patch + to test is highly appreciated. +
  4. +
  5. + Provide maximum information about steps necessary to reproduce the bug. + If a patch for the test has not been supplied, provide as much + diagnostic information about the failure as possible: stack trace, + failure output, expected output, etc. +
  6. +
  7. Use issue links if applicable.
  8. +
  9. Check the issue resolution, when it is committed. Add a comment.
  10. +
+ +
+ +

To resolve an issue, define its type first.

+

+ If the issue is a non-bug difference, not a bug or invalid, + you should do the following:

+
    +
  1. Discuss the issue on the + developer mailing list.
  2. +
  3. Add a link to the discussion thread as a comment to the issue.
  4. +
+ +

If the issue is a bug, you should do the following:

: +
    +
  1. + Notify the community that you started investigation by adding + a comment to the issue and send a message to the + developer mailing list. + If you cannot create a patch, add another comment with your + investigation results.
  2. +
  3. If reporter did not provide a patch to test: +
      +
    • Try to create a patch to test.
    • +
    • If you cannot create a patch, write a comment about it.
    • +
    +
  4. +
  5. + Create a patch to fix the issue. If you have any questions, + discuss them on the developer mailing list. + Add a link to the discussion as a comment.
  6. +
  7. All pacthes, such as tests and fixes, should be relative to the directory where + the main build.xml is:
    + https://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk,
    + or to the module root directory.
  8. +
  9. Test and fix patches should be in different files.
  10. +
  11. If the patch requires adding, removing or moving some files in the repository, + provide the appropriate script.
  12. +
  13. Check that all unit tests pass.
  14. +
  15. If the issue is application-oriented, check the application.
  16. +
  17. Use issue links if applicable.
  18. +
+ +
+ + + +

To close an issue, define its type first.

+

+ If the issue is a non-bug difference, not a bug or invalid, you should close the issue.

+

If the issue is a bug, you should do the following:

+
    +
  1. If a patch to test is available, apply it.
  2. +
  3. Check that the test fails.
  4. +
  5. Apply the fix for the issue.
  6. +
  7. Check that test succeeds now.
  8. +
  9. Make sure that all unit tests pass.
  10. +
  11. For application-oriented issues, check the application.
  12. +
  13. If there are any problems on previous steps, post a comment to + JIRA and let "resolution provider" resolve them.
  14. +
  15. Make sure that the issue reporter is happy with the resolution.
  16. +
  17. Add revision info into the JIRA issue.
  18. +
+ +
+
+ +
Index: xdocs/mailing.xml =================================================================== --- xdocs/mailing.xml (revision 485548) +++ xdocs/mailing.xml (working copy) @@ -26,135 +26,116 @@
- +

You are welcome to share all your ideas, ask questions and discuss plans + on the Apache Harmony mailing lists!

+

+ The Apache Harmony mailing lists operate under the following terms : +

-Apache Harmony mailing lists operate under the following terms : -

- -
-This forum has been created for public communication about projects -of The Apache Software Foundation (the "Foundation"), a Delaware -nonprofit corporation classified as a public charity under 501(c)(3). -All communication intentionally submitted to the Foundation on this -forum is considered a Contribution to the Foundation unless otherwise -noted in the communication. The terms and conditions that apply to -your Contributions are defined by either a contributor license -agreement (CLA) signed by you and/or your employer or, if no such CLA -is on file at the Foundation, by the terms and conditions of -Contributions as defined by the Apache License, Version 2.0. -
-> - -

-Further : -

- -
-
    -
  • -If you do not wish your post to be a Contribution, we would prefer that you do not post it. However, in the -event that you do, please mark as "NOT A CONTRIBUTION" at the top of the posting. +There are currently three publicly available mailing lists for Harmony: +
    • + Developer Mailing List - dev@harmony.apache.org
    • -
    • -Do not post any code that is not your original work, or code that you do not have -clear authorization to contribute. +
    • Source Control Mailing List - commits@harmony.apache.org
    • -
    • -Do not engage in detailed discussion of any implementation that you have been exposed -to unless such implementation is available to everyone under an open source license or is -your own implementation. -
    • -
    • -Under no circumstances will any committer accept code for inclusion in our SVN -repository contributed on the mailing list unless -it is from an -Authorized Contributor. -
    • -
    -
-

-There are currently three publicly available mailing lists for Harmony : +

  • PMC Private Mailing List - private@harmony.apache.org +
  • + - -

    The developer mailing list is used by the developers to discuss -plans, make decisions, vote on technical issues, etc. This -list has a higher volume, though some conversations take place on - IRC as -well.

    - +

    + The developer mailing list is used by the contributors + to discuss plans, make decisions, vote on technical issues, etc. Subscription to + the list is open, but only subscribers can post directly to the list. This + list has a higher volume, though some conversations take place on + IRC as + well. +

    + -

    - Please note that at this time, we are keeping all developer traffic on one list, - for classlibrary, virtual machine, doc, site and tool development, in order to - help build one homogeneous community. It is expected that at some point in the - near future, we'll be splitting off into technical domains. -

    -

    - In order to help people sort and make sense of the traffic, please prefix your - subject line with an appropriate token : -

    +

    Note

    +

    + Now we are keeping all developer traffic on one list, + for classlibrary, virtual machine, doc, site and tool development, in order to + help build one homogeneous community. It is expected that at some point in the + near future, we will be splitting off into technical domains. +

    +

    + To help people sort and make sense of the traffic, please prefix your + subject line with an appropriate token: +

      -
    • - [general] - for things of general interest -
    • -
    • - [announce] - announcements -
    • -
    • - [legal] - discussion about legal issues -
    • -
    • - [classlib][module] - for classlibrary-related - issues (and you can optionally specify the specific module) -
    • -
    • - [drlvm][module] - for DRLVM-related - issues (and you can optionally specify the specific module) -
    • -
    • - [jchevm][module] - for jchevm-related - issues (and you can optionally specify the specific module) -
    • -
    • - [bootvm][module] - for bootvm-related - issues (and you can optionally specify the specific module) -
    • -
    • - [doc] - for documentation-related issues -
    • -
    • - [tools] - for tools-related issues -
    • -
    • - [testing] or [qa] - for tools-related issues -
    • +
    • + [general] - for things of general interest +
    • +
    • + [announce] - announcements +
    • +
    • + [legal] - discussion about legal issues +
    • +
    • + [classlib][module] - for classlibrary-related + issues (and you can optionally specify the specific module) +
    • +
    • + [drlvm][module] - for DRLVM-related + issues (and you can optionally specify the specific module) +
    • +
    • + [jchevm][module] - for jchevm-related + issues (and you can optionally specify the specific module) +
    • +
    • + [bootvm][module] - for bootvm-related + issues (and you can optionally specify the specific module) +
    • +
    • + [doc] - for documentation-related issues +
    • +
    • + [tools] - for tools-related issues +
    • +
    • + [testing] or [qa] - for tools-related issues +

    - Simply add the token to the start of your subject line. For example : -

    + Simply add the token to the start of your subject line. For example : +

    - To : dev@harmony.apache.org - From : harmony_user@openjava.org - Subject : [classlib][io] Problem with java.io.OutputSocket + To : dev@harmony.apache.org + From : harmony_user@openjava.org + Subject : [classlib][io] Problem with java.io.OutputSocket - .... + .... -
    +
    - - -

    This list receives notifications (with diffs) every time a change is -committed to the Harmony source tree. It also receives change notices -for changes to the Harmony Wiki and whenever issues are added to or + + +

    All of the Apache projects are maintained in shared information + repositories using SVN. Only some of the Apache developers, the committers, have + write access to these repositories; everyone has read access via + anonymous SVN.
    This list receives notifications (with diffs) + every time a change is committed to the Harmony source tree. It also receives + change notices for changes to the Harmony Wiki and whenever issues are added to or updated in our JIRA issue tracking system.

      @@ -166,11 +147,12 @@ - + +

      The Apache Harmony PMC's private mailing list for discussion of issues + that are inappropriate for public discussion, such as legal, personal, + or security issues prior to a published fix. Subscription to the list + is only open to Apache Harmony PMC members.

      -

      The Harmony PMC has a mailing list to resolve any administrative issues, -This list is limited to PMC members (most committers on the project).

      -
    Index: xdocs/sitemap.xml =================================================================== --- xdocs/sitemap.xml (revision 0) +++ xdocs/sitemap.xml (revision 0) @@ -0,0 +1,502 @@ + + + + + + + +Site Map +Harmony Documentation Team + + + +
    +

    The Apache Harmony site map helps the visitors to understand the site structure + and layout and thus, quickly gain access to what the site has to offer. This map + reflects links to all relevant Apache Harmony website pages. +

    +
    +
    + +

    Welcome to Apache Harmony - general + information about the project, its status, Harmony news and external news stories + about the Harmony project +

    +

    Harmony News Archive - description of + the project develment +

    +

    + Related Projects - the list of other projects + related to open source Java +

    +
    + +

    Apache License - terms and + conditions for use, reproduction, and distribution +

    +
    + +

    + Contribution Policy - + information on division of the repository, limitations on committer + contributions and policies for committers and contributors +

    + +
    + + +

    + Project Downloads - + you can find all project downloads here, such as snapshot builds and + Subversion +

    +
    + +

    + FAQ - frequently asked questions +

    +
    + +
    + +
    + +

    + Apache Harmony Community - + description of the Harmony community and its structure +

    +
    + +

    + Get Involved - + general information on how to contribute, give feedback, fix + bugs and so on +

    +
    + +

    + JIRA - the + project to post bugs and other issues on +

    +

    + + When an Issue Occurs + - description of action item types, such as + long term plans, short term plans, a release plan, a release testing, + showstoppers, product changes; general rules for commiters, information + on reporting, resolving and closing issues + +

    +
    + +

    + Mailing Lists - the Apache + Harmony mailing lists where you can share all your ideas, ask + questions and discuss plans +

    +
    + +

    + Voting Procedure - + guidelines for the Apache Harmony Project including definitions of how + conflict is resolved by voting and who is able to vote +

    +
    + +
    + +
    + +

    + Apache Harmony Source Code - + description of the Subversion version control system and access to it +

    +

    + + Code Scanning Tools + - tools to examine code in a more efficient way +

    +
    + +

    + + Getting + Started for Users + - the getting started guide for those that + wish to use pre-built snapshots of + Apache Harmony +

    +

    + + Getting Started for Contributors + - the getting started guide for + those that wish to checkout and build the source of Apache Harmony +

    + +
    + +

    + Roadmap and TODO - + an approximate roadmap for what the project hopes to achieve in the next + year and a collection of things that the project community has listed + as needing to be done +

    +

    + What Can We Do Now? - + reflects the position of the project +

    +
    + + +

    + Harmony Wiki - + the project for additional documentation and discussions +

    +
    +
    + + +
    + + +

    + + Harmony Development Kit for the Apache Harmony Class Library + - description of the HDK layout and its contents +

    + +
    + +

    + + DRLVM Navigator + - documentation links specific to DRLVM effort + underway at Apache Harmony +

    +

    + + Developing and Building the Code Documentation + +

    +

    + + README + - source package and building instructions for + the VM source code +

    +

    + + Getting Started with DRLVM + - basic usage scenarios of VM: starting an + application, working in Eclipse +

    +

    + + Debugging the DRL Virtual Machine and the JIT Compiler + - practical instructions on how to debug the DRL virtual machine and its + baseline just-in-time compiler Jitrino.JET +

    + + +

    + Architecture and Component Documentation +

    + +

    + + DRLVM Developer's Guide + - in-depth description of the DRLVM + internal architecture and components' interaction +

    + +

    + + Execution + Manager Component Description + - detailed description of the Execution + Manager current implementation +

    +

    + + Guide to Execution Manager Configuration + - guide to Execution Manager (EM) + options and configuration file format +

    + +

    + + How to Write DRL GC + - instructions on creating a custom garbage collector + implementation in C++ and configuring the DRL virtual machine to use it + with a real-life example of a copying GC implementation (source included) +

    + + + +

    + + DRLVM Jitrino + Just-in-time Compiler + - detailed description of the Jitrino just-in-time + compiler implementation; gives details on the internal architecture of the + Jitrino.JET baseline compiler and Jitrino.OPT optimizing compiler, as + well as processes running inside them + +

    + +

    + + Jitrino + Pipeline Management Framework + - detailed description of the pipeline + management framework that provides complete control over just-in-time + compilation process through the Java property mechanism; the description + covers the PMF application to the command-line interface and to the + Jitrino logging system +

    + +

    + + Kernel Classes + - detailed description of the kernel classes implementation + with focus on the native part of kernel classes and the internal kernel classes + interface +

    + +

    + Thread Manager - + detailed description of the Thread Manager current implementation +

    +

    + JVMTI Pop Frame - + details on the PopFrame implementation as currently done in DRLVM, description of the functions + responsible for the operation and gives info on specifics of the current implementation +

    + +
    + + + +

    + + Class Library Navigator + - documentation links specific to the + class library effort underway at Apache Harmony +

    + +

    + + Class Library Component Status + - comparisons of JDK 1.4 and JDK 1.5. against + the Harmony class library snapshots +

    +

    + + Developing and Building the Code Documentation + +

    + +

    + + Getting Started for Contributors + - the getting started + guide for those that wish to checkout and build the source of + Apache Harmony +

    + +

    + + Getting Started with Eclipse + - instructions on how to set up + Eclipse to develop Java code in Apache Harmony, with sections for + both DRLVM and class library development +

    +

    + + Eclipse Movie + - a brief webcast for those who want to see a step-by-step + guide to configuring Eclipse, and developing a patch to the classlibrary code +

    + +

    + + Project Conventions + +

    +

    + + Class Library Package Naming Conventions + - the package naming conventions used in the Apache Harmony Class Library +

    + +

    + + Class Library Testing Conventions + - description of the PROPOSED + placement and package naming conventions for different types of Harmony + class library tests; general guidlines and recomendations + that might be adapted/modified to reflect module specifics +

    +

    + + Building the Apache Harmony Class Library + - compatibility goals in the Apache Harmony Class Library +

    +

    + + Harmony Developer Agreements and Recommendations + - the summary of agreements + and recommendations that were discussed on the development mailing list + dev@harmony.apache.org +

    + +

    + + Framework for Testing Serialization + - guidelines for creating tests and + conventions for resource files +

    +

    + Architecture and Guides Documentation +

    +

    + + ASN.1 Framework + - introduction to the ASN.1 (Abstract Syntax Notation) framework + with an overview of ASN.1 types and encoding rules focusing on the + characteristics of the current implementation +

    +

    + + Abstract Window Toolkit Framework + - description of the AWT (Abstract Window Toolkit) framework covering + major design features and internal implementation specifics, such as the + event handling mechanism, the focus dispatching flow, appearance handling + with custom visual themes and multi-threading support +

    +

    + + DNS Service Provider + - implementation description of the DNS service provider + for the Java Naming Directory Interface (JNDI) including a package overview, a + design description and a guide to using the provider +

    +

    + + DRL Java 2D* + - introduction to the Java two-dimensional (2D) graphics + and image processing technology implementation focusing on the internal + specifics of implementation +

    +

    + + Regex Processing Framework + - overview of the java.util.regex + package and implementation architecture focusing on the performance + improvement aspects +

    + +
    + + + +

    + Build-Test Framework + - instructions to set up and configure the build-test framework +

    +
    +
    +
    +

    + + Building and Deploying the Apache Harmony Website + - tools required + for the Harmony website build, building and deploying instructions +

    + +
    +
    +

    + + Building the Apache Harmony Class Library + - outdated classlib building instructions +

    +
    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Index: xdocs/voting.xml =================================================================== --- xdocs/voting.xml (revision 0) +++ xdocs/voting.xml (revision 0) @@ -0,0 +1,90 @@ + + + + + + + Project Guidelines + Harmony Documentation Team + + + +
    + +

    + This document provides information on the voting procedure to resolve conflicts, + defines who is able to vote and make final decisions, and describes the process + of votes counting. +

    + +

    + Any of the Apache Developers may vote on any issue or action item, + but only long-time contributors to the project can make final decisions.
    + All votes are divided into binding and non-binding. + Binding votes are cast by active members of the Apache Harmony PMC; + the author of the issue can cast a vote as a binding one, if the vote is + about a change to source code or documentation. All other votes are non-binding.
    + The act of voting presupposes that all voting members state their opinion and they + agree to help do the work of the Apache Harmony Project. +

    +
    + +

    You can vote in one of three ways:

    +
    +
    +1
    +
    Yes, agree, or the action should be performed. On some issues, this + vote is only binding if the voter has tested the action on + their own system(s). +
    +
    0
    +
    Abstain, no opinion, or I am happy to let the other group members + decide this issue. An abstention may have detrimental effects if + too many people abstain. +
    +
    -1
    +
    No. On issues where consensus is required, this vote counts as a + veto. All vetos must include an explanation of + why the veto is appropriate. A veto with no explanation is void. + No veto can be overruled. If you disagree with the veto, you + should lobby the person who cast the veto. Voters intending to veto + an action item should make their opinions known to the group immediately, + so that the problem can be remedied as early as possible. +
    +
    +
    + +

    + All voting decisions are based on a minimum quorum. +

    +

    An action item requiring consensus approval must receive +at least 3 binding +1 votes and no vetos.
    +An action item requiring majority approval must receive +at least 3 binding +1 votes and more +1 +votes than -1 votes (i.e., a majority with a minimum +quorum of three positive votes).
    +All other action items are considered to have lazy approval until someone +votes -1, after which point they are decided by either consensus +or a majority vote, depending upon the type of action item.

    + +

    All votes must be sent to the mailing list.

    +
    +
    + +
    +