- 1 Introduction
- 2 Bugzilla Contribution
- 2.1 Opening new Bugs
- 2.2 Find Existing Scout Bugs
- 2.3 Bug Report Quality Matters
- 2.4 Open a Scout bug
- 2.5 Choose the proper Component
- 2.6 Choose the proper Version
- 2.7 Choose the proper Severity
- 2.8 Use a decent Summary line
- 2.9 Bug Life Cycle
- 2.9.1 Typical Life Cycle
- 2.9.2 [Contributor] After starting to work on a Bug
- 2.9.3 [Contributor] After having pushed to Gerrit
- 2.9.4 [Committer] After having submitted the change to Gerrit
- 2.9.5 Checklist for setting status to RESOLVED FIXED
- 2.9.6 [Tester] After having tested
- 3 Source Code Contribution
- 4 Documentation Contribution
- 5 Committer Nominations
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:
- You use Scout, i.e. install it, go through tutorials, build your own Scout apps
- You will find bugs, or have ideas for your great feature.
- You provide some public feedback
- Eventually, you might want to speed up bug fixing by providing patches
- Getting enthusiastic enough, you will contribute many valuable, high quality patches for Scout bugs/enhancements
- 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 behavior and expected behavior
- Steps to reproduce
- Stack traces
- 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 ) 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...
 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 anything 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. You can find an overview of the current Scout versions here: https://eclipsescout.github.io/
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:
|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: Table: columns with an active filter should be identifiable. Bad example: Layout.
In case the bug relates to a specific Scout runtime component you can use that component as prefix (E.g Table:).
Bug Life Cycle
Consult the Eclipse wiki for a diagram showing the possible bug live cycles.
Typical Life Cycle
- Resolved (Fixed)
- 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
- Wait for the Hudson build (+1 Verified)
- Ping (mail, forum, phonecall...) a committer to get a review. Committers rarely look in the Gerrit Inbox for open changes.
- If you are committer, it is allowed to review your own change. A good practice is to speak about it with another committer.
[Committer] After having submitted the change to Gerrit
After having submitted the change to Gerrit, the committer should:
- Add a comment in Bugzilla: „Pushed to 8.0 with commit + URL”
- Check the Target Milestone.
- Change Status to: “RESOLVED FIXED”
- Assign the Bug to a Tester “Could you verify please?”
Checklist for setting status to RESOLVED FIXED
- Milestone is correct
- Ticket is assigned to the person who is supposed to test it
- The release notes and migration guide on Github are updated, if necessary.
[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?
- Comment: „Tested with version XXXXX” (for example 188.8.131.5231003-1140)
- 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.
Reset assignee to default
Use the Bugzilla feature to reassign the assignee to default.
Source Code Contribution
Getting the Scout Sources
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
For an overview of the current Scout releases see https://eclipsescout.github.io.
Patches (new features or bugfixes) should be contributed using Gerrit. (You do not need to attach a patch file to bugzilla anymore.) Setup your development environment, make your changes and push to gerrit. See Git Workflows instructions on how to push your code.
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 1000 lines of code
- make sure you have signed the Contributor License Agreements
- If your contribution is larger than 1000 lines of code we need to fill in a contribution questionnaire and open a corresponding IPZilla bug
- If the license 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 pushed a Gerrit change and are not satisfied with its 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
We have moved the majority of the Scout documentation from the Eclipse wiki to AsciiDoc hosted on GitHub https://github.com/BSI-Business-Systems-Integration-AG/org.eclipse.scout.docs which will be published on GitHub.io: https://eclipsescout.github.io.
We encourage Eclipse Scout developers and contributors to take the "better to ask for forgiveness than permission" approach to adding and updating the Scout wiki or the AsciiDocs.
Forum to AsciiDoc
A forum thread has a very short life time (sometimes some user use the search engine, but it is not always the case). As the ascii doc 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 an ascii doc (e.g. Scout Technical Guide). 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 ascii doc is kept up to date. When a Forum Topic is summarized into an ascii doc, 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 Scout documentation. 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 technical guide. Then answer the forum’s question by adding a link to the newly created chapter.
AsciiDoc 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 documentation, but it is sometimes not possible to control where the discussion takes place. If there is/are (roughly) matching existing documentation but the person responding the forum thread does not have the necessary time to amend this existing ascii doc at least add a link from the ascii doc page to the forum thread.
Nominations for committer status can be created in the committer portal. Nominations should follow the according to the Eclipse wiki guidelines. 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.
- Ralph Steiner, January 2017, pmc approval
- Paolo Bazzi, January 2017, pmc approval
- Michael Rudolf, January 2017, pmc approval
- Thomas Plüss, May 2016, pmc approval
- Arthur van Dorp, March 2016, pmc approval
- Patrik Bänziger, January 2016, pmc approval
- Nathan Burgherr, August 2015, pmc approval
- Matthias Otterbach, August 2015 pmc approval
- Christian Rusche, August 2015 pmc approval
- André Wegmüller, December 2014
- Adrian Sacchi, Mai 2014
- Reto Aschwanden, Mai 2014
- Matthias Nick, January 2014
- Christoph Schwank, May 2013
- Oli Schmid, May 2013
- Bruno Koeferli, May 2013
- Adrian Moser, Dezember 2012
- Beat Schwarzentrub, Dezember 2012
- Jeremie Bresson, Dezember 2012
- Ken Lee, August 2012
- Stephan Merkli, August 2012
- Matthias Villiger, September 2011
- Claudio Guglielmo, September 2011