* If your contribution is larger than 250 lines of code we need to fill in a contribution questionnaire and open a corresponding IPZilla bug

* If your contribution is larger than 250 lines of code we need to fill in a contribution questionnaire and open a corresponding IPZilla bug

* If the licence is not EPL we will need to have this verified (e.g GPL is a no-go)

* If the licence is not EPL we will need to have this verified (e.g GPL is a no-go)

+

+

= I have provided a Patch. Now What? =

+

+

If you have attached a patch to a bugzilla ticket and are not satisfied with it's progress (read: nobody seems to notice after a week or so): Nudge us in the [http://www.eclipse.org/forums/index.php?t=thread&frm_id=174 Scout forum], and please allow for some more days. We will then find a committer for your bug and figure out the next steps together.

+

+

To list the currently pending patches you may use

+

[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=bug_id%2Cbug_severity%2Cpriority%2Ctarget_milestone%2Cbug_status%2Cresolution%2Ccomponent%2Cassigned_to%2Cshort_desc&f1=attachments.filename&list_id=3534658&o1=substring&product=Scout&query_format=advanced&v1=patch&order=bug_id&query_based_on= this query]

A good starting point for nominations is a significant number (8-15) of well written patches, meaningful posts on the [http://www.eclipse.org/forums/index.php?t=thread&frm_id=174 Scout forum] and other community activities.

+

To count patches we typically use the [http://www.eclipse.org/projects/ip_log.php?projectid=technology.scout Scout IP Log].

Scout Docs: Bugs on www.eclipse.org/scout, wiki.eclipse.org/scout, and any other public communication regarding Scout

Choose the Scout version that you are having the issue with. For the Scout coming with Indigo this would be 3.7.0.

Use a decent Summary line

Helps a lot to identify the bug in a large list of bugs. Good example: SWT: Columns with an active filter should be identifiable. Bad example: Layout.

In case the bug relates to a specific Scout runtime UI please use one of the following prefixes:

Swing:: For bugs specific to the Scout Swing UI

SWT:: For bugs specific to the Scout SWT UI

Bug Life Cycle

Consult the Eclipse wiki for a diagram showing the possible bug live cycles.

Typical Life Cycle

New

Assigned

Resolved (Fixed)

Verified

Closed

Some notes:

Status 'Assigned' may be skipped

For a bug in status 'Resolved' the 'Target Milestone' must be specified

If a patch contributed by a non-committer is applied, set the iplog flag to '+' and follow the guidelines in section below

Ideally, the implementation/Fix is verified by the person opening the bug

If bug and implementation is from the same person, someone else should verify the bug

Bugs are closed by Scout project leads after a release is shipped

Contributing Patches

Please create a Bugzilla entry with a patch attached. Some guidelines on how to create such a patch can be found in the following Eclipse article (specifically the sections 'Fixing the Bug' and 'Submitting a Patch').

To successfully contribute you also have to follow the Eclipse legal guidelines.

Specifically, you need to:

make sure the patch doesn't contain cryptography

make sure the patch is written from scratch

make sure the patch is submitted under the EPL

make sure the change is less than 250 lines of code

Special cases

If you're employed outside of bsi, you will need to explicitly confirm all above points in the bugzilla ticket

If your contribution is larger than 250 lines of code we need to fill in a contribution questionnaire and open a corresponding IPZilla bug

If the licence is not EPL we will need to have this verified (e.g GPL is a no-go)

I have provided a Patch. Now What?

If you have attached a patch to a bugzilla ticket and are not satisfied with it's progress (read: nobody seems to notice after a week or so): Nudge us in the Scout forum, and please allow for some more days. We will then find a committer for your bug and figure out the next steps together.

Development IDE Configuration

Scout has Java 5.0 and Eclipse Platform 3.5 as minimum requirements, so dependencies to newer Java and platform versions must be avoided.

In order to minimize the inadvertent introduction of dependencies to Java 6.0, add both a Java5 and a Java 6 SDK to your workspace. Do this in Window/Preferences -> Java/Installed JREs. Then configure your Execution Environments so that J2SE-1.5 refer to a Java 5 SDK and JavaSE-1.6 refer to a Java 6 installation.

If you are using OS X Snow Leopard, then Java 5 is hard to find. Using the search button in Eclipse will tell you that you have a 1.5.0 version of Java. That is probably a lie. It is just a link to 1.6. Fortunately some nice guys have made a download that you may use. Follow these instructions to download and installl a real Java 5. You do not need to make it default. Downloading, unpacking and fixing the version links is enough.

Committer Nominations

Nominations for committer status can be created in the committer portal. Nominations should follow the according to the Eclipse
wiki guidlines.
A good starting point for nominations is a significant number (8-15) of well written patches, meaningful posts on the Scout forum and other community activities.
To count patches we typically use the Scout IP Log.