Mailing-List: contact dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jakarta.apache.org
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.220.172 as permitted sender)
MIME-Version: 1.0
Date: Thu, 6 Oct 2011 00:39:40 +0100
Message-ID: 
 <CAOGo0Va8s46dTqb+063hAVEQz0VS7CS1oJoo3=r3oKR0VuumAQ@mail.gmail.com>
Subject: Welcome to Jakarta and JMeter!
From: sebb <sebbaz@gmail.com>
To: Philippe Mouawad <philippe.mouawad@gmail.com>
Cc: Jakarta Developers List <dev@jakarta.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Welcome to Apache Jakarta and JMeter!

==

[This is a brain dump in no particular order and is open to discussion]

First: decisions are made on the public mailing lists (or occasionally
on Bugzilla issues for technical issues).
Apache code is open source, and so are the related decisions.
The only exception is for reports of security issues, but that is
unlikely to be relevant for JMeter.
Also personnel matters - election of new committers etc - happen on
the PMC private list.

The developer list (this list) is for development issues; usage
questions should be confined to the JMeter User list.

Code layout: follow the existing conventions of classes; generally 4
spaces indentation (never any tabs).
We don't use @author tags in source code. Credit can be given in the
changes list if required.
Don't use the $Date: $ SVN tag - it is displayed in the default
Locale, which causes problems when comparing source code with SVN.

Make sure you have configured SVN defaults correctly, see [1]

Each commit should deal with a single issue.
Ideally all the updates needed to fix an issue or implement a new
feature should be added in a single commit, including the
documentation and test cases.
However, sometimes this would result in a very large commit, in which
case try to break it down into smaller self-contained commits.

Remember that the commit messages may be reviewed by many people, so
- use a log message that helps the reader understand the reason for the commit
- don't mix different fixes in a single commit

When fixing a Bugzilla issue, remember to include the Bugzilla details
in the commit message, and it helps to add the SVN commit message
summary to the Bugzilla issue when resolving it.

SVN log messages should be regarded as temporary, as a means to
understand the reason for the commit.
They should not be used to document the code.
ASF code is released as source code, and it should not be necessary to
have to read the SVN logs to understand the code.
The SVN logs might not be available to the end-user - and SVN log
messages can be modified; any previous log message is lost.

Change logs should not be added to source files; that's what SVN history is for.
Nor do Bugzilla ids need to be added to the source code except where
it helps explain the code.

Code layout fixes such as tab removal and indentation fixes should
generally be done in a separate commit.

Javadoc can be omitted for trivial getter/setter methods, but
otherwise should be present. (yes, there are lots of methods which
need Javadoc still!)

All new files created at the ASF should have the AL header.
If you have not created the code yourself, please check that it is OK
to commit it.
Short patches submitted via Bugzilla are OK, but anything substantial
may need additional documentation.

If you want to work on a new feature that changes a lot of files, it
might be worth doing so in a branch; just e-mail the dev list first to
say what you are proposing.

JMeter-specific issues
================

It is important to maintain upwards compatibility of JMX files, so
don't change any constants that are used to define the JMX attributes.
When adding new attributes, ensure that the default value is also
defined as a constant; this can then be used to ensure the attribute
is omitted if using the default value.

Likewise, the output sample result XML files have a specific format.
These files may be read back by JMeter listeners, and may be processed
by various different 3rd party tools and scripts.
Changes to the fomat need to be upwards compatible or a lot of JMeter
users will be seriously inconvenienced.

JMeter runs in GUI, non-GUI, and in client-server mode. GUI classes
should only do processing that is relevant to the GUI, or problems may
occur when the test plan is run non-GUI.

The JMeter code is split into several different source trees, which
are combined into different jars.
These are built in a specific order; care must be taken not to
reference "later" methods from "earlier" classes otherwise a clean
build will fail.

JMeter code is 100% Java, and should run on any OS with a compatible JVM.
OS-specific code should only be used to fix problems on that specific
OS; code that only works on a specific OS - OS-specific extensions -
are out of scope for JMeter.

The Ant build script has a "test" target which exercises most of the
code; if making a non-trivial change please run this before
committing.
However if you do manage to break the code, the Gump test run will
find it soon enough.

[1] http://www.apache.org/dev/version-control.html#https-svn-config

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org