Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Scout/Contribution"

(Step 5: Push feature branch to remote repository)
(Preparing Nominations)
(27 intermediate revisions by 4 users not shown)
Line 3: Line 3:
 
The [http://wiki.eclipse.org/Development_Resources#Users:_Contributing_To_A_Project Eclipse wiki] gives a good detailed overview of the various ways you can contribute to a project:
 
The [http://wiki.eclipse.org/Development_Resources#Users:_Contributing_To_A_Project Eclipse wiki] gives a good detailed overview of the various ways you can contribute to a project:
  
The typical contributor will go through the following steps:
+
The typical Eclipse Scout contributor will go through the following steps:
 
# You use Scout, i.e. {{ScoutLink|HowTo|Install Scout SDK|install}} it, go through {{ScoutLink|Tutorial|name=tutorials}}, build your own Scout apps
 
# You use Scout, i.e. {{ScoutLink|HowTo|Install Scout SDK|install}} it, go through {{ScoutLink|Tutorial|name=tutorials}}, build your own Scout apps
 
# You will find bugs, or have ideas for your great feature.  
 
# You will find bugs, or have ideas for your great feature.  
Line 125: Line 125:
 
* Status 'Assigned' may be skipped
 
* Status 'Assigned' may be skipped
 
* For a bug in status 'Resolved' the 'Target Milestone' must be specified
 
* For a bug in status 'Resolved' the 'Target Milestone' must be specified
 +
<!-- TODO: check this: Not necessary since the migration to git?
 
* If a patch contributed by a non-committer is applied, set the '''iplog flag to '+'''' (on the individual patch file, not on the bug!) and follow the guidelines in section below
 
* If a patch contributed by a non-committer is applied, set the '''iplog flag to '+'''' (on the individual patch file, not on the bug!) and follow the guidelines in section below
 +
-->
 
* Ideally, the implementation/Fix is verified by the person opening the bug
 
* 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
 
* 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
 
* Bugs are closed by Scout project leads after a release is shipped
  
=== Checklist for setting status to Resolved (Fixed) ===
 
* Iplog is set, if necessary (on patch not ticket, if a patch is available)
 
* Milestone is correct
 
* Ticket contains migration notes, if necessary
 
* Whiteboard contains ''migration'' text, if necessary
 
* Ticket is assigned to person that is supposed to test it
 
* News entry is written in [[Scout/NewAndNoteworthy]], if necessary (for enhancements and other important changes)
 
  
=== Verifying a ticket ===
+
== [Contributor] After starting to work on a Bug ==
* Test, if the original problem was solved and it is save to close it. Test on all branches where the ticket was applied.
+
* If the ticket is ok set the status to "VERIFIED" and reassign it to the default assignee
+
* If the ticket was not ok, set the status to "REOPENED" and reassign to the person who solved the ticket.
+
  
= Contributions for Non-Scout Committers =
+
A good practice is to assign the bug to the person working on the bug. This way everybody knows someone is working on the bug.
  
== Contributing patches ==
+
* Change the status to "ASSIGNED"
 +
* Target milestone where you plan to fix the Bug (corresponding to the develop branch). If the fix should also be backported to a previous branch, indicate this in the comment.
  
Please create a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Scout Bugzilla] entry with a patch attached. Some guidelines on how to create such a patch can be found in the [http://www.eclipse.org/articles/article.php?file=Article-How-to-Fix-a-Bug-in-Eclipse/index.html following Eclipse article] (specifically the sections 'Fixing the Bug' and 'Submitting a Patch').
 
  
Contribution to the Eclipse Scout project needs to follow the [[Scout/Coding_Guidelines|coding guidelines]].
+
== [Contributor] After having pushed to Gerrit ==
  
To successfully contribute you also have to follow the Eclipse [http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf legal guidelines].
+
In Bugzilla [OPTIONAL]
 +
* Comment: Link to Gerrit change
  
Specifically, you need to:
+
In Gerrit [MANDATORY]
# make sure the patch doesn't contain cryptography
+
* Wait for the Hudson build (+1 Verified)
# make sure the patch is written from scratch
+
* Review: (+2 Code-Review; +1 IP-Clean)
# make sure the patch is submitted under the EPL
+
** ping (mail, forum, phonecall...) a commiter to get a review. Nobody looks in the Gerrit Inbox for open changes.
# make sure the change is less than 250 lines of code
+
** if you are commiter, it is allowed to review your own change. A good practice is to speak about it with an other commiter.
  
Special cases
 
* If you're employed outside of [http://www.bsiag.com bsi], you will need to explicitly confirm all above points in the gerrit change or 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? ==
+
== [Commiter] After having submitted the change in Gerrit ==
 +
After having submitted the Gerrit change in Gerrit, the commiter should:
  
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.
+
In Bugzilla [MANDATORY]
 +
* Add a comment in Bugzilla: „Pushed to develop with commit + URL”
 +
  <nowiki>http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/commit/?id={{commit}}</nowiki>
 +
* Check the Target Milestone.
 +
* Change Satus to: “RESOLVED FIXED”
 +
* Asign the Bug to a Tester “Could you verify please?”
  
To list the currently pending patches you may use
+
=== Checklist for setting status to RESOLVED FIXED ===
[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]
+
<!-- TODO: check this: Not necessary since the migration to git?
 +
* Iplog is set, if necessary (on patch not ticket, if a patch is available)
 +
-->
 +
* Milestone is correct
 +
* Ticket contains migration notes, if necessary
 +
* Whiteboard contains ''migration'' text, if necessary
 +
* Ticket is assigned to person that is supposed to test it
 +
* News entry is written in [[Scout/NewAndNoteworthy]], if necessary (for enhancements and other important changes)
  
= Contributions for Scout Committers =
 
  
== Contributing a patch or feature ==
+
== [Tester] After having tested ==
  
=== Summary ===
+
''' How do I test?'''
  
Contributing a patch or a new feature to Eclipse Scout Kepler or Luna is done by creating a new feature branch that will be merged into the corresponding develop (currently Luna) or release branch (release/3.9.1 is Kepler SR1). In this chapter all necessary steps are shown to contribute a patch or a feature.
+
Now is a good time to (re)read the bugzilla and verify that the implemented solution actually solves the problem(s).
This example requires EGIT to be installed in the Eclipse IDE.
+
  
=== Step 1: Clone GIT repository ===
+
Please test the change in a Scout application. The binary form (.jar) should be tested (continuous job, milestone release...)
  
All Eclipse Scout GIT repositories are listed [http://git.eclipse.org/c/scout/ here]. In this example, we'll provide a new feature to the Scout Runtime. Therefore, we clone the [http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/ Scout RT] repository is cloned.
+
Test on all branches where the ticket was applied.
  
In your Eclipse IDE click on ''Windows ->  Open Perspective -> Others...'' and select ''Git Repository Exploring''.
+
''' How do I report the results?'''
  
[[Image:GitContribution.01.select.git.perspective.png]]
+
In Bugzilla [MANDATORY]
 +
* Comment: „Tested with version XXXXX” (for example <tt>3.10.0.20131003-1140</tt>) (see [[#Find_the_version_of_a_plugin]])
 +
* Change “Status” and “Assigned to”:
 +
* If the ticket is ok set the status to "VERIFIED FIXED" and reassign it to the default assignee (see [[#Reset_assignee_to_default]]).
 +
* If the ticket was not ok, set the status to "REOPENED" and reassign it to the person who solved the ticket. Explain what is wrong in the comment.
  
In the GIT perspective, click on ''Clone a Git repository'' and select ''URI'' as a repository source in the next dialog.
 
  
[[Image:GitContribution.02.clone.git.perspective.png]]
+
=== Find the version of a plugin ===
 +
With CTRL-Shift-A you can look for any scout bundle in your target platform. Select the bundle that should contain your modification. Click OK.
  
For the [http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/ Scout RT repository] we use the SSH URL ssh://git.eclipse.org/gitroot/scout/org.eclipse.scout.rt.git. Please fill in your Eclipse Scout committer credentials in the Username and Password field.
+
[[File:Open_Plug-in_Artifact.png]]
  
[[Image:GitContribution.03.enter.url.and.credentials.png]]
+
In the Manifest editor, you can copy the exact version. The timestamp you see in the version is corresponding to the last commit for this bundle.
  
Since we are interested in the develop and release/3.9.1 (Kepler SR1) branches, we only select these two branches.
+
[[File:Copy_version_from_Manifest_editor.png]]
  
[[Image:GitContribution.04.select.remote.branches.png]]
 
  
The Scout RT GIT repository will be cloned to a local destination. Select the directory and location to which the GIT repository should be cloned. Choose ''develop'' as the initial branch and enter ''origin'' to reference the remote GIT repository.
+
=== Reset assignee to default ===
 +
Use the Bugzilla feature to reassign the assignee to default.
  
[[Image:GitContribution.05.choose.local.destination.png]]
+
[[File:Bugzilla_reset_assignee_to_default.png]]
  
Finally, click on ''Finish'' to clone the Scout RT repository.
+
= Contributions for Non-Scout Committers =
  
=== Step 2: Import Plugins into Workspace ===
+
== Contributing patches ==
  
After having cloned the Scout RT Git repository, we are going to import all plugins from the repository into our workspace.
+
Please create a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Scout Bugzilla] entry with a patch attached. Some guidelines on how to create such a patch can be found in the [http://www.eclipse.org/articles/article.php?file=Article-How-to-Fix-a-Bug-in-Eclipse/index.html following Eclipse article] (specifically the sections 'Fixing the Bug' and 'Submitting a Patch').
Double-click on the cloned repository ''org.eclipse.scout.rt'' and right-click on the ''Working Directory'' and select ''Import Projects...''
+
  
[[Image:GitContributionStep2.01.import.into.workspace.png]]
+
Contribution to the Eclipse Scout project needs to follow the [[Scout/Coding_Guidelines|coding guidelines]].
  
In the next step, we will import all plugins into our workspace.  
+
To successfully contribute you also have to follow the Eclipse [http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf legal guidelines].
  
[[Image:GitContributionStep2.02.import.into.workspace.wizard.png]]
+
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
  
Click on the ''Next'' button and select all plugins.
+
Special cases
 +
* If you're employed outside of [http://www.bsiag.com bsi], you will need to explicitly confirm all above points in the gerrit change or 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)
  
[[Image:GitContributionStep2.03.select.plugins.png]]
+
== I have provided a Patch. Now What? ==
  
Click on ''Finish'' to start the import process.
+
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.
  
=== Step 3: Create a local feature branch ===
+
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]
  
For every new feature a separate branch is created.
+
= Contributions for Scout Committers =
Assume we want to provide an implementation for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=412011 bug 412011]. We will create a local branch first based on the latest commit of the develop branch. Then we apply some initial changes for the bug, commit them to the local branch and will push the local feature branch to the remote Git repository (origin). Afterwards, we will do some further changes, commit them locally and push these changes to the recently created remote branch.
+
  
First, we will have a look at the history. In the Git perspective expand your local branches and right click on the ''develop'' branch and choose ''Show In -> History''.
+
Please refer to [[Scout/Contributions_for_Scout_Committers]]
  
[[Image:GitContributionStep3.01.show.history.png]]
 
  
The History view should be opened and it should like something look this
 
 
[[Image:GitContributionStep3.02.history.timeline.png]]
 
 
We can see that our local develop branch (marked in green) refers to the same last commit as the remote develop branch shown as origin/develop in grey. Right-click on the commit where the origin/develop branch is pointing to and select ''Create Branch...''.
 
 
[[Image:GitContributionStep3.03.create.branch.png]]
 
 
As Source ref or commit we select ''refs/remotes/origin/develop'' and call the local feature branch ''luna_target_bug412011''. Select ''None'' as pull strategy and check ''Checkout new branch''.
 
 
[[Image:GitContributionStep3.03.create.new.feature.branch.png]]
 
 
Click on ''Finish''. The feature branch should now be created locally.
 
 
[[Image:GitContributionStep3.03.feature.branch.created.png]]
 
 
The check icon on the left and the bold font in the History view indicate that the feature branch is currently active.
 
 
=== Step 4: Change Push URL ===
 
 
In the previous step we cloned our Scout RT repository from read-only [ssh://git.eclipse.org/gitroot/scout/org.eclipse.scout.rt.git URL]. To be able to push our feature branches and patches, we have to configure the Push URL to use Gerrit where write access is granted.
 
Expand the ''Remotes'' directory, right-click on ''origin'' and select ''Gerrit Configuration...''
 
 
[[Image:GitContributionStep4.01.configure.push.url.png]]
 
 
For Scout RT, we add the URL ''ssh://[username]@git.eclipse.org:29418/scout/org.eclipse.scout.rt.git'' where [username] should be replaced with your committer ID.
 
 
[[Image:GitContributionStep4.02.add.gerrit.png]]
 
 
Click on ''Finish''. Your Push URL should now look similar like
 
 
[[Image:GitContributionStep4.03.gerrit.added.png]]
 
 
 
=== Step 5: Push feature branch to remote repository ===
 
 
Now we push the recently created local feature branch to the remote repository. Right-click on the local feature branch luna_target_bug412011 and select ''Push Branch...''.
 
 
[[Image:GitContributionStep5.01.push.feature.branch.to.remote.png]]
 
 
Select the remote repository which correspond to the Gerrit Push URL we've just added in the previous step. Press ''Next''.
 
 
[[Image:GitContributionStep5.02.select.remote.repository.png]]
 
 
Now we choose the target ref name for the feature branch. The convention is as follow:
 
''refs/heads/features/[committerID]/shortDescription_bug[ID]'', where [committerID] and [ID] should be replaced by the actual value.
 
 
[[Image:GitContributionStep5.03.choose.target.ref.name.png]]
 
 
Press ''Finish'' and the feature branch should now be pushed onto the remote repository.
 
 
[[Image:GitContributionStep5.04.feature.branch.pushed.png]]
 
 
The feature branch is visible in the ''Remote Tracking'' directory.
 
 
[[Image:GitContributionStep5.05.feature.branch.added.png]]
 
 
=== Step 6: Commit changes to local feature branch and push to remote repository ===
 
 
= Development IDE Configuration =
 
 
Scout has Java 6.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 7.0, add both a Java6 and a Java 7 SDK to your  workspace. Do this in Window/Preferences -> Java/Installed JREs. Then configure your Execution Environments so that J2SE-1.6 refer to a Java 6 SDK and JavaSE-1.7 refer to a Java 7 installation.
 
  
 
= Getting the Scout Sources  =
 
= Getting the Scout Sources  =
  
Starting with Scout 3.9.0 (Kepler) we are using git. See: http://git.eclipse.org/c/scout/.
+
We are using git at eclipse: [http://git.eclipse.org/c/scout/]. How to setup your environment to compile the sources and contribute see [[Scout/Contributions_for_Scout_Committers#Setup | Setup]].
 
+
{{ScoutLink| Contribution|Scout Git Scripts|Some internal Scout Git scripts}}.
+
  
 
Repositories
 
Repositories
Line 308: Line 251:
 
  SDK: git://git.eclipse.org/gitroot/scout/org.eclipse.scout.sdk.git
 
  SDK: git://git.eclipse.org/gitroot/scout/org.eclipse.scout.sdk.git
  
 +
The branching policy is described here: [[Scout/Contribution_Guidelines#Git_Branching_Policy|Git Branching Policy]].
  
The sources for earlier releases are still available on SVN (see section Juno or Indigo). You may browse the SVN repository [http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/ online].
+
Webviewer: [http://git.eclipse.org/c/scout/ Scout Git Repositories]
  
 
== Luna ==
 
== Luna ==
  
   Eclipse Scout 3.10.0 (upcoming Luna Release)
+
   Eclipse Scout 4.0 (upcoming Luna Release)
 
   Branch: develop
 
   Branch: develop
 
  
 
== Kepler ==
 
== Kepler ==
  
   Eclipse Scout 3.9.1 (upcoming Kepler SR1)
+
   Eclipse Scout 3.9.2 (upcoming Kepler SR2)
   Branch: release/kepler_sr1
+
   Branch: release/3.9.2 ([http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/log/?h=release/3.9.2 view RT repository] - [http://git.eclipse.org/c/scout/org.eclipse.scout.sdk.git/log/?h=release/3.9.2 view SDK repository])
  
 +
  Eclipse Scout 3.9.1 (Kepler SR1)
 +
  Branch: master
 +
  Tag: Kepler_SR1_RC4 ([http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/tag/?id=Kepler_SR1_RC4 view RT repository] - [http://git.eclipse.org/c/scout/org.eclipse.scout.sdk.git/tag/?id=Kepler_SR1_RC4 view SDK repository])
  
 
   Eclipse Scout 3.9.0 (Kepler)
 
   Eclipse Scout 3.9.0 (Kepler)
 
   Branch: master
 
   Branch: master
 +
  Tag: Kepler_RC4 ([http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/tag/?id=Kepler_RC4 view RT repository] - [http://git.eclipse.org/c/scout/org.eclipse.scout.sdk.git/tag/?id=Kepler_RC4 view SDK repository])
  
== Juno ==
+
[[Sources for Old Releases]] are available in a SVN repository: [http://dev.eclipse.org/viewsvn/viewvc.cgi/scout.rt/tags/?root=Technology_SCOUT SVN]
 
+
The most current state of the Juno release of Eclipse Scout is
+
 
+
  Eclipse Scout 3.8.x (Juno)
+
  Runtime: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.rt/branches/3.8
+
  SDK: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.sdk/branches/3.8
+
 
+
To get access to the sources of the Juno release you may access the repository through the tags provided below.
+
 
+
  Eclipse Scout 3.8.1 (Juno SR1)
+
  Runtime: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.rt/tags/2012-09-17_S-3.8.1
+
  SDK: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.sdk/tags/2012-09-17_S-3.8.1
+
 
+
  Eclipse Scout 3.8.0 (Juno)
+
  Runtime: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.rt/tags/2012-06-13_S-3.8.0RC4
+
  SDK: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.sdk/tags/2012-06-13_S-3.8.0RC4
+
 
+
== Indigo ==
+
 
+
The most current state of the Indigo branch of Eclipse Scout is
+
 
+
  Eclipse Scout 3.7.x (Indigo)
+
  Runtime: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.rt/branches/2011-Jun
+
  SDK: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.sdk/branches/2011-Jun
+
 
+
To get access to the sources of the Indigo release you may access the repository through the tags provided below.
+
 
+
  Eclipse Scout 3.7.2 (Indigo SR2)
+
  Runtime: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.rt/tags/2012-02-14_S-3.7.2RC4/
+
  SDK: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.sdk/tags/2012-02-14_S-3.7.2RC4/
+
 
+
  Eclipse Scout 3.7.1 (Indigo SR1)
+
  Runtime: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.rt/tags/2011-09-14_S-3.7.1RC4
+
  SDK: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.sdk/tags/2011-09-14_S-3.7.1RC4
+
 
+
  Eclipse Scout 3.7.0 (Indigo)
+
  Runtime: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.rt/tags/2011-06-06_S-3.7.0RC4
+
  SDK: http://dev.eclipse.org/svnroot/technology/org.eclipse.scout/scout.sdk/tags/2011-06-06_S-3.7.0RC4
+
  
 
= Wiki Contribution =
 
= Wiki Contribution =
Line 475: Line 384:
  
 
== Preparing Nominations ==
 
== Preparing Nominations ==
 +
* [[Scout/Scout_Nomination_ASA|Adrian Sacchi]], April 2014
  
 
== Current Nominations ==
 
== Current Nominations ==
 +
 +
== Past Nominations ==
 +
* [[Scout/Scout_Nomination_MNC|Matthias Nick]], January 2014
 
* [[Scout/Scout_Nomination_CSC|Christoph Schwank]], May 2013
 
* [[Scout/Scout_Nomination_CSC|Christoph Schwank]], May 2013
 
* [[Scout/Scout_Nomination_OSC|Oli Schmid]], May 2013
 
* [[Scout/Scout_Nomination_OSC|Oli Schmid]], May 2013
 
* [[Scout/Scout_Nomination_BKO|Bruno Koeferli]], May 2013
 
* [[Scout/Scout_Nomination_BKO|Bruno Koeferli]], May 2013
 
== Past Nominations ==
 
 
* [[Scout/Scout_Nomination_AMO|Adrian Moser]], Dezember 2012
 
* [[Scout/Scout_Nomination_AMO|Adrian Moser]], Dezember 2012
 
* [[Scout/Scout_Nomination_BSH|Beat Schwarzentrub]], Dezember 2012
 
* [[Scout/Scout_Nomination_BSH|Beat Schwarzentrub]], Dezember 2012

Revision as of 11:51, 10 March 2014

Introduction

The Eclipse wiki gives a good detailed overview of the various ways you can contribute to a project:

The typical Eclipse Scout contributor will go through the following steps:

  1. You use Scout, i.e. The Scout documentation has been moved to https://eclipsescout.github.io/. it, go through The Scout documentation has been moved to https://eclipsescout.github.io/., build your own Scout apps
  2. You will find bugs, or have ideas for your great feature.
  3. You provide some public feedback
    1. Read/ask questions on the Scout Scout Forum
    2. Report these bugs/enhancements via Scout bugzilla
  4. Eventually, you might want to speed up bug fixing by providing patches
  5. Getting enthusiastic enough, you will contribute many valuable, high quality patches for Scout bugs/enhancements
  6. Now is the time to start the committer election process :-)

Opening new Bugs

1) Before you do anything related to bugs please have a look at the Eclipse Bugzilla FAQ.

2) Before you open a new Scout bug, please try to scan through the known bugs to verify that you are not reporting a bug that is already known for Eclipse Scout. See next section.

Find Existing Scout Bugs

For your convenience a number of links are provided below:

Bug Report Quality Matters

High quality bug reports help to quickly understand/analyze/fix bugs. Bad quality bug reports lead to poor developer morale and slow down everything.

Good quality bug reports often feature many of the following things:

  • Well organized description
  • Clear distinction between observed behaviour and expected behaviour
  • Steps to reproduce
  • Stack traces
  • Screenshots
  • Source file and line numbers from attempts to locate the source of the bug

Lack of any of the above characteristics is considered poor quality. A drastic example (taken from [1]) reads as follows:

I wand to create a new plugin in Eclipse using CDT. Shall it possible.
I had made a R&D in eclipse documentation. I had get an idea about create a
plugin using Java. But i wand to create a new plugin ( user defined plugin )
using CDT. After that I wand to impliment it in my programe. If it possible?.
Any one can help me please...

[1] Nicolas Bettenburg et al. "Quality of bug reports in Eclipse", Proceedings of the 2007 OOPSLA workshop on eclipse technology eXchange, 2007

Good guidelines on how to write a bug may be found here:

Open a Scout bug

When you cannot find an existing bug, feel free to open a new bug:

Please also read the text below that introduces some Scout specific aspects of bug writing

Choose the proper Component

Select the component according to the following criteria

  • Scout: Scout Runtime bugs, or anyting else that you are not sure what component to choose
  • Scout SDK: Bugs in the Scout SDK, e.g. wizards that create code that won't compile
  • Scout Docs: Bugs on www.eclipse.org/scout, wiki.eclipse.org/scout, and any other public communication regarding Scout

Choose the proper Version

Choose the Scout version that you are having the issue with. Next the Scout release coming with Kepler (june 2013) this would be 3.9.0.

If you are using an older version of Eclipse Scout, there is no more release planned, but relevant bugs will still be fixed on these branches.

Choose the proper Severity

Severity is assigned by a user and describes the level of impact the bug is having on them, the Eclipse Scout project has defined following meanings:

Severity Definition Used when
Blocker Prevents function from being used, no work-around, blocking progress on multiple fronts The bug prevents use or testing of the build
Critical Prevents function from being used, no work-around frequent crashes, “loss of data”
Major Prevents function from being used, but a work-around is possible “loss of function”
Normal A problem making a function difficult to use but no special work-around is required default value, typically the correct setting unless one of the other levels fit
Minor A problem not affecting the actual function, but the behavior is not natural (or it is not important). something's wrong, but it doesn't affect the function significantly
Trivial A problem not affecting the actual function, a typo would be an example feature requests, nice to have (also when the new feature is “major”)

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

  1. New
  2. Assigned
  3. Resolved (Fixed)
  4. Verified
  5. Closed

Some notes:

  • Status 'Assigned' may be skipped
  • For a bug in status 'Resolved' the 'Target Milestone' must be specified
  • 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


[Contributor] After starting to work on a Bug

A good practice is to assign the bug to the person working on the bug. This way everybody knows someone is working on the bug.

  • Change the status to "ASSIGNED"
  • Target milestone where you plan to fix the Bug (corresponding to the develop branch). If the fix should also be backported to a previous branch, indicate this in the comment.


[Contributor] After having pushed to Gerrit

In Bugzilla [OPTIONAL]

  • Comment: Link to Gerrit change

In Gerrit [MANDATORY]

  • Wait for the Hudson build (+1 Verified)
  • Review: (+2 Code-Review; +1 IP-Clean)
    • ping (mail, forum, phonecall...) a commiter to get a review. Nobody looks in the Gerrit Inbox for open changes.
    • if you are commiter, it is allowed to review your own change. A good practice is to speak about it with an other commiter.


[Commiter] After having submitted the change in Gerrit

After having submitted the Gerrit change in Gerrit, the commiter should:

In Bugzilla [MANDATORY]

  • Add a comment in Bugzilla: „Pushed to develop with commit + URL”
 http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/commit/?id={{commit}}
  • Check the Target Milestone.
  • Change Satus to: “RESOLVED FIXED”
  • Asign the Bug to a Tester “Could you verify please?”

Checklist for setting status to RESOLVED FIXED

  • Milestone is correct
  • Ticket contains migration notes, if necessary
  • Whiteboard contains migration text, if necessary
  • Ticket is assigned to person that is supposed to test it
  • News entry is written in Scout/NewAndNoteworthy, if necessary (for enhancements and other important changes)


[Tester] After having tested

How do I test?

Now is a good time to (re)read the bugzilla and verify that the implemented solution actually solves the problem(s).

Please test the change in a Scout application. The binary form (.jar) should be tested (continuous job, milestone release...)

Test on all branches where the ticket was applied.

How do I report the results?

In Bugzilla [MANDATORY]

  • Comment: „Tested with version XXXXX” (for example 3.10.0.20131003-1140) (see #Find_the_version_of_a_plugin)
  • Change “Status” and “Assigned to”:
  • If the ticket is ok set the status to "VERIFIED FIXED" and reassign it to the default assignee (see #Reset_assignee_to_default).
  • If the ticket was not ok, set the status to "REOPENED" and reassign it to the person who solved the ticket. Explain what is wrong in the comment.


Find the version of a plugin

With CTRL-Shift-A you can look for any scout bundle in your target platform. Select the bundle that should contain your modification. Click OK.

Open Plug-in Artifact.png

In the Manifest editor, you can copy the exact version. The timestamp you see in the version is corresponding to the last commit for this bundle.

Copy version from Manifest editor.png


Reset assignee to default

Use the Bugzilla feature to reassign the assignee to default.

Bugzilla reset assignee to default.png

Contributions for Non-Scout Committers

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').

Contribution to the Eclipse Scout project needs to follow the coding guidelines.

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

Specifically, you need to:

  1. make sure the patch doesn't contain cryptography
  2. make sure the patch is written from scratch
  3. make sure the patch is submitted under the EPL
  4. 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 gerrit change or 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.

To list the currently pending patches you may use this query

Contributions for Scout Committers

Please refer to Scout/Contributions_for_Scout_Committers


Getting the Scout Sources

We are using git at eclipse: [1]. How to setup your environment to compile the sources and contribute see Setup.

Repositories

Runtime: git://git.eclipse.org/gitroot/scout/org.eclipse.scout.rt.git
SDK: git://git.eclipse.org/gitroot/scout/org.eclipse.scout.sdk.git

The branching policy is described here: Git Branching Policy.

Webviewer: Scout Git Repositories

Luna

 Eclipse Scout 4.0 (upcoming Luna Release)
 Branch: develop

Kepler

 Eclipse Scout 3.9.2 (upcoming Kepler SR2)
 Branch: release/3.9.2 (view RT repository - view SDK repository)
 Eclipse Scout 3.9.1 (Kepler SR1)
 Branch: master
 Tag: Kepler_SR1_RC4 (view RT repository - view SDK repository)
 Eclipse Scout 3.9.0 (Kepler)
 Branch: master
 Tag: Kepler_RC4 (view RT repository - view SDK repository)

Sources for Old Releases are available in a SVN repository: SVN

Wiki Contribution

We encourage Eclipse Scout developers and contributors to take the "better to ask for forgiveness than permission" approach to adding and updating wiki documentation.

Create links

Forum to Wiki

A forum thread has a very short life time (sometimes some user use the search engine, but it is not always the case). As forum threads As a wiki page has a much longer lifetime than a forum thread, it is a good practice to increase the value of the information accumulated in a forum thread by condensing it into a wiki page. Its value is further growing over time because – in contrast to information in a forum thread - it is much more likely that the information in the wiki is kept up to date. When a Forum Topic is summarized into a wiki page or pages, it is a good practice to let the forum readers know about it. (This helps people that find an old forum thread via search engines). The above recommendation does not apply to all forum threads, but often it’s already clear from the first question in a new thread if the asked for information would be a valuable addition to the wiki. To make the process more efficient we like to suggest the following approach. Once it’s clear that the question is of a conceptual nature and it will take some time to compile a good answer consider to first create the answer as a how-to entry or a concept entry in the wiki. Then answer the forum’s question by adding a link to the newly created wiki page.

Wiki to Forum

Sometime there is a very good discussion in the forum (example, how to, architecture description, advanced topic explanations). Such valuable know how belongs to the wiki, but it is sometimes not possible to control where the discussion takes place. If there is/are (roughly) matching existing wiki pages but the person responding the forum thread does not have the necessary time to amend this existing wiki at least add a link from the wiki page to the forum thread.

What you type What you see
{{note|TODO|Merge the content of this post:
build your own fragment containing the MySql jdbc driver
http://www.eclipse.org/forums/index.php/mv/msg/214013/691589/#msg_691589 
}}
Note.png
TODO
Merge the content of this post:

build your own fragment containing the MySql jdbc driver

http://www.eclipse.org/forums/index.php/mv/msg/214013/691589/#msg_691589

Wiki to Wiki

A wiki is not a book, it is not linear. It is not possible to assume where a reader will start reading (he might land on a page with a search engine). Therefore it is important to link the pages together. We try to add a “see also” section on each page. It is the default solution to link pages with each other.

It is possible to check how many other wiki pages contain a link to a page. Link “What links here” from the Toolbox section. At list 2-3 pages should reference a new page.

Use MediaWiki Features

Java Syntax highlighting

Tag the code blocks with source tag

What you type What you see
<source lang="java">
@Override
protected IPage execCreateChildPage(final ITableRow row)
    throws ProcessingException {
      MyNodePage childPage = new MyNodePage();
      childPage.setId(getTable().getIDColumn().getValue(row));
      return childPage;
}
</source>
@Override
protected IPage execCreateChildPage(final ITableRow row)
    throws ProcessingException {
      MyNodePage childPage = new MyNodePage();
      childPage.setId(getTable().getIDColumn().getValue(row));
      return childPage;
}
<source lang="xml">
<filter
    aliases="/process"
    class="org.eclipse.scout.http.servletfilter.security.LDAPSecurityFilter"
    ranking="50">
</filter>
</source>
<filter
    aliases="/process"
    class="org.eclipse.scout.http.servletfilter.security.LDAPSecurityFilter"
    ranking="50">
</filter>
<source lang="sql">
select language_id, name
from languages
</source>
SELECT language_id, name
FROM languages


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.

Preparing Nominations

Current Nominations

Past Nominations

Back to the top