Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Linux Tools Project/Getting Involved"
(→Documentation) |
(→Web and Wiki) |
||
Line 131: | Line 131: | ||
== Web and Wiki == | == Web and Wiki == | ||
− | Our [http://www.eclipse.org/linuxtools website] and [http://wiki.eclipse.org/Linux_Tools_Project wiki pages] can always use beautification, clarification, and general editing. One good example that could use cleanup is our [http://wiki.eclipse.org/Linux_Tools_Project/Releng release engineering] page. The website can be checked out of [[CVS]] by using [http:// | + | Our [http://www.eclipse.org/linuxtools website] and [http://wiki.eclipse.org/Linux_Tools_Project wiki pages] can always use beautification, clarification, and general editing. One good example that could use cleanup is our [http://wiki.eclipse.org/Linux_Tools_Project/Releng release engineering] page. The website can be checked out of [[CVS]] by using [http://www.eclipse.org/linuxtools/project-info/linuxtoolswebsite.psf this PSF]. For assistance with using this project set file, see [[PSF]]. |
Patches for the website can be submitted [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Linux%20Tools&component=Website here]. | Patches for the website can be submitted [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Linux%20Tools&component=Website here]. |
Revision as of 15:17, 31 March 2011
{{#eclipseproject:technology.linux-distros}} Getting involved in the Linux Tools project is easy and new contributors are always welcome! Many committers hang out on #eclipse-linux on Freenode and we all monitor our mailing list, linuxtools-dev@eclipse.org.
Contents
General Information
A good guide to fixing Eclipse bugs can be found in this article by Remy Suen.
Getting Code
Our code is all maintained in the Eclipse Foundation Git server. It is best to check out the code directly into Eclipse. To do so, install EGit and clone from one of the following URLs:
git://git.eclipse.org/gitroot/linuxtools/org.eclipse.linuxtools.git
http://git.eclipse.org/gitroot/linuxtools/org.eclipse.linuxtools.git
ssh://<committerId>@git.eclipse.org/gitroot/linuxtools/org.eclipse.linuxtools.git
Submitting Patches
Generate patches against the SVN repository's trunk (using Subclipse or Subversive from within Eclipse -- see Team -> Create Patch). Ensure the patch can be applied from within Eclipse and attach it with rationale, a bit of background information, etc. to a bug:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Linux%20Tools
Automated Builds
We use the Eclipse Hudson server to run continuous integration builds when changes are pushed to our Git repository. Every 6 hours we poll for Git changes and if they have occurred, we run a full build using Tycho and run all unit tests. See instructions for building locally for how to perform a full local build. More information on our automated build process is available on our release engineering page. The unit tests results and output of the build including logs can be seen on our Hudson job pages:
- https://build.eclipse.org/hudson/job/cbi-linuxtools-Indigo/
- https://build.eclipse.org/hudson/job/cbi-linuxtools-Helios/
Ways to get involved
Plugin Hacking
Eclipse plugins are written in Java and developed using Eclipse itself. It is easy to get started.
- Ensure you have the Eclipse Plugin Development Environment installed
- See "Getting Code" section above and check out plugin source code
- If you have errors (little red 'x's), resolve them by either installing plugin dependencies or checking out the source for these dependencies into Eclipse
- Hop on #eclipse-linux (Freenode) or email linuxtools-dev@eclipse.org if you have trouble
- Verify that the plugins work by running them:
- Right-click on any of the plugins and select Run As -> Eclipse Application to launch a second instance of Eclipse (aka 'runtime workbench')
- By default, Eclipse will run all plugins in your workspace PLUS all plugins that are running the host Eclipse workbench
- Ensure menu items and general plugin functionality are present and correct in your runtime workbench
- Make changes, debug, set breakpoints, etc.
Helpful knowledge and skills:
- Eclipse plugin development
- Java
- Underlying tool experience if developing an Eclipse plugin to interact with an existing tool
Time commitment: as much or as little as possible
Unit Tests
One area that is great for new contributors to help with is writing unit tests. Right-clicking on a plugin that has "test" in its name and selecting Run As -> JUnit Plugin Test will run that plugin's unit tests. They should all pass. We can always use more tests written and they are a good way to learn the code. A tool such as EclEmma can be used to determine unit test coverage and those plugins with low percentages are the best places to start.
Helpful knowledge and skills:
- Eclipse plugin development
- Java
- Underlying tool experience if developing an Eclipse plugin to interact with an existing tool
Time commitment: a few hours per week
eclipse-build (building the Eclipse SDK)
One aspect of our project is to increase the quality and quantity of Eclipse technology in Linux distributions. A key aspect of this is the building of the Eclipse SDK. We call our efforts here "eclipse-build". Our work is kept in our Git repository:
http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.eclipse-build.git/
Be sure to use EGit from within Eclipse to generate patches directly against Git that will be applicable with Eclipse.
Helpful knowledge and skills:
- ant
- p2
- OSGi
- PDE Build
Time commitment: a few hours per week
Release Engineering
Our automated builds are generally in good shape. Project committers usually fix build problems quickly but there are always things we could do to make the builds more useful to developers. Adding tools to the automated builds such as PMD, FindBugs, EMMA, etc. can really help developers find problems. Now that we are using Tycho, it should be relatively simple to add such analysis tools. Contact our mailing list linuxtools-dev@eclipse.org if you are interested in helping in this area.
When it comes time for a release, many tasks are necessary: branching, tracking bugs, tagging SVN, running builds, verifying results, etc. Help in this area is always appreciated. If you see traffic on the mailing list indicating that a release is pending (these are listed in our project plan), or notice that a planned release date is upcoming, email the list announcing your availability and how you can help.
Helpful knowledge and skills:
- Tycho
- Java
- p2
Time commitment: varies per level but not very much
Documentation
Some of our plugins have user guides.
We could use more of them and a probably a nice guide to tie them all together. It would also be nice to write use SWTBot to generate screenshots for the documentation upon each release (this is bug 272038).
Helpful knowledge and skills:
- command of the written English language
- MediaWiki syntax
- Minor graphics editing
Time committment: a few hours per week
Testing and Bug Filing
Our project can always use more users. Users who provide constructive criticism and suggestions are very welcome. Bugs should be filed via this URL:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Linux%20Tools
We have regular (up to 3 or 4 times per day) automated builds which are available for installation via our nightly update site:
http://download.eclipse.org/technology/linuxtools/updates-nightly
Helpful knowledge and skills:
- Installing and updating Eclipse plugins from an update site
- Bugzilla
- Communication via Bugzilla, email/IRC
- Expected functionality of plugins
- (Sometimes) Underlying tool knowledge
- (Sometimes) Running Eclipse plugins from within Eclipse workbench
Time committment: a few hours per week
Bug Triage
Sometimes bugs are filed against the wrong component or are stuck in a state requiring more information or clarification. Other times, bugs have been fixed but have not been marked as such in Bugzilla. Ensuring patches which are accepted have the iplog flag set to "+" and verifying that the Version and "Target Milestone" are set correctly are ways one can help. Helping to move the bug process along is of great help to the project. All open project bugs can be seen here
Helpful knowledge and skills:
- Bugzilla
- Communication via Bugzilla, email/IRC
- Expected functionality of plugins
Time committment: a few hours per week
Web and Wiki
Our website and wiki pages can always use beautification, clarification, and general editing. One good example that could use cleanup is our release engineering page. The website can be checked out of CVS by using this PSF. For assistance with using this project set file, see PSF.
Patches for the website can be submitted here.
Helpful knowledge and skills:
- Web design
- Command of the written English language
- MediaWiki syntax
- Minor graphics editing
Time committment: a few hours per week (more if desired)