I'd like to note my opposition. I don't have the same vision as you do
and do not wish to be distracted by 100 irrelavant emails a day about
Commons ABCD.
I'm glad Henri posted that "reorganization" things were being discussed.
I would have preferred that he posted a more detailed message as I
think others would likely be opposed to such forms of social
engineering. Things evolve the way the evolve for a reason. That POI
has relatively little to do with Commons-DB is not really a good reason
to force us to listen to noise/interference. In radio, you tend to try
and pick bands that aren't real close together so that you don't overlap
and trample on each other's bandwidth. I had to do this with my
wireless network because my neighbor's stuff kept interferring. No I
don't think it would be great if we both shared channel 6 and I don't
feel like vetting some non-technical irrelevant change by someone who
wanted to get their API used by more projects (nevermind that it
performs half as well as the JDK implementation and sucks down 100 other
dependencies). And I bet [EMAIL PROTECTED] would be
REALLY popular...so popular that ALL questions about POI would go to
[EMAIL PROTECTED] with CC to every email address I've ever had and
appologies for not posting on the list but half the time you can't
unsubscribe and I really don't want 10000 emails a day about stuff I'm
not using.
If projects share obvious common technical ties then it makes sense,
otherwise lets let darwin decide rather than radical social engineering.
The PMC should ASK the individual projects if they would like to share a
common list and set of committers rather than a top down decision
proposed on a list that most committers don't subscribe to (which might
indicate...duh...that they don't want to be on a list mostly not about
their project). This proposal and any that resemble it are non-starters
for me.
A lot of this sounds like Commons trying to remake Jakarta in its image.
As an alternative why can't commons be top level? The namespace is
now free (http://commons.apache.org/).
That is all,
-Andy
Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for
change notification.
The following page has been changed by StephenColebourne:
http://wiki.apache.org/jakarta/OneCommunityProposals
The comment on the change is:
Create page for one community proposals
New page:
This document proposes ways that we as Jakarta can move towards becoming one
community rather than many.
''Note that there is a counter-argument that states that multiple communities
within Jakarta is fine. However, at present this conflicts with the ASF board
opinion and legal structure.''
== Mission ==
Jakarta has a less than completely clear mission at the moment. Here is a
proposed 'mission statement', please feel free to make alternate suggestions:
''Jakarta provides a diverse set of Java-based components which aim to make
day-to-day development easier. The focus is on reusable, small-scale,
single-purpose libraries that can be used directly by your application or by
larger frameworks.''
It would seem appropriate for whatever mission we choose to be on the top of
the Jakarta home page.
== Maililng lists ==
Jakarta has about 16 current project mailing lists. One is very active
(commons) and the rest vary from some activity to very little.
Mailing lists are significant as they represent the primary means of
communication in a project, and thus the primary form of community. Any change
to mailing list structure needs careful consideration.
The aim of any change is to create better oversight of the mature components.
A 'one community' proposal must provide a technique to reduce the mailing list
silo effect, where developers are not interested in other lists (and thus other
parts of the same community).
== Subversion access ==
Jakarta currently gives out SVN access to individual subprojects.
A 'one community' proposal almost certainly involves removing this barrier. Any
Jakarta committer can thus commit anywhere in Jakarta. Social norms will still
act as a barrer to undesirable behaviour.
== Subprojects ==
As developers we tend to abstract and form hierarchies naturally. Subprojects
are a natural outcome of this. However, Jakarta as 'one community' must mean
the end to the term 'subprojects'.
Instead, a focus on many, many components directly at the Jakarta level is the
best viewpoint.
== Practicalities ==
The single-level groupings proposal.
Theory - One community split into groups for practicality purposes (everyone
together would be chaos!)
* Move all commons proper projects up to the jakarta level in SVN and on the
website.
* Commons level infrastructure/pages is dismantled and moved to jakarta-level
* Agree on 4 to 5 groupings for the current subprojects (this is hard!!! it
should ideally be driven by the current component owners)
* The groupings should have bland names - they are not subprojects
* The commons-sandbox moves to be a jakarta concept
* Provide a mailing list for each of the groupings
* Redfine the Jakarta home page to display all the components in Jakarta using
the groupings as a navigation aid
* Use a single mailing list to discuss cross jakarta issues, such as maven
builds etc. This may be jakarta-general or a new jakarta-dev
* No SVN commit restrictions across groups
The aim is for each grouping to be large enough to avoid inactivity, but small
enough to be manageable and to foster community. The proposal also aims to
encourage a significant percentage of developers to be in more than one
grouping.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
