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>
