Henri Yandell wrote:
As a second email in the Notice of intent series; here's what I think
being a Jakarta component will be like in the future.
* Jakarta is a collection of components. Hopefully all sitting at the
same level. ie) a big bag of things.
How are you defining "component"? Something reusable? Something you
build applications with? Something like a commons component? If that
is the case, then Jmeter, Cactus, Velocity et al would have to go TLP.
Is that part of the plan?
* Groups exist. These are categorically not subprojects, but a way to
allow for slicing of the website etc. Some groups may have their own
mail list; thus the importance of making sure they don't become
subprojects. An important rule will probably be that they must do
votes on the main list.
Hopefully we can keep it at a point where the groups are really just
there to refine the flow of mail, not to separate it. HttpComponents
is an example of this (though not a good one as most of its components
came from HttpClient). WebComponents (formerly hoped to be known as
Silk) is another example.
Commons would be groupalized out.
Not sure I understand exactly what you mean here, but if it means
breaking commons up - even the list - I think we should think very
carefully about that. From what may be a selfish perspective - and
which I will back off from if the rest of the community feels otherwise
- I think getting feedback from the full group of commons committers and
voluneers *really* helps those of us who work on commons components. I
am afraid that if we break up the dev list and we don't all just agree
to subscribe to all of the sublists (really defeating the purpose), we
will both have a harder time building community around components and we
will lose some valuable feedback. We will also have less collective
energy to apply to things like the site, how we think about versioning
and releases, etc. We are developing a pretty good body of collective
experience developing small java components and I think that if we
"split up" now we may be losing something.
Hopefully. Groupings are not vague names - HttpComponents good, Silk
bad. CoreComponents good, Turbine bad. The idea with that being that
boring grouping names are intentionally dull, no subcommunity
identification.
+1 - as we at least used to state in the commons charter ;-)
* No svn authentication beyond being in the jakarta group. Velocity
coders have rw access to POI.
+1
* Improved Committer->PMC process. Chair's responsibility (I've failed
at this so far) is to turn around the new committer process. A new
committer of 6 months is effectively voted against going to the PMC,
not for. Might not be able to make it exactly that way, but the idea
being that joining the PMC is the exception, not the norm. Personally
I'd like to see committership be removed if people repeatedly are not
allowed onto the PMC.
Not sure about this one. I am OK with kicking off the nomination more
or less automatically, but would prefer that it be a postive vote.
* Application of Commons thinking. Not entirely sure on this one as I
think we've overcomplicated things in Commons a bit; but things like a
common build system, common site system etc.
* Sandbox becomes a Jakarta resource, not a Commons resource. Much of
the same rules as it has currently. Probably a separate mailing list.
I agree with Martin's comment on this.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
