Re: Jakarta at the center of the (ASF) universe

2007-11-19 Thread Ted Husted
I would tend to agree with Jim. The commit rights never attached to
Jakarta but only to a specific subproject under the Jakarta
umbrella. There has never been any such thing as a Jakarta committer,
only committers to current and former Jakarta subprojects. Likewise,
there is no such thing as an ASF committer. The codebase commit rights
attach to specific TLPs.

As mentioned elsewhere, the first graph might be even more interesting
if the threshold was lowered, even to just one committer in common.

-Ted.

On Nov 18, 2007 4:10 PM, Jim Jagielski [EMAIL PROTECTED] wrote:
 On Sun, Nov 18, 2007 at 01:58:29PM -0500, Geir Magnusson Jr. wrote:
 
  But that's the fact - that most of JavaLand sprang from jakarta...
 

 Jukka's graph shows committer cross-polination, not *codebase*
 cross-polination (as I understand it)... So yes, since most
 committers for most ASF java projects were in Jakarta (since
 those projects were *in* Jakarta, after all), I still think
 that the non-Jakarta page provides a more accurate representation
 of the real dynamics, by removing the artifical aspects of
 Jakarta.

 Of course, I could be wrong :)
 --
 ===
Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
 Great is the guilt of an unnecessary war  ~ John Adams

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Is there interest in an integrated development infrastructure built using Java open source products? (was: Suggestion to use OpenGrok... )

2007-09-04 Thread Ted Husted
On 9/3/07, Henri Yandell [EMAIL PROTECTED] wrote:
 Personally I'd ask the reverse question of the Fisheye users. Can
 OpenGrok serve the same purpose?

 If so, then we should stop using the commercial app and move to the open app.

Following up on similar comments made by various people on various
threads, perhaps we should consider assembling a complete Java open
source stack for use as an integrated development infrastructure. The
stack could use Harmony and Derby as a foundation, with products like
James, Tomcat, Daisy, Roller, EyeBrowse, OpenGrok, Scarab, and
Continuum running in between. The product niche would compare to
SourceForge, Google Code, CollabNet, and so forth.

We could test and document the system, and bundle it up for
distribution to the general public. (Perhaps relying on Maven as a
distribution mechanism, a la AppFuse.) Of course, we could also make
the platform available to interested ASF projects. Ultimately, some of
us might be using the same development infrastructure at our day jobs
that we use for Java work at the foundation.

The Cocoon group is already running Daisy in a zone, and we also have
a Continuum running in a zone, but here the idea is that we would have
a full suite of  ASF and related products running together, over
Harmony, as a single offering.

If we take the perspective that we are going to distribute the
platform to the general public, and perhaps deploy the platform here
for our own use, then the initiative would seem to fall within the
scope of a PMC or lab.

Thoughts?

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Suggestion to use OpenGrok to index all Jakarta source code

2007-09-03 Thread Ted Husted
Would FishEye serve the same purpose?

 * http://fisheye6.cenqua.com/

There is already a procedure for using FishEye with an ASF project.
First, ask on infra@ for permission to have cenqua.com setup a FishEye
instance for your project. Then, contact  [EMAIL PROTECTED]
and ask them to add your project, and include a copy of the post from
[EMAIL PROTECTED]

ATM, the only concern seems to be that the initial indexing occur over
the weekend. The administration is handled on the cenqua.com side, and
so our group is not directly involved.

Meanwhile, Atlassian has acquired Cenqua Products, and we're told that
Atlassian is  working on integration components with JIRA and other
Atlassian products. The integration products are expected to be open
source, and so we will be able to use them here as soon as they are
available.

-Ted.

On 9/1/07, Alf Høgemark [EMAIL PROTECTED] wrote:
 I have a number of times missed an an easy to use web interface for
 searching through all Jakarta source code and subversion change logs,
 and to also being
 able to see line number and subversion change log history for a
 particular file.

 The OpenGrok tool ( http://www.opensolaris.org/os/project/opengrok/ )
 seems to me to be very useful in that respect.
 So I would like to suggest that OpenGrok is set up to search and index
 the Subversion repository at http://svn.apache.org/repos/asf/
 OpenGrok seems to be a lot more useful than what is currently available
 using a web browser to point to http://svn.apache.org/repos/asf/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Commons moving to TLP

2007-06-06 Thread Ted Husted

FWIW, I'd like to change my vote to +1.

The existence of a Apache Commons project devoted to Java doesn't
automatically preclude the future existence of an Apache Ruby Commons
or Apache .NET Commons. After all, the project names are only labels.
Should another application for a TLP Commons be made, my hope would be
that our Java commons would be predisposed to sharing the host name
with our fellow volunteers, should such a request be made.

-Ted.

On 5/10/07, Ted Husted [EMAIL PROTECTED] wrote:

On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
 [ ] +1 I support the proposal
 [ ] +0 I don't care
 [x] -1  I'm opposed to the proposal because...

I do not feel the draft resolution adequately addresses several
remarks made in the discussion thread.

The resolution should address issues raised as to the scope of the PMC
and the use of the commons namespace. Comments on the other thread
included remarks like

* We'll do whatever the community wants to do. If someone proposes a
Ruby library and we have a community interested in creating and
supporting a Ruby library, then it would of course be strongly
considered. 

and

* Multiple PMCs, one website. So we'd have Java Commons, Ruby
Commons, BobsYourUncle Commons PMCs, and they'd all share a
commons.apache.org website.

But, as it stands, the resolution implies that the proposed PMC will
be excluded to Java and would own both the top-level Commons project
name and the commons.apache.org namespace. Neither remark is
addressed.

If we are open to a TLP Ruby Commons or DotNet Commons, then we
should reflect that openness in the resolution and in the project
name. We can't use Java (been there, Sun complained). But we can
preserve the Jakarta name, and leave the door open for an top-level
Apache XML Commons or a top-level Apache C# Commons. So why not the
Apache Jakarta Commons Project?

Or, if we intend that this PMC provide oversight for components in
other languages later, then we should strike the word Java from the
resolution now, and clarify our intent.

Time is not of the essence, and I believe we should define the scope
of the PMC and the commons.apache.org host name and namespace now,
rather than create FUD later. It took five hundred email messages to
create the commons in the first place, and we can spare a few more to
get the TLP resolution right.

My suggestion is to

 * amend the Project name to Apache Jakarta Commons PMC.

and setup shop as commons.apache.org/jakarta

Let the focus of this PMC remain on Java, but, in the Apache spirit of
openness and collaboration, make way for other Apache Commons projects
in other languages.

-Ted.




--
HTH, Ted http://www.husted.com/ted/blog/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-30 Thread Ted Husted

On 5/26/07, Henri Yandell [EMAIL PROTECTED] wrote:

Ack in terms of driving a community away because it is unable to meet
our arbitrary criteria.


That sort of thinking just seems so Borg to me. It's another way of
saying that a software product only has value if its hosted by the
ASF.

If a subproject, or even a project, is down to one or two committers,
and those committers can't find a third, and don't want to apply to
the Commons or declare the product dormant, then setting up shop on
GoogleCode is an excellent alternative. I've done the same myself, and
it's not the least bit painful. In many ways, it's joyful.

It might even be healthy if more ASF committers were involved with
other hosts. The ASF may be a cult, but it should not also be a fetish
:)

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-26 Thread Ted Husted

On 5/25/07, Henri Yandell [EMAIL PROTECTED] wrote:

4) Goto code.google. Ack :(


I wouldn't discount GoogleCode (or Java.net or SourceForge or
CodeHaus). Right now, there's a GoogleCode site that I use everyday,
and it's been utterly reliable. There's features I miss, but the UI is
so convenient, I don't mind. We are not Borg, and not every software
product need live under the ASF umbella.


Jakarta2 - A flattened commons-like umbrella which in terms of change
means a flattened dev@ list and svn changes. What I don't know is
whether people are going to be demanding that the subsites look the
same; ie) need to mavenize each project and adjust the site. The
easiest way to deal with things will be to move the other subprojects
into Commons and reestablish the Project.


This is probably just an unfortunate turn of phrase, but we can't just
move anyone anywhere.  The Incubator PMC is not going to accept any
code without volunteers to go with it.  Likewise, we can't do anything
about the subproject websites without volunteers to do that work too.
But, as a PMC, we could ask infra@ to create a shared mailing lists to
replace the others, and make karma adjustments.

Here's my take-away from Henri's post. The Jakata PMC, as it stands
today, could set a deadline for the remaining subprojects to make
other hosting arrangements (TLP, Commons, Google). Otherwise, on a
date certain, we would create single Jakarta Dev and User lists for
all the remaining subprojects to share, and open karma to all the
subprojects to all the Jakarta committers, in the style of the
Commons.

In other words, create a TLP,  join the Commons, or become a commons.

One other alternative would be for the active committers to those
remaining subprojects to draft their own resolution proposal for
creating a new Jakarta PMC, and boot the rest of us out. :) Though, if
anyone wanted to make that happen, I'd suggest making it happen for
the June board meeting, to coincide with the Commons proposal.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Commons moving to TLP

2007-05-26 Thread Ted Husted

On 5/23/07, Niall Pemberton [EMAIL PROTECTED] wrote:

Committ access and being a PMC memeber are 2 different things - its
been mooted that we should carry over the current Jakarta commit list
for Commons (which I'm in favour of) - but that would be for the PMC
to decide if its formed. Retaining someones commit access is a passive
thing which is OK - making someone responsibe for a new TLP needs
their consent IMO.


As to the point of active consent, did each and every individual
listed on the proposed resolution either actively consent in an email
message on an ASF list, or add their own name to the list?

In other words, what was the source of the initial list of PMC
members? If there was a thread behind this thread, we should
incorporate it by reference.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-25 Thread Ted Husted

On 5/23/07, Stephen Colebourne [EMAIL PROTECTED] wrote:

In fact, I object to the fact the it seems to be so difficult to escape Jakarta.


:) So far, it's been *much* less difficult than creating the Jakarta
Commons in the first place! Back in the day, we actually had a
separate mailing list just for for the discussions about whether to
create the subproject, and how it would work if we did! :)

So far, the TLP resolution quickly passed by a landslide. Two of us
had reservations about an Apache Commons project that's devoted to
Java, as opposed to an Apache  [Java|Jakarta|Mocha|J] Commons that's
devoted to Java. There were two other negative votes for different
reasons, and almost thirty votes in the affirmative.

Meanwhile, some of us have pointed out that the other remaining
subprojects are within the scope of the Jakarta Commons, and have
wondered if these subprojects would now like to join the commons. Of
course, that could happen before or after the proposed resolution is
offered to the board. But, if it did happen first, that change would
remove any complaint as to using Apache Jakarta Commons as a project
name.


From the beginning, the intent was to submit the proposed resolution

to the June board meeting. There's time yet to see if the other
subprojects want to join, so nothing is being delayed.



I'd encourage people to step back for a moment and look at what Jakarta 
actually is
today. Its a very disparate group of voices pulling in different directions. 
This is a natural
result of the true meaning of Jakarta - the community around the code - 
leaving. There is
no longer any focus within Jakarta. Nor has there been for a *very* long time.


Ummm, you may be confusing cause and effect. Jakarta has been  very
disparate group of voices pulling in different directions for as long
as I've been here, which would be going on seven years. :)

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-22 Thread Ted Husted

On 5/22/07, Craig McClanahan [EMAIL PROTECTED] wrote:

PS:  Yes, of course, there are passionate believers in the development
of particular libraries.  Are there enough to make a viable community
for *any* of the libraries on their own?  Or enough that care about
the Commons ecosystem as a whole to satisfy Apache's notions of
community?  It is not clear to me (any longer) that a commons type
environment fits Apache culture (as it is currently being discussed)
at all.


You're right, it probably doesn't. Towards that end, we should encourage
Commons components with robust communities to apply for top-level
status, so that they can report directly to the Board and have their
own mailing lists. The one list rule is a great equalizer and should
help keep the Commons from becoming another Jakarta.

To support smaller communities throughout the ASF, we may need to
adjust our notion of Committer and PMC Member to include not only
people who can write and apply patches, but to embrace power users
too.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-22 Thread Ted Husted

On 5/22/07, Stephen Colebourne [EMAIL PROTECTED] wrote:


In summary:
a) I believe the status quo is not viable
b) I believe that merging commons into Jakarta merges two mismatched groups


My suggestion was to merge the Jakarta subprojects into the Commons,
not the other way around.

* The remaining subprojects all seem to be reusable components
within the scope of the Commons charter.

* If the remaining subprojects join the Jakarta Commons, then we could
then ask the board to re-establish the Jakarta PMC, using the list
suggested in the draft resolution as the initial PMC.

* The extended Commons group then becomes the new Jakarta PMC.

* The http://jakarta.apache.org/commons/index.html page becomes the
Jakarta home page, and we change the first sentence there to read The
Jakarta Commons project is focused on all aspects of reusable Java
components..

In the alternative, without an anchor subproject, or a ready
initiative to promote Java at Apache, realistically, Jakarta whithers
away.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: ad dormant code: what about matured code? (Re: [PROPOSAL] The future of Jakarta

2007-05-21 Thread Ted Husted

On 5/21/07, Rony G. Flatscher [EMAIL PROTECTED] wrote:

There may be many reasons why a project turned dormant: no interest
(dead technology), committers having gone astray, etc.

One reason that may be special is a project which got developed, is
used, but there is no reason to develop it further. If classifying a
project as matured it still may need fixing of problems and/or
enhancements over time, making it necessary to create a new distribution.

The idea of putting a matured project into the incubator realm does
not sound right to me.


That's is *not* what is being said.

What is being said is that if a codebase loses all of its committers,
and there is no one to nominate new committers, and one or more new
volunteers come along that want to work on the codebase, then those
individuals could become committers by applying to the Incubator.

Anyone who is the position where they have become the last one or two
committers to a codebase should put out a bulletin, first asking for
other ASF Committers to step up, and if no one replies, then
nominating likely candidates from the user list.



Unless there are already rules that mandate that projects that got
developed to a point after which they go into maintenance mode need to
go into the incubator, I would suggest to create a new classification
for such projects.


Again, no one is suggesting that any codebase be unilaterally moved anywhere.

If we are short of committers for a codebase, then what committers
remain should recruit new committers.

If we lose all the committers, and new volunteers come along, then the
Incubator becomes the way that we bootstrap the new set of committers.
When we realize that have no committers, for whatever reason, then
someone should patch the website so that everyone knows where we
stand.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-21 Thread Ted Husted

On 5/21/07, Danny Angus [EMAIL PROTECTED] wrote:

Ok Ownership is perhaps the wrong word, if Jakarta is being
disbanded who provides the oversight?


The same people who provide oversight for any ASF project: The people
doing the work.

If anyone wants Jakarta to be the ASF portal to all of our Java
assets, then make it so.

A commit is the only vote that counts.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-21 Thread Ted Husted

On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote:

That *you* don't see a problem in using the Jakarta name, doesn't mean no one 
has
expressed objections (you even responded to those objections)


Yes, I looked back over the thread, and I stand corrected. You did say
that the use of the Jakarta name in another TLP seemed premature. Do
you still feel that way?

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-21 Thread Ted Husted

On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote:

It's not just you :) It's just too early to do that at this stage, since if it 
is just some
commits
as Teds says, it will be a dead horse. I don't need something formal or 
something, but at
 least get
some attention from the java projects out there if they are willing to help out 
and also
have some
collaboration with David Reid / projects.a.o. It's not worth it if the Apache 
java projects
don't
like the idea and help out at least with their project.
(not suggesting you are of a different opinion though Danny)


Then take it to the next stage. Update the Jakarta home page to
include links to our other Java products that were never part of
Jakarta, like iBATIS, and invite all ASF Java products to use our news
feed. Open the door, and see if anyone walks in.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-21 Thread Ted Husted

On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote:

 Then take it to the next stage. Update the Jakarta home page to
 include links to our other Java products that were never part of
 Jakarta, like iBATIS, and invite all ASF Java products to use our news
 feed. Open the door, and see if anyone walks in.

I am on a different schedule, volunteering on my own terms. In my view doing 
this now is
*way* too premature. I currently only want to invest my time and energy on 
Jakarta and
it's current projects.


That's fair. Every volunteer should scratch their own itch :)

If other volunteers were ready to explore this course of action now,
would you object to someone creating a [EMAIL PROTECTED] portal here by
extending the Jakarta home page?

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-21 Thread Ted Husted

What if the proposal were to create the TLP for the purpose of
reporting directly to the board, but nothing else changed? Would the
project name Apache Jakarta Commons still be a problem for you if
the physical infrastructure remained here, under the Jakarta
hostname?

-Ted.

On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote:

Yep still feel that way. Projects that want to use the Jakarta name, should 
just stay here
till they
are the only one left and after that re-establish the Jakarta Project.

Mvgr,
Martin

Ted Husted wrote:
 On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote:
 That *you* don't see a problem in using the Jakarta name, doesn't mean
 no one has
 expressed objections (you even responded to those objections)

 Yes, I looked back over the thread, and I stand corrected. You did say
 that the use of the Jakarta name in another TLP seemed premature. Do
 you still feel that way?

 -Ted.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-21 Thread Ted Husted

On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote:

One link to a separate page isn't a problem, since I prefer that no major 
changes happen
to the main site at this stage.
Currently I am pretty much dedicated in keeping Jakarta as a brand. And when 
that time
comes to worry about that, I'll work with the people who still have the itch 
and the cycles
to spare. Starting to make it happen now feels like a waste of time, since the 
future of
Jakarta is by no way set at this moment.


Why does it have to be and either/or proposition?

I would think that regardless of what anyone envisions the future of
Jakarta to be, extending the home page to highlight *all* of the Java
products at the ASF would be a Good Thing.

The notion of extending the Jakarta home page so that it can become
the focal point of all things Java at Apache seems orthogonal as to
whether or not Jakarta continues to host subprojects.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-21 Thread Ted Husted

On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote:

It's pretty simple to solve this though (even though repeating myself here) : 
Let (a
flattened) commons become Jakarta..


Then why the concern about the use of Apache Jakarta Commons as a project name?

When the time comes, we could just point jakarta.apache.org at
commons.apache.org/jakarta.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-21 Thread Ted Husted

On 5/21/07, Ted Husted [EMAIL PROTECTED] wrote:

On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote:
 It's pretty simple to solve this though (even though repeating myself here) : 
Let (a
 flattened) commons become Jakarta..


Actually, it might be helpful if you repeated yourself in full, to be
sure we're not talking past each other. For example, I don't know what
flattened means.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] The future of Jakarta

2007-05-16 Thread Ted Husted

On 5/15/07, Danny Angus [EMAIL PROTECTED] wrote:

0/ Do we agree that the end-game is dissolution of the Jakarta PMC and
closure of the project?
  Pro - Draws a line under the reorg effort which has gone on for 3 or
4 *years*.
  Con - Removes the remaining tangible  historic links between former
Jakarta sub-projects.


At the ASF, we let them that do the work make the decisions. (Mainly
because we have to ... otherwise, there would be no one willing to do
the work!)  We can talk about end-games until Sol goes nova, but in
the end the volunteers who do the work will make the decision.

So far, the subproject committers have been deciding to create their
own TLP. Not because the Jakarta PMC said so, but because the
subproject committers said so.

The one proactive step we could take is to set a deadline for other
TLPs to migrate or to find some other home, either as part of another
TLP, or with another project host. Or, we could just wait the
remaining subprojects out, and let nature take its course over the
next year or three.



1/ If so do we wish to preserve the Jakarta brand? (the website and
possibly general@)
   Pro  - As Ted H. says We should stop thinking of Jakarta only as
an entity, and go back to thinking of it as to the ASF synonym for
Java, as originally intended.
   With this thought in mind around 10% of the referrals to
james.apache come from jakarta.apache.
   Con - Others consider that the effort of maintaining the resources
would be unacceptable to anyone.\


The goodness of the Jakarta brand isn't the result of working on the
Jakarta brand. It's the result of fostering healthy communities that
create great software. Now, those communities have gone on to create
their own TLPs, and to create their own brands. Sure, Jakarta has name
recognition. But so does Ant and Maven and Struts and Tapestry and
Velocity.

Essentially, Jakarta was the first incubator. Now we have a top-level
Incubator, and most of our subprojects have gone on to become TLP too.
I think Java at Apache has succeeded beyond anyone's wildest dreams.
Today, the communities we fostered don't need the crutch of an
uber-project. They can stand alone, and for that we should be happy!

But not to worry. Whenever we foster healthy communities that create
great software, we will create another great brand.  It's what we do.
:)




2/ If we believe that the brand should be preserved should the commons
TLP take ownership of the brand (if/when Jakarta PMC is dissolved)
   Pro - Commons is an active community which continues to fulfil the
jakarta==java remit.
   Con - Commons is not necessarily interested in the brand or
maintenance of its resources. (would people from other projects step
up)


At the ASF, great brands are created by healthy communities that
create great software. I would say that the Commons certainly fits
that bill. An excellent way to preserve the Jakarta name would be to
lend it to the Jakarta Commons TLP.  After all, the Commons had a lot
to do with creating the Jakarta brand as it exists today.



3/ If we believe that a commons TLP should not own the brand are any
of the alternative options acceptable?
  - Retain the Jakarta PMC solely to maintain the brand
  - Move ownership of the brand to the prc (should they agree to have it)
  - Move ownership of the brand to projects.apache maintainers


An Apache Jakarta Commons does not obviate a Jakarta federation or a
Jakarta portal. If anything, reuse of the name increases its value. We
can have our cake and eat it too!



 x/ Should we consult more widely the Members and/or the Board?


At the ASF level, when we talk about protecting a brand, we usually
mean give credit where credit is due. Being a meritocracy, we don't
want other people diluting our brand by claiming our work as theirs,
or their work as ours. So long as the Jakarta brand is not being
poached by a third-party, I doubt that anyone else would care. From an
ASF perspective, the only things of value are those things that
attract qualified volunteers. From a marketing perspective, a brand
may attract downloads, but I don't know if it attracts volunteers.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Commons moving to TLP

2007-05-15 Thread Ted Husted

On 5/14/07, Jesse Kuhnert [EMAIL PROTECTED] wrote:

From a practical pov isn't java already associated with the word grouping
commons apache?


To Java folks it is. But, XML has a Commons too, as does Web Services.
A third group tried to create a top-level Commons last year, and
creating Commons for other languages has been discussed in other
places. Once we have a Commons PMC for the Java language, other folks
will want to do the same.


If you need a differentiator I would put it in the commons-net.apache.org or
whatever name instead of soiling the existing branding that has already
been cemented in everyones minds whether people like it or not.


The underlying problem is that Sun won't like us use Java as a
modifier. The reason we use the word Jakarta is because Sun asked us
to find another host name. The brand that is cemented in everyone's
mind is Jakarta == Java.

Speaking as the knucklehead who suggested the Commons subproject
name in the first place, I don't believe it is in the spirit of the
Foundation, or the Commons ideal, for us to assume such a generic name
all to ourselves.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Commons moving to TLP

2007-05-15 Thread Ted Husted

On 5/14/07, Stephen Colebourne [EMAIL PROTECTED] wrote:

Also, from a practical matter, our projects already use org.apache.commons, so 
this is
already recognised in the ASF.


Verbose package names are a Java notion, and they are only relevant
within a Java application. Regardless of whether there are other
{$Language} Commons projects, we could still use the o.a.c package
name.

On 5/15/07, Danny Angus [EMAIL PROTECTED] wrote:

No, that's the point http://commons.apache.org/


I think what's important is that the Java-language Commons PMC not
hijack the top-level hostname space or the top-level projectname space
all to ourselves. If we plan to share the hostname space with other
TLPs, then we all we need to do is make the base URI

* http://commons.apache.org/jakarta

or

* http://jakarta.commons.apache.org

instead. But, we should do that from the beginning, rather than try
and retrofit it later.

The key point would be what modifier to use along with the Commons
moniker. We can't use Java, because Sun will likely complain again.
We could use some other modifier, but we already adopted the term
Jakarta for this very reason.

We can create a Jakarta Commons PMC without affecting the future of
the Jakata PMC. We should stop thinking of Jakarta only as an
entity, and go back to thinking of it as to the ASF synonym for
Java, as originally intended.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Commons moving to TLP

2007-05-13 Thread Ted Husted

On 5/13/07, Martin van den Bemt [EMAIL PROTECTED] wrote:

 I don't see why. As a member of the Jakarta PMC I'm willing to allow
 jakarta-commons.apache.org to use our trademark :-)

The problem is that you will be hijacking the Jakarta name and since the future 
of Jakarta
(and usage of the name) is by no way set, using the Jakarta name in a new 
commons
TLP is for me at this stage a premature call.


We can't hijack what is ours. This vote is not taking place on the
Jakarta Commons-Dev list. It is taking place on the Jakarta General
List, and, AFIAK, it represents a vote of the *Jakarta* PMC.

In the alternative, we hijack the Commons name, which, as others
have pointed out, is already being used by other ASF entities, not to
mention that it was also used by a top-level project, now closed.

* http://commons.apache.org/

I don't know if Henri has discussed the reuse of the Commons TLP name
with the Board, but it's possible not everyone will be thrilled with
creating a new Commons TLP with a different charter (e.g. Java).

Creating a Jakarta Commons PMC avoids overlap with the closed
Commons TLP, and avoids overlap with any future projects that might
want to create a TLP

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Commons moving to TLP

2007-05-13 Thread Ted Husted

On 5/10/07, Henri Yandell [EMAIL PROTECTED] wrote:

 * Multiple PMCs, one website. So we'd have Java Commons, Ruby
 Commons, BobsYourUncle Commons PMCs, and they'd all share a
 commons.apache.org website.

This one was definitely a random suggestion. If we reach a point of
impasse with another commons wanting to start, then I (with board hat
on) think the solution would be to have multiple PMCs and 1 website.
Or maybe that really means a portal and a site behind it. All
hypothetical though - XML Commons is dead, DB Commons never happened
and WS Commons is afaik not highly active. We do own the Commons space
currently.


The suggestion may have been random, but it's sound. We already have
three ASF Commons group, Jakarta, XML, and Web Services. At one point,
some of were working on a dotnet proposal

* http://opensource.atlassian.com/confluence/oss/display/commonsnet/Home

It would be niave to believe that the ASF will not want to create
another Commons for another language. To clear that path, we only need
to include a modifier in the project name as well as the website
address.

As much as I would like to believe we could create a multi-language
Commons project, it just doesn't seem like a realistic goal.
Experience shows that we can have multi-language products (iBATIS,
Logging, Lucene), but experience also indicates that we can't have
multi-language projects with multiple products (Jakarta).

I would suggest that the reasonable path would seem to be to

* keep the focus of the Jakarta Commons PMC on Java,
* keep Jakarta in the new project name, and
* use jakarta-commons.apache.org as the host name.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Commons moving to TLP

2007-05-10 Thread Ted Husted

Then why not just strike the word Java from the resolution now?

-Ted.

On 5/9/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote:

Hi,

I think this was discussed before and the consensus was we will change
the charter if a C# project actually shows up. Jakarta is dying because
there is not enough adhesion between the projects. The binding element
of the commons TLP is currently we are developing Java components. If
there is significant mass in any other language/technology, it is simple
to update the charter later, not to over-engineer it at inception.

Best regards
Henning

On Wed, 2007-05-09 at 15:44 -0400, Ted Husted wrote:
 It would be nice if the proposal allowed for some flexibility as to language.

 We do have several ASF products written in C#, and the notion of
 starting a C# commons has come up a couple of times in discussions
 between open source C# developers.

 -Ted.

 On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
  Sadly a bit too late to make the next board meeting I suspect.
 
  However, here's a vote for Commons to officially request that it move to 
TLP.
 
  http://wiki.apache.org/jakarta-commons/TLPResolution
 
  Please add your name if you're a Commons developer and haven't added
  your name yet.
 
  [ ] +1 I support the proposal
  [ ] +0 I don't care
  [ ] -1  I'm opposed to the proposal because...
 
  Voting will close in one week.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

--
Henning P. Schmiedehausen  -- [EMAIL PROTECTED] | J2EE, Linux,   
|gls
91054 Buckenhof, Germany   -- +49 9131 506540  | Apache person  |eau
Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Commons moving to TLP

2007-05-10 Thread Ted Husted

On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote:

[ ] +1 I support the proposal
[ ] +0 I don't care
[x] -1  I'm opposed to the proposal because...


I do not feel the draft resolution adequately addresses several
remarks made in the discussion thread.

The resolution should address issues raised as to the scope of the PMC
and the use of the commons namespace. Comments on the other thread
included remarks like

* We'll do whatever the community wants to do. If someone proposes a
Ruby library and we have a community interested in creating and
supporting a Ruby library, then it would of course be strongly
considered. 

and

* Multiple PMCs, one website. So we'd have Java Commons, Ruby
Commons, BobsYourUncle Commons PMCs, and they'd all share a
commons.apache.org website.

But, as it stands, the resolution implies that the proposed PMC will
be excluded to Java and would own both the top-level Commons project
name and the commons.apache.org namespace. Neither remark is
addressed.

If we are open to a TLP Ruby Commons or DotNet Commons, then we
should reflect that openness in the resolution and in the project
name. We can't use Java (been there, Sun complained). But we can
preserve the Jakarta name, and leave the door open for an top-level
Apache XML Commons or a top-level Apache C# Commons. So why not the
Apache Jakarta Commons Project?

Or, if we intend that this PMC provide oversight for components in
other languages later, then we should strike the word Java from the
resolution now, and clarify our intent.

Time is not of the essence, and I believe we should define the scope
of the PMC and the commons.apache.org host name and namespace now,
rather than create FUD later. It took five hundred email messages to
create the commons in the first place, and we can spare a few more to
get the TLP resolution right.

My suggestion is to

* amend the Project name to Apache Jakarta Commons PMC.

and setup shop as commons.apache.org/jakarta

Let the focus of this PMC remain on Java, but, in the Apache spirit of
openness and collaboration, make way for other Apache Commons projects
in other languages.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Commons moving to TLP

2007-05-09 Thread Ted Husted

It would be nice if the proposal allowed for some flexibility as to language.

We do have several ASF products written in C#, and the notion of
starting a C# commons has come up a couple of times in discussions
between open source C# developers.

-Ted.

On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote:

Sadly a bit too late to make the next board meeting I suspect.

However, here's a vote for Commons to officially request that it move to TLP.

http://wiki.apache.org/jakarta-commons/TLPResolution

Please add your name if you're a Commons developer and haven't added
your name yet.

[ ] +1 I support the proposal
[ ] +0 I don't care
[ ] -1  I'm opposed to the proposal because...

Voting will close in one week.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How do projects use SVN to manage site documentation updates?

2007-04-24 Thread Ted Husted

The simple answer is that most of us have handled documentation in the
same way as we handle the code. We don't patch tagged code once it is
released, and we wouldn't patch the tagged version of documentation
either. Most often, the website represents the HEAD, so we fix the
HEAD, and upload the latest and greatest version.

Though, that's been an ongoing question: Should the website represent
the HEAD or the latest GA release?

The best answer is: Both.

Each project (or Jakarta subproject) should a segment of its website
intended for the general public. This site would host the GA release
of the documentation, warts and all, just like it were burned into a
CD. (If you want to fix a serious documentation bug, cut a new
release, just as you would with code.)

Another segment of the site, intended for the development group, can
host the latest and greatest version of the documentation. But, it
should be separate and distinct from the GA/General public area.

For example, at Struts, we link to the latest GA release of the
documentation first

* http://struts.apache.org/2.0.6/

But, we also host the HEAD version in the development area of the website

* http://struts.apache.org/2.x/index.html

On the site, we label the link the Struts 2.x draft docs.

The draft/head link stays the same, but each time we issue a new
public release (GA or beta), we create an archive folder for that
release's documentation.

* http://struts.apache.org/downloads.html#PriorReleases

Problems with the documentation aside, a common problem is that people
try to use a feature that's part of a later release, so we keep the
documentation for all the releases handy, so that people can refer to
the correct feature set.

- HTH, Ted
http://www.husted.com/ted/blog/


On 4/21/07, sebb [EMAIL PROTECTED] wrote:

How do projects use SVN to manage site documentation updates for
exisiting releases?

When a new release is created, the site documentation and source files
etc will all be in an SVN tag directory.

I assume that the SVN tags should never be updated once created, so if
problems are subsequently found in the site documentation, and it
needs to be updated, what is a recommended way to do this in SVN?

S///


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Differences

2004-01-14 Thread Ted Husted
On Wed, 14 Jan 2004 09:00:31 -0500, Andrew C. Oliver wrote:
 I understand why you came here to ask this, but its not really a
 good place to ask (its more of an administrative list).  You'd be
 better going and asking each of the projects (who will probably
 send you links to their website).  Generally these messages devolve
 into flamebait because each project feels very passionate about
 their approach (enough to devote real time to developing it in
 fact) so asking them all in a room together what's the difference
 is well...often not pretty.

Actually, this used to be the place where people could ask questions like this, and 
chat about everything under the Java sun.

A while back, we co-opted the General list for use as the PMC public list. And 
subscribes to General have been falling every since. Less than a third of what they 
once were.

Perhaps once most of the Committers are on the PMC list, we can move the 
administrative nonsense there again, and let the General list be the General list 
again :)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Differences

2004-01-14 Thread Ted Husted
On Wed, 14 Jan 2004 09:00:31 -0500, Andrew C. Oliver wrote:
 Yes struts can use things that aren't JSP but is not OPTIMAL for
 that.

Thanks to the Velocity Tools,

http://jakarta.apache.org/velocity/tools/index.html

many people, including myself, find Struts and Velocity to be an optimal combination.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Decision Needed Regarding Wiki

2004-01-09 Thread Ted Husted
On Thu, 08 Jan 2004 19:12:39 -0500, Noel J. Bergman wrote:
 As I noted, we have two different PMC members each expressing an
 opposing viewpoints:

  - The wikis can be changed by anybody, not just committers, and so
 we have a more urgent need to keep many eyes on them, which
 might not be done by a less active project with its own Wiki.
 A single list provides oversight.

  - Having content changes for all projects go to a central list is
 not a good solution because people don't want noise that
 doesn't relate to their microcosm.

 We just need to resolve this issue.  Honestly, I don't really care,
 but other people have expressed opposing views.  Geir is proposing
 that *IF POSSIBLE*, there could be one Wiki with multiple lists
 based upon a URL convention, but that doesn't appear to be
 available today, and implies that he's happy with multiple lists.

--- Noel

The situation is not so different than Bugzilla. Anybody can post to Bugzilla too. 
Committers and PMC Members need to review the Bugzilla reports, and CVS changes, just 
as we should review the wiki changes.

Right now, Bugzilla and the CVS modules, and the DEV lists to which they report, are 
all aligned along subproject lines. So, there being no other clear consensus, I would 
say we should do with the wiki what we do with everything else: Align the wikis with 
subprojects and send the reports to each subproject's DEV list.

Since it is not uncommon for a Jakarta subproject to eventually graduate to a top 
level project, it might be best if we did not bother to nest the wiki's under a 
Jakarta level, since I believe the content may be harder to shift than a mailing list 
or CVS module.

So, the simplest solution seems to be

Allow wiki.apache.org/$subproject
      Notification: [EMAIL PROTECTED]

Here's my +1

If it helped, I'd be happy to migrate by hand what Struts wiki content we have.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] Proactively encourage TLP status

2003-12-30 Thread Ted Husted
- Original message 
From: Geir Magnusson Jr. [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Received: Sun, 28 Dec 2003 16:05:11 -0500
Subject: Re: [PROPOSAL] Proactively encourage TLP status
SNIP/

I never understand why you keep doing this. There is no 'schism'
between the PMC and the community, and no one is proposing it.
I hate to appeal to authority because the ASF charter does provide a
healthy bit of freedom for any given PMC, but for example, if we want
to follow the model of the httpd project, from which the ASF bylaws
were fashioned, and I know you are a vocal proponent of the 'ASF Way',
it is my understanding they invite committers onto the PMC after some
time after receiving committership when it's clear that is appropriate
for that person. Committing != oversight.
There are people who are committers that may not wish to participate on
the PMC. We want everyone to, but if they aren't *interested* in doing
it, putting them on the PMC achieves nothing, and actually, IMO,
weakens the PMC. There are all sorts of valid reasons to not want to
be on the PMC, I suppose, and we should never stop inviting that
person.
100% should be the goal, not the requirement.



The schism is that the PMC did not elect our committers. In the normal 
course, the body that elects the committers also decides which 
committers (or other interested parties) merit inclusion in the PMC.

However, Jakarta has not done things in the normal course. The PMC did 
not select most of the committers: the subproject communities did. And 
when our community selected the committers they expected that these 
individuals would be the ones actively managing the codebase. The 
community expected these individuals to have the rights and 
responsibilities we now abscribe only to the PMC.

I believe from the ASF perspective

  committing==voting

and

  committing==oversight

Every time a committer commits, they vote for the code they commit. Most 
often, it a vote subject to lazy consensus, and in rare cases it might 
not be binding. But, it is vote nonetheless.

Every time a committer commits, they either donate code to the ASF or 
facilitate a donation, and they incur the obligation to ensure, to the 
best of their ability, that this is IP that can be donated to the ASF.

If we have a committer that does not accept these obligations, then a 
misunderstanding has occurred, and such committers should step down. The 
ASF does not grant write-access lightly. I think people understand that.

In the normal course, virtually all ASF committers are PMC members, 
because its the committers make the decisions and do the work.

It is true that on occasion an ASF committer will not yet be member of 
the project PMC. Their votes may not be binding, and their commits will 
be scrutinized by PMC members (which is to say other members of the 
development team). But, in due course, the PMC that made them a 
committer also makes them a member.

When our community elected all of our committers, it was with the 
understanding that they were the ones with binding votes, that they were 
the decision makers, that the Jakarta Committers were, in practice, the 
Jakarta PMC.

In my humble opinion, it is the duty of the PMC to now ratify the 
decisions our community has already made. Since we now know that the PMC 
is *not* a steering committee and is in fact the active managers of the 
codebase, we are obligated to finish the job our community started: give 
the committers the legal rights and responsibility that we always 
believed they already had.

Make the committers the PMC, because they are the only true PMC that we 
have ever had.

Each and every one of our committers have earned their stripe. They have 
all proven to the community that they are thoughtful, responsible 
self-starters capable of managing our codebase on the community's 
behalf. These are the individuals that have been creating, maintaining 
and releasing the products we all cherish. These are the individuals 
that have been doing the true work of the PMC.

Where things have gone wrong, they have gone wrong because we were still 
using a bootstrap PMC that excluded all but a few of our decision 
makers. I'm sure that there are Jakarta committers that would be 
unwilling to serve on a bootstrap PMC, but serving on a true, 
inclusive PMC may be a different matter.

Right now, the only plan seems to be to nominate committers one-by-one 
on the PMC list. I'm just saying that we shouldn't play favorites. I 
believe all Jakarta committers have already earned membership in the 
PMC; we should tender the offer to every Jakarta committer and let each 
decision-maker decide for himself or herself.

If the consensus is that the bootstrap PMC will continue to hand-pick 
which of our duly-elected committers are promoted to the PMC, and which 
are not, then so be it. But, personally, I think that process is nothing 
but busy work. The community 

Re: [PROPOSAL] Proactively encourage TLP status

2003-12-29 Thread Ted Husted
- Original message 
From: Geir Magnusson Jr. [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Received: Sun, 28 Dec 2003 16:05:11 -0500
Subject: Re: [PROPOSAL] Proactively encourage TLP status

SNIP/

Because the PMC would consist of those doing the active management
(i.e. the active, interested committers) , we have things covered.

All active committers should be interested or else they wouldn't be active 
committers.

Oversight is not some otherwordly task to be conducted by an elite subset of our 
committers. IP oversight is something *every* decision-maker should be thinking about 
*every* time they commit a line of code. Consensus oversight is something *every* 
decision-maker should be thinking about *every* time they post to the DEV list. If 
committers aren't thinking about this now, it's only because they have no reporting 
requirements to remind them.

Our community has already decided who its decision-makers should be: the committers.

The Jakarta PMC doesn't need to second-guess the Jakarta community. We simply need to 
ratify the choices the community, in its wisdom, has already made.

Moving forward, we may want to distinguish between newbie committers and the 
silver-haired PMC members. But, as it stands, when each of these committers were 
selected, they were selected to be *the* decision-makers. They were selected to do 
what the PMC does: actively manage the codebase.

We should trust the judgment of our community, let each committer decide for 
themselves, and then Jakarta be whatever Jakarta wants to be.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] Proactively encourage TLP status

2003-12-29 Thread Ted Husted
- Original message 
From: Costin Manolache [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Received: Sun, 28 Dec 2003 12:12:29 -0800
Subject: Re: [PROPOSAL] Proactively encourage TLP status

SNIP/

Ted, Stephen - you are free to propose or encourage any subproject to do
whatever you want - but please make clear that this is your personal
opinion or proposal ( unless jakarta PMC or the board votes on this ).
But please start with the projects you are dirrectly involved with :-) -
I don't think it's a good practice to act as a parent for childs you
don't know very well.

In Struts, we are discussing the TLP issue,

http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg20416.html

but tabled the discussion pending the 1.2.0 release ... which is where I'll be 
spending most of my volunteer time again.

If Struts does graduate to a TLP, I would update the wiki page based on our own 
experience (if someone doesn't beat me to it) and post a link to all the DEV lists. 
(Unless, of course, the growing consensus changes and the PMC decides to do such a 
thing itself.)

As mentioned, my core concern is that everyone concerned has been given due notice of 
the disconnect between the original Jakarta guidelines and the status quo. As one of 
the early PMC members, I am partially responsible for that disconnect and need to 
discharge my own responsibilities to the community.

As for the rest of it, I've said my piece, and I'm happy to let Darwin and Consensus 
decide.

Thanks for all the fish. :)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Indemnification of the PMC

2003-12-28 Thread Ted Husted
- Original message 
From: Danny Angus [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Received: Sat, 27 Dec 2003 22:58:55 +
Subject: RE: Indemnification of the PMC

Seems to me that part of the reason it is difficult to resolve the issues confronting
Jakarta is that several initial assumptions are required, and that these are not 
stated or
clearly implied anywhere.

Greg assures us that the board aren't likely to act precipitately (if thats how you 
spell it),
and we haven't had official communications from The Members of The Board on the
topic, yet there are a lot of hints about the unsuitability of Jakarta's present 
organisation.

I think we could do with some concrete direction, or at least an affirmation of our
mandate to continue what we are currently doing. Because to me it is increasingly
feeling like we're trying to fix something which (apart from a few details like the 
bylaws)
isn't broken on the basis of speculation and conjecture, and the danger in that is
obvious, we'll end up breaking the thing we're trying to fix, or failing to fix the 
parts which
are broken.

And with the utmost respect for Sam hopefully that is something a new Chairman, with
more time and fresh enthusiasm for the role, will be able to provide.

Well, first, the idea of consensus is at the core of the Apache culture. Consensus 
means that everyone involved has agreed that a course of action is the best available. 
It may not be everyone's first choice, but it is a solution everyone can live with.

Consensus is not something that is easy to represent in a list of rules and 
procedures. It's a process of human engineering and difficult to reduce to writing. It 
would even be harder to reduce to writing for every community. Communities are like 
all other human relationship. Each one is a little bit difference, and, in human 
terms, the little differences can mean a lot.

Now, with Jakarta, there seems to be a belief that we should be following a 
deterministic process with definitive procedures. Elsewhere in ASF land, there's a 
feeling that if you need to call upon a formal procedure (say, by exercising a veto), 
then consensus has failed. When this happens, many Apaches might feel that the real 
problem isn't the technical issue underlying the veto, but the consensus issue 
underlying the *need* to veto.

Procedure is a fail-safe. Achieving consensus through discussion is the nominal 
process.

The Apaches on the board don't like to make dictates, since dictates defeat consensus. 
They are not our bosses as much as they are our colleagues. They want to us to sort 
this out for ourselves. Because, if we can't sort it out ourselves, then we're not 
building a community that can endure. Tough love.

As for what we are suppose to be doing here, the board has already made two mandates. 
One in section 6.3 of the bylaws  http://apache.org/foundation/bylaws.html and 
another by resolution http://tinyurl.com/3x6rs.

The PMC is responsible for the active management of the Jakarta codebase. Part of good 
management is effective oversight http://tinyurl.com/2eyvg, which is to say solving 
little problems before they become big problems.

We know oversight is failing because we've had to take some drastic measures over the 
years. One subproject could not resolve an issue, either through consensus or by 
following the voting process. As a result, a committer lost his write access. By 
Apache standards, having to do such a thing is a red-letter scandal. Consensus 
oversight failed.

We've also had to temporarily restrict access to CVS modules because of unresolved IP 
issues. All the issues were resolvable and should have been resolved *proactively* 
rather than *reactively*.  IP oversight failed.

There is no doubt that the Jakarta subprojects are healthy. Every project has its 
hiccups, and Jakarta is no exception. But, we seem to lack a mechanism that allows  
issues of consensus and IP  to come to to forefront *before* it is too late. The 
infrastructure club is our final fail-save, employed as a last, desperate measure.

Denying access to resources is a black-mark that screams oversight has failed. It's 
not an oh well that we can sweep under the rug and forget about.

Other ASF projects have fewer lines of code to worry about, and most, or all, of the 
committers are on the PMC. If a committer/member has a problem, he or she can bring it 
up directly on the PMC list, without having to find an intermediary or post a 
sensitive observation on a public list.

IMHO, we need to put aside the maverick guidelines posted at Jakarta and just try to 
do things the ASF Way.

* We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* 
the committers, and

* We need to insist that all subprojects file regular reports, with some statutory 
bullets to ensure everyone is still thinking about consensus and oversight.

If anyone reading this message agrees, 

RE: [PROPOSAL] Proactively encourage TLP status

2003-12-28 Thread Ted Husted
+1

I agree that interested volunteers should:

* setup a Wiki area describing the TLP process and rationales , AND

* give notice to each and every Jakarta DEV list that the area exists.

My main beef is that we have not done due diligence in alerting ALL of the subprojects 
of the latest developments.

I've outlined a wiki page as described by this proposal 
http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCTopLevelProjectApplication, 
and setup a draft TLP resolution.

I would also volunteer to subscribe to each of the DEV lists and post a message 
pointing them to the archive of this thread. (Unless another volunteer already has an 
account setup to do such things. )

Whether a subproject follows through or not can be totally up to each subproject. The 
important thing is that we do the due diligence in making sure *everyone* concerned 
has been apprised.

-Ted.


- Original message 
From: Stephen Colebourne [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Received: Sun, 28 Dec 2003 14:39:30 +
Subject: [PROPOSAL] Proactively encourage TLP status

There has been considerable emphasis on this list over recent weeks for the
sticking plaster approach. That is to make small minor changes to Jakarta in
the hope the board will stop hassling us. This could be because this is the
consensus view and I'm an odd one out. Or it could be that those in favour
of multiple TLPs just can't be bothered with the arguing. So I thought I'd
place the alternative proposal on the table. If you like it, +1 it.

SNIP/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] As it ever were (draft 2)

2003-12-28 Thread Ted Husted
 -PROPOSITION (1)-

 * Require all Jakarta products (or subprojects) to file regular reports
 with the PMC.
You mean 'make each subproject work like a TLP' don't you?

 Since the PMC cannot delegate its responsibilities, the report would
 have to be prepared by a PMC member, ideally one directly involved with
 subproject. (A likely suspect being the DEV list moderator.)
Er, doesn't this just emphasise how broken this process is?

 -PROPOSITION (2)-
 [snip]
 Work regarding a specific subproject can continue to occur on that
 subproject's DEV list. PMC members (aka committers) following that list
 can vote on its releases and other day-to-day affairs. So long as the
 minimum quorum is met, the vote is legal and binding.
So, we are trying to delegate power to subprojects? Er, but we can't now can
we.

So who can vote? 'Following the list' is a very vague term. Presumably I can
simply subscribe to struts-dev and then vote, never having even used struts?
It also seems highly dubious to say that a vote is legal and binding if most
of the PMC never knew the vote occurred.

 Under proposition (1), the significant events occurring for each
 subproject would be reported to the PMC list, for the review of the PMC
 at-large.
So the PMC is reviewing events already happened, not actively managing. Er,
sounds like the relationship between the board and a PMC to me.

 PMC membership is voluntary. Anyone can resign from the PMC at any
 time. If a volunteer would like to be a committer, but not a PMC member,
 then each subproject can then decide whether to support separate
 committer and PMC member roles or not.

--
I would suggest that there is nothing in this proposal that will cause the
board members to have any more faith in Jakarta than they do now. And thats
because it changes nothing of significance.

Stephen








-
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]



Re: [PROPOSAL] As it ever were (draft 2)

2003-12-28 Thread Ted Husted
- Original message 
From: Stephen Colebourne [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Received: Sun, 28 Dec 2003 14:16:26 +
Subject: Re: [PROPOSAL] As it ever were  (draft 2)

 Since the PMC cannot delegate its responsibilities, the report would
 have to be prepared by a PMC member, ideally one directly involved with
 subproject. (A likely suspect being the DEV list moderator.)

Er, doesn't this just emphasize how broken this process is?

Not that I see. It formalizes what should have been done from the beginning.

We tried to do it before, but we then run into the politics of whether the person 
making the report is the PMC representative to the subproject.

The fundamental disconnect is that all of the committers should be on the PMC, because 
all of the committers are the decision-makers for one or more of our various products.


 -PROPOSITION (2)-
 [snip]
 Work regarding a specific subproject can continue to occur on that
 subproject's DEV list. PMC members (aka committers) following that list
 can vote on its releases and other day-to-day affairs. So long as the
 minimum quorum is met, the vote is legal and binding.

So, we are trying to delegate power to subprojects? Er, but we can't now can
we.

No. We are instituting a minimum threshold meritocracy for each product. The PMC 
members/committers who are working on a product, and interested in its development, 
and the ones who make the decisions about that product. That's how it works now 
socially, and that's how it should work legally.


So who can vote? 'Following the list' is a very vague term. Presumably I can
simply subscribe to struts-dev and then vote, never having even used struts?
It also seems highly dubious to say that a vote is legal and binding if most
of the PMC never knew the vote occurred.

As it stands today, any of the current PMC members could do exactly that.

And, this is also how it works in the Commons today. If I want to chime in on a 
product and start committing, other volunteers are happy for the help.

If you did subscribe to the Struts list and took an interest in the product, I'm sure 
we'd welcome your commits. You're an Apache Committer, and I'm sure you've earned your 
stripe. Not by trying to do harm, but by trying to do good.

The value of administrative [vote]s on the DEV list are often overrated. A veto must 
have technical merit to be binding. Malicious vetos are not valid. And, as you know, 
when someone tried to enforce their own will over the will of the community, the 
ultimate result (sadly) was a suspension of write access.


 Under proposition (1), the significant events occurring for each
 subproject would be reported to the PMC list, for the review of the PMC
 at-large.

So the PMC is reviewing events already happened, not actively managing. Er,
sounds like the relationship between the board and a PMC to me.

No, the committers to each subproject are committee members. Most Apache projects 
practice a minimum threshold meritocracy. We don't expect every committer to be 
involved in every decision, or cast votes or opinion outside their area of interest or 
expertise. If three committers/members vote +1, we're good to go.

The PMC was not meant to be a legislative body: it's suppose to be the core group, the 
decision-makers, the active managers, the committers.


 PMC membership is voluntary. Anyone can resign from the PMC at any
 time. If a volunteer would like to be a committer, but not a PMC member,
 then each subproject can then decide whether to support separate
 committer and PMC member roles or not.

I would suggest that there is nothing in this proposal that will cause the
board members to have any more faith in Jakarta than they do now. And thats
because it changes nothing of significance.

It changes everything. It turns Jakarta from a place that is supposedly governed by an 
other wordly elite to a place that practice minimum threshold meritocracy -- both 
socially and legally. Today our social order is out-of-synch with our legal status. 
This proposal legalizes what already happens in practice.

* It provides a forum where ALL the decision makers can discuss oversight (not just a 
chosen few).

AND,

* It puts reporting in the lap of the decision-makers for each product, which ensures 
it stays on the *decision-makers* radar, and is not pushed up to some body that cannot 
possible oversee our products.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Indemnification of the PMC

2003-12-28 Thread Ted Husted

On Dec 28, 2003, at 8:43 AM, Ted Husted wrote:

 * We need to put *all* the decision-markers on the PMC. At Jakarta,
 that means *all* the committers, and

No, it doesn't.  We need to put as many as possible, hopefully all, but
it's not required to be all.  We can also have people that aren't
committers on the PMC.


 * We need to insist that all subprojects file regular reports, with
 some statutory bullets to ensure everyone is still thinking about
 consensus and oversight.

Erm, I'm not so sure that this needs to be legislated like this.


 If anyone reading this message agrees, or disagrees, please respond to
 the As it ever were proposal  under another thread. Let's see if we
 can build a consensus and then create and maintain a solution that
 works.

 IMHO, the ASF Way *will* work if we let it; we've just never tried to
 let it.

I don't think that anyone is debating if the ASF works.  I think we all
know it does.  I think we disagree what the ASF Way is - I think it
simply requires inclusive participation on the PMC of those willing to
feel responsible for more than just the code they are working on,
namely project direction and oversight.  Thus, the PMC does not
necessarily mean forced 100% committer participation, although that
percentage is the goal, nor does it mandate strict reporting schedules
and reporting content and format.

I do believe that if we continue on the way already started - ensuring
CLAs, putting as many active Jakarta committers on the PMC as are
interested, educating them as to their oversight role, then we would be
in a much healthier position and able to then grapple with the
day-to-day PMC process.  Until we achieve the former, the latter is
somewhat of a intellectual game.  As you like to point out, we all are
adults working for the best interest of the organization.

Please work with us on this.

geir

--
Geir Magnusson Jr   203-247-1713(m)
[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]



Re: [PROPOSAL] Proactively encourage TLP status

2003-12-28 Thread Ted Husted

On Dec 28, 2003, at 10:25 AM, Ted Husted wrote:

 +1

 I agree that interested volunteers should:

 * setup a Wiki area describing the TLP process and rationales , AND

Do you think we all should setup our own individual Wiki page, or work
together?  I'm getting the feeling you don't want to work together on
this.


 * give notice to each and every Jakarta DEV list that the area exists.

 My main beef is that we have not done due diligence in alerting ALL of
 the subprojects of the latest developments.

What 'developments'?  We are discussing things here on general@, and as
far as I can see, we have no developments yet.  Ted, you seem to be in
a terrible hurry to push this through.  Can you wait until people come
back from the holiday break and read and catch up?  the point of doing
things here is to *increase* participation, not reduce it by rushing
something through during a generally world-wide western holiday.


 I've outlined a wiki page as described by this proposal
 http://nagoya.apache.org/wiki/apachewiki.cgi?
 JakartaPMCTopLevelProjectApplication, and setup a draft TLP
 resolution.

 I would also volunteer to subscribe to each of the DEV lists and post
 a message pointing them to the archive of this thread. (Unless another
 volunteer already has an account setup to do such things. )

Instead of doing it yourself, why not try to work w/in the PMC
structure and get a message that we all agree on, and have one person
from each project on the PMC send to their community.  It would be a
good step in the direction you just were espousing in a different
thread, namely increased participation.


 Whether a subproject follows through or not can be totally up to each
 subproject. The important thing is that we do the due diligence in
 making sure *everyone* concerned has been apprised.

LOL. There is no legal requirement that any arbitrary idea that a
person has *must* be propagated directly to the dev list of each 
sub-project.  Let others join in this...


 -Ted.


 - Original message 
 From: Stephen Colebourne [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Received: Sun, 28 Dec 2003 14:39:30 +
 Subject: [PROPOSAL] Proactively encourage TLP status

 There has been considerable emphasis on this list over recent weeks
 for the
 sticking plaster approach. That is to make small minor changes to
 Jakarta in
 the hope the board will stop hassling us. This could be because this
 is the
 consensus view and I'm an odd one out. Or it could be that those in
 favour
 of multiple TLPs just can't be bothered with the arguing. So I
 thought I'd
 place the alternative proposal on the table. If you like it, +1 it.

 SNIP/



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


--
Geir Magnusson Jr   203-247-1713(m)
[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]



Re: [PROPOSAL] Proactively encourage TLP status

2003-12-28 Thread Ted Husted
- Original message 
From: Geir Magnusson Jr. [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Received: Sun, 28 Dec 2003 11:11:07 -0500
Subject: Re: [PROPOSAL] Proactively encourage TLP status

On Dec 28, 2003, at 10:25 AM, Ted Husted wrote:

 +1

 I agree that interested volunteers should:

 * setup a Wiki area describing the TLP process and rationales , AND

Do you think we all should setup our own individual Wiki page, or work
together?  I'm getting the feeling you don't want to work together on
this.

Steve made a proposal I supported, so I demonstrated my support by pitching in.

AFAIK, there's no such thing as a personal wiki page (which Steve has already 
proven).


 * give notice to each and every Jakarta DEV list that the area exists.

 My main beef is that we have not done due diligence in alerting ALL of
 the subprojects of the latest developments.

What 'developments'?  We are discussing things here on general@, and as
far as I can see, we have no developments yet.  Ted, you seem to be in
a terrible hurry to push this through.  Can you wait until people come
back from the holiday break and read and catch up?  the point of doing
things here is to *increase* participation, not reduce it by rushing
something through during a generally world-wide western holiday.

I had some time over the holidays myself, so I put together a proposal that reflected 
how I believe we should proceed. Other people responded to that, so I made some 
changes and issued another draft. There were other threads that seemed related to that 
proposal, so I tried to draw them together to see if we could build a consensus.

All I've done is make a proposal for the community to review at its leisure. If a 
consensus were to develop, I'd volunteer to move it along. If not, the kids need shoes 
...


 I've outlined a wiki page as described by this proposal
 http://nagoya.apache.org/wiki/apachewiki.cgi?
 JakartaPMCTopLevelProjectApplication, and setup a draft TLP 
 resolution.

 I would also volunteer to subscribe to each of the DEV lists and post
 a message pointing them to the archive of this thread. (Unless another
 volunteer already has an account setup to do such things. )

Instead of doing it yourself, why not try to work w/in the PMC 
structure and get a message that we all agree on, and have one person
from each project on the PMC send to their community.  It would be a
good step in the direction you just were espousing in a different
thread, namely increased participation.

Committers commit. I believe it's something that should be done, so I volunteered to 
do it.

I also mentioned if someone else were ready and willing to do it, I'd be happy to step 
aside.


 Whether a subproject follows through or not can be totally up to each
 subproject. The important thing is that we do the due diligence in
 making sure *everyone* concerned has been apprised.

LOL. There is no legal requirement that any arbitrary idea that a
person has *must* be propagated directly to the dev list of each
sub-project.  Let others join in this...

My point is that  there is a social and ethical requirement to inform the committers 
of the status quo. There are many ways in which the points covered on the 
http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges wiki page 
conflict with the original guidelines.  The only way to ensure everyone is aware of 
the status quo is for a posting to be made to every DEV list. Since I've served on the 
PMC,  I feel jointly responsible for erroneous information. I don't discharge my 
responsibilities lightly.

I guess all that I'm really asking is that a posting be circulated to each DEV list 
regarding the proposed changes.  As mentioned, I'd be happy to do this myself, or 
help someone else do it, so long as it was done.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Indemnification of the PMC

2003-12-28 Thread Ted Husted
Mea culpa.

I'm trying a new mail client and managed to press the wrong buttons. Sorry for the 
confusion.

-Ted.

- Original message 
From: Geir Magnusson Jr. [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Received: Sun, 28 Dec 2003 11:19:04 -0500
Subject: Re: Indemnification of the PMC

Is it my mailer that's making a mess here, or is something else going
on?  This is the second message I've seen today that is attributed to
Ted but was written by someone else (in this case me, in the previous
case Stephen)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Indemnification of the PMC

2003-12-27 Thread Ted Husted
- Original message 
From: Stephen McConnell [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Received: Sat, 27 Dec 2003 06:48:59 +0100
Subject: Re: Indemnification of the PMC

If I understand correctly, the opinions of an individual are not the
same as a motion passed by the BOD.  It is my understanding the BOD has
not passed any resolution that grants a PMC member any of the rights
implied by the message quoted below.  In fact, my understanding is that
the role of PMC implies no rights at all - just extra responsibility.

Is there anything concrete to suggest otherwise?

The ASF's authority to indemnify individuals stems from Section 12.1 of the ASF bylaws:

  http://apache.org/foundation/bylaws.html

This section provides for indemnification of directors, officers, and members, as well 
as individuals serving at the request of the corporation 

The theory is that the PMC Committee members fall under the latter clause. Since, the 
corporate resolution only installs the PMC (the argument goes), plain-vanilla 
committers don't fall under section 12.3, since they don't serve at the request of 
the corporation.

Though, section 12.1 does not specify PMC members as such, and so there's some wriggle 
room there. From a legal standpoint, the safest thing is to be an ASF Member *and* 
serve on the relevant PMC. (Something more of us ASF Members need to do this year is 
nominate more Jakarta-bred committers to the ASF.)

For those of you with access to the ASF Members list, there's a good post by Roy dated 
12-Mar-2003 that sums up the indemnification issues as well as the issues surrounding 
the role of the PMC.

According to the ASF Bylaws and the Jakarta resolution,

 http://tinyurl.com/3x6rs

being on the PMC doesn't grant additional responsibility, it grants *all* the 
responsibility. While, in practice, the lowly Jakarta committers now handle the 
active, day-to-day management of the codebase, it is not their responsibility to do 
so.

Personally, I think that this perception that being on the PMC means more work than 
being a committer is a nonsense. Elsewhere, most or all of the committers are PMC 
members. Elsewhere, committers who are not a PMC members are the exception rather than 
the rule. The reason being on the PMC here may seem like more work, is because we are 
*making* it more work than it should be.

Within Jakarta, we've gotten the fallacious idea that the PMC is a steering committee 
that sets the strategic direction for the project. This idea is not based on the ASF 
bylaws or the Jakarta resolution. The guidelines altered the role of the PMC years 
ago, either as a misunderstanding or as an experiment.

The bylaws specifically say that the chairman shall establish rules and procedures 
for the day to day management, which is what our committee spends a lot of time 
trying to do. As for what the PMC is supposed to be doing, the bylaws state that Each 
Project Management Committee shall be responsible for the active management of one or 
more projects.

Within Jakarta, we've trying to fill the chairman role with a committee and let the 
committers take responsibility for the active management of our codebase. (Recently 
subject to the PMC's rubber stamp.)

IMHO, this is why there seems to be a fundamental disconnect between Jakarta and the 
rest of the ASF. We've reduced the chair to a notetaker, given the PMC the chair's 
responsibilities, and given the committers the PMC's responsibilities. Jakarta folks 
and the ASF board folks on not on the same page, and we talk past each other.

Here's how Roy Feilding styles the roles:



project= something the ASF wants to accomplish,
management = making decisions for progress toward a goal, and
committee  = the people voting on decisions



Roy also stated that: The PMC must equal the voters on a given project, or the entire 
theory of delegated authority, responsibility, and oversight upon which the ASF 
depends for legal defense of its contributors [is defeated].

The PMCs were based on the Apache Core Group. The PMC is *not* suppose to be some

  other-worldly land where benevolent beings ponder deep issues and create solutions.

The PMC is them that make the real, day-to-day decisions that foster the project's 
community and create and maintain the project's codebase. At Jakarta, that would be 
the committers -- ALL the committers.

It's possible we might also want to create some type of executive steering committee 
within Jakarta that could do the sort of stuff the current PMC seems to want to do. 
But, we cannot usurp the PMC constituted by the ASF for some other role. We must make 
the PMC what the PMC is intended to be: The committers who make the day-to-day 
decisions.

If we did want to get back to basics, we should start by going back to the HTTPD 
guidelines,

  http://httpd.apache.org/dev/guidelines.html

and make the minimum number of changes needed to 

Re: [PROPOSAL] As it ever were (draft 2)

2003-12-25 Thread Ted Husted
[PROPOSAL] As it ever were

I've incorporated many of the suggestions made on the list and prepared
another draft for community review.
-ISSUE-

The ASF Board has indicated that it does not believe that the Jakarta
PMC, in its present form, is capable of providing oversight of all the
subprojects under its purview.
The role of the Jakarta PMC is two-fold:

* The PMC is responsible the active management of the project

* The PMC provides oversight for the project

-Management-

When the board creates a project, it passes a resolution. Resolutions
regarding Jakarta
have been passed here:

  http://tinyurl.com/3x6rs

and here

  http://tinyurl.com/2zkdb

The board's authority to create Projects and PMCs stems from section 6.3
of the ASF bylaws:
  http://apache.org/foundation/bylaws.html

From a legal perspective, the PMC is the only entity that the board
recognizes as being responsible for the management of a project. Only
committee members have binding votes. Only committee members would be
indemnified by the ASF in the event of a law suit
http://tinyurl.com/3eq9c.

In fact, most of the rights and responsibilities we at Jakarta have
ascribed to committers in fact belong only to PMC members.
Originally, we envisioned the PMC to be a steering committee
http://tinyurl.com/2o2v5, responsible for the strategic direction and
success of the Jakarta Project. But this is *not* the case. The PMC
doesn't just set the agenda, it is the body that *actively manages*
the project. The PMC has the rights and responsibilities that most of us
would ascribe to the subproject committers.
-Oversight-

As used here, the term oversight follows its dictionary definition:

o·ver·sight

   1. An unintentional omission or mistake.
   2. Watchful care or management; supervision
http://tinyurl.com/2eyvg

The board expects PMCs to exercise (2) so as to avoid (1). :) All good
managers must provide oversight, and a PMC is no exception.
For a PMC, oversight boils down to issues of committer consensus and
intellectual property. In the past, there have been incidents at
Jakarta on both counts that lead to suspension of access, for both
individuals and modules (on different occasions).
Jakarta now manages 21 subprojects (with Pluto on the way), and another
40+ components in the Commons and Commons Sandbox, The board's question
is How can the Jakarta PMC, as it is now constituted, possibly provide
oversight for all of this code?.
-CURRENT APPROACH-

The PMC has decided to expand its membership to an indefinite number and
is actively soliciting nominations of qualified committers. So far, the
PMC has rejected the idea of nominating all the committers or any
committers who volunteers. Each new nominee must be voted in by the PMC
(or not).
At this time, no other changes are on the agenda.

For additional background, see

* http://tinyurl.com/226pt

* http://tinyurl.com/2vclu

and the archives for the general list

* http://tinyurl.com/2gq7d or http://tinyurl.com/3cw3e.

-PROPOSED CHANGES-

(1) Require all Jakarta products (or subprojects) to file regular
reports with the PMC
(2) Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc

-PROPOSITION (1)-

* Require all Jakarta products (or subprojects) to file regular reports
with the PMC.
A key element of oversight is vigilance. One way to achieve vigilance is
regular reporting. Just as the board requires the vice president of a
project to file regular reports, the PMC should require each subproject
to file a similar report.
Here is a format often used by projects reporting to the board:



* What code releases have been made?

* Legal issues:

* Cross-project issues:

* Any problems with committers, members, etc?

* Plans and expectations for the next period?



Since the PMC cannot delegate its responsibilities, the report would
have to be prepared by a PMC member, ideally one directly involved with
subproject. (A likely suspect being the DEV list moderator.)
Failure to report would have to be considered a serious matter,
possibly leading to blocking CVS access. Accordingly, each subproject
would want to be very, very sure these reports are in fact being filed.
-PROPOSITION (2)-

* Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc

The original Jakarta guidelines state that committers have the binding
votes and make the decisions regarding the codebase. We now know that,
from an ASF perspective, committers have write-access to the codebase,
but the PMC members have binding votes and make the decisions.
The idea of committers with non-binding votes has been broached many
times over the years. Each time, the consensus has been that we vote
most with our commits, and that every volunteer committing to a Jakarta
codebase is entitled to a binding vote (and veto).
Whenever we selected any committer for any Jakarta codebase, we did so
with the expectation that they would be responsible for its active
management. We were in fact not merely electing committers but PMC

Re: [PROPOSAL] As it ever were

2003-12-24 Thread Ted Husted
My complaint is this:

Our current base of committers were led to believe they have binding 
votes. We are now told this is not the case. The committers we now have 
were all elected on the premise that they had binding votes and 
oversight responsibilities for their codebase. They were in fact elected 
as if they were to be members of the PMC.

Personally, I feel it is an abomination to think we have the right to 
hand-pick a subset of these committers and bestow upon them binding 
votes. Our communities deserve to be represented by the set of 
committers that they have already chosen, not an arbitrary subset deemed 
to be PMC material.

I call for the Jakarta Chair, as the ASF Vice President in charge of 
Jakarta, to do the Right Thing and promote all Jakarta committers to the 
Jakarta Project Managemenet Committee.

Anything less breaks the covenant we made with each and every Jakarta 
committer, as published in the original Jakarta guidelines. We said 
committers had binding votes, and it is now our obligation to make it 
so. If we fail to make a good faith effort to correct our oversight, 
then we will have accepted all these contributions under false pretenses.

If all committers are PMC members, then all committers can then be 
subscribed to the PMC list. Each subproject can be given the 
responsibility of submitting to the PMC list a regular report as to 
their status. Routine business can be conducted in the subproject DEV 
list by the PMC members associated with that subproject. In the event 
there is an unreported oversight issue, any Jakarta Committer/PMC member 
will be able to bring it up on the PMC list at will.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PROPOSAL] As it ever were

2003-12-24 Thread Ted Husted
I apologize for not quoting. I'm experiencing technical difficulties and 
making do the best I can.

I meant what I said. We must make an immediate, good faith effort to 
correct the false and misleading information in the Jakarta guidelines, 
and give all committers due notice of their true status. Otherwise, 
there's a point where we cross the line.

The PMC does not now nor has it ever affirmed each and every decision 
made by the committers. It may affirm some of the release votes, but 
there's a lot that goes into making a release. And, AFAIK, the PMC is 
not authorized to delegate its decision making to non-members.

IMHO, we all thought we had the rights and responsibilities of PMC 
members in the first place. When each and every of these committers were 
appointed by a subproject, they had the traditional role of a PMC member 
in mind. Hence, the proposal is to make all Jakarta committers PMC 
members, which, I believe, was the underlying intent of the original 
guidelines, and what we all thought was happening in the first place.

I reject the idea that being a PMC member brings additional 
responsibility. All committers are already responsible for 
decision-making and oversight. We simply need a mechanism that reminds 
everyone of our existing responsibilities.

If all committers are subscribed to the PMC list, and each subproject is 
given the explicit responsibility for regular reporting, I sincerely 
believe we will be able to easily dispatch the oversight issues. All we 
need is a little infrastructure, and the volunteers will take care of 
the rest.

A long-standing principle at Jakarta has always been that the highest, 
best votes are the commits. We have always rejected the idea of 
committers without binding votes. To say now that votes are socially 
binding but not legally binding is inconsistent with community standards.

I am happy that we do have communities that will honor the votes of all 
its committers, whether they are legally binding or not. But, our 
legalities should reflect the community standards, which are that a 
committer is a committer.

Obviously, if a committer wants to opt-out and become a developer again, 
that is their choice. But we should not be second-guessing the 
communities by opting-in committers to the PMC. The community thought 
they were good enough to have binding votes and binding vetos: who are 
we to say different?

I've proposed my solution: Promote everyone who doesn't opt-out to the 
PMC; subscribe all committers to the PMC list; require regular reports 
from each subproject.

AFAIK, the only other option on the table is to continue to nominate 
committers willy-nilly and hope-against-hope that a few more heartbeats 
will somehow give the PMC the wisdom to make decisions on the 
subproject's behalf and the mystic ability to oversee all the codebases.

I don't think we need to create a Jakarta elite. I think we need to do 
what we meant to do in the first place: let the committers make the 
binding decisions.

Accordingly, if a positive consensus develops among the committers 
regarding the original proposal, we can bring it as a vote in the 
Jakarta way. Otherwise, I would just let the proposal drop, so that the 
consensus view can proceed.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PROPOSAL] As it ever were

2003-12-24 Thread Ted Husted
(Again, sorry about the quoting.)

o·ver·sight

   1. An unintentional omission or mistake.
   2. Watchful care or management; supervision
http://dictionary.reference.com/search?q=oversight

The board expects PMCs to exercise (2) so as to avoid (1). :)

For a PMC this boils down to issues of committer consensus and 
intellectual property. In the past, there have been incidents at 
Jakarta on both counts that lead to suspension of access, for both 
individuals and modules (on different occasions).

IMHO, if we were to

* require subprojects to file regular reports with bullets regarding 
consensus and oversight, and

* subscribe all committers to the PMC list where these reports are filed

then we'd be able to defuse these happenstances before they turn into 
incidents.

IMHO, the one and only set of individuals that can provide watchful 
care over a codebase is the set of committers we already have for each 
subproject.

IMHO, each and every committer to a Jakarta subproject has already 
passed through a gauntlet that proves they are PMC material and entitled 
to binding votes.

All we need to do is complete the process that promotes our committers 
to PMC members with binding votes, as our original guidelines 
contemplated, and require subprojects to provide regular status reports. 
(Just as the board requires our project to report.)

As both Roy and Greg have said, if the Jakarta committers truly 
understood how few rights and privileges they have, they would be 
demanding both ASF and PMC membership. Few do, so few have.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PROPOSAL] As it ever were

2003-12-23 Thread Ted Husted
 steward

The proposal is to expand the role of the moderator, rather than invent 
an overlapping role with similar responsibilities. If the volunteer is 
not up to task, then another volunteer can be sought. (Hence, the 
language about the Chair appointing another volunteer.) The idea is that 
they have *already* volunteered to moderate the list. If one individual 
doesn't want to volunteer, another can be found.

 delegate

The proposal does not delegate the board's responsibility. To be 
binding, anything voted on any DEV list would still need the a 3+ quorum 
of PMC members. PMC members would be voting on PMC business.

There is nothing anywhere that says all the PMC business has to take 
place on a single list. If PMC members want to subscribe to all the 
lists and monitor all the PMC business, that's their choice. Conversely, 
if PMC members want to abstain from the routine business surrounding a 
given codebase, they don't have to subscribe to that DEV list.

Meanwhile, through the steward's reports, the committee-at-large is 
being kept in the loop as to each subproject's big picture.

The proposal does the things.

* It realizes the fact that Jakarta doesn't have non-binding committers 
(meaning that all committers must become PMC members).

* It provides a clear mechanism for scoping the work of the PMC. The 
business of each subproject can be conducted by people who are in-touch 
with that subproject on that subproject's DEV list.

* It provides a clear channel for oversight.

The steward's reports are designed to ensure that someone is at least 
thinking about these matters on a regular basis. Since it's someone's 
role to report on these things, they are more likely to be reported. 
Some issues we had in the past would not be readily addressed, since all 
the committers will be on the PMC list. A PMC member won't have to go 
off and talk to a subproject and report back. The subproject 
committers can hash issues out on the PMC list, where other members can 
provide input. And, any committer/PMC-member who thought there *might* 
be a problem, can now bring it up directly on the PMC list, whether the 
steward brings it up or not.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PROPOSAL] As it ever were

2003-12-23 Thread Ted Husted
 Make release managers the default stewards

Not every subproject has a clearly defined release manager. In Struts, 
we are even starting to have multiple people collaborate on the release 
manager role.

The key to oversight is persistence. Since it is not possible for every 
committee member to be personally aware of what's happening in every 
subproject, we need regular reports from someone who does -- just as the 
board needs regular reports from each chair.

We don't need for subprojects to have a chair, but we do need someone 
to tender regular reports as to the subproject's status. The keyword 
being regular.

The person making these reports should already have a working knowledge 
of the subproject and be able to report based on what they already know. 
Of course, what they know is based on reading and understanding the 
traffic on the lists.

Ideally, the DEV list moderator should also be someone who is plugged 
into the subproject. So, instead of starting out by creating two roles 
with overlapping responsibilities, I'm suggesting we try extending the 
list moderator's role first. List moderator is the only persistent role 
that must already exist for each subproject's DEV list.

In some cases, we may need to have different volunteers fulfilling each 
role. But, personally, I like to try making do with what we have before 
running out and creating something new.

I also don't want to get bogged down with finding a steward for each 
subproject. The DEV list moderators are there, so let's use them. If a 
list moderator doesn't want to steward, then I'm sure they can find 
someone who does. Hey, we all friends here. :)

The key point is that the chair, and its PMC, need consistent, reliable 
reports, so that the chair can report in turn to the board. We need each 
subproject to fulfill the responsibility of regular reporting by 
whatever means necessary. We also need to push that responsibility down 
to the subproject. The people working in the subproject are the only 
ones truly aware of its status.

Should we encourage subprojects to elect a steward? No. AFAIK, we 
don't elect roles like list moderator or release manager. People just 
step up and offer to do the job -- as it should be. But if a subproject 
wants to a elect a steward, or a list moderator, or a release manager. 
that's their business. All we need is for the job to get done.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


[PROPOSAL] As it ever were

2003-12-21 Thread Ted Husted
Re: Proposal to grandfather Active Committers to Jakarta subprojects as
PMC Members.
As it stands, most Jakarta committers have assumed that they already
have the rights, privileges, and responsibilities granted PMC members.
(Mainly because it was written that way in the Jakarta bylaws).
When all these committers were elected, it was with the understanding
they had binding votes and oversight responsibility, as stated by the
original Jakarta bylaws. It could be said that we have been electing PMC
members, rather than only committers, all along, without realizing it.
Following our original bylaws and practices, there is no such thing as a
committer without the rights and responsibilities of PMC membership.
Accordingly, a stipulation of becoming (or remaining) a committer to a
Jakarta subproject can said to be PMC membership, as it is described by
the ASF bylaws.
To complete the process we've already begun, I suggest a [VOTE] be
brought on each [EMAIL PROTECTED] list to nominate the list of
its active committers to the PMC. This vote will also serve as notice to
committers who wish to opt-out.
To bootstrap the process, the current moderator of each DEV list can be
asked to bring the vote and report the result. If necessary, a new
moderator can be installed by the Chair.
The moderator of each dev list will also act as the PMC steward for
the subproject. The list moderator is suggested since that individual is
already suppose to be monitoring the list where this activity occurs.
The steward will have the responsibility of immediately
reporting any new committers/PMC members elected to a subproject, so
that they can be affirmed by the chair and notice given the board.
All PMC members (which is to say all active committers to jakarta-* CVS
repositories) will be subscribed to the PMC list, which will be a
required list for PMC membership, like [EMAIL PROTECTED]
The PMC business for each subproject will continue to take place on its
own dev list. The steward for each project will report to the [EMAIL PROTECTED] list
the status of his or her subproject, covering such points as:


* What code releases have been made?

* Legal issues:

* Cross-project issues:

* Any problems with committers, members, etc?

* Plans and expectations for the next period?



The chair can then summarize these reports for presentation to the board.

Effectively, each dev list becomes a sub-committee of the PMC. (Divide
and conquer.) The list moderator/steward becomes the subcommittee's
secretary, with the additional responsibility of summarizing the result
of our ongoing meetings.
As appropriate, the steward or any PMC member can bring up oversight
issues to the PMC list. Routine matters, such as releases, can be
approved by the PMC members who are committers to a given subproject. So
long as the usual 3+ quorum is met, there would be no reason to bring
routine votes before the [EMAIL PROTECTED] list. Of course, the result would be
tabulated on the steward's report, which *is* published to the [EMAIL PROTECTED] list.
-Ted.

Pro-forma [VOTE]

It has come to our attention that the Committers to a Jakarta subproject
must also be members of the Jakarta Project Management Committee to have
binding votes. To complete the legal process, the current PMC is asking
each subproject to nominate it's active committers to the PMC.
Since we have never supported the idea of non-voting committers at
Jakarta, and only PMC members have binding votes, if a committer is
unwilling to serve on the Jakarta PMC, we will be unable to continue to
extend write access to any jakarta-* CVS to that individual.
Each PMC member will also be subscribed to the Jakarta PMC list.
*However, all subproject business can continue to occur on this DEV list
as always!* In the future, we anticipate that the PMC list will be very
low-volume. (Really, we do!)
The only change is that the owner of the DEV list must also serve as the
PMC steward for the subproject. The steward must submit monthly status
reports for the project and immediately report any new Committers to the
PMC list.
But, other than that, it will be business as usual.

Accordingly, we ask that the Committers to this subproject nominate the
following individuals to the Jakarta PMC. Please check all that apply.
[ ] $committer

Any committer who wishes to opt-out may notify the Jakarta chair
([EMAIL PROTECTED]). If you opt-out, regardless of the vote, you will not
be subscribed to the PMC list, and your write access to jakarta CVS
repositories will be removed. (Sorry, but it's part of the package now.)
###



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Ted Husted
Geir Magnusson Jr. wrote:
I'd say it the other way around. The ASF is a collection of 
communities that create and maintain codebases. To obtain 
infrastructure support and some legal protection, these communities 
donate the copyright of its software and ownership of its brand to the 
Foundation. In order to provide legal protection and watchdog its 
copyright, the board assigns a vice president to oversee the project. 
A committee is also convened to assist the VP with oversight.


I think this is mostly right, and I say mostly because it's legally 
precise, but in practice, the community tends to be there first, rather
than be convened later, 
Yes, that's what it says. A collection of communities that ... *not* a
collection of codebases.
[SNIP]

A very subtle concept is that the ASF doesn't actually own the 
codebase. The codebase belongs to its community, and under the Apache 
License, that community can always vote with its feet. Since it is 
the community that gives the software its value (by using and 
maintaining it), there is an Apache belief that the community is the 
true owner of the codebase. The ASF just owns the brand and 
yesterday's copyright.


I believe that this isn't right - the ASF does own the codebase via the 
copyright, and the codebase is licensed at no cost to any entity that is 
willing to agree to the terms of the license.  That entity, community or 
otherwise, cannot remove that license or change it unilaterally.
It owns a static image of the codebase, but from an Apache perspective,
a codebase is a living, growing thing with a lifecycle that can endure
for decades.
The point is that without a community, even if it is a stable community
of users helping users, the codebase has no value, and there is nothing 
*worth* owing.

The board may sometimes disagree with a dysfunctional PMC, for the good
of the community, but I don't believe the board would ever deliberately
act against the community.
The point of the exercise is to create communities around codebases,
which means the community always comes first. (Else, there is no reason
to have the codebase to begin with.)
The essential difference between SourceForge and Apache is that
SourceForge is just about sharing code. Apache is about building
communities around the code we share.
The reason a true community (in the Apache sense of the word) has never
coalesced around Jakarta is that the subprojects were too coarsely
grained to share code. So, we invented the Commons.
The difference between Jakarta and Jakarta Commons is that the Commons
has codebases that are *designed* to be shared with a community of
developers and users.
The truly marvelous thing about Jakarta Commons is that its communities 
transcend Jakarta. Everywhere I go in open-source land these
days, I find other projects importing packages from the Commons. Thus, 
our license and style of management is exposed, and fresh blood is drawn 
into the Apache community, so that the cycle of life can continue.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Ted Husted
Santiago Gala wrote:

[SNIP]

This implies that those having easier ability or will to maintain the 
product are the effective owners of it. as in a rapidly changing 
environment, software rot takes care of static code bases.
Exactly. There is a saying from Dune:

Whoever has the power to destroy a thing, owns that thing.

(The case in point being melange.)

The community has the power to effectively destroy the ASF's codebase by 
defecting and reforming elsewhere, leaving the ASF project dormant.

Conversely, the ASF cannot destroy the codebase, since the community can 
just set up shop somewhere else under a new brand.

Meanwhile, the ASF cannot create or maintain the codebase itself, since 
it has neither the resources nor the will.

So, while the static copyright and the brand belong to the ASF, the 
living codebase belongs to the community that supports it.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Ted Husted
Michael Davey wrote:
Jakarta is the *brand*.  It defines itself.  Jakarta brand development. 
A brand can give a unique identity and grouping to an otherwise 
disparate and commodity range of goods and services.  
Apache is a brand too, and, IMHO, a much stronger brand than Jakarta.

I believe Jakarta distracts people from the fact that everything we do 
here is on behalf of the Apache Software Foundation. We are not Jakarta 
Committers, we are Apache Committers. We use the Apache License, 
package our product for apache.org, check code into cvs.apache.org, and 
donate every line to the Apache Software Foundation.

I realize that there are people who have romantic notions about 
Jakarta and like to talk about preserving Jakarta for Jakarta's sake. 
But for the life of me, I can't see why. For me, it's always been about 
the codebase and its community. If a product I use is hosted at 
SourceForge, I work at SourceForge. If it's hosted at Jakarta, I work at 
Jakarta. If it's a top-level ASF project, then I work there. I go where 
my community lives; and my community is centered on a codebase, not a 
hostname.

There are people who have called Jakarta a jewel. I'd agree that 
Cactus is a jewel, as is Lucene, and Velocity, and all the other 
*communities* we've built around our codebases. But Jakarta is not the 
jewel, at best it's a jewelry box.

All along, there have been people who envisioned a Jakarta community. 
But, what's the point of that, really? We already have the Apache 
community and the open source community. Why do we need another 
community within a community? What's the point of another layer of 
indirection?

In my experience, if you make a significant contribution to any open 
source codebase anywhere, its community will welcome you with open arms. 
We don't need hostnames to create communities. People create their own 
communities and forge their own relationships, by the simple virtue of 
their contributions.

And look what's happening with logging: Now that it's a TLP, they are 
bringing-in the various Log4J compatibles. Now, there can be one Apache 
logging project serving every platform. That's community-building!

The real, underlying issue with Jakarta is that most of our products are 
*not* about Java. They are about a feature set. Java was just a 
convenient implementation language, but most of our products could be 
implemented in other languages and made available to a broader community.

In fact, many have, but since they are not Java implementations, we have 
multiple communities around a product instead of one. A language-centric 
project like Jakarta doesn't create community, it dilutes it.

But I would not say that Jakarta is broken. I'd say Jakarta is finally 
starting to work. The proof that Jakarta is working is that products are 
finally growing up and becoming projects.

Every worthy parent's goal is self-sustaining children. The Foundation, 
like a good parent, has always tried to build self-sustaining projects 
-- projects that can outlive their creators. I'm happy that some of 
these projects were born at Jakarta and became great enough to join our 
top-level peers.

So, why are Ant, Maven, Logging, Slide, et al, graduating to top-level 
Apache projects: because they can :)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Ted Husted
Harish Krishnaswamy wrote:
ASF is a group of projects administered by the Apache board members. The 
board delegates certain responsibilities over to the PMCs of the 
individual projects while still maintaining the authority and management 
responsibilities. The PMC is responsible for a wholesome code and 
community of the project it oversees but does not have the authority to 
recognize new projects.
I'd say it the other way around. The ASF is a collection of communities 
that create and maintain codebases. To obtain infrastructure support and 
some legal protection, these communities donate the copyright of its 
software and ownership of its brand to the Foundation. In order to 
provide legal protection and watchdog its copyright, the board assigns a 
vice president to oversee the project. A committee is also convened to 
assist the VP with oversight.

Since the committee is formed by a resolution of the board, its members 
are eligible for legal protection in the event of a lawsuit. Also, since 
the committee is the only formal body created by the board, only the 
votes of committee members are considered binding. In the normal 
course, most or all of the committers are also committee members. 
(Jakarta being an anomaly.)

In most cases, the community's codebase is focussed on a single product, 
and so all the committee members and committers are in tune with what 
is happening with it. The ASF has also been exploring the idea of 
umbrella projects like Jakarta, XML, Database, and Web Services. At 
this time, there is no clear consensus of whether these umbrella 
projects can function as well as the traditional projects.

A very subtle concept is that the ASF doesn't actually own the 
codebase. The codebase belongs to its community, and under the Apache 
License, that community can always vote with its feet. Since it is the 
community that gives the software its value (by using and maintaining 
it), there is an Apache belief that the community is the true owner of 
the codebase. The ASF just owns the brand and yesterday's copyright.

The board is *very* sensitive to the needs of its communities. Software 
versions come and go, but communities endure.

-Ted.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Choosing against Jakarta

2003-12-18 Thread Ted Husted
No worries, mate. The Apache License is the ultimate hedge. No matter 
what happens, you can always set up the source someplace else. The most 
you could possibly lose would be the product name, and, realistically, 
if there wasn't a community behind the product, Apache wouldn't want it 
anyway :)

As an Apache Committer, you can setup a product in the Jakarta Commons 
sandbox whenever you want. (Just like SourceForge.) If you can interest 
other people in the product, and build a community to support it, the 
product can be promoted to the Commons Proper -- or even to the 
top-level of Jakarta or the ASF, depending on the product's extent.

The thing to keep in mind is that you are not donating code to Jakarta. 
You are donating it to the Apache Software Foundation. The ASF is here 
to stay, as are all of its products, no matter where they are hosted. As 
long as a product has a vital, meritocratic community, it's sure to have 
a home at the ASF.

Of course, SourceForge is also a fine place to host a project. I often 
choose SourceForge when the people I'm working with are not ASF 
Committers. This in itself is a good reason to choose SourceForge: you 
can't add ASF Committers at will. ASF Committers must have demonstrated 
a sustained interest in the project and an understanding of the Apache 
Way. Usually this is a good thing, but sometimes it is not.

As far as anything else goes: This too shall pass, but open source and 
the Apache License endure.

-Ted.

Stephen Colebourne wrote:
As some of you may know, I look after my own date and time code in Java at
www.joda.org. I had been hoping to bring this code to Apache, as I believe
it to be a very good fit with developments within Jakarta/Jakarta-commons.
Today I decided not to pursue this option for the time being, until the
situation with Jakarta's future is resolved. Instead I applied for a new
sourceforge project to house it more cleanly.
Why post this here? Because I believe that others may also be questioning
the value of Jakarta. I confess that I have no idea what, or if, Jakarta
will look like in 6 months time. Certainly it made no sense to me to attempt
to get a new project adopted by Jakarta at the moment.
Stephen

-
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]


Re: Why you *want* to be on the PMC

2003-12-18 Thread Ted Husted
To do this, each product would simply need to draft a resolution to 
create the PMC and select a chair, and ask that it be placed on the 
board's agenda for the next meeting, just as Log4J and the others did. 
It would be very important that each product do this themselves, to help 
show they are ready for self-management.

Essentially, each product would still be a TLP, but would just be hosted 
at Jakarta.

This option has always been available, it's just that every product 
since Ant has chosen to have their own hostname and website.

It's also important to remember that some of these products, like Log4J, 
are not just about Java anymore. The Apache Logging project will have 
compatible codebases available for half-a-dozen platforms. (Now *that's* 
community building!)

-Ted.

Dirk Verbeeck wrote:
+1

If this is acceptable by the board then it's the ideal solution.
No changes to the email/website structure, jakarta remains the center of 
the apache java development with a shared announcement list, general 
list, news and download pages, ...

The only change is that the board gets a list of members overseeing each 
project (=PMC) and additionally a Jakarta Community project building a 
java community at Apache. (assisting the java projects)
The board will not get one big report from jakarta but many small ones 
and can see witch (sub)projects needs more members.

Of course many members will be joining multiple PMCs.
Is this possible?
-- Dirk



Noel J. Bergman wrote:

There is a difference between a hierarchy and a confederation.  There is
absolutely nothing that says that we cannot have:
  Jakarta PMC: responsible for jakarta-site/jakarta-site2
  Tomcat PMC: tomcat and related code
  Struts PMC: struts and related code
  Jakarta Commons PMC: ...
  Tapestry PMC: ...
  ...
All without a single change to the Jakarta domain.

No one should feel that there is any relationship between the 
Foundation's
legal structure, and e-mail/web addresses.  We have had this confirmed
already by both Greg and Sam.  The above *is* an acceptable solution 
to the
Board.  The question is whether or not it is an acceptable one to us.

--- Noel




-
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]


Re: POI Logo legal matter

2002-07-11 Thread Ted Husted

I'd ask if the contributor could remove the diamond look so that it
looks more like steam and less like the Windows flag, then see if we
need to run it by counsel. The cup part seems like a stretch to me too,
since it is a very different looking cup. But the diamond pattern does
seem a bit too close for comfort.

Andrew C. Oliver wrote:
 
 Hi All,
 
 The committers are about to be asked to vote on the new POI logo.  While
 the recent user logo poll was not binding (as only committer votes are
 binding), I expect the majority of committers may cast their vote
 democratically.
 
 Unfortunately, the logo that has won the poll is controversial.  Had I
 seen the Windows XP logo (I use Linux and sometimes w2k due to
 work/cross browser testing, but I always shower afterwards), I probably
 would have nixed this one.  However, my opinion is but that of a lay person.
 
  From my understanding the foundation employs council that is available,
 however not being a member of the foundation, I'd like to solicit the
 assistance of a foundation member to bring this issue to the foundation
 or said legal council.
 
 I've been told that the logo is potentially a problem:
 
 a. because it looks too much like the windows xp logo
 b. because it employs a coffee cup (which I think is unlikely) and
 therefore would peeve sun too.
 
 I'd like to ask the legal reprentative to look at:
 
 http://jakarta.apache.org/poi/news/images/logoRaPiGmbH8.png
 results: http://vote.sparklit.com/poll.spark/640946
 
 and tell us whether this logo is likely a trademark infringement on
 either issue.
 
 In the event it is, we'll not submit it to the POI committers as a
 candidate.
 
 Thanks,
 
 Andy
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY US
-- Java Web Development with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: process of OSS development at jakarta

2002-07-02 Thread Ted Husted

Leo Simons wrote:
 
 If y'all could comment and perhaps expand a bit, I'll put a webpage somewhere.
 Or, if I missed the mark completely, I'll do nothing =)

How about tieing that page in with the outline we started here:

http://jakarta.apache.org/site/guides


-- Ted Husted, Husted dot Com, Fairport NY US
-- Java Web Development with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [DRAFT2] Jakarta Newsletter - June 2002

2002-07-02 Thread Ted Husted

I add a /news directory and the first edition to the site2 CVS. So on
the website this would be under jakarta.apache.org/site/news. 

But I don't know how to get the web site to checkout the new folder. cvs
update ignored it. I tried creating a news directory but that didn't
help. If someone can set up the website to checkout the new directory,
the rest is done.

-Ted.


Rob Oxspring wrote:
 
 Please find attached the xdoc/html/txt versions of the the second draft
 (zipped).
 
 The changes:
 oNew sections for Jetspeed, Lucene, and Tomcat
 oMentions actual release of JXPath not just talk of
 oCeki's name is now in its full glory, as is Mike McAngus's
 oSwitched Mahler Thomas to Thomas Mahler
 
 Do people want the html version? if so, we could do with finalising the
 location and someone committing the xdoc before I send the final copy out to
 the wide world.
 
 If we can decide this matter and there are no more changes / submissions
 then I'll send this copy out tomorrow.  So again - let me know of any
 changes you think are necessary.
 
 Rob
 
   
  Name: draft2.zip
draft2.zipType: Zip Compressed Data (application/x-zip-compressed)
  Encoding: base64
 
   
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [DRAFT2] Jakarta Newsletter - June 2002

2002-07-02 Thread Ted Husted

Thanks, Danny. (Been using a GUI too long =:0)

A draft archive page is now up at 

http://jakarta.apache.org/site/news/

Once this ships, I'm thinking we could add a Newsletter section at the
top of the welcome page

[Jakarta Newsletter]

* June 2002

[Product News]

* ...

And change from June to July when the time comes.

We could also change the default News  Status page to a portal that
links to the pages we have now have for

* Newsletter archive
* Product News 
* Other Jakarta News
* Elsewhere 

and get all this moved under the new /news folder. 

Sound like a plan?

-T.

Danny Angus wrote:
 
 cvs up -d
 
  -Original Message-
  From: Ted Husted [mailto:[EMAIL PROTECTED]]
  Sent: 02 July 2002 13:34
  To: Jakarta General List
  Subject: Re: [DRAFT2] Jakarta Newsletter - June 2002
 
 
  I add a /news directory and the first edition to the site2 CVS. So on
  the website this would be under jakarta.apache.org/site/news.
 
  But I don't know how to get the web site to checkout the new folder. cvs
  update ignored it. I tried creating a news directory but that didn't
  help. If someone can set up the website to checkout the new directory,
  the rest is done.
 
  -Ted.
 
 
  Rob Oxspring wrote:
  
   Please find attached the xdoc/html/txt versions of the the second draft
   (zipped).
  
   The changes:
   oNew sections for Jetspeed, Lucene, and Tomcat
   oMentions actual release of JXPath not just talk of
   oCeki's name is now in its full glory, as is Mike McAngus's
   oSwitched Mahler Thomas to Thomas Mahler
  
   Do people want the html version? if so, we could do with finalising the
   location and someone committing the xdoc before I send the
  final copy out to
   the wide world.
  
   If we can decide this matter and there are no more changes / submissions
   then I'll send this copy out tomorrow.  So again - let me know of any
   changes you think are necessary.
  
   Rob
  
  
  
Name: draft2.zip
  draft2.zipType: Zip Compressed Data
  (application/x-zip-compressed)
Encoding: base64
  
  
  
   --
   To unsubscribe, e-mail:
  mailto:[EMAIL PROTECTED]
   For additional commands, e-mail:
  mailto:[EMAIL PROTECTED]
 
  --
  To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY US
-- Java Web Development with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: FW: Third-Party Support

2002-07-01 Thread Ted Husted

Done.

Pier Fumagalli wrote:
 
 Not acked...
 
 Pier
 
 -- Forwarded Message
  From: Alex McLintock [EMAIL PROTECTED]
  Date: Sun, 30 Jun 2002 21:50:28 +0100
  To: [EMAIL PROTECTED]
  Subject: Third-Party Support
 
  Please add my firm to the page http://jakarta.apache.org/site/vendors.html
 
  We would like to be in the Complete solution providers section.
 
  Please can our entry read
 
 
  OpenWeb Analysts Ltd http://www.owal.co.uk
  OpenWeb Analysts Ltd solves problems through software. We specialise in making
  the most of Open Source software in web situations. Whether that is working
  with
  a perl based content management system, or writing Java code for an XML/XSLT
  based document generation system, OpenWeb Analysts has the skills.
  London, UK
  info at OWAL.co.uk
 
 
 
  Thanks
 
  Alex McLintock
 
 
 
  Openweb Analysts Ltd, London: Software For Complex Websites
  http://www.OWAL.co.uk/
  Free Consultancy for London Companies thinking of Open Source Software.
 
 
 
 -- End of Forwarded Message
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY US
-- Java Web Development with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jakarta Newsletter - May 2002

2002-06-06 Thread Ted Husted

+1 on no biding peer review

But the sequence of events Pier suggested seems fine 

(1) The volunteer list editors post submissions to the general list and
copy their own DEV list.

[NEWS] July 2002 - Struts

copy/

(2) The volunteer newsletter editor collects the submissions together
and sends it out on announcements like a digest.

If there were comments, it would be up to the newsletter editor that
month to decide whether to commit them to the newsletter or not; perhaps
consulting with the committers for the product first. 

-Ted.


Peter Donald wrote:
 
 I would actually prefer no peer review (or at least no binding peer
 review). If people want to have a say what goes into it then they should
 get off their butts and write something for it ;)
 
 I am sure that the writers will be at responsible enough (and if not we can
 yank
   their privlidges to post it to announcement list)
 
 At 04:19 PM 6/5/2002 +0100, you wrote:
 Rob Oxspring [EMAIL PROTECTED] wrote:
 
   Jakarta Newsletter
   ==
   Issue: 0
   Date: May 2002
 
 Great job... I'd like to propose the following: peer review on this mailing
 list, vote request, and then send it off on announcements... This can be
 done every month if Rob is willing to keep up with the pace of my flamewars.
 
  Pier
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] Committer access and responsibilities...

2002-05-27 Thread Ted Husted

I think the real point is that while, given the chance, some people may
prefer to do one thing or another, as Committers we all can potentially
do anything that needs to be done whenever we have time to do it. 

Since this is a volunteer organization, and we all have other pressing
responsibilities, it is important that we do not encourage any systemic
bottlenecks. If the Committer who likes to do the releases can't,
someone else can just step up to bat without any hoopla. A committer is
a committer .. from each according to their abilities, to each according
to their needs. 

Regardless of what we choose to do from time to time, the codebase is
our joint responsiblity. And when we drift away, someone else will step
into our shoes. When we are gone, another committer may elect to do what
we used to do, or a new contributor may fill the void and then be 
nominated as the product's newest Committer. 

The real problem I would have with non-voting Committers is that
comitting is an important way of how we vote. Because we are all
responsible for the entire codebase, jointly and severally, we don't 
have to vote on every little thing. We can vote through our commits -- 
unless and until another Committer points out an error in our judgment. 

Since committing is voting, what I think what some people want is a
non-vetoing Committer. Someone to do the work without sharing in the
responsibility. Which is to say, we can reject what they do, but they
can't reject what we do. Personally, I would find that type of
master/slave relationship difficult to maintain in a volunteer 
organization like this. If you are working hard enough to need commit 
rights, you are working hard enough to have veto rights. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Leo Simons wrote:
 we have, in practice, in quite a few of the subprojects. The in
 practice part in that sentence explains the quotes around leads.
 
 We have a nice theoretical meritocracy model defining several roles and
 responsibilities. That's just fine. The current model defines user,
 developer, committer and pmc member.
 
 In real life, there's more roles, overlapping roles, more specific
 roles, less specific roles.
 
 Examples: with Avalon, Peter and Berin handle most of our releases; they
 assume the role of release manager. Jeff Turner's been working on the
 build process; he had the cap of build process manager, now passed
 over to Nicola Ken, all informally.
 
 Fortunately, this is all okay and no-one complains. Like Ted said, we're
 pragmatic about it.
 
 Thing is, formal roles and responsibilities currently are
 (as per http://jakarta.apache.org/site/roles.html):
 
 user: no rights, no responsibilities
 developer: right to get quoted as author for authored pieces, no
 responsibility
 committer: right to vote as per voting guidelines, responsibility to
 sign and submit Contributor License Agreement
 pmc member: right and obligation to set overall project direction
 
 when these no longer reflect the ad hoc pragmatic roles defined within
 subprojects, or when they make using these pragmatic roles difficult,
 we should think about changing these definitions, roles and
 responsibilities.
 
 Fact of the matter is, the model is not perfect, and not everyone in our
 community fits into these categories very well. Saying that everyone who
 submits a patch is a developer is a bit of a strange definition, as you
 don't really develop documentation, etc etc etc.
 
 Pier brings this up, perhaps in a somewhat clumsy way, but with a valid
 point and valid arguments: voila, heated discussion and comments on a
 personal note.
 
 if it ain't broken, don't fix it leads to things like windows. We'd
 still be forced to work with AWT and JSP.
 
 - Leo

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] Committer access and responsibilities...

2002-05-26 Thread Ted Husted

Those who do the work of creating a Jakarta product are entitled to make 
the decisions regarding that product. A successful product is more than 
code, it also requires documentation and support and easy-to-use 
distributions. 

Whether a patch is to the code or the documentation isn't relevant. A 
patch is a patch, a contribution is a contribution, and anyone who 
makes sustained contributions to a product is elligible to become a 
committer. 

A change to the codebase can affect everyone, including them that don't
code but simply document. They should have as much to say about the
codebase as everyone else. 

The real point behind meritocracy, I believe, is that we are all equal
and there is no formal hierarchy. It's also a big part of what 
makes Jakarta both fun and different from our regular jobs. 

We have a simple and effective system here that's been proven to work. 
I don't believe that the formal system is broken or needs to be 
refactored.

-1 on there being shades of gray between contributors and committers. 

A contributor is anyone who has submitted code, documentation or 
any other deliverable that has been made part of the product. 
Committers do the work of creating the product by posting 
contributions to the CVS or other secure area. 

+1 on non-coders or specialists being voted as committers when 
the circumstances warrant. There is nothing to prevent this now 
nor should there ever be. If its OK with the other committers to a 
product, there's no reason for the rest of us to care. If it's not 
OK with the other committers, then it is not the system that's 
broken, but the committers -- and no amount of tinkering is going 
to fix that.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services



Pier Fumagalli wrote:
 
 Chatted with a lot of people, seen many, different development models, went
 around, asked, talked, and I believe I have a pretty decent picture, and
 maybe even a solution...
 
 So the major topic of discussion is that I perceive a substantial difference
 between being able to commit code to a CVS repository, and being a
 committer committer, with all dues and responsibilities that this role
 concerns...
 
 For example sometimes someone might want to have commit access just because
 he is working for a company that deals with a particular project in Apache
 (we've seen this happening several times with some projects such as Xerces
 and Tomcat), but he really doesn't care about the whole fuzz of Apache and
 stuff, and once the employment contract ends, the relationship with Apache
 terminates as well (I don't need to enumerate all those examples along those
 lines).
 
 One other example, if we didn't have Henri building RPMs for basically all
 Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
 don't you think that he would deserve committer status even if he's not tied
 to any particular codebase? We had this problem in the current election of
 the members, Sally Khudairi: Sally doesn't code, but she was involved with
 the ASF since before it was even created as a press organizer. Does she
 deserve to be a member of the foundation? Even if she doesn't code? Yes she
 does, IMO (and she was elected and nominated a member today)...
 
 So, IMO, there's a great difference between being a coder, and being a
 member of the Jakarta community, at least in my opinion. There might be
 coders who are not involved with the community, and there might be
 non-coders who are much involved with it, want to participate, are active
 and deserve to be committers...
 
 Our current structure doesn't allow that to happen, both things. If you
 need to write code in a particular source-base, and you need CVS access, you
 are automagically made a committer, even if you don't care about much else,
 and if you're very much involved with the overall project, but not tied to
 ANY whatsoever codebase, and really, don't want / can't do it.
 
 So, given this little background, I would like to ask to the PMC, and all
 other committers, if others agree that we should splitting the committer
 figure in two parts:
 
 - contributor: a contributor is someone who has access to a particular CVS
 tree, but for any reason doesn't want/need to be involved with the whole
 Jakarta community. He just wants to code his little bit and live a long
 life.
 
 - member: is someone who is involved with the Jakarta community, somehow,
 somewhere (might be just giving a great deal in supporting users of our
 projects, or providing extra value to projects, like guidance in respect to
 overall specifications, binary builds). He is effectively a member of the
 community and has all the rights and dues of every member, such as
 participate in the election of the PMC.
 
 And redefining the figure of the committer as follows:
 
 - committer: is a contributor, but also a member, therefore he has all

Re: subproject layout conventions

2002-03-29 Thread Ted Husted

Leo Simons wrote:
 I very much agree. I was under the impression though that at this point,
 there are some designers available somewhere. It would be good if they
 would explain which things would be good to change so we can put that
 into the system.

There is no paid staff, and AFAIK, no designers who are also
committers. And even if there was one, we can't depend on something like
that. We can depend on there being programmers here, otherwise there
would be no living products, and before long, no users or Website to
worry about.

 except that the website is not only for geeks. It's also for people
 that make decisions and have money.

Says who? 

I'm thinking Jakarta is a developer-to-developer site. If other stop by,
they're welcome, but our focus has to be on what we know. 

Personally, I leave the eye-candy to others, and focus on functionality.
Given the products we write here, I think that's going to very common. 

I'm not saying that I would be particularly interested in any design
anyone else came up with. I'm just saying that if I need to change it,
I'm going to change it, because there ain't nobody else here to do it.

Personally, I'd say it's better that our sites don't look ~too~ good.
That way people don't get the wrong impression. There is no commericial
support here. Just a bunch of volunteers doing the best they can.
Jakarta is an all-you-can-eat buffet, and should probably look like one
:o)

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: subproject layout conventions

2002-03-29 Thread Ted Husted

Leo Simons wrote:
 As long as we agree that nothing should get into the way of site functionality (and 
we do), why would you oppose a site that also is easy to navigate and looks good?

The only thing I oppose is the idea something being set in stone or
approved by some mythical designer. 

http://www.mail-archive.com/general%40jakarta.apache.org/msg04500.html

I need to change something, then I will change it. Everything is a
shared resource here, and every committer is encouraged to take whatever
action they feel prudent. 

I actually support what you are doing, so long as you remember who you
are doing it for. The committers are the bosses here. Everything we do
has to empower the committers and help them get past the adminutia and
on with the development; or else there will be no committers, no
products, no users, and no Web site. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jakarta Overview

2002-03-22 Thread Ted Husted

Danny Angus wrote:
 Try and look at the front page for, admittedly a one liner, but one
 without subjective overtones, which doesn't present a non-contributors view
 of many projects as the Jakarta Overview Definition of what the project
 is.

The overview has been donated to the ASF, and is under Jakarta rules
now. If anyone wants to make it more objective, have at it. If not,
leave it alone and it will wither away. 

Regardless of the content, it's important to recognize that the initial
author Did The Right Thing. The overview was prepared in XML and
required no afterwork to commit. This makes him a Contributor in my
book. If more of our users went to the trouble this person went to, we'd
have more and better documentation throughout Jakarta.

We are very quick to say Thanks for Volunteering around here. OK,
someone volunteered, and we got what we wished for. 

Apache stands for patching ...

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Printable pages

2002-03-21 Thread Ted Husted

Jon Scott Stevens wrote:
 I'm ok with that. Netscape 6 and IE 5.5 are released versions of the latest
 technologies. If those new technologies support the features we need, then
 lets require them for those features. It is like the big switch from JDK 1.1
 to JDK 1.2. :-)

I agree that a more printable site would be a good thing, but I don't
know if I would classify this as as a feature we desperately *need* --
if it means forcing people to change browsers just to access the Jakarta
web site. I would be -1 on a product change that made the main Jakarta
web site inaccessible with Netscape 4.x.

Of course, what each individual subproject does with their own area is
up to their own comitters.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Web: http://husted.com/struts

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [site] proposed changes to site.vsl template

2002-03-21 Thread Ted Husted

[EMAIL PROTECTED] wrote:
 Cool, feedback :) Where do u think it needs more whitespace - between
 'menus' or 'items'?

Personally, I like putting the sidebar menus on the right, so they are
near the scrollbar. Then if the page is a little wide, its the menu that
gets pushed off rather than the content. This also can also let you
reduce the gutter between the columns (as you have already done, without
it looking quite as squished. And, I believe, if the page is being
viewed with a screen reader, this puts the navigation after the
content, since the reader would read the columns left to right. 

I don't know if the menu has to be in an actual HTML list, which tends
to indent things a little much. I'd either use non-breaking spaces
(which are apparently not permitted right now) or a tranparent GIF to
indent them.

I haven't tried to do it yet, but it would also be nice to have
different sidebar menus for sub-areas of the main site, like the
volunteer guides area, the PMC area, and some other places where we are
using page links instead of putting up a new sidebar. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Web: http://husted.com/struts

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jakarta Overview

2002-03-20 Thread Ted Husted

Jakarta is developer-centric because developers are the ones who
volunteer to do the work. 
They need working products to use with their paying jobs, and find that
sharing the 
development load works better than going it alone. 

We don't get many marketing volunteers because there is very little
payback. 
More marketing generates more users, but that doesn't always translate
into more 
development or better products. Sometimes more users can actually hurt
development, 
since user support distracts developers from developing. (Only so many
cycles in a day.)

I do a lot of work on product documentation myself, mostly becuase I
have a mind like 
a sieve, and need it for my own reference. But for most developers and
users, there is 
less of a payback, since once they know the product they don't feel the
need to 
document it for their own use.

Jakarta is here to build products. If someone wants to market those
products, that's 
great. If volunteers want to provide commit-ready documentation, like
Phillip did, I'll 
fulfill my responsibility as a committer, and post it. 

But the problem now is, who's going to maintain it over the long run? If
the developers 
want to, that's great, but if they don't, well, how the other committers
spend their 
volunteer hours is up to them. 

So, sure, some clear exposition about Jakarta would help a lot of
people. If someone has 
an itch for more documentation, they should create it and share it with
the group in a 
ready-to-commit format, as Phillip did. Though, I'm sure anyone ready to
do the work
doesn't need someone else to suggest the idea.

Jakarta cannot be anything by design; it can only be what the volunteers
make it.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Web: http://husted.com/struts


Chris Pheby wrote:
 
 I have to disagree! Speaking as a /user/ it is really hard to find projects
 on Jakarta, and how the various projects relate to each other. I have spent
 many weeks doing this and still haven't even scraped the iceberg. Which I
 think is a shame. Some clear exposition would really help.
 
 I have heard on this list that the Jakarta project is developer centric, and
 the site is hard to penetrate if you are not a Jakarta developer. I am sure
 this is not by design, but that is my perception as well. Any suggestion
 that helps improve this situation such as Philipp's I would hope has serious
 consideration - even if it presents new challenges that need to be resolved.
 
 As to deciding such things as how to assess the maturity of the project, how
 about taking measures such as:
 
 a) polls/votes of users
 b) number of downloads
 c) release number
 
 I'm sure there are other possibilities...
 
 Chris.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jakarta Overview

2002-03-19 Thread Ted Husted


http://jakarta.apache.org/site/news.html#0319

Thank you for your contribution. 

-Ted.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [VOTE] ASL vs. GPL page: is this okay?

2002-03-07 Thread Ted Husted

http://www.dictionary.com/search?q=license

http://www.dictionary.com/search?q=licence


alex wrote:
 
 At 09:16 07/03/02, Danny Angus wrote:
   It is spelled licence.  ;-)
 
 Wow - we managed to correct Jon on a technical point!   (Just kidding Jon -
 no offence)
 
 licenSe is what Apache Software Foundation does - ie the act of licensing.
 licenCe is the document or permit given - eg the file itself.
 
 Since this is all about the document then licenCe is the correct spelling
 (ignoring Case that is).
 
 Personally I feel the existing web page which Jon reminded us of was quite
 good and if there is anything important missing then that is the page which
 should be improved.
 
 Alex
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: news@jakarta list? (Re: Introducing Enterprise Object Broker)

2002-03-07 Thread Ted Husted

I think the original suggestion of [EMAIL PROTECTED] was fine. 

It is not mysterious or hard to remember, and most of the OT threads
around here are generated by some type of news item. 

-Ted.


Jeff Turner wrote:
 
 On Thu, Mar 07, 2002 at 06:03:21PM +, Pier Fumagalli wrote:
  Paul Hammant [EMAIL PROTECTED] wrote:
 
   Folks,
  
   Enterprise Object Broker (EOB) is an application server that tries to a
   be a simpler EJB container.  It is not complete yet, but we have many
   demos showing local, remote, and webapp usage.
 
  Ok. Will we all stop using general@jakarta for advertisement of things which
  are NOT ASF related? Thankyou...
 
 Then could we perhaps have a news@jakarta list for this sort of thing? A
 lot of people find announcements like this relevant and interesting.
 
 How is it different from freshmeat? It's that 'community' thing Stefano
 goes on about. People have established webs of trust here. EOB is by
 Apache people, using Apache code, and that makes it *relevant*.
 
 --Jeff
 
  Pier
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: jakarta-site2 sidebar

2002-03-06 Thread Ted Husted

+1 (done).

Andrew C. Oliver wrote:
 
 Hi all,
 
 quick proposal... does anyone object to me moving [MISC] Who we are? bla
 bla bal to the TOP of the sidebar and renaming it [ABOUT]?
 
 Rationale: the MISC trivializes the information and says don't read
 me.  If community is more important than codewhy is the code above
 the community info?  ;-)
 
 I'm volunteering just waned consent first.
 
 -Andy
 --
 www.superlinksoftware.com
 www.sourceforge.net/projects/poi - port of Excel format to java
 http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
 - fix java generics!
 
 The avalanche has already started. It is too late for the pebbles to
 vote.
 -Ambassador Kosh
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: The Complete Server Platform?

2002-02-24 Thread Ted Husted

Leo Simons wrote:
 2) a statement of intent in important places on the website.
 I'm guessing that putting we would like to see tomcat
 integrate with avalon on the projects' respective websites
 would mean that such will happen sooner.

My concern would be that this promotes a We are Borg attitude.

Why would we like to see Avalon integrate with Tomcat? Why not Jetty
or Resin? 

If our committers are choosing to use Tomcat because it meets their
real-life needs, then why would we have to tell them that. Won't they
just do it because they need it?

IMHO, committers should decide what is best for their product first. If
we all do that, and we all create best-of-breed products, then
interoperability will be a natural occurance. 

If it is not a natural occurance, then we are mixing politics with
technology ... We would simply be replacing the Dark Lords with a Dark
Lady.

AFAIK, we don't tell Jakarta committers to use Ant. They choose Ant
because it is a great tool. The same should go for every Jakarta or ASF
product.

Meanwhile, I do think documenting how J2SE (Standard Edition)
technologies can provide an end-to-end solution is a great idea. For
example, jGuru is running on Resin, Lucene, James, and JSPs. Scales
great, and not an EJB to be found. 

So, should we (meaning I) write that up as a case study and post it on
the site? Or, pass because they are not using Tomcat?

AFAIK, Apache is part of the JS2E group, rather than the J2EE group, so
it seems to me that promoting J2SE solutions is a natural thing for us
to do, regardless of who provides the underlying product.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/struts

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Java Persistence Layer [was EJB, etc]

2002-02-23 Thread Ted Husted

See

http://jakarta.apache.org/site/newproject.html

If you are serious, the first thing you really need to do is get the
source posted someplace. This could just be a page on a free host, with
the Apache License recast as the Michael Lee license. Or, SourceForge if
you think you might want to play with it bit first. 

But, the ASF does not simply take code donations. We host projects and
products with developers that want to actively promote the product as
open source, under the Apache License, and manage the codebase in a
meritocratic way. So, its not so much about the tool itself, but about
them that want to use and improve the tool.

You might also want to take a look at 

http://netmeme.org/simper/

Seems like you have a number of bullets in common.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Michael Lee wrote:
 
 Along the same lines as a smaller alternative to EJB (entity at least), I
 wrote my own java persistence layer for smaller 2-3 tier type environments.
 What would I need to do to submit this to jakarta? Its pretty damn cool.
 Every developer I showed loved it and immediately saw the void it filled. It
 is INCREDIBLY easy, fast and powerful. It is complete but has some design
 holes I'm not happy with that I hope the open source community could help
 aleviate. Anyone who has written a smaller 2 to n tier app would love this.
 I use it for most of my persistence coding where EJBs or toplink are
 overkill (which is most).
 I have to respond to something.
 I am putting up my qualifications to try to expunge and unneccesary
 cricism/bias that people should have if I were not to disclose this
 information; I was a consultant for BEA professional services for a couple
 of years. Before, and after, BEA I did a lot of RMI/CORBA/JDBC/servlet work.
 Before even that I wrote some of my own cross platform networking, database
 code in C/C++. Believe me, I have done my fair share of N-tier development
 on all kinds of os/hardware environments in all kinds of vertical markets.
 As for J2EE, I did a lot of work in Weblogic (obviously) but have also
 worked with JBoss/Websphere/IPlanet (I LOVE JBOSS!! Not quite as good as
 weblogic but the price is sure better! And to respond early, I could start
 up JBoss in under 12 seconds or so with about 40 EJBs and 200 jsps in a WAR
 file on a Pentium III 750mhz with 512MB ram). I currently work for a company
 that is is folding that makes a web services
 development/deployment/management tool.
 
 Knowing my qualifications here is my response to Aaron's post whom I have
 summarized with this one line from him;
 No matter what you try to do with EJB, I can provide a simpler, faster,
 more scalable, and cheaper solution.
 
 Wow, you should start your own company. Your obviously much smarter than the
 100 or so developers that make Weblogic or the 50 or so that make JBoss, or
 the ? 100 ? or so that make Websphere, etc. You can make a Java Bean
 container that can handle clustering, fail over, caching, persistence,
 transactional services, security, etc. better than all those people? Wow,
 your the man. If I could create a product by myself better than all those
 people and create a billion dollar company I would. Seems stupid not to?
 Kind of strange you call 'people' stupid and claim you can do better than
 these teams at creating this monumental amount of complex code yet you don't
 do it, even though it could bring you great wealth? Ok then, how about open
 source? I have an open source persistence layer that I wrote to fill a void
 that I saw. It is a smaller persistence layer that performs C.R.U.D.
 operations, has caching, performs rudimentaty find operations, is
 PATHETICALLY easy and reusable, is fast and has no meta-data. It is not
 scalable like a J2EE container, has no built in security other than through
 the JDBC connection, does not have fail-over, does not have transactional
 integrity except that which the developer writes, etc. But if you want a
 quick from the web through a JSP form with little or no business logic, to
 the database, and back it performs like a champ. Much faster than EJB for
 one machine for just this type of task.
 I do not make claims that I could do something better than someone else
 without proving it. I want to release this open source and put my money
 where my mouth is. If I wanted a larger persistence system I would use JBoss
 (as I have no money) or Weblogic if I had some money. If I needed even more
 control and versatility over my persistence layer I might even add something
 like a Toplink. All perform well for what they do. My API/tool is a
 persistence layer between nothing and EJB. EJB is great at what it does.
 Granted, it is used many times where it does not need to be (ie: a simple
 RMI/JDBC design would probably suffice) but it does have a void that it
 fills. I have designed/coded many systems

Re: Bug database appears to be down

2002-02-23 Thread Ted Husted

Until the Bugzilla is fixed, you should direct any issues regarding Ant
to the Ant DEV list. Could get lost here =:o)

http://jakarta.apache.org/site/mail.html


Christopher Taylor wrote:
 
 Hello,
 
 The bug database appears to be down.  The bug I wanted to submit was against
 ANT.  If you use the copy task with filtering turned on, and the file is a
 different encoding type than the default decoding, the copy task will mangle
 the destination file.
 
 For example, I am using a Windows 2000 workstation with JDK 1.4 installed.
 I am putting together a Japanese and English website, where the files are
 all in UTF-8 format.  The default encoding (as seen with the following code:
 
 import java.io.*;
 
 ...
 FileReader reader = new FileReader(some file);
 System.out.println (reader.getEncoding());
 ...
 
 will be CP1252 (US-ASCII).  What the copy task needs is an additional
 IMPLIED attribute that specifies the encoding for filtering tasks.  The code
 in the org.apache.tools.ant.util.FileUtils class would need to be changed so
 it could receive an encoding parameter as well.  Lines 220, 221 of
 FileUtils.java would need to be replaced with:
 
 FileInputStream fis = new FileInputStream (sourceFile);
 FileOutputStream fos = new FileOutputStream (destFile);
 InputStreamReader in = new InputStreamReader (fis, encoding);
 OutputStreamWriter out = new OutputStreamWriter (fos, encoding);
 
 This would fix the encoding problems with the filtering, as long as all
 content encountered during the filtering process was UTF8 encoded (since
 ASCII is subsumed by UTF8, this shouldn't be a problem for most people).
 
 Thanks, and I will post a patch on the jakarta-ant mailing list.
 
 -Chris
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: EJB = bad = MS.net

2002-02-21 Thread Ted Husted

Struts works just fine with EJBs, along with any other standard Java
technology.

The discussion is about EJBs in general, independant of whether they are
used with Struts or not. 

A good number of Struts developers do use EJBs, which is why so many
people are contributing to this thread. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Yu, Yanhui wrote:
 
 Hi,
 
 I am involved in a pretty large project (we have not really started coding
 yet).  As far as I can tell, we seem to go with Struts + WSAD + EJBs  Java
 + JSP.  Am I right to interpret that you mean the combination of Struts and
 EJBs are problem prone?  Please help me to clarify on this.  Thank you very
 much,
 
 Yanhui

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: bug HTML in STRUTS

2002-02-15 Thread Ted Husted

The best place to post a message like this is the Struts USER list. 

http://jakarta.apache.org/site/mail.html



BELGHALI Hassan (INFOGOLD) wrote:
 
 Hello ,
 Whe are encontred a problem  in the Taglibs HTML: OPTIONS  and
 HTML:SELECT
 The Taglib OPTIONS  is  change in to sevrols lines
 
 See after the exemple in Frensh:
 There are the javascript code before and after
 
 Best regards .
 
 Problèmes dans le FrameWork Struts.
 
 Dans la situation actuelle, le menu d'accueil est créé entièrement en Java
 Script ( pour être dynamique )
 Afin d'intégrer la Date de Consultation dans ce menu dynamique, nous avons
 besoin des Taglibs du Struts HTML :SELECT et HTML :OPTIONS
 Le problème se pose sur le Taglib OPTIONS car celui ci est transformé en
 plusieurs ligne d'options :
 
 Voici le code Java Script :
 
 document.write('html:select name=CompteurForm property=dateConsultation
 ');
 
 document.write('html:options collection=listDateConsultation
 property=value labelProperty=label /');
 
 document.write('/html:select');
 
 Voici le code après traduction par le Struts :
 
 document.write('select name=dateConsultation');
 
 document.write('option value=05/02/200205/02/2002/option
 
 option value=06/02/200206/02/2002/option
 
 option value=07/02/2002 selected=selected07/02/2002/option
 
 ');
 
 document.write('/select');
 
 Cela nous génère des erreurs par la suite lors de la lecture du Java Script
 à cause du 'Retour à la ligne'.
 La solution pour éviter cette erreur serait de retirer le caractère 'Retour
 à la ligne' dans le Taglib OPTIONS.
 J'ai donc modifier la méthode 'addOption()' de la classe 'OptionsTag' du
 package 'org.apache.struts.taglib.html' en remplaçant la ligne
 'sb.append(/option\r\n);'
 Par 'sb.append(/option);'
 
 Voici le nouveau code après la traduction par le Struts :
 
 document.write('select name= dateConsultation ');
 
 document.write('option value=05/02/200205/02/2002/optionoption
 value=06/02/200206/02/2002/option option value=07/02/2002
 selected=selected07/02/2002/option');
 
 document.write('/select');
 
 Maintenant les options sont sur une seule ligne. ( même si cela ne se voit
 pas dans ce document) Ainsi Java Script reconnaît la commande et l'exécute
 correctement !
 
 Rappel : Cela concerne le même package pour lequel une modification a déjà
 été faite sur la méthode 'doEndTag' de la classe 'FormTag'
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Tomcat 4.0.2 Security Exception

2002-02-15 Thread Ted Husted

The best place to post a message like this is the Tomcat USER list. 

http://jakarta.apache.org/site/mail.html



Lars Wunderlich wrote:
 
 I get the following error after installation the current 4.0.2 release of
 Tomcat. I doesn't make a difference whether I use the exe-representation or
 the zip-file regarding this release.
 
 What can I do in order to install Tomcat correctly?
 
 D:\Tomcat40\jakarta-tomcat-4.0.2\bincatalina run
 Using CATALINA_BASE:   ..
 Using CATALINA_HOME:   ..
 Using CATALINA_TMPDIR: ..\temp
 Using JAVA_HOME:   D:\jdk1.3.1
 Exception during startup processing
 java.lang.reflect.InvocationTargetException:
 javax.xml.parsers.FactoryConfigurat
 ionError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl could not be
 inst
 antiated: java.lang.SecurityException: sealing violation
 at
 javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:
 141)
 at
 org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:224)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:725)
 at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
 at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
 at java.lang.reflect.Method.invoke(Native Method)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: need help!!!

2002-02-06 Thread Ted Husted

The best place to post a question like this is the Struts USER list. 

http://jakarta.apache.org/site/mail.html

¶ª ¶ª wrote:
 
 hello!
   I am a java developer,and I used Struts for serval days..but i found
 something wrong whit struts.
   For a chinese,I use gb2312 code ..and i write the APPLICATIONRECOURCES in
 chinese.but it appears bad code ,i must change encoding in IE...but why?
   i also changed the text from struts-example, and the same things
 happend..
   please help me!!!
 
 iexcl;iexcl;iexcl;iexcl;
 
 
iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;
 
 
iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;diudiu
 
 
iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;[EMAIL PROTECTED]
 
 
iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;2002-01-23
 
 _
 ÏíÓÃÊÀ½çÉÏ×î´óµÄ Web µç×ÓÓʼþϵͳ ¡ª¡ª MSN Hotmail¡£
 http://www.hotmail.com/cn
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: PMC Nomination - Ted Husted

2002-02-06 Thread Ted Husted

Assuming there is a sufficient number of willing candidates to fill the
seven slots, I would respectfully decline my nomination, so as to ensure
someone else the chance to serve. 

It's been my experience that the best way to build community is to not
only participate yourself, but also to give others the chance to step up
to bat, and this seems like a good opportunity to do that =:0)

In the event another person is needed to serve on the Committee to fill
the seven seats, I would be happy to volunteer again. 

-Ted.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Java is dead... but it could still be saved!

2002-02-05 Thread Ted Husted

+1

Kevin A. Burton wrote:
   Heck no.  .NET/c# why would I want to use an even more proprietary thing
   to get back at SUN?  Heck no.
 
 ... hm.. this discussion could be on the list... buy anyway.



-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: TomCat license

2002-02-05 Thread Ted Husted

The license for Tomcat, and all other Apache Software Foundation
products, can be found here:

http://apache.org/LICENSE

Other questions regarding Tomcat can be directed to the Tomcat USER
list. 

http://jakarta.apache.org/site/mail.html


Kollár Dóra wrote:
 
 Dear Sir / Madame,
 
 My name is Dora Kollar and I am Presales Specialist at Noreg Ltd,
 Hungary. Noreg Information Protection Ltd. has been present on the
 Hungarian information protection market since 1998. Noreg provides a
 full scale information protection service for its customers. Besides the
 vulnerability testing and intrusion detecting, the safe network
 communication, access control, encryption, electronic signature
 authentication solutions and all information protection auditing and
 consultation activities in connection with all the mentioned fields are
 also included in the scope of service of the company.
 
 Last year we implemented Baltimore UniCERT modules at a customer.
 UniCERT WebRAO 2.2 MediaKit contains a non-commercial Jakarta Tomcat web
 application (TomCat 3.2.1). Does it (Tomcat) contain some limitations?
 Do we have to purchase licence to use it legally? If your answer is
 yes, how many licences do we have to purchase? What is your license
 policy?
 
 I am looking forward to your reply.
 
 Many thaks and best regards,
 
 Dora Kollar
 Presales Specialist
 Phone: +36 1 4386380
 Fax: +36 1 4386381
 E-mail: [EMAIL PROTECTED]
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: jkarta-site2

2002-02-04 Thread Ted Husted

Danny Angus wrote:
 2/ if I add it to news xdoc do I also have to add it to index under
 headlines, and.. if I do that do I knock off the earliest headline to keep
 the lists the same length.

+1

Actually, I'm thinking five looks a little crowded. If you wanted to go
with three, I think that would be fine too. But I don't think we want
more than five.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Broken Link On Struts Page

2002-02-04 Thread Ted Husted

The best place to post a message like this is the Struts-DEV list. Each
subproject maintains their own area of the Web site. 

But in this case, I'll take care of it :-)

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


[EMAIL PROTECTED] wrote:
 
 FYI -
 
 On this page: http://jakarta.apache.org/struts/userGuide/resources.html,
 the link called StrutsResourcesChecker to this page:
 http://jakarta.apache.org/struts/userGuide/resources/checker.html is
 broken.
 
 David
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [OT] RE: J2EE considered harmful

2002-02-01 Thread Ted Husted

Perhaps the question to ask is how are real sites providing real
scalabilty without resorting to Enterprise JavaBeans?

Take google.com and yahoo.com for example, 

Yahoo offers a signficant number of remote, multi-user applications like
the ones we would like to provide to our own clients. Are they using
EJBs? If not, what do they use? How can we turn Yahoo's approach into a
toolkit model that other developers can use?

Google is offering a single, read-only servvice, but at mind-bending
speed. How does it serve so many users so quickly? Again, how can we
package that approach in a way that it accessible to other developers?

Sorry to be providing more queries than code, but to paraphrase Linus,
it often takes one person to articulate an issue, and another to resolve
it =:o)


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [OT] RE: J2EE considered harmful

2002-02-01 Thread Ted Husted

yahoo.com goes way beyond a search engine:

Email, address books, auctions, classified ads, file storage, calendars
and shared calendars, personalized portals for like 27 different sub
applications, the list goes on.

Yahoo is delivering a vast number of dynamic applications to an
incredible number of users, with excellent performance and reliabity. If
there a success story in IT, this is it.

I picked yahoo.com and google.com as two different examples of high
traffic Web sites that are delivering scalability. 

I only mentioned google.com since it is ~blazingly fast~, and represents
a very different best-of-breed right now. 


Andrew C. Oliver wrote:
 
 Those are both search engines with non-critical data update issues.  You
 do need an example with more business-logic oriented type
 functionality.  I could mock something like those up with Lucene just
 with a few routers and pushing the indicies to the mirrored systems.
 This doesn't answer the enterprise system question.  Secondly we need
 examples on a more moderate basis.
 
 (sorry, if that sounds critical, I don't mean to be, I think you're
 heading the discussion the right direction, I just don't think those
 examples do that)
 
 On a more personal note.  Funny story: My wife went to high/grade school
 with the Google guy.  Small world eh?
 
 -Andy
 
 On Fri, 2002-02-01 at 08:57, Ted Husted wrote:
  Perhaps the question to ask is how are real sites providing real
  scalabilty without resorting to Enterprise JavaBeans?
 
  Take google.com and yahoo.com for example,
 
  Yahoo offers a signficant number of remote, multi-user applications like
  the ones we would like to provide to our own clients. Are they using
  EJBs? If not, what do they use? How can we turn Yahoo's approach into a
  toolkit model that other developers can use?
 
  Google is offering a single, read-only servvice, but at mind-bending
  speed. How does it serve so many users so quickly? Again, how can we
  package that approach in a way that it accessible to other developers?
 
  Sorry to be providing more queries than code, but to paraphrase Linus,
  it often takes one person to articulate an issue, and another to resolve
  it =:o)
 
 
  -- Ted Husted, Husted dot Com, Fairport NY USA.
  -- Java Web Development with Struts.
  -- Tel +1 585 737-3463.
  -- Web http://www.husted.com/struts/
 
  --
  To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 
 --
 www.superlinksoftware.com
 www.sourceforge.net/projects/poi - port of Excel format to java
 http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
 - fix java generics!
 
 The avalanche has already started. It is too late for the pebbles to
 vote.
 -Ambassador Kosh
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: J2EE considered harmful

2002-02-01 Thread Ted Husted

You know, since Apache is a member of the J2SE group at Apache, it would
make a lot of sense for us to develop a resource page regarding J2SE
scalability. 

I'd be very happy to start and maintain such a page here, as I do for
Struts. 

http://husted.com/struts/resources.htm

If anyone has some starter links, send them along, and I'll get going.

More importantly, we should also not hesitate to pubish our own orignal
material, such as case studies, if anyone here wants to pass one along
:-)

Personally, like James, I think all the tools are already there, and
much easier to deploy that bothering with EJBs. The vendor slove to say
you get this-and-that for free, but the hidden costs are staggering,
and in the end, it's obvious that you lose much more than you gain. Two
steps forward, six steps back.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


James Strachan wrote:
 Agreed. Though I've 2 points to make.
 
 #1 you don't need to use EJBs to distribute business logic If you do need to
 distribute business logic, then there are various alternatives open, from
 HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits,
 cost/benefits etc.
 
 #2 just because you may eventually distribute your business logic, assuming
 you're going to from the start (and assuming that means EJBs and then
 jumping through lots of EJB hoops  headeaches and paying a fortune to some
 EJB vendors) is bad XP practice IMHO
 
 I prefer to take an XP approach, first build a web application that works,
 is performant and scalable then worry about whether business logic needs to
 be distributed later. Afterall us Java folk are OO guys right? We can write
 our business logic in such a way that it could migrate to EJB later if we
 think thats the right thing to do.
 
 Or to put that another way - I'd prefer to focus on giving the customer what
 they want and making a good web application than grappling with EJBs just
 because one day, maybe, under some conditions, I might want to distribute
 some of the business logic in the web app under the 'faith' that its the
 right thing to do.
 
 Most business logic in most web applications is pretty minimal in terms of
 computation and is often mostly database intensive so moving this code to
 another process doesn't usually buy much in terms of scalability - if
 anything its the reverse thats true - what with all that EJB distributed
 garbage collection  connection based protocol stuff that needs to be done
 scalability (and usually always performance) can go down.
 
  If your application will grow it is good to have a middle tier that
  can be moved and load balanced.  With Entity beans of course this is
  less possible.
 
 (And stateful session beans ;-).
 
 I think this is true of traditional GUIs, say a Swing client front end, a
 middle tier server (say server side beans aka EJBs) and a database. I don't
 think this is true of web applications as they are quite different things -
 a servlet engine is not a 'GUI' client.
 
 Servlet engines are a stable, performant and very scalable application
 servers in their own right. Get a hardware load balancer and a farm of
 servlet engines and your *way* scalable.
 
 Arguing for the need for another, remote CORBA component-centric application
 server based on mostly connection-based protocols, RMI, stubs and
 distributed garbage collection to make your web-application more scalable
 seems, well, strange.
 
 In my experience web applications scale best when you have a big server farm
 of servlet engines which are load balanced. A database at the back and
 hopefully some kind of read only caching going on to take as much load off
 the poor database as you can. Then you can distribute parts of your web
 application into different server farms, get load balancing, shuffle things
 around as load changes etc. Then pick the web technologies of your choice,
 Struts, JSP, Velocity, Turbine etc. Away you go.
 
 I still don't see the 'scalability' argument as in any way advocating that
 EJBs are actually useful for web applications.
 
 In fact this idea that EJBs are required to build scalable web applications
 is plain false - probably marketing hype spread by the EJB vendors.
 
 James
 
 _
 Do You Yahoo!?
 Get your free @yahoo.com address at http://mail.yahoo.com
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jakarta PMC Nomination - Rejection

2002-02-01 Thread Ted Husted

So long, and thanks for all the fish =:0)


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


Jon Scott Stevens wrote:
 
 Hey all,
 
 I just wanted to say that I'm not going to accept my Jakarta PMC nomination
 and do not want to be included in the voting for the next election.
 
 I have been involved with Java Apache/Jakarta since Sept 1996 and I think
 that it is time for me to move on from being politically responsible for
 this group. Honestly, I'm jaded and burned out on it all.
 
 That said, I recently signed a 10 year lease on a prime event space in
 downtown San Francisco and I am moving towards spending more time being a
 big time night club owner than working on Jakarta. More info:
 http://www.studioz.tv/ (p.s. that site is built with Anakia smile)
 
 I also just released Scarab 1.0b1 and am focused primarily on making Scarab
 the best issue tracking tool around. Expect to see more great developments
 on this project. It is by far, one of the best designed, largest and most
 complex pieces of software that I have ever had the pleasure of helping
 develop. It will be around for a very long time and will eventually put
 Bugzilla out of business. More info: http://scarab.tigris.org/
 
 thanks,
 
 -jon
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




[Fwd: cvs commit: jakarta-site2/xdocs index.xml]

2002-01-30 Thread Ted Husted

I'm not comfortable with carrying this type of editorial matter at the
top of the home page, and would like to move it to the news and status
page. 

-Ted.

 Original Message 
Subject: cvs commit: jakarta-site2/xdocs index.xml
Date: 30 Jan 2002 21:53:04 -
From: [EMAIL PROTECTED]
Reply-To: Jakarta WebSite CVS List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

jon 02/01/30 13:53:04

  Modified:docs index.html
   xdocsindex.xml
  Log:
  lets have a little fun.
  
  Revision  ChangesPath
  1.52  +32 -0 jakarta-site2/docs/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-site2/docs/index.html,v
  retrieving revision 1.51
  retrieving revision 1.52
  diff -u -r1.51 -r1.52
  --- index.html29 Jan 2002 01:47:06 -  1.51
  +++ index.html30 Jan 2002 21:53:03 -  1.52
  @@ -140,6 +140,38 @@
  
table border=0 cellspacing=0 cellpadding=2 width=100%
 trtd bgcolor=#525D76
   font color=#ff face=arial,helvetica,sanserif
  +  a name=That flaming fireball in the sky...strongThat
flaming fireball in the sky.../strong/a
  +/font
  +  /td/tr
  +  trtd
  +blockquote
  +p
  +In a recent a
href=http://www.theserverside.com/resources/article.jsp?l=SunInterview;article/a,
Karen Tegan, Director of J2EE Compatibility and Platform
  +Services for Sun Microsystems, had the following to say:
  +/p
  +p
  +The J2EE Compatible brand has achieved significant momentum over the
  +past two years, and we want to make sure that any open source efforts
  +don't impact the viability of that effort.
  +/p
  +p
  +In other words, Sun doesn't give a hoot about whether J2EE licensing
  +restricts open source J2EE products (in case you missed it, it does).
  +Thus, the Apache Software Foundation's involvement in the Java
Community
  +Process (JCP) is simply an advertising statement for Sun to claim
that
  +they have a 'vision which uses open standards and non-proprietary
  +interfaces'. If you would like to express your opinions of Sun's
  +licensing terms, feel free to contact a
href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a and let us know what you
  +think. Thanks.
  +/p
  +/blockquote
  +/p
  +  /td/tr
  +  trtdbr//td/tr
  +/table
  +table border=0
cellspacing=0 cellpadding=2 width=100%
  +  trtd bgcolor=#525D76
  +font color=#ff face=arial,helvetica,sanserif
 a name=WelcomestrongWelcome/strong/a
   /font
 /td/tr
  
  
  
  1.21  +28 -0 jakarta-site2/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-site2/xdocs/index.xml,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- index.xml 20 Jan 2002 16:28:07 -  1.20
  +++ index.xml 30 Jan 2002 21:53:03 -  1.21
  @@ -9,6 +9,34 @@
   
   body
   
  +section name=That flaming fireball in the sky...
  +p
  +In a recent a
 
+href=http://www.theserverside.com/resources/article.jsp?l=SunInterview;
  +article/a, Karen Tegan, Director of J2EE Compatibility and
Platform
  +Services for Sun Microsystems, had the following to say:
  +/p
  +
  +p
  +The J2EE Compatible brand has achieved significant momentum over the
  +past two years, and we want to make sure that any open source efforts
  +don't impact the viability of that effort.
  +/p
  +
  +p
  +In other words, Sun doesn't give a hoot about whether J2EE licensing
  +restricts open source J2EE products (in case you missed it, it does).
  +Thus, the Apache Software Foundation's involvement in the Java
Community
  +Process (JCP) is simply an advertising statement for Sun to claim
that
  +they have a 'vision which uses open standards and non-proprietary
  +interfaces'. If you would like to express your opinions of Sun's
  +licensing terms, feel free to contact a
  +href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a and let us know what
you
  +think. Thanks.
  +/p
  +
  +/section
  +
   section name=Welcome
   
   !-- ApacheCon is over.
  
  
  

--
To unsubscribe, e-mail:  
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Struts vs. Turbine

2002-01-17 Thread Ted Husted

http://nagoya.apache.org:8080/jyve-faq/Turbine/screen/DisplayQuestionAnswer/action/SetAll/project_id/2/faq_id/36/topic_id/203/question_id/781

or (same thing) 


http://www.mail-archive.com/struts-user@jakarta.apache.org/msg03206.html
 
 http://www.mail-archive.com/general@jakarta.apache.org/msg00495.html  
 http://jakarta.apache.org/velocity/ymtd/ymtd.html 

-Ted.

Gerhard Froehlich wrote:
 
 Hi,
 DISCLAIMER: No flame war please!
 
 I just overlooked the 2 jakarta project Struts and Turbine. Both seems
 very similar to me and I want to know where they main difference
 is and when to use Turbine and when to use Struts.
 
 Please add you comments!
 
   Gerhard
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] POI @ Jakarta

2002-01-17 Thread Ted Husted

+1

Andrew C. Oliver wrote:
 
 Proposal for POI - A Jakarta Subproject
 version 1.0 - 17 Jan 2002
 
 (0) rationale
 
 The POI project seeks to provide pure Java APIs for reading, creating
 and manipulating files written in formats based on Microsoft OLE 2
 Compound Document Format.  The POI project has already successfully
 created a Pure Java OLE 2 Compound Document Format library (POIFS) and a
 port of the Microsoft Excel '97(-2002) file format (aka XLS, BIFF8) and
 tools for serializing XML in these formats (which will be hosted as part
 of Cocoon 2).
 
 The POI project user community is growing leaps and bounds in usage as
 evidenced by its position as one of the most active projects on
 SourceForge and the 2,290 people who have downloaded it so far this
 month.  The POI project currently has two active developers.  The
 development community  might be small but is fanatically committed (and
 growing rather  quickly).  It is likely that the upcoming port of the
 Microsoft Word 97 File format will increase the size of the development
 community, not to mention the user community.  The documentation is
 comprehensive and includes full documentation on the previously
 undocumented (or at least incompletely documented) Microsoft OLE 2
 Compound Document Format. There are also HOW-TO documents that
 illustrate use cases and examples. Lastly, The project founders have
 agreed to collaborate with a developer at the OpenOffice.org project on
 the Excel File Format Documentation.
 
 Many Jakarta projects could potentially take advantage of POI and its
 use in Jakarta will likely further seed the POI developer community.
 POI is a unique project in the Java world.  Up until now there have been
 no successful free attempts to provide read/write access to OLE 2 CDF or
 MS Excel (97+) file formats. POI coupled with other Jakarta technologies
 could produce some highly useful offspring.  A few specific examples
 might be Office Document indexing for Lucene, Velocity generating Excel
 and Word document presentations, Office document management capabilities
 for Slide as well as content delivery and editing in Turbine.
 
 POI would make it possible to use Jakarta and XML-Apache projects in
 many cases where currently a proprietary solution is currently required.
 
 (1) scope of the subproject
 
 The subproject shall create and maintain packages written in the Java
 language, intended for use in generating and reading files in formats
 based on the OLE 2 Compound Document Format.
 
 (2) identify the initial source from which the subproject is to be
 populated
 
 The initial packages would be based on existing POI codebase currently
 located at SourceForge:
 
 http://poi.sourceforge.net
 
 (3) identify the Jakarta resources to be created
 
 (3.1) mailing list(s)
 
 poi-user
 poi-dev
 
 (3.2) CVS repositories
 
 jakarta-poi
 
 (3.3) Bugzilla
 
 program - poi
 components - Web site, POIFS, HSSF, HDF
 
 (3.4) Jyve FAQ (when available)
 
 poi-general
 poi-poifs
 poi-hssf
 poi-hdf
 
 (4) identify the initial set of committers
 
 Andrew Oliver
 Marcus Johnson
 
 (5) identify apache sponsoring individual
 
 Stefano Mazzocchi
 --
 www.superlinksoftware.com
 www.sourceforge.net/projects/poi - port of Excel format to java
 http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
 - fix java generics!
 
 The avalanche has already started. It is too late for the pebbles to
 vote.
 -Ambassador Kosh

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] Jakarta PMC bylaws change

2002-01-16 Thread Ted Husted

+1

Sam Ruby wrote:
 
 The number of PMC seats will be set at seven.  Annually, all seven seats
 will be up for renewal.  The ASF board will be asked to provide a person or
 persons to administer the nominations and a subsequent ballot. The
 administrator(s) will determine the mechanics of the voting procedures.
 Any committer to any Jakarta code base will be eligible to vote.  Once the
 new PMC is in place, the first order of business will be to determine a
 chairperson from amongst their ranks.
 
 Once ratified, this proposal would be effective immediately, and an
 election would be initiated.
 
 - Sam Ruby
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PATCH] jakarta-site2.xml [Was Re: updating subproject websites]

2002-01-16 Thread Ted Husted

Done. 

http://jakarta.apache.org/site/jakarta-site2b.html


robert burrell donkin wrote:
 
 On Tuesday, January 15, 2002, at 10:27 PM, Ted Husted wrote:
 
  If you would like to send the XML the page to me, Robert, and I will
  post it as an alternative page, and we can whiteboard it for a day or
  two, as we did on the New Product Proposal page, before talking it live
  and direct :)
 
 sounds like a good plan to me :)
 
 - robert


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] Jakarta PMC bylaws change

2002-01-16 Thread Ted Husted

True. Right now, I monitor the Commons, Lucene, and Taglibs, and only
have commit rights to one of these. 

Since the PMC meets here, the subprojects can represent their own
interests. The primary role of the PMC is to ensure that the ASF bylaws
and Jakarta guidelines are observed, and that Apache resources are not
used in inappropriate ways. 

The PMC gets to vote on new subprojects, but the committee members have
no other special privledges or powers.

-Ted.


Marc Saegesser wrote:
 
 Simply because each Jakarta project doesn't have a committer on the PMC does
 not necessarily imply that each project would not have representation on the
 PMC.  Hopefully, through the nomination and voting process, each project
 would find someone that is willing to represent their interests in the PMC.
 Requiring direct representation for each project does not sound like a good
 long term strategy.
 
 Marc Saegesser
 
  -Original Message-
  From: Peter Donald [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, January 16, 2002 4:07 PM
  To: Jakarta General List
  Subject: Re: [PROPOSAL] Jakarta PMC bylaws change
 
 
  On Thu, 17 Jan 2002 06:27, Sam Ruby wrote:
   The number of PMC seats will be set at seven.  Annually,
  all seven seats
   will be up for renewal.  The ASF board will be asked to
  provide a person or
   persons to administer the nominations and a subsequent ballot. The
   administrator(s) will determine the mechanics of the voting
  procedures.
   Any committer to any Jakarta code base will be eligible to
  vote.  Once the
   new PMC is in place, the first order of business will be to
  determine a
   chairperson from amongst their ranks.
  
   Once ratified, this proposal would be effective immediately, and an
   election would be initiated.
 
  Sounds good - but this kinda has one other implication. The
  PMC will no
  longer be able to adequetly cover all sub-projects - it would
  be quite
  possible that some some projects would be completely without
  representation.
 
  If this was put in place it kinda suggests that maybe jakarta
  should not be
  so big ... ;)
 
  --
  Cheers,
 
  Pete
 
  
   These aren't the droids you're
   looking for. Move along.
  
 
  --
  To unsubscribe, e-mail:
  mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
  mailto:[EMAIL PROTECTED]
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: proposal for the jakarta startpage

2002-01-13 Thread Ted Husted

For the time being, I've removed the sentence about the Commons from the
working draft. 

Though, since both Jakarta and Commons have procedures for accepting new
products, it would seem polite to steer anyone interested in donating a
codebase to Jakarta to both places. After all, many proposals have been
met by the response, Why not propose this to the Commons or try it in
the sandbox. 

If another subproject were to publish guidelines for proposing a new
product, as the Commons does, then I agree we should cite that
subproject here too. 

It's also important to note that the advertisement was originally put
in by Jon Stevens, not any of the Commons committers. 

http://jakarta.apache.org/site/newproject.html


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


Peter Donald wrote:
 
 On Mon, 14 Jan 2002 00:18, Sam Ruby wrote:
  Peter Donald wrote:
   Unless you plan on adding similar comments for a few other projects I
 
  would
 
   suggest you remove the commons advertising
 
  Why?  Should the reference to Turbine be removed from
  http://jakarta.apache.org/site/source.html ?
 
  Do you have a proposed patch?  Something you would like to add?
 
 Um ... here is the section I am talking about
 
 Jakarta can host a product within a top-level subproject, or as a component
 in the Jakarta Commons. This document covers what is expected of a proposal
 for a top-level Jakarta subproject. The Jakarta Commons has a similar but
 different procedure for accepting new products. See the Jakarta Commons site
 for details.
 
 Is this something you think is needed and should be in the jakarta guidelines?
 
  Guys, I can understand why some of you may not want to participate in other
  activities, but this is no excuse for attempting to block the progress of
  others.
 
 hmm - exactly how am I blocking the progress of commons?
 
 I have wanted to do something very similar to commons for ages - hell way
 before JDD even proposed AUT which was way before commons was proposed. And
 if you recall I was somewhat active in early library-dev discussions, no? Do
 you disagree with anything here?
 
 Have I ever blocked anybody moving anything to commons?
 
 Yes I would love to particpate in commons but I probably wont because I
 consider the management process of it broken.
 
 Consider this - how many committers are there in commons atm - 10, 20, 30 ?
 Now to get a new project moved you need a 3/4 vote - lets be generous and say
 about 12 votes! That seems real likely.
 
 Then you have the joy that every commons committer has voting rights on
 everything - even code they have never contributed and never will - sounds
 like a great meritocracy - right? M, just the sort of thing we are
 meant to be promoting.
 
 So yes theres buckets of stuff in ant, in excalibur and at home that I would
 love to move to commons but that aint going to happen till its fixed or if
 ever.
 
 Considering you seem to be accusing me of blocking progress in commons I want
 you to explain it in real simple terms how I am doing it? I seem to be a bit
 think and can't quite figure it out.
 
 --
 Cheers,
 
 Pete
 
 Whoever would overthrow the liberty of a nation must begin by subduing the
 freeness of speech. - Benjamin Franklin
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: proposed redraft of the subproject proposals

2002-01-13 Thread Ted Husted

+1 

http://jakarta.apache.org/site/newproject2.html

Sam Ruby wrote:
 
 Good draft.  Here's some ideas (not quite proposals) that might merit
 discussion:
 
 1) Upping developers from 2 to 3.  I'd rather have a rule that said three
 that we chose to break on occasion than to have to explain why 2 is barely
 sufficient.
 
 2) Alignment with existing Apache subprojects.  Code that is used by many
 existing subprojects is attractive.  Code that makes use of alternatives to
 Apache code exclusively is less so.
 
 3) Warning sign: developers who ONLY work on the task because it is their
 job.
 
 4) Warning sign: lack of diversity in developers.  For example, if all of
 the developers are from the same company...
 
 - Sam Ruby


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: proposal for the jakarta startpage

2002-01-13 Thread Ted Husted

+1 

There is now a Subproject Alternatives section citing Taglibs, Avalon,
Commons, Turbine, XML, et al.

http://jakarta.apache.org/site/newproject2.html

Peter Donald wrote:
 Unless you plan on adding similar comments for a few other projects.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: updating subproject websites

2002-01-13 Thread Ted Husted

robert burrell donkin wrote:
 i've reread it a few times and i think that i might i understand it now.
 is the following the answer to 'how should i go about making changes to
 the existing web pages of a subproject':

Assuming that the subproject is setup to use the site2 default advice.
This is not required, but is usually the case. The subprojects are
responsible for their own subsite, so the best people to check with are
the committers to that subproject. 



 1. modify the subproject's xml (in the subproject's source directory) and
 run anakia to get html versions.
 2. check in the changes into CVS.
 3. logon to the machine hosting the Jakarta web site, cd to the subproject'
 s web directory and execute a 'cvs update'.
 4. enjoy the revised web pages :)

Yes, if the subproject site has been setup to work the same way the
main site works.

But, again, you should consult with the committers to the subproject. 


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




  1   2   >