Re: [VOTE] Move Jakarta to the Attic; close down Jakarta PMC

[Phil Steitz]

Is there anything left actually to put in the attic?  Maybe just disband the 
PMC?

Phil



On Nov 10, 2011, at 10:01 AM, Henri Yandell  wrote:

> A joint vote to retire Jakarta into the Attic and to ask the board to
> close down the PMC.
> 
>  [ ] +1
>  [ ] -1, because
> 
> Hen
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
For additional commands, e-mail: general-h...@jakarta.apache.org

Re: Release BSF 3.1 (based on RC3)

[Phil Steitz]

sebb wrote:
> On 19/06/2010, Phil Steitz  wrote:
>> sebb wrote:
>>  > [Third time lucky?]
>>  >
>>  > Please review and vote on the BSF 3.1 release.
>>  >
>>  > The artifacts are available at:
>>  >
>>  > http://people.apache.org/~sebb/bsf-3.1-RC3/
>>  >
>>  > The Maven artifacts are at:
>>  >
>>  > https://repository.apache.org/content/repositories/orgapachebsf-004/
>>  >
>>  > The SVN tag is at:
>>  >
>>  > http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC3
>>  >
>>  > This will be renamed following a successful vote.
>>  >
>>  > Keys are here:
>>  > http://www.apache.org/dist/jakarta/bsf/KEYS
>>  >
>>  > Vote will remain open for at least 72 hours.
>>  >
>>  > [ ] +1 I support this release.
>>  > [ ] -1 I am against releasing the packages (must include a reason).
>>  >
>>  > Thanks in advance!
>>  >
>>
>>> -
>>  > To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
>>  > For additional commands, e-mail: general-h...@jakarta.apache.org
>>  >
>>
>>
>> Sigs and hashes are good.  All else looks good; but I got this error
>>  when I tried "mvn clean test" from the source distro (JDK 1.6):
>>
>>  [INFO] Unable to find resource 'org.apache.bsf:bsf-engines:jar:3.1'
>>  in repository central (http://repo1.maven.org/maven2)
>>  Downloading:
>>  
>> http://repo1.maven.org/maven2/org/apache/ws/commons/axiom/axiom-impl/1.2.2/axiom-impl-1.2.2.jar
>>
>>  [INFO]
>>  
>>  [ERROR] BUILD ERROR
>>  [INFO]
>>  
>>  [INFO] Failed to resolve dependencies for one or more projects in
>>  the reactor. Reason: Missing:
>>  --
>>  1) org.apache.bsf:bsf-engines:jar:3.1
>>
>>
>>  When I later did just "mvn" it seems to have downloaded / installed
>>  everything it needs, so "mvn clean test" subsequently succeeds.  I
>>  don't know if this is a real problem or not.
> 
> This seems to be a general problem with multi-module maven testing.
> 
> The command:
> 
>   mvn package
> 
> works OK, and performs tests, even if the jars have not been installed
> locally yet.
> 
> However
> 
>mvn test
> 
> does not work unless you do a prior install.
> 
> I think that is a bug (or at the very least a sub-optimal design
> feature) in Maven.
> 
>>  Might be good to add
>>  something to the BUILDING doc to indicate what you have to do first.
> 
> This does already say to start by running:
> 
> mvn
> 
> The default goal is install, so this will ensure that subsequent "mvn
> test" commands do succeed.

Thanks, Sebb.

+1 for the release.

Phil
> 
>>  Phil
>>
>>
>>  Phil
>>
>>
>>  -
>>  To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
>>  For additional commands, e-mail: general-h...@jakarta.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
For additional commands, e-mail: general-h...@jakarta.apache.org

Re: Release BSF 3.1 (based on RC3)

[Phil Steitz]

sebb wrote:
> [Third time lucky?]
> 
> Please review and vote on the BSF 3.1 release.
> 
> The artifacts are available at:
> 
> http://people.apache.org/~sebb/bsf-3.1-RC3/
> 
> The Maven artifacts are at:
> 
> https://repository.apache.org/content/repositories/orgapachebsf-004/
> 
> The SVN tag is at:
> 
> http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC3
> 
> This will be renamed following a successful vote.
> 
> Keys are here:
> http://www.apache.org/dist/jakarta/bsf/KEYS
> 
> Vote will remain open for at least 72 hours.
> 
> [ ] +1 I support this release.
> [ ] -1 I am against releasing the packages (must include a reason).
> 
> Thanks in advance!
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
> 

Sigs and hashes are good.  All else looks good; but I got this error
when I tried "mvn clean test" from the source distro (JDK 1.6):

[INFO] Unable to find resource 'org.apache.bsf:bsf-engines:jar:3.1'
in repository central (http://repo1.maven.org/maven2)
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/commons/axiom/axiom-impl/1.2.2/axiom-impl-1.2.2.jar

[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve dependencies for one or more projects in
the reactor. Reason: Missing:
--
1) org.apache.bsf:bsf-engines:jar:3.1


When I later did just "mvn" it seems to have downloaded / installed
everything it needs, so "mvn clean test" subsequently succeeds.  I
don't know if this is a real problem or not.  Might be good to add
something to the BUILDING doc to indicate what you have to do first.

Phil

Phil

-
To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
For additional commands, e-mail: general-h...@jakarta.apache.org

Re: [VOTE] JMeter 2.3.2RC6

[Phil Steitz]

sebb wrote:

Trying again ...

The licence issues reported by Henri have (I trust) been fixed.

To rebuild or test JMeter, you need to unpack both the binary and
source archives in the same directory structure. This is because the
library files are not duplicated in the source archive.
  


I unpacked both, but am still getting this:
BUILD FAILED
/home/phil/jmeter/jakarta-jmeter-2.3.2/build.xml:927: 
/home/phil/jmeter/jakarta-jmeter-2.3.2/lib/opt not found.


The build succeeds (other than the test error mentioned in the README) 
if I mkdir opt from the /lib directory.


Phil


 Note that there is a bug in Java on some Linux systems that manifests
 itself as the follow error when running the test cases or JMeter itself.

 [java] WARNING: Couldn't flush user prefs:
 java.util.prefs.BackingStoreException:
 java.lang.IllegalArgumentException: Not supported: indent-number

 Archives/hashes/sigs and RAT report:
 http://people.apache.org/~sebb/jmeter-2.3.2RC6/dist

 Site/Docs are here:
 http://people.apache.org/~sebb/jmeter-2.3.2RC6/docs

 Tag:
 http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC6

 Keys are here:
 http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt
 also
 http://www.apache.org/dist/jakarta/jmeter/KEYS

 All feedback (and votes!) welcome.

[  ] +1  I support this release
[  ] +0  I am OK with this release
[  ] -0   OK, but
[  ] -1   I do not support this release (please indicate why)

 The vote will remain open for at least 72 hours.

 Note: If the vote passes, the intention is to release the archive
 files and create the release tag from the RC tag.

 Here's my:

 +1

S///

-
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: [VOTE] JMeter 2.3.2RC3

[Phil Steitz]

On Thu, May 29, 2008 at 5:56 PM, sebb <[EMAIL PROTECTED]> wrote:

> On 30/05/2008, sebb <[EMAIL PROTECTED]> wrote:
> > On 28/05/2008, Henri Yandell <[EMAIL PROTECTED]> wrote:
> >  > MD5, PGP good.
> >  >
> >  >  It's a bit odd that the binary version comes chock full of jars and
> >  >  the source version doesn't. When I run 'ant' in the source version I
> >  >  get:
> >  >
> >  >  BUILD FAILED
> >  >  /Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/build.xml:925:
> >  >  /Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/lib/opt not found.
> >
> >
> > I need to look at that.
>
> Fixed in SVN.
>
> If a build is attempted from just the source archive the output is:
>
> C:\ReleaseCheck\jakarta-jmeter-test> ant
> Buildfile: build.xml
>
> _message_3rdParty:
> [echo] Cannot find all the required 3rd party libraries.
> [echo] If building from a release, you need both source and
> binary archives.
>

I tried unpacking the binary archive and then building the sources, but even
the binary tarball does not create or populate the "opt" directory that
seems to be required by the source build.

Phil

Re: [VOTE] Commons moving to TLP

[Phil Steitz]

Stephen Colebourne wrote:
> This seems a little overplanned in my mind ;) Allow a little more evolution.
>
> - Commons goes TLP.
> - Rules for Commons TLP become clear (one mailing list, one PMC, anyone 
> commits in any component, anyone votes/reviews any release, comfortable 
> social group)
> - Then invite communities from Jakarta to join if they wish (once the rules 
> and expectations are clear)
>
> Simple. And community-up not top-down.
>   
+1

Phil
 

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

RE: [VOTE] Commons moving to TLP

[Phil Steitz]

+1
 
Phil

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.

Hen

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




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

Re: [VOTE] Petar Tahchiev as Jakarta Committer

[Phil Steitz]

+1

Phil
Felipe Leme wrote:
> Hi all,
>
> I'd like to call a vote to have Petar Tahchiev as a Jakarta Committer.
>
> Petar currently works as software engineer in Bulgaria, but was a MSc
> student last year, when we proposed porting the Cactus build to Maven
> 2 as a "GSOC" (Google Summer of Code) project. Although the project
> didn't make it to the allotted ASF projects, Petar kept doing the
> (hard) work, despite my slowness to support him.
>
> Prior to participate on Cactus development, he made some contributions
> to Apache Ant and other ASF projects. He also has a blog at java.net
> (http://weblogs.java.net/blog/paranoiabla/).
>
> A couple of months ago, I failed (again :-() to setup a sandbox SVN
> branch at ASF for him to continue his work, so he ended up creating a
> separated repository on SourceForge where we could do some work in
> parallel. Now that code is ready to come back to the Jakarta codebase,
> and the proper legal measures has already been taken (see
> http://incubator.apache.org/ip-clearance/jakarta-cactus-tahchiev.html).
>
> Besides the technical aspect, I can tell from personal experience that
> he is a talented and enthusiastic developer, and will be a valuable
> contributor to the Cactus/Jakarta communities. So, here is my (PMC
> binding) +1 vote.
>
> -- Felipe
>
> -
> 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: Nightly builds docu?

[Phil Steitz]

Henri Yandell wrote:
> On 1/16/07, Ortwin Glück <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Does anyone (Henry?) know what happened to
>>   http://www.apache.org/dev/nightly-builds.html ?
>>
>> It's referenced from
>>   http://www.apache.org/dev/
>> at the very bottom of the page. I'm looking for information how to get
>> nightly builds done for HttpComponents.
>
> It probably never existed. When that page was created the links were
> made for pages that didn't exist to encourage people to write them -
> didn't work :)
>
> Nightly build wise... it's still an unorganized situation. In Commons
> we have some hand written scripts that are used on a zone (vmbuild) to
> build the code each night. Taglibs used to be built each night on
> Glenn's machine (I suspect that's not true anymore).
>
> We could expand the script for Commons to work from the Jakarta
> perspective and not the Commons one. 
+1 and would not be hard to do.  Makes sense to do this for all Jakarta
components that want nightlies and as long as the builds are
"reasonable" in execution time, this should not be a problem.  The
current script supports Ant, Maven 1 and Maven 2.   The script code is
in svn at jakarta/commons/proper/commons-nightly/.  The main script,
commons_nigthly.sh gets svn upped on vmbuild by a crontab wrapper before
executing each night, so if you just make changes to include a new build
or build type into this script and config and check in the changes, the
new component will be added.  

Phil


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

[m2 config] was: Re: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml

[Phil Steitz]

Dennis Lundberg wrote:

I don't think so. After I had deployed the pom, Maven wanted to deploy
*all* of the sandbox components. At this point I simply canceled the
rest of the deploy.

Thanks again, Dennis.   Let's take this to commons-dev now.

Sorry, all, about all the noise.

Phil
>> Still in learning mode here...
>>
>> Phil
>
>


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

Re: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml

[Phil Steitz]

Dennis Lundberg wrote:
> Phil Steitz wrote:
>> Henri Yandell wrote:
>>>
>>> On Fri, 11 Aug 2006, Dennis Lundberg wrote:
>>>
>>>> Phil Steitz wrote:
>>>>> Thanks, Dennis.  That helps and I agree with your arguments for
>>>>> inheritence in genera;.
>>>>>  But why a Jakarta parent?
>>>> I'll leave that one for Henri to answer.
>>> Do I look like I know what I'm doing? :)
>>>
>>> The Jakarta pom is there because it seemed like a good idea to share
>>> things between Jakarta m2 projects and not just Commons ones - or at
>>> least to try and encourage that sharing. Though I had thought that the
>>> mailing lists in the parent would appear in the children and that's
>>> not happened.
>>>
>>> It didn't seem like it would be damaging to represent the current
>>> structure and Brett didn't run screaming when I asked him :)
>>>
>>> I'm not tied to it though - just throwing energy at the commons to m2
>>> problems.
>> Can someone less m2-newbie than me pls publish the jakarta and commons
>> parents to the m2-snapshot-repo?  The sandbox parent appears to be
>> there, but the others are not and they have to be manually installed to
>> get any commons m2 builds to work.   That makes it pretty hard for the
>> non-initiate to build the components (e.g. [pipeline]) that are dropping
>> m1 poms.
>
> Done.
> I have deployed the poms jakarta, commons and commons-sandbox.
>
Thanks, Dennis!

Now I am confused, though, since we seem to have both commons-sandbox
and commons-sandbox-parent and the sanbox m2 builds seem to be evenly
split between them, though all (other than pipeline) are listed as
modules of commons-sandbox.  Are these for different purposes?

Also, do we really want to have the individual components set up as modules?

Still in learning mode here...

Phil


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

Re: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml

[Phil Steitz]

Henri Yandell wrote:
>
>
> On Fri, 11 Aug 2006, Dennis Lundberg wrote:
>
>> Phil Steitz wrote:
>>> Thanks, Dennis.  That helps and I agree with your arguments for
>>> inheritence in genera;.
>>>  But why a Jakarta parent?
>>
>> I'll leave that one for Henri to answer.
>
> Do I look like I know what I'm doing? :)
>
> The Jakarta pom is there because it seemed like a good idea to share
> things between Jakarta m2 projects and not just Commons ones - or at
> least to try and encourage that sharing. Though I had thought that the
> mailing lists in the parent would appear in the children and that's
> not happened.
>
> It didn't seem like it would be damaging to represent the current
> structure and Brett didn't run screaming when I asked him :)
>
> I'm not tied to it though - just throwing energy at the commons to m2
> problems.
Can someone less m2-newbie than me pls publish the jakarta and commons
parents to the m2-snapshot-repo?  The sandbox parent appears to be
there, but the others are not and they have to be manually installed to
get any commons m2 builds to work.   That makes it pretty hard for the
non-initiate to build the components (e.g. [pipeline]) that are dropping
m1 poms.

Thanks!

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


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

Re: Jakarta BOF @ apachecon USA

[Phil Steitz]

Henning Schmiedehausen wrote:
> I'll join you and muse about the state of Jakarta. Should be fun. :-)
>   
Good idea. Assuming I make it to the conference, I will be there.

Phil


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

RE: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml

[Phil Steitz]

Thanks, Dennis.  That helps and I agree with your arguments for inheritence in 
genera;.
 
But why a Jakarta parent?  And can you answer the second question about 
addressing?  I am -0 on doing anything that cements "Jakarta" into the 
namespace above commons artifacts.  Sorry if this has been discussed and agreed 
and I just missed it.
 
Phil



From: Dennis Lundberg [mailto:[EMAIL PROTECTED]
Sent: Fri 8/11/2006 9:36 AM
To: Jakarta General List
Subject: Re: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml



Phil Steitz wrote:
> Henri Yandell wrote:
>> First few commit messages bounced on this btw, until I fixed that up.
>> It's a maven2
> Hen,
>
> Can you enlighten the rest of us as to what this is for and what, if
> any, implications it has on how we address maven2 artifacts originating
> in jakarta projects?
>
> Phil



The purpose of having a parent pom is to reduce the amount of
information you need to put in the pom of a specific project.

It also makes sure that all projects us the *same* information for
certain things. These things are put in the parent. An example of this
is which plugins *all* projects must use. Each project can then add more
plugins if they so desire.

Now I know some of you are preparing to throw in arguments about how we
tried to do this with Maven 1 and it failed. Before you do there is one
crucial difference. In Maven 1 the parent had to reside somewhere within
the same file system as your project. In Maven 2 the parent pom is
published to a Maven repository. It is then downloaded like any other
artifact by Maven automatically. So there will be no need to check out
jakarta-build from svn and putting it in the exact correct location on
your own machine.

--
Dennis Lundberg

-
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: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml

[Phil Steitz]

Henri Yandell wrote:
>
> First few commit messages bounced on this btw, until I fixed that up.
> It's a maven2
Hen,

Can you enlighten the rest of us as to what this is for and what, if
any, implications it has on how we address maven2 artifacts originating
in jakarta projects?

Phil
> parent pom for Jakarta projects. Created under advice from Brett on
> #maven :)
>
> Hen
>
> On Fri, 11 Aug 2006 [EMAIL PROTECTED] wrote:
>
>> Author: bayard
>> Date: Thu Aug 10 21:03:21 2006
>> New Revision: 430653
>>
>> URL: http://svn.apache.org/viewvc?rev=430653&view=rev
>> Log:
>> not released yet, so giving it a dev version of 1-SNAPSHOT
>>
>> Modified:
>>jakarta/jakarta-build/trunk/pom.xml
>>
>> Modified: jakarta/jakarta-build/trunk/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/jakarta/jakarta-build/trunk/pom.xml?rev=430653&r1=430652&r2=430653&view=diff
>>
>> ==
>>
>> --- jakarta/jakarta-build/trunk/pom.xml (original)
>> +++ jakarta/jakarta-build/trunk/pom.xml Thu Aug 10 21:03:21 2006
>> @@ -10,7 +10,7 @@
>>   jakarta-parent
>>   pom
>>   
>> -  1
>> +  1-SNAPSHOT
>>   Apache Jakarta
>>   http://jakarta.apache.org/
>>   1999
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

Re: Opening up the PMC

[Phil Steitz]

Yoav Shapira wrote:
> Hi,
>
>> My view is that we shouldn't keep wasting our time on such a separation.
>
> I think the separation is valid.  Jim put it nicely earlier today
> (paraphrased here): committership is the right to vote a code base,
> PMC membership is the right to oversee a project.  In my mind there
> definitely is a separation, and the latter requires more trust.  
+1  I see "PMC==committers" as an aspiration, not something that can
defined away. 
> This
> is especially true for projects whose committership is granted (at
> first maybe) on a partial basis, e.g. only to some directory trees
> within the project's SVN repository.  So if I were to go just with
> that, I'd say -0 (if only because I don't have the energy and
> bandwidth to contribute alternative suggestions, so I don't want to -1
> the issue).
>
> You mentioned that we're bad at remembering to add people to the PMC:
> agreed, but I don't think the solution to that is a policy-level one.
I agree here as well.  We should be aiming to a) get as many committers
as possible both wanting and deserving the additional trust that PMC
membership represents and b) nominating them once they have earned that
trust and indicated that they are willing to participate in the
oversight of the project. 

I agree that we can all improve the speed with which we nominate people,
but I bet if you did the super svn-analysis, you would find that people
with sustained contributions do tend to get nominated over time.  I
think the large number of non-PMC committers is at least in part
attributable to "vanishing committers" or committers whose activity is
at best sporadic. 

With my PMC member hat on, I would be hard pressed to +1 a mass addition
of PMC members based on historical commit votes from all across Jakarta,
with no support provided for any of the nominees. 
> Instead, I would opt for a simple command-line tool, to be run at the
> PMC's discretion (or indeed, probably at any committers' discretion),
> that looks at svn-authorization and spits out who's a committer for
> project X but not on the PMC for that project.  With the crew here,
> we'll probably have this tool done in your choice of the top 20
> programming languages in under an hour.  Heck we can even make it a
> cron / gump / nag the PMC chair every month type of thing.
>
> The above said, I think Jakarta is a different beast.  Because it's an
> umbrella project, it has many disparate groups of people doing their
> own thing.  In a nicer world, those smaller groups would be
> responsible for their oversight, so we'd have multiple smaller PMCs
> instead of one big Jakarta one.  And I think that's where we're
> heading gradually, as we graduate projects, make them dormant, move
> them elsewhere, etc.
>
> But because of the current structure of Jakarta and its current
> membership, I'd probably say +0.  It's not optimal, but it might be
> the best solution for a large and largely mature umbrella-type
> project.
>
Here I disagree.  When you think about it, making committers==PMC
analytic really amounts to dissolving the PMC.  It could be that
dissolving Jakarta is a good idea sometime soon, but as long as it
exists as an apache project, it needs a PMC which is more than just a
collection of committers with binding votes on code.  This is why PMCs
exist at apache and why you can't *define* the PMC to be the set of
committers.

As an alternative to Hen's "invite everyone" proposal, I would be fine
with allowing and encouraging self-nominations.  That would bring out
committers who really want to be part of the PMC, but still allow us to
vote them in. 

Phil
 

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

Re: testing.apache.org, take 2

[Phil Steitz]

Rahul Akolkar wrote:
> On 6/20/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
>> Rahul Akolkar wrote:
>> > On 6/16/06, Felipe Leme <[EMAIL PROTECTED]> wrote:
>> > 
>> >>
>> >> I think these statements are a good start for the next meeting's
>> >> proposal - could someone write an wiki entry for it (or even update
>> >> the current resolution)? I'm traveling until Sunday and my internet
>> >> connection is pretty bad here, so it would be hard for me to do it...
>> >>
>> > 
>> >
>> > Thanks for putting it all together as a summary, I've put the closing
>> > statements from that email, verbatim, on a wiki page [1]. Its open to
>> > edits (I might make some minor edits myself in a day or two).
>> This is good.  Here are a few additional things that we might want to
>> think about adding, assuming all are OK with these commitments.
> 
>
> This (below) is generally in line with my expectations of how things
> should work, and aligned to what we've said previously in these
> threads, IMO.
>
> Ideally, there'd be a mechanism to get some feedback, even in your
> absence (thanks for volunteering though).
>
> -Rahul
>
>
>>  This
>> list is designed to address some of the concerns that have been raised
>> in the past about umbrella projects.  Obviously, not all may agree with
>> the points below, and even with these provisions, the board may not
>> approve the Testing proposal.  I just thought it would be a good idea to
>> get these ideas out for discussion for this and the other
>> "umbrella-like" things that we may be splitting Jakarta into.
>>
>> 1.  The PMC members named in the proposal are signing up to provide
>> oversight for the *entire project*, not just "subprojects" that they
>> participate in.  In fact, there are formally no subprojects, just
>> products or code bases that are versioned / released separately.   I
>> would recommend that we avoid the use of the term "project" other than
>> for the TLP itself and avoid "subproject" altogether.
>> 2.  As new components are incorporated, the PMC will grow and will
>> always include the (the majority of) active committers working on each
>> of the components.  Ability to make decisions on behalf of the whole
>> project will be considered when granting commit access.
>> 3.  A necessary condition for adoption of a codebase or creation of a
>> new component will be commitment from a minimum of 3 PMC members
>> (possibly existing ASF committers, joining with the codebase) agreeing
>> to review / apply patches, review commits, serve as RM, etc. for the new
>> component.
>> 4.  If one or more of the components, or the entire project, grows in
>> complexity or community size  to
>> the point where effective oversight / active involvement by the Testing
>> PMC on all components is no longer possible, the project will be split
>> (just as Jakarta is being split now, per this proposal).  Note that this
>> is a statement of intent, not an administrative mandate (i.e., the
>> somewhat painful, consensus-driven process that we are following now in
>> Jakarta is our *intention* to improve and maintain).
>> 5.  Inactive components, or components without a sufficient number of
>> active PMC members, will be regularly archived.
>>
>> One more personal thing:
>>
>> I just learned that the board meeting has been postponed until next
>> Tuesday.  Unfortunately, I will not able to attend that day.  Therefore,
>> it would be great if one of the other members supporting this proposal
>> could step up to attend.
>>
>> Phil
With his permission, I am forwarding an excerpt from a recent post from
Roy Fielding, in response to questions about a proposed "Security" TLP
originating out of the XML project.   The concerns he raises below all
pretty much apply directly to Testing.  Could be the right approach here
is to limit it to Cactus + Jmeter, or even have them each TLP
separtately.  I think the key is really point 1. above as well as Roy's
argument below about not claiming dominion over a topical area.

Roy Fielding on 6/22:

"When a project "owns" a category, such as security, the participants
think that they are responsible for all Apache products in that space.
Meanwhile, what they are actually working on is a fairly small project
that addresses the specific requirements of a given set of users, such
as xml-security.  People don't try to make products that are applicable
to every possible consumer in a given category, and volunteers cannot
ove

Re: testing.apache.org, take 2

[Phil Steitz]

Rahul Akolkar wrote:
> On 6/16/06, Felipe Leme <[EMAIL PROTECTED]> wrote:
> 
>>
>> I think these statements are a good start for the next meeting's
>> proposal - could someone write an wiki entry for it (or even update
>> the current resolution)? I'm traveling until Sunday and my internet
>> connection is pretty bad here, so it would be hard for me to do it...
>>
> 
>
> Thanks for putting it all together as a summary, I've put the closing
> statements from that email, verbatim, on a wiki page [1]. Its open to
> edits (I might make some minor edits myself in a day or two).
This is good.  Here are a few additional things that we might want to
think about adding, assuming all are OK with these commitments.   This
list is designed to address some of the concerns that have been raised
in the past about umbrella projects.  Obviously, not all may agree with
the points below, and even with these provisions, the board may not
approve the Testing proposal.  I just thought it would be a good idea to
get these ideas out for discussion for this and the other
"umbrella-like" things that we may be splitting Jakarta into.

1.  The PMC members named in the proposal are signing up to provide
oversight for the *entire project*, not just "subprojects" that they
participate in.  In fact, there are formally no subprojects, just
products or code bases that are versioned / released separately.   I
would recommend that we avoid the use of the term "project" other than
for the TLP itself and avoid "subproject" altogether.
2.  As new components are incorporated, the PMC will grow and will
always include the (the majority of) active committers working on each
of the components.  Ability to make decisions on behalf of the whole
project will be considered when granting commit access.
3.  A necessary condition for adoption of a codebase or creation of a
new component will be commitment from a minimum of 3 PMC members
(possibly existing ASF committers, joining with the codebase) agreeing
to review / apply patches, review commits, serve as RM, etc. for the new
component. 
4.  If one or more of the components, or the entire project, grows in
complexity or community size  to
the point where effective oversight / active involvement by the Testing
PMC on all components is no longer possible, the project will be split
(just as Jakarta is being split now, per this proposal).  Note that this
is a statement of intent, not an administrative mandate (i.e., the
somewhat painful, consensus-driven process that we are following now in
Jakarta is our *intention* to improve and maintain). 
5.  Inactive components, or components without a sufficient number of
active PMC members, will be regularly archived.

One more personal thing:

I just learned that the board meeting has been postponed until next
Tuesday.  Unfortunately, I will not able to attend that day.  Therefore,
it would be great if one of the other members supporting this proposal
could step up to attend. 

Phil

 


 

 

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

Re: testing.apache.org

[Phil Steitz]

Henri Yandell wrote:
>
>
> On Sat, 10 Jun 2006, Phil Steitz wrote:
>
>> I was not planning to attend the board mtg - I just volunteered to fill
>> in by preparing the Jakarta report and submitting it on Hen's behalf.  I
>> don't think delegates / proxies are allowed at board mtgs.   I am happy
>> to do whatever I can to help make sure the proposal gets fairly
>> reviewed, though.
>
> Any member can call in to the board meeting as a guest - for the last
> few I've been calling in as a guest just out of interest to see what
> goes on, and as I'm there I get asked about the Jakarta bits that come
> up.
>
Thanks for clarifying this, Hen.  I thought PMC chairs always attended
the meeting and that they were otherwise closed. Sorry for the
confusion.  I will plan to join as a guest.  If any of the other
sponsoring members are available, please feel free to step up for this.
>> It would seem a reasonable request to have one of the people on the
>> proposal attend the meeting to represent Testing.  Does anyone know how
>> this kind of thing has been handled in the past at board meetings?
>
> Imprompty IRC conversations I suspect, and someone on the board being
> tasked with sending a reply to the people taking up the resolution. I
> didn't do a very good job of making notes of that when I was listening
> in, so my passing of information back is a bit anaemic.
OK, I will plan to join the meeting and do my best to get a clear
picture of what the board is looking for. 

Phil


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

Re: testing.apache.org

[Phil Steitz]

Rahul Akolkar wrote:
> On 6/10/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
>> Rahul Akolkar wrote:
>> 
>> >
>> > While it may make sense to say something along those lines in a larger
>> > context, I do not believe this can be part of any central argument
>> > towards the cause.
>> >
>> > If we're going to stand, we are going to do it on the basis of the
>> > merit of our proposal and the community support for it, rather than
>> > some sort of comparative analysis.
>> That's not what I meant.  If the objection is "this looks like an
>> umbrella, and umbrellas are evil" it is fair and reasonable for us to
>> ask what exactly is meant by an umbrella so that we can address the
>> specific concerns directly.
>>
> 
>
> Agreed.
>
> Phil, are you going to fill in for Hen at the next board meeting? I
> have no clue who attends board meetings (members? officers of the
> foundation? -- we have a few members listed on the proposal). We need
> someone to talk to this proposal when it is picked up at the next
> meeting. Are you willing and able?
I was not planning to attend the board mtg - I just volunteered to fill
in by preparing the Jakarta report and submitting it on Hen's behalf.  I
don't think delegates / proxies are allowed at board mtgs.   I am happy
to do whatever I can to help make sure the proposal gets fairly
reviewed, though. 

It would seem a reasonable request to have one of the people on the
proposal attend the meeting to represent Testing.  Does anyone know how
this kind of thing has been handled in the past at board meetings?  

Phil


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

Re: testing.apache.org

[Phil Steitz]

Rahul Akolkar wrote:
> On 6/9/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
>> Rahul Akolkar wrote:
> 
>> >
>> > Per the umbrella concern, the question then becomes what -- if any --
>> > are the mitigating factors that can address such a concern with
>> > regards to this proposal. Based on Hen's email, seems like the ball is
>> > still in the board's court -- as we wait for the next meeting -- so
>> > maybe its premature to discuss if we should be trying to address those
>> > comments yet?
>>
>> I would also like to understand exactly what the problem is and what
>> mitigating steps may be possible.  In particular, I would very much
>> appreciate a definition of "umbrella" that allows Geronimo, Logging,
>> Jakarta Commons, DB, XML, Web Services and Struts,  but somehow
>> disallows Testing.
>>
> 
>
> While it may make sense to say something along those lines in a larger
> context, I do not believe this can be part of any central argument
> towards the cause.
>
> If we're going to stand, we are going to do it on the basis of the
> merit of our proposal and the community support for it, rather than
> some sort of comparative analysis.
That's not what I meant.  If the objection is "this looks like an
umbrella, and umbrellas are evil" it is fair and reasonable for us to
ask what exactly is meant by an umbrella so that we can address the
specific concerns directly.

Phil
 

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

Re: testing.apache.org

[Phil Steitz]

Rahul Akolkar wrote:
> On 6/6/06, Felipe Leme <[EMAIL PROTECTED]> wrote:
> 
>>
>> So, answering your question, yes, the project is supposed to support
>> libraries from another languages. In fact, the existence of such
>> libraries is an argument for the TLP creation; besides the existing
>> Cactus and JMeter, we have at least 3 sub-projects contenders (the 2 you
>> mentioned and one for testing HTML pages), 4 if we count DbUnit
>> (although this one will take more time due to the licenses
>> incompatibility).
>>
> 
>
> Yup, there clearly is developer/community interest towards the
> formation of this project. Plus, there is a chance to rejuvenate some
> existing projects by sheer proximity to newer projects with active
> developers (amongst other things).
>
> Per the umbrella concern, the question then becomes what -- if any --
> are the mitigating factors that can address such a concern with
> regards to this proposal. Based on Hen's email, seems like the ball is
> still in the board's court -- as we wait for the next meeting -- so
> maybe its premature to discuss if we should be trying to address those
> comments yet?
I would also like to understand exactly what the problem is and what
mitigating steps may be possible.  In particular, I would very much
appreciate a definition of "umbrella" that allows Geronimo, Logging,
Jakarta Commons, DB, XML, Web Services and Struts,  but somehow
disallows Testing. 

Phil
 

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

Re: Other Jakarta Components

[Phil Steitz]

Martin Cooper wrote:


I think this whole thing is putting the cart before the horse. You're in the
process of destroying Commons, not just dismantling it, and for no good
reason that I can see. The people involved with Digester should be the ones
to initiate a discussion about whether or not they want to take Digester
elsewhere. As it is, this is coming across more like "why don't you guys go
away, somewhere far away, 'cos we think that's a good idea".

Stephen's proposal for Jakarta Language Components came from "inside" that
grouping. So should any other proposals for groupings or departures.

With respect to departures in particular, there is a serious potential for
losing community. For example, I keep tabs on a bunch of different Commons
components, primarily because all of the discussions happen on communal
lists. If Digester and DbUtils, for example, go to some other community
where they also share lists, I am very unlikely to sign up for those lists
just to keep tabs on those components. Maybe the developers will move, but
how much of the community will go with them?
  
I agree strongly with the points above.  I am +1 for jlc but -1 for 
"engineered dissolution" of j-c.  The key point is that movement needs 
to be driven by people who want to move.  Consider these two specific 
examples:
[naming] - we decided on "ontological" grounds to move this to Directory 
some time ago.  We were never able to build a community around it there, 
the Directory community had no interest in it, and it has gone nowhere.  
Of course, it may have gone nowhere in j-c as well, and its stalling 
could all just be lack of vision / ability to get tomcat to go along, 
but I can't help thinking that it would have done better off staying in j-c.
[dbcp] - suppose some grand scheme had already moved it to DB.  Would 
volunteers there now be stepping up to maintain it now?  If the move to 
DB was initiated by community members who really wanted to drive it, 
then the answer would likely be yes.  That is the key point. 

There have been *many* examples over the years of j-c community members 
stepping up to contribute to components that they were not involved in 
when they started at the commons.  There is also tremendous value in the 
collective oversight, both technical and community / legal, that happens 
in j-c.   We should think very carefully before dissolving that community. 


Phil

Phil


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

Re: Other Jakarta Components

[Phil Steitz]

Thomas Dudziak wrote:

On 3/7/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:

  

Thomas Dudziak wrote:


Could you elaborate a bit on what the physical / visual-to-users
differences to the current commons, well, Jakarta sub-project will be
? Will this be a new Jakarta sub-project (and the other commons
components will remain in the current commons one) ?
  

I've been trying to dodge this question. Why? Because I want to
encourage other groupings (especially from commons) to self-select. If I
make a proposal, then it will be an imposition.

My hope is that in a few months we will have a mentality of working on
*Jakarta* components, not working on commons (or any other) components.
To achieve this will require other groupings.

Note: I suspect that some Jakarta sub-projects, perhaps POI, Turbine and
Velocity, may have real issues with this whole grouping philosophy. My
answer is to *not* force communities that are truly content with the
status quo to change.

Each grouping will have:
- a bland name (Jakarta Xxx Components)
- an identity (how and why does the group exist)
- sufficient size (to be active not inactive)
- mailing lists (one ML for all Jakarta doesn't work)
- SHARE COMMON ISSUES on a shared ML, [EMAIL PROTECTED]

What I will say is that its too early to worry about website issues. For
now, all we need to know is that there will be a link somewhere to each
component, and probably a single page describing each group. Pages such
as release procedures etc are Jakarta-scoped and discussed on [EMAIL PROTECTED]



I understand this, but I wonder whether this move will have an
immediate negative effect on the other Jakarta components in terms of
developer attention both to the projects and to the users. As you say,
probably not so much for the direct Jakarta sub-projects like
Velocity, but for the other commons components.
  
This is a good question and the one that has always given me pause when 
thinking about breaking up j-c.  My expectation, though, is that like me 
personally, many of the people that will be active in jlc will also 
remain active in other components.  The benefit will be for new 
contributors or those who want to just focus on the jlc components.  The 
"does it make sense as an extension to JSE?" scoping criteria is also a 
powerful means of focussing effort for this group.

As a side note, perhaps this is an opportunity to evaluate if there
are better homes for some of the components ? E.g.
betwixt/digester/jxpath could benefit from going to XML commons, dbcp
and dbutils from going to DB etc. ?
  
Definitely, but I think it is best to first get jlc set up and then let 
these discussions happen independently.  Changes should be driven by the 
people in the communities who want to make them.


Phil

cheers,
Tom

-
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] Jakarta Language Components

[Phil Steitz]

Stephen Colebourne wrote:

Roland Weber wrote:

Hello,


other 1-word suggestions would be great.


since they're language components, you can call them "Syllables" :-)


I understand the desire for 'fancy' names, but it misses the point 
unfortunately. This is merely a grouping a several *Jakarta* components.


A fancy name should be thought of as implying TLP status.


+1 for the idea and also for the "bland" name - one of the things that I 
personally like about the I guess soon-to-be-defunct (sob, groan, choke 
j-c charter.


Thanks, Stephen for pushing this forward.

On the mailing list issue, I assume you mean we would have a jlc-dev, 
and jlc-user as well as the Jakarta-dev that you mention.


Also, while this is technically [OT] here and probably deserves its own 
thread on j-c-dev, I would like to see [id] adopted as part of the 
formation of jlc - i.e., let it graduate into the new entity.


Phil


Phil


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

Re: Notice of intent.... #2

[Phil Steitz]

Henri Yandell wrote:



As a second email in the Notice of intent series; here's what I think 
being a Jakarta component will be like in the future.


* Jakarta is a collection of components. Hopefully all sitting at the 
same level. ie) a big bag of things.


How are you defining "component"?   Something reusable?  Something you 
build applications with?  Something like a commons component?  If that 
is the case, then Jmeter, Cactus, Velocity et al would have to go TLP.   
Is that part of the plan?




* Groups exist. These are categorically not subprojects, but a way to 
allow for slicing of the website etc. Some groups may have their own 
mail list; thus the importance of making sure they don't become 
subprojects. An important rule will probably be that they must do 
votes on the main list.


Hopefully we can keep it at a point where the groups are really just 
there to refine the flow of mail, not to separate it. HttpComponents 
is an example of this (though not a good one as most of its components 
came from HttpClient). WebComponents (formerly hoped to be known as 
Silk) is another example.


Commons would be groupalized out. 


Not sure I understand exactly what you mean here, but if it means 
breaking commons up - even the list - I think we should think very 
carefully about that.  From what may be a selfish perspective - and 
which I will back off from if the rest of the community feels otherwise 
- I think getting feedback from the full group of commons committers and 
voluneers *really* helps those of us who work on commons components.  I 
am afraid that if we break up the dev list and we don't all just agree 
to subscribe to all of the sublists (really defeating the purpose), we 
will both have a harder time building community around components and we 
will lose some valuable feedback.  We will also have less collective 
energy to apply to things like the site, how we think about versioning 
and releases, etc.  We are developing a pretty good body of collective 
experience developing small java components and I think that if we 
"split up" now we may be losing something.


Hopefully. Groupings are not vague names - HttpComponents good, Silk 
bad. CoreComponents good, Turbine bad. The idea with that being that 
boring grouping names are intentionally dull, no subcommunity 
identification.


+1 - as we at least used to state in the commons charter ;-)



* No svn authentication beyond being in the jakarta group. Velocity 
coders have rw access to POI.


+1



* Improved Committer->PMC process. Chair's responsibility (I've failed 
at this so far) is to turn around the new committer process. A new 
committer of 6 months is effectively voted against going to the PMC, 
not for. Might not be able to make it exactly that way, but the idea 
being that joining the PMC is the exception, not the norm. Personally 
I'd like to see committership be removed if people repeatedly are not 
allowed onto the PMC.


Not sure about this one.  I am OK with kicking off the nomination more 
or less automatically, but would prefer that it be a postive vote.




* Application of Commons thinking. Not entirely sure on this one as I 
think we've overcomplicated things in Commons a bit; but things like a 
common build system, common site system etc.


* Sandbox becomes a Jakarta resource, not a Commons resource. Much of 
the same rules as it has currently. Probably a separate mailing list.


I agree with Martin's comment on this.  


Phil


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

jakarta future WAS: Re: Starting a java specs project (fwd)

[Phil Steitz]

Henri Yandell wrote:







It would be great if we could get a consensus on what an "umbrella"
 is and



An umbrella is a joining of disjoint communities under a common TLP. 
A non-umbrella is one in which the whole project is a part of the 
same community.


Nice definition. Thanks.



The biggest problem with Jakarta currently is that we've become 
increasingly disjoint. In many ways we are less healthy than we were 
4 years ago. We have less projects, but much less in the way of 
intersection between communities. We've replaced a 7 person sub-board

 with a single chair [though there is now quite a clear direction for
 that single chair].


Thanks again. So the real problem is "disjointness."  It seems then that
we have three logical alternatives:

0) Full disintegration - all projects (incl j-c) become TLPs or die and
Jakarta effectively dies as a concept.

1) "Commons or bust" - lump small components (e.g. BCEL, ORO) into j-c
and move the others (e.g. Tapestry, Jmeter, Cactus) to TLP.  Keep
jakarta-general around and the Jakarta site for general Java
community-building across apache.

2) Re-aggregate - divide Jakarta up into a small number of "cohesive"
aggregates. Its not clear to me how this would work or if this kind of
"encouraged merging" is a good idea; but it is logically the same sort
of thing that you are hinting at in 1).

0) seems a shame from the "Java community" and "Jakarta brand" (whatever
that means) standpoint; but may be the most reasonable thing to do.  My
concern with 1) is that j-c is already having trouble scaling and I am
not so sure that once things are merged in (or out) there is anything
substantial left for "Jakarta" to be (i.e., I am having a hard time
seeing the real practical difference between 0) and 1)).  I have to
confess to having no idea how to do 2), but maybe others in the
community do - ideally people working on projects that might want to
"aggregrate."

Phil



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

Re: Starting a java specs project (fwd)

[Phil Steitz]

Henri Yandell wrote:


An FYI. Please kick me if I'm going too far with these ideas; I get the 
feeling I have a general +0, but hard to tell sometimes.


See interspersed. I am not quite to the "+" point yet, but probably 
either just missing some concepts / principles or interested in 
understanding better what the alternatives are.



Hen

-- Forwarded message --
Date: Tue, 27 Dec 2005 11:42:47 -0500 (EST)
From: Henri Yandell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: general@incubator.apache.org
Subject: Re: Starting a java specs project


One idea was to collate them as a part of Jakarta.

My aim for Jakarta is to either promote subprojects to TLP or flatten 
them into Jakarta Commons, 


The risk there is j-c becoming the new "umbrella."  We are also having 
enough trouble scaling j-c now.


leading to a non-umbrella Jakarta 


It would be great if we could get a consensus on what an "umbrella" is 
and what is bad about it. I don't want to open too many cans of worms 
here; but not all of us were around for the "good old bad old days" of 
Jakarta.  It seems to me that all of the following could now be 
considered "umbrellas" in some sense, but we (apache) seem to be 
collectively OK with them:


Geronimo
Web Services
XML
Struts
DB
Logging
Portals

But somehow Jakarta is "too big."  If you look at all of the code now 
coming into Geronimo with the incubations in progress, it will be larger 
than Jakarta currently is soon. So why exactly do we need to either 
mash, e.g. Hivemind into Commons or move it to TLP?  If the answer is 
"PMC oversight" then why doesn't that apply to the projects above as 
well?  We have made a lot of progress - mostly thanks to you, Hen - 
getting adequate PMC representation from all Jakarta projects, so I 
don't see that as such a big concern any more.


So what problem exactly are we trying to solve by pushing things out or 
mashing them into Commons?  I don't mean to be argumentative here, I 
just want to understand clearly what the goal is and what our acceptable 
options are. It would be great to have some principles on what kinds of 
"aggregates" (euphemism for "umbrellas" ;-) are OK and what kinds are 
not.  Based on these principles, we might decide to divide Jakarta 
differently, creating some smaller aggregates rather than one big one 
(j-c) and a string of small TLPs.


(I know,
you didn't think you'd see it in your lifetime). This new Jakarta would 
have the potential to serve two roles:


1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED]
2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons]


While j-c might have begun as 2), this is no longer the whole story, or 
even the main story any more.


Storing the spec source there would be good for everyone I think; it 
would help bring people to Jakarta to share code and conversation, and 
the Commons community would make good stewards for the code if the 
various owners departed.


We already have too much orphaned code in j-c, IMHO.  The advantage of 
bringing this stuff to j-c would be bringing in some more active and 
engaged committers.  This I am sure we would all welcome.  Orphaned code 
we would not.


Maintaining this code will require some specialized expertise most 
likely concentrated in projects like Geronimo, Tomcat, etc.  If 
committers from these projects are interested and willing to sign up to 
actively support the code in j-c (including responding to user 
questions), I am sure we will be happy to have them join us.  I would be 
hesitant to volunteer the j-c community, however, as a support mechanism 
without ongoing active involvement from the apache projects using the 
specs, though.


Some other pluses are that it would help be a part of an attempt to 
rejuvenate Jakarta in 2006 (as a kind of federation) and that non-JCP 
specs could be stored there too.


Not trying to intrude on the JCP stuff though, so I can see if it's 
preferred to keep things under a strictly JCP-oriented environment.


Hen

On Tue, 27 Dec 2005, Alan D. Cabrera wrote:

There has been some discussion on creating a Java specs project which 
would hold all the specs jars from the various JSRs as well as other 
standards, e.g. CORBA.  Often, there are many duplicate "copies" of 
the source code for the same JSR floating around in different Apache 
projects.  It would be a great idea to move them all into one 
project.  This idea, so far, has been met with much enthusiasm.


How do we get this started?


Regards,
Alan





-
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: [site] Missing source files

[Phil Steitz]

Yes, and (thanks to Rahul), Step 12 of the commons release instructions

has been updated to reflect the change.

One more note that I am about to add is that the Ant build now used to 
gen the Jakarta site requires JDK 1.5, so make sure that ant is using a 
1.5 JDK and check html diffs locally before committing.


-Phil

Rahul Akolkar wrote:

On 12/23/05, Martin Cooper <[EMAIL PROTECTED]> wrote:


I just went to add the Commons FileUpload 1.1 release to the Jakarta site,
and discovered that at least two files are missing from the source repo. The
news files for Q3 and Q4 of this year are present in the repo only as HTML
files; the corresponding XML source files are missing. This is not good, to
say the least. Does anyone have any insight as to how this happened? Does
anyone have the source files that they could add back? I'm not about to
start hacking the HTML files to add the FileUpload release...





Martin,

IIUC, the site build has changed a bit in that regard. The news items
now go into the news.xml file in the top level site directory, and the
build will generate the Q3/Q4 HTML files out of there. Ofcourse,
downloads.xml needs to be updated as before.

-Rahul




--
Martin Cooper





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

[Annoucement] Commons Math 1.1 Released

[Phil Steitz]

The Jakarta Commons Math team is pleased to announce the release of 
Commons Math 1.1.


Commons Math is a library of lightweight, self-contained mathematics and 
statistics components.  For more information, see the Commons Math web site:

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

The new release contains bug fixes and enhancements. All API changes are 
binary compatible with version 1.0. The enhancements include some new 
probability distributions, a Fraction class, new matrix and numerical 
utilities, and a PRNG pluggability framework making it possible to 
replace the JDK-supplied random number generator in commons-math (and 
elsewhere) with alternative PRNG implementations.  A full list of 
changes since the 1.0 release can be found in the change log at

http://jakarta.apache.org/commons/math/changes-report.html.

Commons Math is available in either binary or source form from the 
Commons Math downloads page on the Apache mirrors:

http://jakarta.apache.org/site/downloads/downloads_commons-math.cgi.

The commons-math 1.1 release jar has also been deployed to the Apache 
Maven repository:

http://www.apache.org/dist/java-repository/
and the Maven main repository:
http://www.ibiblio.org/maven/.

Please remember to verify the signatures of the files you download using 
the keys available on the download page.


Jakarta Commons welcomes community participation and contributions from 
all interested parties. User feedback or questions related to Commons 
Math should be directed to the commons-user mailing list. 
Development-related topics are discussed on the commons-dev list. See 
the Commons mailing list page 
 for 
instructions on how to subscribe to or view the archives of these lists. 
Please start the subject line of math-related posts to either of these 
lists with [math].


To submit patches or bug reports, follow the directions on this page:
http://jakarta.apache.org/commons/math/issue-tracking.html

Thanks in advance for your feedback!

-The Commons Math Team

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

Re: Multidoc-jnr - opinions?

[Phil Steitz]

Sorry, should be

http://people.apache.org/~psteitz/apidocs/maven.xml

-Phil

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

Re: Multidoc-jnr - opinions?

[Phil Steitz]

Henri Yandell wrote:



On Wed, 24 Aug 2005, Henning Schmiedehausen wrote:


Hi,

I toyed with similar ideas for a long time (I even had once an intern
whip something up), however, there are a number of drawbacks:

- different versions. The osjava variant tries to get this right by
 allowing the user to choose the versions.

- inter-project links. Phils' variant builds everything in one big
 javadoc (don't do that. IMHO). So links beween projects are resolved
 correctly. You might even toss in links to Suns' official API docs
 for java.* and sun.* packages



Once the versions are in official locations, each project can set their 
linking (least at osjava that's my plan). So links will work, but it 
won't all be in one big centrally built javadoc.


Nicest would be to do this in maven.xml; have it automatically know the 
structure of the local javadoc tree and link the dependencies in. 
Easiest is to just hack each one into the project.properties.


More on this when I get put another burst of energy into it. Also as the 
jar files are there, I think I can do something very cool with clirr :)




I got the "single big javadoc" thing to work using maven without having 
to reference any of the projects directly (other than attributes, which 
has its sources in a non-standard place).  The packages come out sorted 
in "reactor order", though and due to general lack of enthusiasm for 
this approach, I did not spend any time trying to get jelly's util:sort 
to work to fix this.  The maven.xml linked below contains some things 
that may be useful for the aggregation approach - collecting 
dependencies and javadoc links from the subprojects.


http://people.apache.org/psteitz/apidocs/maven.xml

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

Re: Multidoc-jnr - opinions?

[Phil Steitz]

Henri Yandell wrote:


Prototype of what I want to do javadoc-wise for Jakarta :)

http://dist.osjava.org/releases/multidoc-jnr/

(click on something as long as it's not Payload 0.3 or 0.4; seems my 
distributions are lacking javadoc there).


Any opinions?


I like the idea of doing this and being able to easily find javadoc for 
all release versions.  It might be more convenient and maybe less 
confusing to have the release versions on the front page, though, so you 
could click on the release you are looking for.


I have been playing with something similar for commons using ant.  Here 
is an example built from current svn trunks:


http://people.apache.org/~psteitz/apidocs/

I was thinking we could add a link on the commons site to "current" 
combined api docs and also "latest release" with the titles changed to 
include the release nunmbers. To keep the "current" content up to date, 
we could in theory add the generating ant script to the nightly build. 
This could be a slight pain to maintain, however, and because javadoc 
likes to do everything in memory, it is a pig to run. The script is here:

http://people.apache.org/~psteitz/apidocs/build.xml

Maybe its just me, but I like being able to browse all of the packages 
in one place.


Phil



-- Forwarded message --
Date: Sat, 20 Aug 2005 03:07:46 -0400 (EDT)
From: Henri Yandell <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Osjava-users] Multidoc-jnr - opinions?


Multidoc was an idea I had to generate a project-wide documentation site
based on links to parts of each individual project (javadoc, xref,
jcoverage etc). http://multidoc.osjava.org/. It works, but has complexity
(has to scrape the parts of the projects to build its front pages).

Multidoc-jnr is a simpler idea, with a much simpler implementation
(http://svn.osjava.org/svn/osjava/trunk/multidoc-jnr/) that does much the
same thing for released javadoc.

Take a look:  http://dist.osjava.org/releases/multidoc-jnr/

Hen

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




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

Re: [VOTE] Naming for new Jakarta subproject

[Phil Steitz]

Henri Yandell wrote:


Sorry for the 5 day instead of 1 day delay. Decided it was time to sell 
the house so have spent much time tidying up :)


Please vote from the following shortlist of names. Please ignore the Web 
vs Web App vs Webapp issue for the moment.



[+1]Apache Silk 
[-0]Apache Web Bricks

[-1]Apache Web Commons (branding issue with Commons)
[+0]Apache Web Components
[-1]Apache Web Parts   (conflict with Microsoft and an sf.net project)


Phil



Assuming it doesn't degenerate into confusion, I'll end the vote on 
Sunday midday EST. 3 votes needed, simple majority wins.



(On Silk:
  Old name of JScheme back in the 90s. Unsure why they renamed.
  One of the potential names for Java:
http://www.javaworld.com/javaworld/jw-10-1996/jw-10-javaname.html
)

--
Veto'd, either by lack of anyone pushing them forward when I listed 
options, or by what seemed to be good reasons:


Web Artifacts - artifacts too vague
Web Modules   - modules too overloaded
Web League- implications on community structure
Web Confederation - implications on community structure
Web Bloc  - ditto;
Webbies   - website awards
Weblets   - implies inheritable framework
Arctic, Telsa - Too obscure
Web Tools - Clash with Eclipse, seems like it would be too close
Jakartlets- Jakarta shouldn't be in the name
Web Libs  - Hard to say quickly :)


-
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: Jakarta - Cleaning house

[Phil Steitz]

Brett Porter wrote:

On 8/10/05, Henri Yandell <[EMAIL PROTECTED]> wrote:


Promoting Commons Sandbox to SLP as 'Jakarta Sandbox'.
+  All Jakarta committers given access, central management of the sandbox
+  concepts as opposed to individual SLP sandboxes (Taglibs, Commons,
+  Turbine probably has things which could have gone in a sandbox).



I'd be interested to know how this works - I'm not sure unification
brings much to each of them, but it would allow a bit more oversight
by Jakarta as a whole as to each things health.


I am -0 on this, meaning I need to understand more what exactly it will 
accomplish and I have a couple of concerns. First I am worried that for 
j-c-s in particular, separation from j-c will make it harder for j-c-s 
projects to gain critical mass and "graduate" to commons proper.


Second, removed from a "parent" SLC, a sandbox becomes a tricky thing to 
provide effective overight for. The mentor and ppmc roles in the 
Incubator are there for a reason. I would actually be more concerned 
about oversight in an "aggregated" sandbox.


If we can implement the "cleanup" policies that we have been discussing 
on commons-dev, I think the j-c sandbox should continue to work fine as 
it is and in fact be a model for the other SLPs, each overseeing its own 
if desired.  As I said, I need to understand better what problem we are 
trying to solve here.




Deletion of all CVS/SVN karma (and subsequent re-addition upon request).
+  Clean up the very large lists of committers we have in each SLP.
+  Later the jakarta unix group can be sync'd to the SVN jakarta list.
+  Should spur a large-scale nomination of new PMC members.



To save a bit of hassle I think you'll want to start by re-adding
anyone who committed to that project in the last 90 days, otherwise
that's a lot of requests :)


Yes, definitely.  Here again, not sure exactly what problem we are 
trying to solve.


Phil


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

Re: svn commit: r224411

[Phil Steitz]

Rahul Akolkar wrote:



P.S.-What list do I subscribe to in order to receive the jakarta site
svn commit messages?


site-cvs@jakarta.apache.org

Phil


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

Re: new components

[Phil Steitz]

robert burrell donkin wrote:

there doesn't see any enthusiasm for those new ideas and no objections
to phil's draft. i think we should go ahead and make the changes
suggested by phil.


I went ahead and updated, making some small changes to (hopefully) 
address the points above. I marked the items to be replaced as "DELETED" 
and added the replacement items at the end. Given that the discussion 
has referenced item numbers, I did not want to mess up the numbering. 
We can reorder as appropriate when the music stops.


Phil

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

Re: new components

[Phil Steitz]

Here is a stab at replacement text for 15, 17 and 18.

15-1 Any member of the community may propose a new package. To be 
accepted, a package proposal must receive majority approval of the
subproject committers and at least one committer must volunteer to serve 
as an initial package team member. Proposals should identify the 
rationale for the package, its scope, its interaction with other 
packages and products, the  resources, if any, 
to be created, the initial source from which the package is to be 
created, and the sponsoring committers.


15-2 The subproject will maintain an svn repository, referred to as the 
sandbox, as a workplace for new packages.  Once approved, new 
packages must all begin in the sandbox. Any apache committer may 
contribute code directly to the sandbox and this code may form the 
initial source for new packages.  Code from existing apache projects 
can, with the support of the contributing projects, also be imported 
directly into the sandbox.  Finally, patches contributed incrementally 
by community members may be committed to the sandox by a subproject 
committer. If the initial source for a new package is from outside of 
apache, the new package must be brought into apache via the apache 
incubator.


15-3 A majority vote among subproject commiters is required to 
"graduate" a package from the "sandbox" to become a proper package. Only 
proper packages may make releases. If a package remains in the sandbox 
for more than six months, a majority vote will be required to prevent 
its being archived from svn and removed from the subproject web site and 
any other public locations (e.g. nightly or continuous integration 
builds). Proper packages may not release code with dependencies on 
sandbox packages.


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

Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

[Phil Steitz]

robert burrell donkin wrote:



Agreed. After a little more discussion, we should rewrite this. 



+1

anyone feel like jumping volunteering to come up with a draft?


Working on this now...

Phil





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

Re: [POLL] drop 8

[Phil Steitz]

+1 to drop this

Phil

robert burrell donkin wrote:

8. Packages are encouraged to either use JavaBeans as core objects, a
JavaBean-style API, or to provide an optional JavaBean wrapper.



doesn't seem very relevant. i think that it'd be simpler just to drop
it.

here's my +1

- robert

--8<---
[ ] +1 Get rid!
[ ] -1 Keep it (please give a reason...)
--



-
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: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

[Phil Steitz]

Martin Cooper wrote:

On 6/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote:


On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:




Interpreted literally, 17 goes against standard practice in jakarta (or
apache, to my knowledge, other than in the incubator).  I would
recommend that new packages require existing committers to support them.
I would at least recommend changing "Anyone" to "Any apache committer."
If an individual has already contributed enough to be voted in as a
committer, then that should be done in a separate VOTE.


this certainly doesn't reflect the current practise in the jakarta
commons. though anyone can propose a new component, they really won't
have any chance of winning a VOTE unless they have the support of
existing committers.

there is also the issue of the incubator: any new component bringing
code from outside apache would need to be incubated.



We have a few different scenarios here, I believe.

1) A new component is proposed, with no existing code to back it up.
I'm not sure that this has ever happened in Jakarta Commons, or is
likely to happen in the new subproject, so frankly I don't much care
about how that would work. ;-)

2) A new component is proposed by an existing Apache committer. This
will almost certainly be backed up by code in the sandbox.
Historically, in Jakarta Commons, there hasn't so much been a
proposal, but rather a new project materialises in the sandbox. This
has, in part, been responsible for dregs that lie around forever. This
could be handled through the "after 6 months" vote that has been
mentioned in another thread.

3) A new component is proposed by a non-committer. Code to back up
such a proposal would necessarily be coming from somewhere else. This
is a situation in which the component should, I believe, come in
through the incubator. The incubation process would resolve the
questions of committers, etc., before the component lands in the new
subproject. (I want to emphasise here, for the folks that might be
concerned about this, that incubation need not be an onerous process,
and can happen rather quickly, if conditions are right.)

I would suggest that we come up with wording in the charter to reflect
these scenarios, rather than trying to crib from the Jakarta Commons
charter in this instance.


Agreed. After a little more discussion, we should rewrite this. FWIW, I 
did NOT mean to suggest that only committers could *suggest* projects, 
only that to actually get one *started*, support from ideally more than 
one committer is required.  I think the following is also possible, 
since at least one j-c component started this way:


4) A new component is proposed by a (some) non-committer(s).  One or 
more existing committers are interested in working on the component. 
The initial code base is built up incrementally in the sandbox from 
patches contributed by community members.  This is more or less the way 
we started commons-math.  The initial code base was contributed 
incrementally, with patches discussed, reviewed and in some cases 
refactored before being committed. I don't see anything wrong with this, 
nor requiring a trip through the incubator.


Phil




is 19 needed in addition to 15?



This seems to be a different topic entirely, but my vote would be yes,
because 15 relates only to the proposal, while 19 relates to the
component as it exists, and is developed, within the subproject.


+1 - different topic and one of the charming features of j-c that 
should, IMHO, be carried over.


--
Martin Cooper




- robert




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

Re: Name for commons-like area for web

[Phil Steitz]

Stephen Colebourne wrote:

There doesn't seem to be a thread for this

The current suggestions are:

 Commons Web
 Jakarta Web Parts for Java (JWP4J)
 Web App Commons
 Web App Components
 Web App Modules
 Web Bricks
 Web Commons
 Web Components
 Web Libs
 Web Parts
 Web Tools
 Weblets

Of these, WebParts has issues with Microsoft, so I would suggest we 
avoid it. Weblets was also used by IBM back in 2000, so could have issues.


The most obvious would be CommonsWeb or WebCommons, as the general user 
community could link the concept to commons easily enough. However, 
there is a danger that it could be confusing precisely because of that.


Thus, my current top three are:
- WebLibs
- WebCommons
- WebBricks
but I can still be persuaded.


I like "WebLibs" the best.

Phil


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

Re: configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

[Phil Steitz]

Stephen Colebourne wrote:

robert burrell donkin wrote:


On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:

9 or somewhere else should speak to J2EE or other external config 
requirments, which should be fine, even encouraged in some cases




is 9 needed? are any configuration guidelines needed?

if they are then i agree that they should encourage specification
compliance. would a general statement about specification compliance be
better? 



Its not needed. The charter should be as simple as possible.


+1 -- after thinking about it some more, I don't think it is wise to 
limit things or to reference J2EE or other specs in the charter.


Phil


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

Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

[Phil Steitz]

Frank W. Zammetti wrote:
I'm not sure I understand #12... is it talking about providing a JAR of 
a release for archival purposes?


I think that in the early (actually as recently as a year or so ago) 
days of Jakarta Commons, a "combo jar" was produced that included *all* 
of the commons components (or at least the most commonly used ones), so 
that you could just deploy one jar and get them all.  As robert points 
out below, internal and external dependencies and conflicts made that 
impractical, so, despite this reference in the charter, we no longer 
produce such a thing.


I would like to see this project adopt the packaging scheme my own Java 
Web Parts project has in that each actual Java package is JAR'd 
separately.  That way a developer can easily pick and choose which parts 
they want to use.


+1

Phil



I mention that because depending on what #12 really is talking about, 
that could conflict with that idea.  I'm not sure.


Frank

robert burrell donkin wrote:


On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:



Don't know what kind of goo 12 would result in or who would use such 
a thing ;-)




this has proved impractical in the jakarta commons. i propose we drop
point 12.

- robert

--8<---
[ ] +1 Get rid!
[ ] -1 Keep it (please give a reason...)
--





-
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: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

[Phil Steitz]

Frank W. Zammetti wrote:
In reading through this all, I have a concern that it will be difficult 
for any outside code to come in.  Indeed it has proven difficult for 
many people I have spoken to to get code into any Commons project 
(although I myself had some things accepted, so clearly it is not 
impossible).


This should be discussed on commons-dev if people really think it is an 
issue.  Maintaining scope boundaries and quality is a key concern there 
(as it should be in the proposed project as well, IMHO), but *many* 
patches do get applied.




What is the general feeling in terms of where the code comprising this 
package will come from?  At least, the largest portion of it?


The majority of the code should be developed collaboratively by the 
community, using the mailing list, Wiki, svn and issue tracker (Bugzilla 
or Jira) to discuss ideas and manage patches.  Any significant 
contribution that is not developed within apache would have to go 
through the incubator before being integrated.





is boils down to the question: does this subproject need it's own
sandbox or will neophyte components start in the jakarta commons
sandbox?


I would not recommend reusing the j-c sandbox and I am not sure that I 
like the "start components in the sandbox" approach that we use there. 
Too many abandoned components that people start to use (and depend on) 
despite disclaimers.  With the ease of branching in svn, I am not sure 
if a sandbox is really needed any more.  In any case, I would not 
recommend repeating the j-c practice of "incubating" new subprojects in 
the sandbox.  Just my HO.


Phil

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

Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications

[Phil Steitz]

Stephen Colebourne wrote:

robert burrell donkin wrote:


there have been a number of long running threads in the commons
discussing the possibility of commons components for use in web
applications. the consensus emerged that it would be best if a new
subproject with a structure similar to the commons was created for
components intended for use in web applications.

opinions, please!



I am in favour of this, although whether I would be able to spare much 
time is debatable.


I am also in favor, also not likely to have much time to contribute. 
Here are some comments on the draft charter.


It is nice to see so much borrowed from the (at least I think) 
successful j-c model ;-)


A couple of things should be changed, though, IMHO.

First in the scope statement "intended for use in server-related 
development" could be narrowed to "web application development"


Uniformly change CVS to SVN (I assume! :)

4.1 in the guidelines repeats the error that I thought was fixed in the 
j-c guidelines saying that each package has its own mailing list.  If 
that is intentional, I think that is a *bad* idea, especially to start.


4.2 should probably reference JSP/Servlet spec level requirements as 
well as JDK requirements


+1 to bullet under 7 :-)

9 or somewhere else should speak to J2EE or other external config 
requirments, which should be fine, even encouraged in some cases


Don't like the many little lists implied by 11 -- dev + user works fine 
in j-c (I know some disagree, but I personally view this as the key to 
the health of j-c)


Don't know what kind of goo 12 would result in or who would use such a 
thing ;-)


Interpreted literally, 17 goes against standard practice in jakarta (or 
apache, to my knowledge, other than in the incubator).  I would 
recommend that new packages require existing committers to support them. 
I would at least recommend changing "Anyone" to "Any apache committer." 
If an individual has already contributed enough to be voted in as a 
committer, then that should be done in a separate VOTE.


I guess 18 refers to the sandbox?  I do not understand what the intent 
of this is.


One final thing to think about.  I know lots of apache people are 
opposed to "umbrella projects" for lots of reasons, one of which is the 
fragmentation and abandonment that can result.  We have certainly not 
been immune to that in j-c.  Two things that have been critical to 
keeping us going have been 1) a relatively small (changing over time) 
set of key contributors who look after multiple components and 2) some 
"large internal customers" (tomcat, struts, maven et al) whose 
committers jump in to push things along as needed.  This project would 
be starting without the "large internal customers."  It would probably 
be a good idea, therefore, to start with a narrower, rather than broader 
scope, so that the fledgling community would not get fragmented too 
quickly and the "key contributors" could emerge.  Just a thought.


Phil






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

[site] Re: Verifying Downloads

[Phil Steitz]

Robert Voelkerding wrote:
Please direct me to an explanation of how to use MDE and/or PGP keys to verify 
downloads.
Thank you.
Robert,
The basic instructions are, e.g., here:
http://httpd.apache.org/download.cgi#verify
Make sure to download the KEYS file from the main apache distribution 
directory (URL starting with http://www.apache.org/dist).

Let us know if this info is not sufficient.
[site]
We should probably either
1) follow struts, ant, et al and make a copy of this to reference on
http://jakarta.apache.org/site/downloads/index.html; or
2) create a more complete page to put on the main apache site and have 
all the download pages link to it

preferences? volunteers?
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: VOTE: Tomcat -> TLP

[Phil Steitz]

Ian F. Darwin wrote:
   I vote in support of the proposal to move Tomcat to an Apache Top 
Level Project as
   detailed in the attached Resolution.

   [X ] +1 Vote in support
   [  ]  0   Abstain
   [  ] -1  Vote against
Phil (psteitz)

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

Re: [draft] SD Magazine: request for change

[Phil Steitz]

Henri Yandell wrote:

You've pointed out that JBoss are the contributor in your commits, 
rather than yourself as an individual. I assume other JBoss employees
are in the same situation. How does that change the email? Do I need
> to drop the paragraph about JBoss not being a contributor
I have asked for clarification of what the CCLA means on legal-discuss, 
but it makes no sense to me that your statement below can be false:

"Two Tomcat committers are employed by JBoss Inc, but they commit to 
projects at the ASF as individuals and not as members of a company. This 
is true of all committers to the ASF, whether the company be Sun, IBM or 
Fred Bloggs Inc."

If companies can in fact contribute directly, then it would seem to me 
that a) we should be voting them in as committers / PMC members and b) 
we should have policies and procedures for extending oversight to them. 
To my knowledge we (ASF) have no way of doing either of these things nor 
intention to develop them.

Phil

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

Re: [VOTE] [site] New download pages

[Phil Steitz]

Thank you, Hen!
Henri Yandell wrote:
I'd like to go ahead and move to my suggested new download pages:
http://jakarta.apache.org/~bayard/jakarta/site/downloads/downloads.html
[X] +1
[ ] -1
or alternatively:
[ ] +1, but fix this first: [ ]
Currently the filenames match the names on the binindex.cgi page, I'm 
trying to stay as close as possible to the current site before making 
any other changes. It's easy enough to then do things like change 
1.0.zip to hivemind-1.0.zip as Howard suggested.

Post change, I'll focus on improving the Taglibs page to match the 
Commons one in style.

72 hour consensus vote. ie) a single -1 is a veto.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

RE: [site] Label for promoted Jakarta project

[Phil Steitz]

Hate to push us around in a circle, but what exactly was so bad about "Related"?
 
Phil

-Original Message- 
From: Henri Yandell [mailto:[EMAIL PROTECTED] 
Sent: Wed 1/12/2005 1:59 PM 
To: Jakarta General List 
Cc: 
Subject: Re: [site] Label for promoted Jakarta project




That's the bit I'm trying to avoid. When a new TLP turns up, we have to
modify our site. Which we're just not in the loop for.

Something moving out of Jakarta, we're completely in the loop for and 
can
catch it, we just don't know what to call it. OJB is a theoretical
problem, it's now db->ojb. Log4j is the same, now logging->log4j. We've
not really had a case where it was a huge problem; log4j is the mainstay
of logging and ojb was barely in Jakarta, but still. Problem.

Hen

On Wed, 12 Jan 2005, robert burrell donkin wrote:

> i'm not really sure there's any good solution to this one. the 
downside of
> ex-jakarta is that it's inaccurate: logging isn't really ex-jakarta 
since it
> contains more than log4j.
>
> i wonder whether we could fit in every apache project and just label 
it
> Apache Projects...
>
> - robert
>
> On 9 Jan 2005, at 00:42, Henri Yandell wrote:
>
>>
>> At the bottom of the left hand navbar is a section of projects that 
used to
>> be a part of Jakarta. It used to be Related and is currently 
Graduated, but
>> neither name has won fans.
>>
>> Martin has suggested 'Ex-Jakarta'. A problem with Graduated is that 
it
>> involves explaining, and also that it is a poor label as it is not a 
noun.
>> Ex-Jakarta wins on both of these.
>>
>> Ex-Jakarta has another advantage that I see, which is that things 
don't
>> have to goto an Apache TLP to be Ex-Jakarta. OJB for example, in
>> db.apache.org, or even to somewhere like Sourceforge.
>>
>> So, any opinions?
>>
>> Barring any -1's to Ex-Jakarta, I'll make the change on Wednesday 
night.
>>
>> Hen
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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



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

Re: Jakarta download pages Was: download pages in j.a.o.

[Phil Steitz]

Henri Yandell wrote:

On Tue, 28 Dec 2004, Phil Steitz wrote:
Henri Yandell wrote:

On Tue, 28 Dec 2004, Martin Cooper wrote:
I think, if we had a standard "template" for download pages, each
subproject could have its own download page, something like we have
for Struts:
http://struts.apache.org/download.cgi

Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects 
didn't have to really care about it; ie) they'd just link to:

http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
You can link directly now, using the anchors in the main Jakarta 
download pages, e.g.
http://jakarta.apache.org/site/binindex.cgi#commons-math

Yep. There are two poor things about this:
1) As with the new header, it means most people jump the text on 
keys/md5 etc.
Ack.  Had not thought about this.  I guess that's why most do not link 
directly now...
2) It seems pointless from a user point of view. The bit they're 
interested in is very small compared to the size of the whole page 
they're being dumped in.
Agreed in general, though grabbing multiple commons components is 
something that some people need to do now and then (at least I have).
The struts download page is a lot nicer from a user point of view, 
though one criticism is that the pgp/key stuff is at the bottom of the 
page there and unlikely to be seen by a downloader too. It's also 
serving more than one file.

I'd like to see each project with links to something like:
http://jakarta.apache.org/download.cgi/jakarta/poi/poi-7.2.zip
which would show a page that automatically does the pgp/md5 blurb, links 
to poi-7.2.zip.md5 and KEYS (in the same dir as the zip?) and handles 
the mirror stuff. We'd use the download.cgi for both binary and source.
Sounds good to me.  In this case, would we rectify the old "components" 
j-c page to present download links to each of the commons components?

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

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

Re: Jakarta download pages Was: download pages in j.a.o.

[Phil Steitz]

Henri Yandell wrote:

On Tue, 28 Dec 2004, Martin Cooper wrote:
I think, if we had a standard "template" for download pages, each
subproject could have its own download page, something like we have
for Struts:
http://struts.apache.org/download.cgi

Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects 
didn't have to really care about it; ie) they'd just link to:

http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
You can link directly now, using the anchors in the main Jakarta 
download pages, e.g.
http://jakarta.apache.org/site/binindex.cgi#commons-math

I notice that some projects use direct links like this from their 
project pages and some do not.

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

Re: [vote] moving jakarta-site2 to subversion

[Phil Steitz]

I am +1 for this move and the plan.
One thing that folks should be warned of, however, is that changing the 
directory structure will break site builds that depend on paths like 
"../jakarta-site2/xdocs/stylesheets", so these will have to changed when 
these projects nove.  I don't know how many sites still do this - 
tomcat-site could be the only one.

Tim O'Brien wrote:
This is the simplest SVN migration in Jakarta.  The migration
instructions follow for review:
http://wiki.apache.org/jakarta/Site2_20Conversion_20Instructions
72 hours for this vote - classify this as a public release vote requires
majority (at least 3 +1s and more +1s than -1s )
[ ] +1, migrate jakarta-site2 CVS to /jakarta/site SVN
[ ] +0
[ ] -0
[ ] -1, No
-
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: jakarta commons net build failed

[Phil Steitz]

Ant cannot find the junit jar that it needs, despite the fact that it is 
grabbing it as a dependency :-(

Look in $ANT_HOME/lib and make sure that both junit.jar and optional.jar 
are there, since that is where ant will look for them. You can copy the 
downloaded junit jar from target/lib if you like.

For future reference, you should post questions about Jakarta Commons 
components to [EMAIL PROTECTED]

hth,
Phil

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

Re: [VOTE] Updating PMC bylaws

[Phil Steitz]

+1
Phil
Suggested new bylaws are at:
http://www.osjava.org/~hen/jakarta/management.html
The aim is to identify the current reality, rather than plan out a new 
set
of bylaws. I believe I've responded to the past week of comments,
sometimes by dropping things from the text as they require discussion
(ie: active/inactive projects).

Voting rules are that we need at least 3 +1 _PMC votes_, and a 3/4
majority of +1's to -1's. I'll announce results next Tuesday.
===
[ ] +1 - let's do it
[ ] -1 - not good
===
I think the above voting rule is fair enough, though there are others we
could use. Let's not worry too much about it unless we have major
disagreements. Also, if people have non-voting commentary, it would be
nice if they could change the subject (ie:  Madness   Was: [VOTE] 
Updating
PMC bylaws). Makes counting the votes a lot easier.

Hen

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

Re: [VOTE] HiveMind as a Jakarta sub-project

[Phil Steitz]

Geir Magnusson Jr wrote:
All Jakarta Community Members :

Howard M. Lewis Ship, on behalf of the committers of the HiveMind 
project in the Jakarta Commons sandbox, has proposed HiveMind as a 
Jakarta sub-project.  The proposal was sent to this list, a copy of 
which can be found here :

http://www.mail-archive.com/[EMAIL PROTECTED]/msg09244.html

Please read the proposal and vote, and add any comments you deem 
appropriate.

All Jakarta community members are encouraged to vote, although only the 
votes of the PMC members are legally binding as per the ASF*.

[X] +1  I support this proposal
[ ] -1  I don't support this proposal
[ ]  0  I abstain from voting for or against this proposal
Comments:

Section (2) of the proposal refers to the "Jakarta Commons incubator." 
This should be changed to "Jakarta Commons Sandbox."

In agreement with Noel, I would also suggest that the community consider 
the Apache Subversion Repository as an alternative to CVS. I see this as a 
HiveMind community decison, however -- i.e., I am +1 to the proposal 
regardless of the repository choice.

Phil




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

Re: [License] for jars in CVS

[Phil Steitz]

Harish Krishnaswamy wrote:
I am with Erik on "no JARs in CVS". Unless it is a legal issue, I would 
certainly like to distribute all JARs with the distribution. It saves a 
lot of hassle and keeps uncessary traffic out of the user-list.
At the expense of lots of wasted bandwidth and disk space.  I agree with 
Robert.  Think about how many copies of commons-collections.jar we would 
have in CVS (and on our local drives) if all projects stored all of their 
dependent jars in CVS.  You can bundle dependent jars in the distributions 
without storing them in CVS.  See the tomcat and struts distros and builds.

I understand Erik's point about wanting to version the dependencies, but I 
don't think that storing dependent jars in CVS is a good general policy 
for Jakarta projects.  As noted elsewhere on this thread, there are also 
legal issues to consider for non-Apache jars.

Phil
-Harish

Erik Hatcher wrote:

In jakarta-tapestry/lib/ext lives all of the licenses of the embedded  
3rd party libraries.  In that directory is a LICENSE.ognl.txt which  
contains the full license.  I believe this is all that is needed to  
satisfy the license to redistribute the binary version.  I can assure  
that you we will never ever have a problem with OGNL (Drew is a good  
friend of mine, and having the high profile use of OGNL in Tapestry 
and  other projects like WebWork2 is great advertising for him and 
his  genius).

As for the larger issue of "no JARs in CVS" - I disagree.  I'm  
pragmatic and also like to have everything in CVS needed to build a  
distribution (even Ant itself for my employers projects).  It saves a  
lot of hassle to version all source code and dependencies together.   
Yes, we could make the Maven repository argument, but I personally  
prefer the complete offline usability of a CVS snapshot.  When 
Tapestry  came to Jakarta, it's dependencies were vetted extensively 
and several  were removed from CVS - so it is still a PITA to build 
Tapestry from  CVS (and according to Howard, his attempts to Mavenize 
the build have  been unsuccessful to date).

Erik

On Dec 24, 2003, at 3:47 AM, Henri Yandell wrote:

As I just happened to notice this on Incubator [AltRMI in fact]:

"Is all source code distributed by the project covered by one or 
more  of
the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C,
MPL 1.1, or something with essentially the same terms?"

The below is, to my quick glance, a BSD licence, so approved. I'm 
with  you
on the no jars in CVS, but each to community to their own. Whether
Tapestry is properly fulfilling the licence by listing their use of  
ognl
in their documentation would be something to check on.

Hen

On Wed, 24 Dec 2003, Robert Leland wrote:

Can we really store non Apache licensed jars in the CVS ?

My personal preference is to store no jars in CVS

For Example I noticed ognl stored in Tapestry CVS :

/ 
/- 
-
//Copyright (c) 2002, Drew Davidson and Luke Blanshard
//  All rights reserved.
//
//Redistribution and use in source and binary forms, with or  
without
//  modification, are permitted provided that the following  
conditions are
//  met:
//
//Redistributions of source code must retain the above 
copyright  notice,
//  this list of conditions and the following disclaimer.
//Redistributions in binary form must reproduce the above  
copyright
//  notice, this list of conditions and the following disclaimer in  
the
//  documentation and/or other materials provided with the  
distribution.
//Neither the name of the Drew Davidson nor the names of its
contributors
//  may be used to endorse or promote products derived from this  
software
//  without specific prior written permission.
//
//THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND  
CONTRIBUTORS
//  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
//  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
//  FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
//  COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,  
INDIRECT,
//  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES  
(INCLUDING,
//  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
SERVICES;  LOSS
//  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
//  AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT  
LIABILITY,
//  OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY  
OUT OF
//  THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF  
SUCH
//  DAMAGE.
//






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

Re: [PROPOSAL] As it ever were

[Phil Steitz]

Ted Husted wrote:
(Again, sorry about the quoting.)

o·ver·sight

   1. An unintentional omission or mistake.
   2. Watchful care or management; supervision


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.
Thanks for directly addressing the oversight issue.  This looks like a 
good plan to me. Can you explain a little more

a) what kinds of "issues" we need to worry most about;
b) what kinds of things should go into the reports; and
c) how subproject committers could share the responsibility of creating 
the reports.

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.
I agree.
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.
Until I understand fully what the responsibilities are, I am not sure that 
I agree with this, partly because subproject committers may not have 
"signed up for" a role beyond the subproject.  I agree with your 
statements about votes being binding, however, so we clearly need to 
change (or "legalize" ;) something.

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.)
This will solve the problem of committers having binding votes on the 
codebase that they work on, but it may not be the best solution for the 
Jakarta PMC.  Is it totally out of bounds from the ASF perspective to 
allow subproject committers to have binding votes for their subprojects 
without being PMC members?  I know that this has been discussed and 
categorical statements have been made, but I frankly do not get it. If the 
Jakarta PMC reviews and aggregates all of the subproject reports and 
includes representation from each of the subprojects, where is the gap in 
oversight?  I don't mean to be argumentative or dense here, but it is very 
important that we understand clearly what the constraints are (and why 
these constraints exist, and whether they can be changed as the ASF scales).
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.
IIUC, it is mostly a matter of legal protection, not so much "rights and 
privileges" (unless you view indemnification as a right or privilege). 
Here again, a little more background / facts would be helpful, as well as 
some indication of what is "written in stone" and why that is so.

Phil
-Ted.



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

Re: Jakarta: Confederation or Single Project?

[Phil Steitz]

Stephen Colebourne wrote:
Not really (my POV)

As people we naturally think in terms of the hierarchy
  ASF to Jakarta to MySubProject.
But the middle layer is artificial. It could just as well be XML or DB or
WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe
Bloggs works'. There simply is no one way of categorizing, hence there
actually is no one community either. (ie. 'the jakarta community' simply
does not exist in my eyes)
I agree that we probably can't "define" Jakarta in terms of content in a 
way that will make everyone happy.  I disagree, however, that this means 
that there is no community, or that Jakarta should be dissolved.  I would 
say that Jakarta = the community. What are called "Products" on the web 
site are what this community produces. Java is one common denominator, but 
so are some common release management and decision-making practices 
(currently under debate / revision).

I am much less bothered than others about the fact that not *all* 
server-side Java in Apache is in Jakarta or that some Jakarta projects 
might "belong" elsewhere. I really don't see why this is a problem.

The only real problem that we have is making sure that we have sufficient 
oversight. The "middle layer" makes that look like more of a challenge, 
but that's only if you assume that oversight has to come from a small 
number of Jakarta PMC members.  Growing the PMC (as we are now) so that 
all community activity has has direct PMC oversight will solve the 
oversight problem.

Phil





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

Re: [PROPOSAL] Agreeing new voting rules for Jakarta

[Phil Steitz]

Robert Leland wrote:
Phil Steitz wrote:

Noel J. Bergman wrote:

It seems odd to me that code changes effectively require consensus,
but a release would not.  What am I missing here?




All code in CVS is already there on consensus.


As are the bugs ;-)

Seriously, this seems like sort of a grey area between "technical, 
code-related" (so needing consensus) and "policy."  The decision to 
cut a release has technical implications (e.g. backward 
compatability), but it is not a technical decision per se.  I am not 
pushing for this, just trying to understand better how we look at 
releases.


There are two schools.
For Struts 0.5, 1.0 , 1.1 we used the criteria that all bugs had to 
fixed or marked as later.
As a result between 0.5 and 1.0 took  12 months
   and between 1.0 and 1.1 took  20 months.

For Struts 1.2 we agreed to switch to the x.y.z

style that Apache HTTPD and Tomcat are using, where you post the bits and
then call for a vote on stability (alpha/beta/general availability).
A release can also be withdrawn.
After a release there is often a flood of new users, and a few, usually 
very few new bug reported.
More importantly there are improvements new users make and hopefully share
as they tinker with and extend Struts to make it fit their needs.  It's 
this synergy that is good for the project.

We tried it the other way first and while we were always making progress 
on the software,
the development could have easily stagnated. Between Struts 1.0 and 1.1 
we were fortunate enough
to vote in about 8 committers, each gave the software development a much 
needed boost.

By releasing more often we hope to actually increase the quality, by the 
fact of greater participation
from the app developers. It's easier to do this now in Struts since 
presently it is in an evolutionary mode.

Also I would say that Tomcat and HTTPD are two of the most successful 
projects Apache has
so they have to be doing something right.



Thanks for the perspective, Robert.

Does this mean you are in favor of having release votes just require 
majority approval?

After re-reading http://jakarta.apache.org/site/decisions.html carefully, 
I am in favor of keeping things as stated there -- Release Plans require 
lazy majority, but Release Testing just requires majority approval.

Phil






-
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: [website][patch] Add instructions for setting up mail to newbie.xml

[Phil Steitz]

Tetsuya Kitahata wrote:
On Sat, 13 Dec 2003 10:06:34 -0700
Phil Steitz wrote:

I did make the patch and posted it in an email to infrastructure@ on 
11/23.  It has not been applied.

Darn!  I referenced the wrong post.  I got some feedback and incorporated 
that in a revised patch submitted 11/26.  Attached is a patch against the 
current head that makes the suggested changes.

Please cross-check.


If we do get this applied, we should change the Jakarta Newbie page to 
point to this for mail account setup questions.


Added.
What I meant was to change the link on newbie.html to point to the new 
section on the apache site.  I guess its OK to duplicate, but the comments 
about sending from apache accounts should probably provide a reference to 
apache.org/dev/committers.html

Thanks for applying the patch and sorry for my mistake with the reference.

Phil

-- Tetsuya. ([EMAIL PROTECTED])

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


Index: xdocs/dev/committers.xml
===
RCS file: /home/cvspublic/site/xdocs/dev/committers.xml,v
retrieving revision 1.18
diff -u -r1.18 committers.xml
--- xdocs/dev/committers.xml14 Dec 2003 00:16:30 -  1.18
+++ xdocs/dev/committers.xml14 Dec 2003 02:27:44 -
@@ -282,28 +282,31 @@
 per-virtual-host configuration (at the end of the file).
 
 
-
-
-
-Mail Questions
 
 
 How do I setup my email account?
 
-You can use ssh and Pine, put a .forward file in your user directory 
-to forward your mail to another account, or use ssh tunneling to 
-send/receive mail using a mail client.
-
-One way to create a .forward file is to use ssh to login to 
-cvs.apache.org and then execute the following commands:
-
-  vi .forward
-  i your_normal_email
-  ESC :x
-
+You can use ssh and Pine, put a .forward file in your 
+user directory to forward your mail to another account, or use ssh 
+tunneling to send/receive mail using a mail client.
+
+When your account is first set up, a .forward file 
+should be created for you.  If you want to have your Apache mail 
+forwarded, check that the .forward file exists and contains 
+the right forwarding email address by logging in via ssh and looking at
+the file.  You can use the following command to display the file:
+
+cat .forward
+
+The file should contain one line with your forwarding email address.
+If the .forward file is missing or the address is 
+incorrect, you can create or update it using the command:
+
+echo your_correct_forwarding_email > .forward
 
 To set up an ssh tunnel for both sending and receiving, run the 
 following from your local machine (may require root access):
+
 
 ssh [EMAIL PROTECTED] -L X:locahost:110 -L Y:localhost:25
 
@@ -311,6 +314,7 @@
 where X and Y are available local port 
 numbers. Then configure your mail client to use localhost:X
  to receive and localhost:Y to send.
+
 
 
 

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

Re: [website][patch] Add instructions for setting up mail to newbie.xml

[Phil Steitz]

Tetsuya Kitahata wrote:
Hi, Phil and all.

Did you make it? If you failed, I think i can
apply the patch for it (I am *not* subscribing to
infrastructure@, now).
I did make the patch and posted it in an email to infrastructure@ on 
11/23.  It has not been applied.

I am attaching the patch to site/xdocs/dev/committers.xml that I created 
on 11/22.

If we do get this applied, we should change the Jakarta Newbie page to 
point to this for mail account setup questions.

Phil

Index: xdocs/dev/committers.xml
===
RCS file: /home/cvspublic/site/xdocs/dev/committers.xml,v
retrieving revision 1.17
diff -u -r1.17 committers.xml
--- xdocs/dev/committers.xml7 Nov 2003 21:15:38 -   1.17
+++ xdocs/dev/committers.xml24 Nov 2003 02:20:02 -
@@ -288,6 +288,32 @@
 Mail Questions
 
 
+How do I setup my email account?
+
+You can use ssh and Pine, put a .forward file in your user directory 
+to forward your mail to another account, or use ssh tunneling to 
+send/receive mail using a mail client.
+
+One way to create a .forward file is to use ssh to login to 
+cvs.apache.org and then execute the following commands:
+
+  vi .forward
+  i your_normal_email
+  ESC :x
+
+
+To set up an ssh tunnel for both sending and receiving, run the 
+following from your local machine (may require root access):
+
+ssh [EMAIL PROTECTED] -L X:locahost:110 -L Y:localhost:25
+
+
+where X and Y are available local port 
+numbers. Then configure your mail client to use localhost:X
+ to receive and localhost:Y to send.
+
+
+
 How do I request the creation of a new mail list?
 
 Mail lists are the virtual room where the communties live, form and

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

Re: jakarta-future Was: [POLL] Future Of Turbine-JCS

[Phil Steitz]

Henri Yandell wrote:
On Wed, 2 Oct 2002, Costin Manolache wrote:


Or even better - since jakarta has a single PMC, it could also have a single
list of committers ( most of them in the single PMC ).
Each PMC member can vote about any jakarta issue - including releases of
each sub-project, etc. If the distinction between pmc and committer is
fading,  then I don't see why do we have to worry about separate karma.
A start could be to have every PMC member have karma in every subproject.


+1 to jakarta-wide karma.

It'd be interesting to look at all the mail-traffic for Jakarta and
estimate just how noisy a single project mail list would be. 
It would be very noisy, indeed.  Here are some stats from October (from 
message counts displayed at http://marc.theaimsgroup.com)

 struts   tomcat   commons
user   3115 2908   375
dev 759 1131  2112


Then maybe
instead of breaking it on code-base, we could break it on concept:

jakarta-bugs
jakarta-announce
jakarta-dev
jakarta-pmc
jakarta-ideas
jakarta-site
or something. I'm assuming it'll be too noisy, but it is a logical
question to ask based on Costin's ideas of opening things up.
I understand that the oversight role of the PMC has to include all of 
Jakarta and I agree that some form of list aggregation/digesting might 
need to happen to make this practical.  I don't think that combining all 
of the lists is the right way to do it though. This would certainly be a 
pain for users and contributors who may be interested in only a small 
number of projects.  One way to attack the problem might be to have PMC 
members who are committers on the different Jakarta projects share the 
responsibility of maintaining list digests for periodic (weekly?) review 
by the full PMC and/or alerting the full PMC of any issues that require 
immediate attention.

I guess the alternative would be for all of us to subscribe to all of the 
lists and take up speed reading ;-)

Apologies if this is old ground. I am new to the PMC.

Phil


Hen

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




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

Re: [website][patch] Add instructions for setting up mail to newbie.xml

[Phil Steitz]

robert burrell donkin wrote:
hi phil

IIRC infrastructure is the right place to submit patches for the main site.

- robert
Thanks, Robert.  I made and submitted a patch against 
site/xdocs/dev/committers.xml and submitted it there.





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

Request for jakarta-site2 Karma

[Phil Steitz]

Can someone grant me Karma for jakarta-site2?  I am a commons committer.

Thanks in advance.

Phil (psteitz)

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

Re: [website][patch] Add instructions for setting up mail to newbie.xml

[Phil Steitz]

Martin Cooper wrote:
Isn't this something that should go somewhere off of here:

http://www.apache.org/dev/

rather than under Jakarta?

I thought about adding it here:

http://www.apache.org/dev/committers.html#mail

and removing this section from jakarta-site2/xdocs/site/newbie.xml

Where should I submit the patch for the main site?

Phil





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

[website][patch] Add instructions for setting up mail to newbie.xml

[Phil Steitz]

Attached is a patch to jakarta-site2/xdocs/newbie.xml that adds 
instructions on how to set up .forward and also ssh tunnelling to 
send/receive from apache accounts.

Phil
Index: xdocs/site/newbie.xml
===
RCS file: /home/cvs/jakarta-site2/xdocs/site/newbie.xml,v
retrieving revision 1.7
diff -u -r1.7 newbie.xml
--- xdocs/site/newbie.xml   8 Oct 2003 01:44:30 -   1.7
+++ xdocs/site/newbie.xml   22 Nov 2003 22:18:46 -
@@ -54,7 +54,26 @@
   
 
   
-  You can use SSH and Pine or put a .forward file in your user directory [:FIXME: 
Need a  brief howto here] to send the mail to another account.
+  You can use ssh and Pine, put a .forward file in your user directory to forward 
your mail to another account, 
+  or use ssh tunnelling to send/receive mail using a mail client.
+  
+
+  
+  One way to create a .forward file is to use ssh to login to cvs.apache.org and then 
execute the following commands:
+  
+vi .forward
+i your_normal_email
+ESC :x
+  
+  
+
+  
+  To set up an ssh tunnel for both sending and receiving, run the following from your 
local 
+  machine (may require root access):
+  ssh [EMAIL PROTECTED] -L X:locahost:110 -L Y:localhost:25
+  where X and Y are available local port numbers. Then 
configure your mail client 
+  to use localhost:X 
+  to receive and localhost:Y to send.
   
 
   

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