Here are my proposal to refresh the development approach and follow and consistent coding style across the code base.
== Use git-flow as a branching model ==
I know that the Virgo wiki recommends a similar "branch on feature" branching model which however
does not comply with the git-flow notation. I would recommend to use the git-flow notation because:
* it's widely used, should reduce the learning curve for contributors and future committers
* it's natively supported by the git-flow command line scripts
* it's supported by an optional EGit plug-in
== Use a uniform style for writing commit messages ==
I would like to suggest that we follow the GIT recommendations for commit messages.
Main points are summarized here.
* First line is the summary line (see below)
* Then a blank line
* Remaining text is the detailed description
Write commit detailed description in the imperative: “Fix bug” and not “Fixed bug”
or “Fixes bug.” This convention matches up with commit messages generated
by commands like git merge and git revert.
Further paragraphs come after blank lines.
Bullet points are okay, typically a hyphen or asterisk is used for the bullet, preceded by a single space.
All lines should not exceed 72 characters to improve commit message readability from the command line.
== Use a standardized commit message template ==
I propose to leverage on mylyn bugzilla connector and egit connector to enforce standard commit messages in the code base and comply with the previous recommendations.
I suggest the following template mylyn commit template:
-----------------------------------------------------------------
Task #${task.key}: ${task.description}
<detailed description here>
-----------------------------------------------------------------
Items in ${} will be replaced by mylyn using the corresponding values of the task that is active in the mylyn task list.
If you don't use mylyn and egit, you can create a file with the content below eg. ~/.gitmessage.txt
Run the command 'git config --global commit.template ~/.gitmessage.txt
-----------------------------------------------------------------
Task #task.key: <task.description>
<detailed description here>
-----------------------------------------------------------------
== Use SonarQube for static code analisys ==
We already share formatting preferences for server and IDE.
I think we should also introduce SonorQube and the SonarLint plug-in and agree on a set of rules to be applied.
== Use JDT Null Analysis ==
I would also recommend to use JDT Null Analysis capabilities and properly annotate code with
@Nullable, @NonNull, @NonNullByDefault as required.
--
Gian Maria Romanato
<gm.romanato (at) gmail (dot) com>
