search

eclipse / omr

Eclipse OMR™ Cross platform components for building reliable, high performance language runtimes
http://www.eclipse.org/omr
Other
940 stars 394 forks source link

Rename compiler OMR_OSX macro to OMR_MACOS #2258

Open 0xdaryl opened 6 years ago

0xdaryl commented 6 years ago

The OMR compiler defines a OMR_OSX macro when the host operating system is macOS (compiler/env/defines.h). For consistency with the actual OS names, rename it to OMR_MACOS. Replace uses of the existing macro to the new one.

esmaeilmirzaee commented 6 years ago

Hi,

My name is Esmaeil Mirzaee, and I like to be an active member and learn about Eclipse OMR. So I have watched several videos, which introduced in 'Readme.md', and started with beginner issues. Therefore, I solved this issue according to the instructions. What should I do next?

Sincerely, Esmaeil

0xdaryl commented 6 years ago

Welcome Esmaeil!

The first step is to read through the Contributor Guidelines that describe the basic rules for making pull requests in the Eclipse OMR project.

But before you make your first pull request you must sign the Eclipse Contributor Agreement (information is here, and the link to sign is in the leftmost pane). Once you've signed the ECA all your commits must be signed-off with that same email address (i.e., use the -s git option when committing your changes).

The next step is to make a pull request from your fork of Eclipse OMR to the Eclipse OMR master branch. Be sure to follow the rules outlined in the Contributor Guidelines around commit messages. Our friendly community will review and merge your pull request when it's ready. When you push commits to your pull request, some automatic continuous integration testing will launch on x86 platforms. A committer may launch additional testing on non-x86 hardware (Power, Z) as appropriate. You can see the status of these test results in the "Checks" section of your pull request.

If you have any questions on the process or any aspect of the technology itself, please reach out via a GitHub issue or an email on the omr-dev@eclipse.org mailing list.

I see you've already found a beginner issue to work on. We have several of those, and they certainly help getting you accustomed to the code and the process we follow. I encourage you to choose other issues that interest you.

Thank you for your participation!

esmaeilmirzaee commented 6 years ago

Dear Mr Maier,

Thank you so much for your kindly reply, I followed the instructions and tried to solve #2258. Also, I provided an article which attempts to describe all the required steps for newcomers.

Would you please give me feedback on my previous work? Would you please give your comments on that?

Sincerely, Esmaeil

On 30 January 2018 at 09:47, Daryl Maier notifications@github.com wrote:

Welcome Esmaeil!

The first step is to read through the Contributor Guidelines https://github.com/eclipse/omr/blob/master/CONTRIBUTING.md that describe the basic rules for making pull requests in the Eclipse OMR project.

But before you make your first pull request you must sign the Eclipse Contributor Agreement (information is here https://www.eclipse.org/legal/ECA.php, and the link to sign is in the leftmost pane). Once you've signed the ECA all your commits must be signed-off with that same email address (i.e., use the -s git option when committing your changes).

The next step is to make a pull request from your fork of Eclipse OMR to the Eclipse OMR master branch. Be sure to follow the rules outlined in the Contributor Guidelines around commit messages. Our friendly community will review and merge your pull request when it's ready. When you push commits to your pull request, some automatic continuous integration testing will launch on x86 platforms. A committer may launch additional testing on non-x86 hardware (Power, Z) as appropriate. You can see the status of these test results in the "Checks" section of your pull request.

If you have any questions on the process or any aspect of the technology itself, please reach out via a GitHub issue or an email on the omr-dev@eclipse.org mailing list.

I see you've already found a beginner issue to work on. We have several of those, and they certainly help getting you accustomed to the code and the process we follow. I encourage you to choose other issues that interest you.

Thank you for your participation!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/eclipse/omr/issues/2258#issuecomment-361615200, or mute the thread https://github.com/notifications/unsubscribe-auth/AIXFxOLJhSNlR7tcwneVdcLifoX6JSrEks5tPyt2gaJpZM4RruOF .

In order to start as a committer in Eclipse OMR. You should follow a series of steps. In this article, I am trying to give the fastest and straightforward steps as I observed to commit my first fix for an issue (i.e. ). Also, I got a quick email reply from Mr. which I believe it has several significant guidance. So I compiled my own experience and his advice in this article.

Please be aware of legal issues. It has mentioned in the article several times.

  1. Read through the guideline (https://github.com/eclipse/omr/blob/master/CONTRIBUTING.md). 0.1. How should I submit or open a pull request? 0.2. How can I assign a bug to myself?
  2. Create an account or Log into your Eclipse Foundation.
  3. Subscribe to the dev.eclipseomr mailing list.
  4. Sign in the ECA certification.
  5. Log into https://git.eclipse.org/r/#/q/status:open
  6. Read through coding standard guideline https://github.com/eclipse/omr/blob/master/doc/CodingStandard.md
  7. I found an interesting issue to work on. What is the process? 6.1. Read through the message provided by the reporter. 6.2. Assign the issue to yourself (How?). 6.3. Create a new branch based on the bug number (Is this required?). git checkout -b #bug-number 6.4. Apply the changes. 6.5. Prepare a reasonable commit message, which is described entirely on (https://github.com/eclipse/omr/blob/master/CONTRIBUTING.md) 6.6. Commit your changes.

Questions

  1. Would you please give more examples to not adding [skip ci]?
  2. At step 6.2, should committer create a new branch?