Salut,
I would like to propose the following rules developer should follow when
committing code in Grizzly (so new developer follow the same rules).
I've attached the proposal. Note that it is just formalizing what every
body is doing right now.
Vote:
[ ] Yes
[ ] Yes, but add the following rule/comments:
[ ] No, because____
Please vote. I want to soon invite new commiters and have something for
them to start.
A+
-- Jeanfrancois
The rules to follow when committing any code in Grizzly consists of:
+ First, open an issue and describe the features/bugs/enhancement/new features you want to commit
+ When committing, make sure you add the following information:
Fix for Issue
https://grizzly.dev.java.net/issues/show_bug.cgi?id=180
("Add Servlet support to the comed-webserver")
Describe the fix you did...
(Optional) Reviewed by
+ Next, commit your work, making sure all the unit tests pass for all modules.
+ Make sure you copy the svn commit revision. That number must be included inside the issue your have filled so peoples interested to read the fix can easily retrieve it using svn:
Fixed:
Sending trunk/modules/bundles/cometd/pom.xml
Sending
trunk/modules/bundles/cometd/src/main/java/com/sun/grizzly/
standalone/cometd/Cometd.java
Sending
Transmitting file data ...
Committed revision 1286.
+ If you are modifying an API signature, make sure you first send an heads up to the dev alias. Changing API signature means we need to bump current version by one, e.g. 1.8.1 will becomes 1.9.0.
+ Never remove a class, but instead deprecate it and move it under the grizzly-compat package.
+ If you are making a major changes, make sure your fix has been discussed on dev.
+ Any changes/designs should be discussed in public, and never privately as the community cannot follow if private.