Thanks, Henri.
My feedback.
* Generally positive with an aversion to anything involving significant work
for the sake of a "cleaner Jakarta". By this I mean that I like the idea of
a flatter hierarchy and a clearer message to the public as to what Jakarta
is about. As I noted on the Velocity list, 4 years ago I discovered
Velocity after identifying Jakarta as a "cool Java project resource" and
then browsing through every project looking for useful libraries. We should
encourage that.
* I'm skeptical about the "common build and web site" part of your plan.
Seems like an awful lot of reorg work for little purpose. Many sites have a
maven site build. Who is going to integrate all of the projects so that the
individually desired features appear on each site. Same for building.
Velocity has a mildly customized build script that compiles differently
under JDK 1.3 and JDK 1.4/5. If we go to a "master web site and build"
this will make it too difficult to introduce changes to the proces and will
stifle innovation. Better to keep this at the subproject level. (Note:
Jakarta-wide style guidelines with common fonts, colors, logos would be a
great idea though).
* Also, I'm against changing the project names. Velocity (for example) is a
recognizable brand name. Calling it "Jakarta Template Language" or
something similar would be foolish.
* On a positive note, establishing a standard template for web site format
and build would speed up the introduction of new subprojects. We could
migrate the common subprojects to a standard, and encourage new subprojects
to use it. But if a group wants to modify this template for one piece of
it - why not? (as long as they keep some common Jakarta fonts, colors,
etc).
Best, WILL
----- Original Message -----
From: "Henri Yandell" <[EMAIL PROTECTED]>
To: "Jakarta General List" <general@jakarta.apache.org>
Sent: Tuesday, January 10, 2006 1:12 AM
Subject: Notice of intent.... #2
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.
* 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. 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.
* No svn authentication beyond being in the jakarta group. Velocity coders
have rw access to POI.
* 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.
* 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.
-----
Shout, scream, yell :)
Hen
On Mon, 12 Dec 2005, Henri Yandell wrote:
dum de dum de dum.....
Just to be public so that it doesn't look like I'm sneaking around
trying to manipulate things.
--
I'm starting to open the question of TLP on many of the Jakarta dev
mailing lists. It's with a general plan where we would see another
half a dozen subprojects move to TLP and then really leave Commons as
the main entity inside Jakarta along with some commons-like components
that are currently subprojects.
I've been talking unofficially with lots of people at ApacheCon, so
I've had a fair bit of feedback on various bits. The important part is
that the loose plan above finds a way to coalesce the Jakarta
community into a much tighter, more TLP e like project.
I've talked with a couple of board members to feel out things would
be. One question being, is it a problem if we're pushing a TLP with
just a few committers. The answer I had was that Excalibur is the
example TLP, it's rather dormant and it's not a problem.
I was also advised to be a bit more active in pushing forward. I think
this makes sense, a lot of our cross-community activity is gone
because people with high activity tend to move to TLP, so we need a
bit more drive to get things done. Thus the change of tack that I'll
be trying to pull off without getting hung :)
Please discuss, argue, wibble; but what I'm looking for are active
ways forward instead of maintaining the status quo. I don't think the
status quo is good for Jakarta as an entity, it puts strain on our
oversight because the number of subprojects stretches the chair's and
community in general's ability to keeps things covered.
*denies the blindfold and stands against the wall waiting*
Hen
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
