Hi everyone
Now that we've got 14 developers with CVS rights, and we've recently
introduced JIRA, I wish to propose some project management procedures.
These are aimed at making life easier for all of us, and helping the
community to understand our approach to different matters (particular if
running from CVS HEAD). Most of them are based on what is already
happening, yet it seems worthwhile to list them in a single email so
there is some reference.
I invite discussion on these procedures if the community feels there
might be better ways of achieving these objectives. After a period of
discussion, we can implement the finalized procedures. The proposals are:
1. JIRA for this project is located at
http://opensource.atlassian.com/projects/spring/secure/BrowseProject.jspa?id=10040.
Please log a task in JIRA for any changes you make to CVS, with the
exception of very minor changes that users are unlikely to ever be
interested in searching for and/or the change affects code that has
never been in an officially released version of the project (eg ongoing
changes to a new feature in CVS HEAD that hasn't been released previously)
2. Any users running from CVS HEAD are warmly encouraged to join
acegisecurity-cvs so that they can keep an eye on commit comments.
Developers are encouraged to join acegisecurity-cvs and read the commit
comments. If anyone has a concern with any commit, please raise it on
acegisecurity-developers so that the broader community can participate
(not acegisecurity-cvs). Alternatively, contact the author of the change
directly if you think that would be more appropriate or diplomatic.
3. Please make your commit comments informative, yet not too detailed.
Detailed comments are ideally placed in the JIRA task. In the case of a
contribution by a non-developer, please use the CVS commits to reflect
who provided the contribution and add that person's name to /project.xml
in the contributors section. If the contributors section does not list
the name of someone who has contributed accepted code, please add them
or let me know so that I can do so.
4. If you add a major new feature, please announce it on
acegisecurity-developer. That way people using the project have an idea
of what is coming up in the next release, and any
implementation-specific comments can be received prior to the first
release when users will start expecting some degree of consistency and
stability. It also encourages people to try out your new feature.
5. Please edit /docs/xdocs/changes.xml to reflect any changes you
commit. The entry should be short enough so that I can copy it into the
new release announcement email, and reflect the JIRA issue number if
appropriate.
6. Please edit /docs/xdocs/upgrade/upgrade-xx-yy.html if you make a
change that is significant and you think users who are upgrading should
be aware of it. Equally, users are encouraged to consult the
upgrade-xx-yy.html file before they deploy subsequent official release JARs.
7. Please use Jalopy with the /jalopy.xml file to format your Java code
before checkin. This keeps our code consistent and ensures the license
message is correct. There are plugins for all major IDEs.
8. The /sandbox can be used to obtain feedback from fellow developers
and the community about your code, general approach or new ideas. If you
have CVS rights, please use /sandbox instead of emailing ZIP files to
other developers for feedback. The community should understand that code
in the sandbox is unsupported, subject to refactoring, may not have any
unit tests, and may be removed at any time. The /sandbox will never be
included in official release ZIPs. It's a "scratching pad" only.
9.Unit tests are important to any security project, and we have a good
history of high coverage. You can view the latest coverage report
(rebuilt every 24 hours) by visiting
http://acegisecurity.sourceforge.net/multiproject/acegi-security/clover/index.html.
Please keep an eye on coverage and don't hesitate to add more unit
tests. Please do not check code into /core unless it has at least an
exercising unit test - use the /sandbox instead.
10. Never check in code if the unit tests fail. This means, at minimum,
successfully running "maven test:test" from /core. Always name your unit
test classes so they end in "*Tests" - this ensures that Maven picks
them up. If there is code in CVS which you didn't write and it is
breaking the unit tests, please correct it yourself - don't leave CVS
"broken" whilst waiting for the responsible developer to address it (the
delay causes confusing and long-running threads on the list and forum).
You can always rollback to the previous working version if in doubt of
how the class works (just remember to comment the commit appropriately
and let the author know).
11. Please update the reference guide and JavaDocs for any new major
features. The JavaDocs should always be correct. The reference guide
