|
|
| (75 intermediate revisions by 10 users not shown) |
| Line 1: |
Line 1: |
| − | = Introduction =
| + | We are now on GitHub! You'll find the new contribution guide here: https://github.com/eclipse-scout/scout.rt#contributing |
| − | | + | |
| − | 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:
| + | |
| − | # 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 provide some public feedback
| + | |
| − | ## Read/ask questions on the Scout [http://www.eclipse.org/forums/eclipse.scout Scout Forum]
| + | |
| − | ## Report these bugs/enhancements via [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;product=Scout Scout bugzilla]
| + | |
| − | # 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 [http://wiki.eclipse.org/Bug_Reporting_FAQ 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:
| + | |
| − | | + | |
| − | * [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=RESOLVED;bug_status=VERIFIED;product=Scout&columnlist=bug_id%2Cbug_severity%2Cpriority%2Ctarget_milestone%2Cbug_status%2Cresolution%2Ccomponent%2Cassigned_to%2Cshort_desc All open Scout bugs]
| + | |
| − | * [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;product=Scout&columnlist=bug_id%2Cbug_severity%2Cpriority%2Ctarget_milestone%2Cbug_status%2Cresolution%2Ccomponent%2Cassigned_to%2Cshort_desc All Scout bugs]
| + | |
| − | | + | |
| − | == 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=175222 drastic example] (taken from [1]) reads as follows:
| + | |
| − | | + | |
| − | : <i>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...</i>
| + | |
| − | | + | |
| − | [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:
| + | |
| − | * [https://bugs.eclipse.org/bugs/bugwritinghelp.html Eclipse Bug Writing Guidelines]
| + | |
| − | | + | |
| − | == Open a Scout bug ==
| + | |
| − | When you cannot find an existing bug, feel free to open a new bug:
| + | |
| − | | + | |
| − | * [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Scout Open a new Scout 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:
| + | |
| − | | + | |
| − | {| border="1"
| + | |
| − | ! 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 [http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use 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 '+'''' (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
| + | |
| − | * 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
| + | |
| − | | + | |
| − | === 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 ===
| + | |
| − | * 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 =
| + | |
| − | | + | |
| − | == Contributing patches ==
| + | |
| − | | + | |
| − | 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]].
| + | |
| − | | + | |
| − | To successfully contribute you also have to follow the Eclipse [http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf 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 [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? ==
| + | |
| − | | + | |
| − | 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]
| + | |
| − | | + | |
| − | = Contributions for Scout Committers =
| + | |
| − | | + | |
| − | == Contributing a patch or feature ==
| + | |
| − | | + | |
| − | Please refer to [[Scout/Contributions_for_Scout_Committers]]
| + | |
| − | | + | |
| − | == Step 7: Apply commits from feature branch to develop ==
| + | |
| − | | + | |
| − | Before we apply our changes from the feature branch to the ''develop'' branch (the development branch of Scout Luna), we decide to make some further changes, commit them into the local feature branch and push them to Gerrit again (please repeat step 6). The new changes for our example are available [https://git.eclipse.org/r/14182 here]. As before, we review and apply these changes into the remote feature branch resulting the Commit History view to display something like this:
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.01.commit.history.png]]
| + | |
| − | | + | |
| − | We now have two commits in our feature branch (remote and local) and both of them will be applied to to the origin/develop branch as 1 commit, i.e. in the Git context we squash our 2 commits from the feature branch into 1.
| + | |
| − | To achieve this goal we reset our local feature branch ''luna_target_bug412011'' to the remote ''origin/develop'' branch by right-clicking and select ''Reset -> Mixed (HEAD and Index)''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.02.reset.mixed.png]]
| + | |
| − | | + | |
| − | Reset-Mixed means that the changes from the feature branch will be made available as ''Unstaged Changes''. In the ''Git Staging'' perspective we move the changes to the ''Staged Changes'' area and commit them locally.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.03.squash.commit.png]]
| + | |
| − | | + | |
| − | The Commit History looks like:
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.04.commit.history.after.commit.png]]
| + | |
| − | | + | |
| − | The local feature branch ''luna_target_bug412011'' is now 1 commit ahead of the ''origin/develop'' branch, so we push this commit to Gerrit as follows: Select ''Push to Gerrit...'' and configure the dialog like this:
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.05.push.to.gerrit.develop.branch.png]]
| + | |
| − | | + | |
| − | Hit Ctrl+Space in the ''Gerrit Branch'' field and choose ''develop'' branch, select ''refs/for/'' in the drop-down field.
| + | |
| − | After a successful code review at [https://git.eclipse.org/r/14189/ Gerrit], we apply this change into the remote develop branch.
| + | |
| − | | + | |
| − | The Commit History should now display a new commit on the ''origin/develop'' branch.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.06.commit.history.after.merging.png]]
| + | |
| − | | + | |
| − | == Step 8: Apply commit from develop to release branch ==
| + | |
| − | | + | |
| − | Assume that the changes from the previous feature branch should also be applied to a release branch, e.g. release/3.9.1. Since we squashed our feature branch commits in the ''develop'' branch, we can just cherrypick the commit from the ''develop'' branch.
| + | |
| − | | + | |
| − | To do this checkout ''origin/release/3.9.1'' to a local branch by right-clicking on the ''origin/release/3.9.1'' and select ''Create Branch...''
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.01.checkout.release.branch.png]]
| + | |
| − | | + | |
| − | The local branch will be named ''release/3.9.1''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.02.checkout.release.branch.dialog.png]]
| + | |
| − | | + | |
| − | Press ''Finish'' and a new local branch should be visible and active.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.03.new.local.branch.png]]
| + | |
| − | | + | |
| − | We will now pick the commit from ''origin/develop'' that we would also like to have in our release branch 3.9.1. Right-click on the commit ''f3ea51c'' and select ''Cherry Pick''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.04.cherrypick.png]]
| + | |
| − | | + | |
| − | The changes are automatically applied and committed to the local release branch.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.05.commit.history.after.cherrypick.png]]
| + | |
| − | | + | |
| − | As explained in step 7, we can push these changes to Gerrit. Right-click on the Scout RT Git repository and select ''Push to Gerrit...'' Enter ''release/3.9.1'' in the ''Gerrit Branch'' field ans select ''refs/for/'' as before.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.06.push.to.gerrit.release.branch.png]]
| + | |
| − | | + | |
| − | Press ''Finish'' and follow the same procedure as described in step 7 for applying the changes in Gerrit to the remote release branch.
| + | |
| − | Note: We abandon the [https://git.eclipse.org/r/14193 change] since this feature is only intended for Scout 3.10 and not for the release branch 3.9.1. However, the main message how to apply changes from the ''develop'' to a release branch should be clear.
| + | |
| − | | + | |
| − | = 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 =
| + | |
| − | | + | |
| − | Starting with Scout 3.9.0 (Kepler) we are using git. See: http://git.eclipse.org/c/scout/.
| + | |
| − | | + | |
| − | {{ScoutLink| Contribution|Scout Git Scripts|Some internal Scout Git scripts}}.
| + | |
| − | | + | |
| − | 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 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].
| + | |
| − | | + | |
| − | == Luna ==
| + | |
| − | | + | |
| − | Eclipse Scout 3.10.0 (upcoming Luna Release)
| + | |
| − | Branch: develop
| + | |
| − | | + | |
| − | | + | |
| − | == Kepler ==
| + | |
| − | | + | |
| − | Eclipse Scout 3.9.1 (upcoming Kepler SR1)
| + | |
| − | Branch: release/kepler_sr1
| + | |
| − | | + | |
| − | | + | |
| − | Eclipse Scout 3.9.0 (Kepler)
| + | |
| − | Branch: master
| + | |
| − | | + | |
| − | == Juno ==
| + | |
| − | | + | |
| − | 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 =
| + | |
| − | 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.
| + | |
| − | | + | |
| − | {| border="1" |
| + | |
| − | ! '''What you type''' !! '''What you see'''
| + | |
| − | |-
| + | |
| − | |
| + | |
| − | <pre><nowiki>
| + | |
| − | {{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
| + | |
| − | }}
| + | |
| − | </nowiki></pre>
| + | |
| − | |
| + | |
| − | {{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
| + | |
| − | }}
| + | |
| − | |}
| + | |
| − | | + | |
| − | === 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
| + | |
| − | {| border="1" |
| + | |
| − | ! '''What you type''' !! '''What you see'''
| + | |
| − | |-
| + | |
| − | |
| + | |
| − | <pre><nowiki>
| + | |
| − | <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>
| + | |
| − | </nowiki></pre>
| + | |
| − | |
| + | |
| − | <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>
| + | |
| − | |-
| + | |
| − | |
| + | |
| − | <pre><nowiki>
| + | |
| − | <source lang="xml">
| + | |
| − | <filter
| + | |
| − | aliases="/process"
| + | |
| − | class="org.eclipse.scout.http.servletfilter.security.LDAPSecurityFilter"
| + | |
| − | ranking="50">
| + | |
| − | </filter>
| + | |
| − | </source>
| + | |
| − | </nowiki></pre>
| + | |
| − | |
| + | |
| − | <source lang="xml">
| + | |
| − | <filter
| + | |
| − | aliases="/process"
| + | |
| − | class="org.eclipse.scout.http.servletfilter.security.LDAPSecurityFilter"
| + | |
| − | ranking="50">
| + | |
| − | </filter>
| + | |
| − | </source>
| + | |
| − | |-
| + | |
| − | |
| + | |
| − | <pre><nowiki>
| + | |
| − | <source lang="sql">
| + | |
| − | select language_id, name
| + | |
| − | from languages
| + | |
| − | </source>
| + | |
| − | </nowiki></pre>
| + | |
| − | |
| + | |
| − | <source lang="sql">
| + | |
| − | select language_id, name
| + | |
| − | from languages
| + | |
| − | </source>
| + | |
| − | |}
| + | |
| − | | + | |
| − | | + | |
| − | = Committer Nominations =
| + | |
| − | | + | |
| − | Nominations for committer status can be created in the committer portal. Nominations should follow the according to the Eclipse
| + | |
| − | [http://wiki.eclipse.org/Development_Resources/HOWTO/Nominating_and_Electing_a_New_Committer#What_Should_a_Nomination_Look_Like.3F wiki guidlines].
| + | |
| − | 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].
| + | |
| − | | + | |
| − | == Preparing Nominations ==
| + | |
| − | | + | |
| − | == Current Nominations ==
| + | |
| − | * [[Scout/Scout_Nomination_CSC|Christoph Schwank]], May 2013
| + | |
| − | * [[Scout/Scout_Nomination_OSC|Oli Schmid]], May 2013
| + | |
| − | * [[Scout/Scout_Nomination_BKO|Bruno Koeferli]], May 2013
| + | |
| − | | + | |
| − | == Past Nominations ==
| + | |
| − | * [[Scout/Scout_Nomination_AMO|Adrian Moser]], Dezember 2012
| + | |
| − | * [[Scout/Scout_Nomination_BSH|Beat Schwarzentrub]], Dezember 2012
| + | |
| − | * [[Scout/Scout_Nomination_JBR|Jeremie Bresson]], Dezember 2012
| + | |
| − | * [[Scout/Scout_Nomination_KLE|Ken Lee]], August 2012
| + | |
| − | * [[Scout/Scout_Nomination_SME|Stephan Merkli]], August 2012
| + | |
| − | * [[Scout/Scout_Nomination_MVI|Matthias Villiger]], September 2011
| + | |
| − | * [[Scout/Scout_Nomination_CGU|Claudio Guglielmo]], September 2011
| + | |
