commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-commons Wiki] Update of "JakartaCommonsEtiquette" by SimonKitching
Date Thu, 12 May 2005 07:14:45 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette

------------------------------------------------------------------------------
  
  The sandbox is a space provided by Jakarta for the development of experimental code by existing
committers. It is divided into components. 
  
- Any Jakarta committer has the right ask for karma and have it granted. The right place to
ask is on the commons-dev mailing list.
+ Any Jakarta committer (not just commons committers) has the right ask for karma (commit
access) and have it granted. The right place to ask is on the commons-dev mailing list.
  
- Components cannot be released from the sandbox.
+ Components cannot be released from the sandbox. This means no binaries posted anywere on
the apache site as "0.x" releases, as this implies that Apache supports the released code.
Users of sandbox code are expected to extract the latest source from the source code repository
and build the code themselves.
+ 
+ Commit access to the sandbox is unfortunately '''not''' available to people who are not
existing Jakarta committers, no matter how good their idea. Such projects are generally encouraged
to start somewhere like sourceforge.net. Once a solid community has been established and existing
projects are using the component, it may be possible to integrate the project direct into
commons if the project developers feel that is appropriate, and the commons community feels
the component is a good fit with commons goals.
  
  = Sandbox Etiquette =
  
@@ -48, +50 @@

  
  There is one important point about the list on the STATUS file. It is used to work out whose
VOTEs are binding. (Since there are a lot of commons committers, this is more useful than
it might first seem.) If you're name isn't on the list, your vote won't count :)
  
+ For components that use '''Maven''' as their build tool (and that is most of them now),
you should add your name to the developers list in the project.xml file rather than the STATUS
file if you intend to work on a component.
+ 
  = VOTEs =
  
  The commons-dev mailing list is a busy place. Very much a bazaar rather than a Cathedral.
This means that VOTE threads have a habit of petering out. It a good idea to post a <tt>[VOTE][RESULT]</tt>
which counts the binding VOTEs and tells people the result. 
@@ -60, +64 @@

  
  Promotion to the commons proper is not the only route out of the sandbox. The commons proper
isn't always the best place for all components from the sandbox.  There isn't any reason why
a component couldn't move directly from the sandbox to become a project or a subproject. At
least one component has moved from the sandbox to sourceforge and then finally back to the
incubator. 
  
- Promotion is basically a beauty contest. If the component can win enough votes and few enough
people vote against it, then the component is promoted. But there is one thing that is most
definitly required:
+ Promotion is basically a beauty contest. If the component can win enough votes and few enough
people vote against it, then the component is promoted. But there is one thing that is most
definitely required:
  
  * Compliance with Apache Software Federation policies. This means a full license at the
top of every file. It means auditing the dependencies. It means ensuring the copyright date
is correct on the licenses.
  
@@ -70, +74 @@

  
  * A good PROPOSAL. A good PROPOSAL is clearly written and tightly scoped (ie. specific rather
than general). Commons components are small, resuable components. The commons does not do
frameworks and anything frameworkesque is likely to be viewed with scepticism. A PROPOSAL
that duplicates an existing component will probably be viewed with suspicion. This is not
because duplication is disallowed (overlapping components are specifically allowed by the
charter) but because it indicates that the PROPOSAL fails to indicate the essential difference
between the proposed component and the existing one. For example, a PROSPOSAL for a small,
fast, compact xml-object mapper with minimal dependencies would be more likely to succeed
than a PROPOSAL for 'a better version of commons-digester'.
  
- * The health of the development community. Fellow committers need to be persuaded that users
will be supported and the code pushed forward by the listed committers. This is a major issue
since there's only a limited amount of energy amongst the commons committers and no one wants
to have to support a component whose committers have gone AWAL.
+ * The health of the development community. Fellow committers need to be persuaded that users
will be supported and the code pushed forward by the listed committers. This is a major issue
since there's only a limited amount of energy amongst the commons committers and no one wants
to have to support a component whose committers have gone AWOL.
  
  * The people proposing the component. It's a sad fact of life but a PROPOSAL that comes
from well known and respected Apache committers is more likely to be viewed positively than
a PROPOSAL by people not well known to the Commons Team. Please don't get offended - you'll
just need to work that little bit harder.
  
@@ -84, +88 @@

  
  * Please give the proposal enough time to give everything the chance to VOTE. I leave promotion
VOTEs several days - maybe up to a week. When VOTEs have stopped coming in then please the
proposer should post a <tt>[VOTE][RESULT]</tt> giving counts. Only the VOTEs of
commons committers are binding so please make sure that these are tallied separately. The
reason why a result email is good is that VOTE thread tend to peter out and so without a final
email, it's hard to look back through the archives and find out what's happened. Another reason
is that it's a good way to let everyone know what the result was. If there are any disagreements
about the result, they can be resolved then. 
  
- 

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


Mime
View raw message