Re: [Jakarta Wiki] Update of "JakartaBoardReport-current" by MartinvandenBemt

[Martin van den Bemt]

If everyone is ok with it, I will send the current state of this page as the 
board report ?

Mvgr,
Martin
- Original Message -
From: "Apache Wiki" 
To: general@jakarta.apache.org
Sent: Monday, May 18, 2009 9:45:42 PM GMT +01:00 Amsterdam / Berlin / Bern / 
Rome / Stockholm / Vienna
Subject: [Jakarta Wiki] Update of "JakartaBoardReport-current" by 
MartinvandenBemt

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for 
change notification.

The following page has been changed by MartinvandenBemt:
http://wiki.apache.org/jakarta/JakartaBoardReport-current

--
  
  === Status ===
  
- Chair to summarize Jakarta-wide news + the current state of affairs. 
+ It has been a while since I reported the last time. In june 2009 I announced
+ that I wanted to be replaced because of time constraints, with no one
+ volunteering. After that however I got caught up with what was happening in my
+ personal life and also was shutdown for over 3 months, which ended up in a
+ long period of silence.
+ Now all major personal events (positive I might add, so please don't worry)
+ have passed, I however still find myself fighting to find time (and energy) to
+ spend at Apache.
+ 
+ In the light of this, I hand in my resignation as VP Apache Jakarta.
+ To my relieve a discussion about the (in reality already effective) vacancy
+ started and some people stood up to volunteer to take over the position.
+ 
+ I myself regret the long absence and silence and I hope it didn't cause to 
+ much worry and problems.
+ 
  
  === Releases ===
  

-
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: [VOTE] JMeter 2.3.2RC7 - please!

[Martin van den Bemt]

Looks good..
+1

Mvgr,
Martin

sebb wrote:
>  Trying yet again ... votes needed (positive or negative) - thanks!
> 
>  The licence issues reported by Henri have (I trust) been fixed.
>  Also the lib/opt directory is now included in the source archives.
> 
>  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.
> 
>   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.2RC7/dist
> 
>   Site/Docs are here:
>   http://people.apache.org/~sebb/jmeter-2.3.2RC7/docs
> 
>   Tag:
>   http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC7
> 
>   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.2RC1 - cancelled

[Martin van den Bemt]

Do you by default run RAT on releases ?

Mvgr,
Martin

sebb wrote:
> I'll be doing another build to try and address the issues raised so far.
> 
> In the meantime, please continue to report any further problems that
> may be seen - thanks!
> 
> -
> 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]

Jakarta Board Report January

[Martin van den Bemt]

== December 2007 Board Report ==

=== Status ===

The downsizing of Jakarta continued this quarter.
HttpComponents became TLP and has finished moving all the resources to their 
own TLP. We wish them
all the best with their new identity!
Slide was retired (see Slide section for more details), with a notice on the 
Slide page (see
http://jakarta.apache.org/slide/).

The main focus this quarter will be (re)starting discussions about the future 
of the mature
components/libraries like ORO, Regexp (maintained) and ECS and BCEL (not 
maintained).

=== Releases ===

  * 29 September 2007 - JMeter 2.3 final
  * 9 October 2007 - !HttpComponents !HttpCore 4.0 alpha 6
  * 7 November 2007 - !HttpComponents !HttpClient 4.0 alpha 2
  * 30 November 2007 - JMeter 2.3.1 final

=== Community changes ===

No changes in the community

=== Subproject news ===

 BCEL 

No activity this quarter. Since there is a lack of developer and user 
community, we should
definitely retire BCEL this quarter and also point the users to possible 
alternatives. A discussion
will be started about this.

 BSF 

There is an outstanding request for the TCK for scripting. Geir expressed the 
concern that
this TCK could be part of the JDK 1.6 TCK and not independ. We are sitll 
waiting for
the definitive answer on this.

 Cactus 

Development has picked up after Apachecon Atlanta and Petar is working towards 
a release.

 ECS 

No activity and not maintained. As with BCEL it is probably best to retire the 
project or see if it
can find a
home at Apache Commons.

 HttpComponents 

HttpComponents released one alpha each for HttpCore and HttpClient
as a Jakarta sub-project. A TLP proposal was submitted for the
November board meeting and accepted. Starting December 2007,
HttpComponents submits separate board reports as a TLP.

By end of December 2007, HttpComponents is no longer using Jakarta resources.
Mailing lists, SVN, website, dist, and archive have been moved.
The HttpComponents Wiki still has Jakarta in it's name, but it is
a separate Wiki.

 JCS 

No developer activity going on at this moment, though there is user activity on
the dev and user lists.

 JMeter 

JMeter released 2.3 and 2.3.1 final.

 ORO 

Since the mature nature hardly any activity (it is maintained). There are still 
a lot of users and
bug reports are actively monitored and acted upon. Since the library nature of 
the subproject it is
definitely worth investigating if Apache Commons can be the new home for this 
library.

 Regexp 

See ORO.

 Slide 

Due to the lack of a developer community, Slide has been retired on 03/Nov/2007.
It is thus no longer actively maintained or supported by the ASF.
Subversion, Bugzilla, and one of the mailing lists will remain open for a 
transition period.
Slide users will be pointed to Apache Jackrabbit as a replacement.

Every few weeks, somebody inquires about a separate WebDAV client project
on a mailing list of Slide, Jackrabbit, Commons, or HttpComponents. There
are some people, some of which are Apache committers, who expressed some
interest to put in some time, if others are with them. But nobody seems to
want to take the lead and request a sandbox or lab project in which to start.
The presence of two separate codebases (Jackrabbit, Slide) from which one
could start doesn't help. Jackrabbit is alive, Slide is used in the wild.

 Taglibs 

Development is still taking place, although not at a high priority. Bug fixing 
took place on the
Standard Taglib and there is the intention to make a final release after all 
bugfixing is done.

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

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

[Martin van den Bemt]

Jukka is not subsribed, but the reason there are 5 is to kind of limit the size 
of the image (1
results in a huge image)

Mvgr,
Martin

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

>>> Jukka's graph shows committer cross-polination, not *codebase*
>>> cross-polination (as I understand it)...
>> then you'd expect Harmony and Geronimo would connect with Velocity via 
>> Geir...
>>
>> i'm not sure what cross-pollination this graph refers to.  Jukka,
>> could you clarify?
> 
> ah.  i RTFA.  a connection requires 5 committers in common.  i'd be
> curious to see the graph with the threshold set to 3 (as that is more
> of a magic number in Apache community stuff). :)
> 
> 
>>> So yes, since most
>>> committers for most ASF java projects were in Jakarta (since
>>> those projects were *in* Jakarta, after all), I still think
>>> that the non-Jakarta page provides a more accurate representation
>>> of the "real" dynamics, by removing the artifical aspects of
>>> Jakarta.
>>>
>>> Of course, I could be wrong :)
>>> --
>>> ===
>>>Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
>>> "Great is the guilt of an unnecessary war"  ~ John Adams
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
> 
> -
> 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]

Who's coming to Apachecon..

[Martin van den Bemt]

Hi everyone,

Since I suffered / suffering from a serious lack of time the last couple of 
months (sorry about
that), I have in mind of doing some catching up at Apachecon :)

So it would be nice to meet up with everyone and have a discussion about things 
todo, timelines, etc :)

I will arrive Thursday afternoon..

Mvgr,
Martin

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

Re: External plugin repository for JMeter?

[Martin van den Bemt]

Mojo plugins start out in the sandbox and need 3 votes from current committers 
to promote to proper.
If you want to release a vote is expected to happen (I think apache voting 
rules apply)

Mvgr,
Martin

Roland Weber wrote:
> Hi Sebastian,
> 
> sebb wrote:
>> I don't see it as splitting the community, rather as an adjunct to the
>> existing community.
>>
>> One of the reasons would be to allow independent release cycles.
>>
>> Also, not every user would need all the plugins.
>>
>> Perhaps this could be done by rearranging the JMeter project, but it
>> seems cleaner to have a separate repository - as is done with Maven.
> 
> HttpComponents is also managing currently two components on
> separate release cycles. However, that comes with a certain
> overhead. At the current frequency of our releases, I can
> fully understand Oleg's reluctance against putting more modules
> on separate release cycles.
> If the idea is to have each extra JMeter plugin on a separate
> release cycle, you're probably better off without the Apache
> overhead. I assume Codehouse does not require three PMC votes
> for a release? If the extra JMeter plugins are meant to share
> on release cycle, and there are no licensing issues, I believe
> it can be handled at Apache.
> 
> cheers,
>   Roland
> 
> 
> -
> 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: Commons is TLP

[Martin van den Bemt]

+1 to keep httpclient and move it to httpcomponents.

Mvgr,
Martin

Roland Weber wrote:
> Martin van den Bemt wrote:
>> The commons one is probably less straight forward, although could be a lot 
>> easier. Since there was a
>> commons in the past, it could well be that you don't need to do a lot 
>> (website, mailinglists, etc
>> already there), besides setting up the karma for the people, moving over the 
>> website, etc,etc.. So
>> probably best to figure out on infrastructure how to approach this specific 
>> situation.
> 
> This also raises the question how the HttpClient 3.x code
> should be managed. Path-wise it is part of commons in SVN:
>   /jakarta/commons/proper/httpclient
> but it is maintained by HttpComponents which doesn't move
> to the Commons TLP. If it isn't too much effort for infra,
> I would suggest to keep that part of the tree under Jakarta
> karma control. Either in place, or by moving it to the
> HttpComponents part of the repository, for example as
>   /jakarta/httpcomponents/oachttpclient
> or
>   /jakarta/httpcomponents/httpclient3x
> 
> cheers,
>   Roland
> 
> 
> -
> 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: Commons is TLP

[Martin van den Bemt]

The commons one is probably less straight forward, although could be a lot 
easier. Since there was a
commons in the past, it could well be that you don't need to do a lot (website, 
mailinglists, etc
already there), besides setting up the karma for the people, moving over the 
website, etc,etc.. So
probably best to figure out on infrastructure how to approach this specific 
situation.

Mvgr,
Martin

Torsten Curdt wrote:
> 
> On 21.06.2007, at 00:57, Martin van den Bemt wrote:
> 
>> Hi everyone,
>>
>> The new Commons TLP was established today, with Torsten Curdt as Vice
>> President.
> 
> ...so where do we start with the TLP move is the question :)
> 
> cheers
> -- 
> Torsten
> 
> 
> 
> -
> 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]

Commons is TLP

[Martin van den Bemt]

Hi everyone,

The new Commons TLP was established today, with Torsten Curdt as Vice President.

Mvgr,
Martin

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

Re: Jakarta Board Report

[Martin van den Bemt]

I've added it to the report..

Mvgr,
Martin

Rony G. Flatscher (Apache) wrote:
> ... snip ...
>>  BSF 
>>
>> MvdB :Silent quarter. A talk for Apachecon US was accepted (Rony Flatcher),
>> which will hopefully increase the user base (observation : since the user
>> list is also pretty quiet it can mean that BSF is bug free or it needs
>> more users)
>>   
> ... snip ...
> 
> Sorry, oversaw that the release of beta 1 of BSF 3.0 fell into the
> second quarter (ant was able to report the result of the vote on
> 2007-04-16) and should have been reported as such by us! This is the
> version that brings JSR-223 (a.k.a.  "Java 6 scripting framework") to
> the Apache table: it allows de/employing the Java scripting framework
> starting with Java 1.4 (the Sun implementation is only available
> starting with Java 1.6/6, foregoing the entire pre-Java-6 installed
> base). ant has been trying to get word on receiving the appropriate Sun
> TCK from Geir, but so far no news can be reported here
> 
> ---rony
> 
> 
> -
> 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]

Jakarta Board Report

[Martin van den Bemt]

== June 2007 Jakarta Board Report ==

=== Status ===

Another 2 projects have left Jakarta to live on their own : POI and Turbine
and both of almost (or completely) finished the move. I like to wish the
projects the best and a very good and long lasting future. In a seperate
mail there is a TLP proposal for commons, which on acceptance will mean
that the biggest part of the Jakarta community have no direct ties anymore
with Jakarta. The focus after commons will be on the projects left at
Jakarta and see if there is possibility for them to go TLP or when
that is not viable or possible, find a suitable solution for those projects.
My explicit wish is that there will be no deadline for projects to move so
there will be enough time to find the best solution, instead of the quickest
solution. We owe that to all the people in those projects who invest a lot
of time and energy in those projects.
One of the big discussions that took place was about the future of Jakarta
and the thing we in majority agreed on (at least the people who spoke up)
is that it is worth to "save" the Jakarta brand. Since I prefer to spend
the energy and time I have in the projects that are left at Jakarta, I
decided not to invest time on what will happen to the Jakarta brand at this
time, simply because they deserve my time and energy and out of respect for
the projects that still currently have their existance at Jakarta.
If the board decides to not esablish the commons TLP, we need to go back
to the drawing table.

All in all : a lot is happening and a lot is going to happen in the months
to come. If there is reason to do so, I will provide extra board reports
besides the quarterly schedule.

Reports prefixed with MvdB are written by me.

=== Releases ===

  * 30 March 2007 - !HttpComponents !HttpCore 4.0 alpha 4 released
  * 4 April 2007 - Commons DBCP 1.2.2
  * 8 April 2007 - Commons Configuration 1.4
  * 18 May 2007 - POI 3.0 Final released
  * 6 June 2007 - JCS 1.3 released

=== Community changes ===

New committers, pmc persons, asf members and departures.

  * New Committers
* Ben Speakmon was voted in as a Commons Committer
* Alf Hogemark was voted in as a JMeter Committer
* Asankha C. Perera was voted in as a !HttpComponents Committer
* M. Johnson (although not new, his account was created just now,
  because of CLA problems). (POI)

  * PMC Members
* Thomas Vandahl was voted on to the PMC
* Danny Angus was persuaded to come back on the PMC.
* Ant Elder was voted on the PMC.

Fixed the bookkeeping on the addition of Nick Burch to the Jakarta PMC (that
was reported in the December 2006 report.

=== Infrastructure news ===

The only things currently happening is the move of infrastructure for the 
Turbine and POI TLP projects.

=== General project news ===

The Jakarta PMC has started to review all Jakarta projects whether they
contain or rely on cryptographic software and if they must be marked as
described on http://apache.org/dev/crypto. This is an ongoing process and
we expect some corner cases where we will need legal advice.

=== Subproject news ===


 BCEL 

No activity.

 BSF 

MvdB :Silent quarter. A talk for Apachecon US was accepted (Rony Flatcher),
which will hopefully increase the user base (observation : since the user
list is also pretty quiet it can mean that BSF is bug free or it needs
more users)

 Cactus 

MvdB:
The ip clearance finally passed, so Petar is now able to (re)integrate
his code into the cactus codebase.

 Commons 

A commons TLP resolution was sent to the Board at the same time of this board 
report.

31 March 2007 - vote passed to promote the JCI (Java Compiler Interface) to a 
proper component (from
the Sandbox).

''Chain''
  * Ready for a 1.2 bugfix release.

''CLI''
  * Gearing up for a 1.1 release.

''Configuration''
  * 8 April 2007 - Configuration 1.4 released

''DBCP''
  * 1 April 2007 DBCP 1.2.2 released

''IO''
  * Gearing up for a 1.3.2 bugfix release.

''JCI''
  * Gearing up for a first 1.0 release.

''JXPath''
  * Gearing up for a 1.3 release.

''Logging''
  * Needs someone to do a 1.1.1 bugfix release.

''Math''
  * Gearing up for a 1.2 release.

''SCXML''
 * Working towards a 0.7 release.

 ECS 

Nothing happened on the ECS front.

 HttpComponents 

Work on the first alpha of !HttpClient 4.0 has made good progress. We expect to 
release
client-alpha1 and the matching core-alpha5 shortly.

There is currently no release manager for a potential !HttpClient 3.1 final 
release. Since the RC1
was released only in March, this is not an immediate problem. Bug reports are 
still dripping in, and
bugs keep getting fixed. But we'll need to find a volunteer eventually.

Various options to spin off !HttpComponents from Jakarta are being discussed.
This could improve the focus of the active members of the !HttpComponents 
(sub-)community.


 JCS 
JCS 1.3 has been released. Thomas Vandahl acted as the release man

Re: Commons TLP for Board Meeting ?

[Martin van den Bemt]

Cool I'll send it in this weekend.. And indeed adding people to the PMC will 
not be a  problem
afterwards. So no worries from my side that people are going to miss the boat..

Mvgr,
Martin

Henri Yandell wrote:
> On 6/11/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> Hi everyone,
>>
>> The board meeting is the 20th, so it would be nice if we can add the
>> commons TLP proposal for that
>> meeting.
>> So we probably need to finalize the proposal and send it off during
>> the weekend.
> 
> I think the majority opinion was to send the proposal as is.
> 
> The only problem I can think of is that there were people who said
> they'd not put their names on there. Not that it'll be hard to add
> them on to the PMC later.
> 
> 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]

Commons TLP for Board Meeting ?

[Martin van den Bemt]

Hi everyone,

The board meeting is the 20th, so it would be nice if we can add the commons 
TLP proposal for that
meeting.
So we probably need to finalize the proposal and send it off during the weekend.

Mvgr,
Martin

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

Re: Jakarta site directory no longer contains .svn directories

[Martin van den Bemt]

Coolio I will keep my hands of Turbine then..
Could you send a message to the private list when the move is complete ?

Mvgr,
Martin

Scott Eade wrote:
> I set Turbine to redirect yesterday.  I will delete the turbine
> directory once I am happy that everything is okay with the new Turbine
> TLP site.  We still have Turbine on the Jakarta downloads page - we will
> sort this out when we have the Turbine download page working.
> 
> In summary: We are taking care of Turbine as part of the TLP move and
> will tidy up after ourselves towards the end of this process.
> 
> Thanks,
> 
> Scott
> 
> Martin van den Bemt wrote:
>> Good one :) Didn't fix Velocity yet (better to put that in the root
>> .htaccess and get rid of subdirs)
>>
>> So Turbine can be redirected too ?
>>
>> Mvgr,
>> Martin
>>
>> Henning Schmiedehausen wrote:
>>  
>>> Once, the sites are up, feel free to
>>> copy  /www/jakarta.apache.org/velocity/.htaccess
>>> and /www/velocity.apache.org/moving.html
>>>
>>> Best regards
>>> Henning
>>>
>>>
>>> On Thu, 2007-06-07 at 22:24 +0200, Martin van den Bemt wrote:
>>>
>>>> Thanx for clearing it up, I was starting to doubt myself, since I
>>>> did some cleanup of old Jakarta
>>>> projects a couple of days ago (no worries, didn't touch POI and
>>>> Turbine yet !)
>>>>
>>>> Mvgr,
>>>> Martin
>>>>
>>>> Thomas Vandahl wrote:
>>>>  
>>>>> sebb wrote:
>>>>>
>>>>>> Thanks; that's also fixed the missing updates.
>>>>>>
>>>>>> I wonder how it happened?
>>>>>>   
>>>>> That was me. I could have *sworn* that I copied these over by accident
>>>>> and as busy to remove them as fast as possible. Is this procedure "svn
>>>>> update - edit - ant - svn commit - svn update site" documented
>>>>> somewhere? I've never seen anything like this.
>>>>>
>>>>>
>>>>> Bye, Thomas.
>>>>>
>>>>> -
>>>>> 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]
>>
>>   
> 
> 
> 
> -
> 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 site directory no longer contains .svn directories

[Martin van den Bemt]

Good one :) Didn't fix Velocity yet (better to put that in the root .htaccess 
and get rid of subdirs)

So Turbine can be redirected too ?

Mvgr,
Martin

Henning Schmiedehausen wrote:
> Once, the sites are up, feel free to
> copy  /www/jakarta.apache.org/velocity/.htaccess
> and /www/velocity.apache.org/moving.html
> 
>   Best regards
>   Henning
> 
> 
> On Thu, 2007-06-07 at 22:24 +0200, Martin van den Bemt wrote:
>> Thanx for clearing it up, I was starting to doubt myself, since I did some 
>> cleanup of old Jakarta
>> projects a couple of days ago (no worries, didn't touch POI and Turbine yet 
>> !)
>>
>> Mvgr,
>> Martin
>>
>> Thomas Vandahl wrote:
>>> sebb wrote:
>>>> Thanks; that's also fixed the missing updates.
>>>>
>>>> I wonder how it happened?
>>> That was me. I could have *sworn* that I copied these over by accident
>>> and as busy to remove them as fast as possible. Is this procedure "svn
>>> update - edit - ant - svn commit - svn update site" documented
>>> somewhere? I've never seen anything like this.
>>>
>>>
>>> Bye, Thomas.
>>>
>>> -
>>> 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 site directory no longer contains .svn directories

[Martin van den Bemt]

Thanx for clearing it up, I was starting to doubt myself, since I did some 
cleanup of old Jakarta
projects a couple of days ago (no worries, didn't touch POI and Turbine yet !)

Mvgr,
Martin

Thomas Vandahl wrote:
> sebb wrote:
>> Thanks; that's also fixed the missing updates.
>>
>> I wonder how it happened?
> 
> That was me. I could have *sworn* that I copied these over by accident
> and as busy to remove them as fast as possible. Is this procedure "svn
> update - edit - ant - svn commit - svn update site" documented
> somewhere? I've never seen anything like this.
> 
> 
> Bye, Thomas.
> 
> -
> 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 site directory no longer contains .svn directories

[Martin van den Bemt]

Weird script when the result was that there was still the directory 
/www/jakarta.apache.org/.svn
present.
Very curious when httpd is going to use maven for their site :)

Mvgr,
Martin

Henning Schmiedehausen wrote:
> probably a 
> 
> find /www -name .svn -type d | xargs rm -rf  ## we do not need these 
> directories, all sites are built and deployed by maven anyway. 
> 
> :-)
> 
>   Best regards
>   Henning
> 
> 
> 
> On Thu, 2007-06-07 at 10:32 +0100, sebb wrote:
>> Thanks; that's also fixed the missing updates.
>>
>> I wonder how it happened?
>>
>> S/
>> On 07/06/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>>> I've fixed it.. Old dir structure under site3.
>>> (just moved the old site directory to site3 and run svn update from the 
>>> /www/jakarta.apache.org
>>> directory)
>>>
>>> Mvgr,
>>> Martin
>>>
>>> Scott Eade wrote:
>>>> sebb wrote:
>>>>> Not sure what's happened, but the .svn directories seem to have
>>>>> disappeared from the directory tree:
>>>>>
>>>>> /www/jakarta.apache.org/site
>>>>>
>>>>> It means that "svn update site" no longer works...
>>>> What would the fix be - to check out the site again?
>>>>
>>>> Scott
>>>>
>>>> -
>>>> 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 site directory no longer contains .svn directories

[Martin van den Bemt]

I've fixed it.. Old dir structure under site3.
(just moved the old site directory to site3 and run svn update from the 
/www/jakarta.apache.org
directory)

Mvgr,
Martin

Scott Eade wrote:
> sebb wrote:
>> Not sure what's happened, but the .svn directories seem to have
>> disappeared from the directory tree:
>>
>> /www/jakarta.apache.org/site
>>
>> It means that "svn update site" no longer works...
> What would the fix be - to check out the site again?
> 
> Scott
> 
> -
> 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]

Board report time..

[Martin van den Bemt]

Hi everyone,

The board meeting is going to be on the 20th (2 weeks from now).
So it's now time to add stuff to the 
http://wiki.apache.org/jakarta/JakartaBoardReport-current page :)

And maybe get the Commons TLP proposal out the door :)

Mvgr,
Martin

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

Re: [VOTE] Release JCS 1.3

[Martin van den Bemt]

If you vote again your vote is binding too :)

Mvgr,
Martin

Thomas Vandahl wrote:
> Hi Sebastian,
> 
> sebb wrote:
>> However:
>>
>> http://apache.org/dev/apply-license.html
>>
>> says much the same, and seems to be policy.
> 
> As you can see from the SVN tag JCS_1_3 and the artifacts at my site,
> your concerns have been addressed and the license files have been fixed.
> 
> I would like to ask you to be so kind as to re-vote on the subject,
> based on the new status.
> 
> Regards, Thomas.
> 
> -
> 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: Result: [VOTE] Release JCS 1.3

[Martin van den Bemt]

Agreed. though that page probably needs a bit of a reality check.. The problem 
is when someone does
a -1 with reasoning, people tend to stop voting until that vote is switched to 
a +1 and if that vote
is switched to a +1 and there are enough votes, people that stopped voting will 
keep silent.

Hope I make sense :)

Mvgr,
Martin

Will Glass-Husain wrote:
> Martin,
> 
> Actually, that's not true.  Releases cannot be vetoed by a -1.  See
> http://www.apache.org/foundation/voting.html
> 
> If there's a majority approval and at least 3 +1 PMC votes, than it's up to
> the release manager to decide whether or not to release.  He can decide to
> table the vote based on feedback, if so desired.  (We had this issue in the
> release of Velocity 1.5).
> 
> WILL
> 
> 
> 
> On 6/3/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> Rony is a PMC member.. However the -1 of Sebb (which is binding and
> blocking) is still there (unless
>> I missed his +1)..
>> Added Rony to the jakarta-pmc authorization file (thanx for spotting
> this)..
>>
>> Mvgr,
>> Martin
>>
>> Thomas Vandahl wrote:
>> > Hi Roland,
>> >
>> > Roland Weber wrote:
>> >> Hi Thomas,
>> >>
>> >>> I could not find any information about whether Rony Flatscher is a
>> >>> member of the PMC
>> >> In the committers-only SVN module is a file board/committee-info.txt
>> >> which lists the PMCs of all Apache projects. It's (supposed to be ;-)
>> >> the authoritative source. Rony Flatscher is listed there as PMC
>> member.
>> >
>> > I came across some commit message regarding asf-authorization which
>> > contained a list of members of the jakarta-pmc group and he was not
>> > listed there. So I was unsure.
>> >
>> >> I'm not sure myself how Sebastian's -1 will be weighed here. I would
>> >> have expected that the NOTICE and LICENSE files get fixed and he
>> >> changes his vote. As by his last mail on the topic, the content in
>> >> SVN did not get fixed. If you changed the release files manually, you
>> >> should commit those changes to SVN and give Sebastian some time to
>> >> change his vote.
>> >
>> > We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
>> > SVN. This is at least what I understood the release-then-vote-policy
>> > means. I have committed the latest changes and moved the tag, however.
>> >
>> > If Rony is a PMC member we have a result of 3 +1 votes, which should be
>> > sufficient. However its up to the PMC to decide this.
>> >
>> > Bye, Thomas.
>> >
>> > -
>> > 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: Result: [VOTE] Release JCS 1.3

[Martin van den Bemt]

Rony is a PMC member.. However the -1 of Sebb (which is binding and blocking) 
is still there (unless
I missed his +1)..
Added Rony to the jakarta-pmc authorization file (thanx for spotting this)..

Mvgr,
Martin

Thomas Vandahl wrote:
> Hi Roland,
> 
> Roland Weber wrote:
>> Hi Thomas,
>>
>>> I could not find any information about whether Rony Flatscher is a
>>> member of the PMC
>> In the committers-only SVN module is a file board/committee-info.txt
>> which lists the PMCs of all Apache projects. It's (supposed to be ;-)
>> the authoritative source. Rony Flatscher is listed there as PMC member.
> 
> I came across some commit message regarding asf-authorization which
> contained a list of members of the jakarta-pmc group and he was not
> listed there. So I was unsure.
> 
>> I'm not sure myself how Sebastian's -1 will be weighed here. I would
>> have expected that the NOTICE and LICENSE files get fixed and he
>> changes his vote. As by his last mail on the topic, the content in
>> SVN did not get fixed. If you changed the release files manually, you
>> should commit those changes to SVN and give Sebastian some time to
>> change his vote.
> 
> We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
> SVN. This is at least what I understood the release-then-vote-policy
> means. I have committed the latest changes and moved the tag, however.
> 
> If Rony is a PMC member we have a result of 3 +1 votes, which should be
> sufficient. However its up to the PMC to decide this.
> 
> Bye, Thomas.
> 
> -
> 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] Release JCS 1.3

[Martin van den Bemt]

Full license text should go in LICENSE and attributions and notices in NOTICE..

Mvgr,
Martin

Henning Schmiedehausen wrote:
> Well, I understand it differently and Thomas (probably looking at other
> projects) did this too:
> 
> - LICENSE.txt contains the terms under which the software is licensed. 
>   This is Apache License 2.0
> 
> - NOTICE contains attributions to included code and the licenses that
>   it is included under. Some projects choose to reference "foo.LICENSE"
>   files for "foo". Some choose to put the appropriate licensess into 
>   the NOTICE file. Yet others put these (third party) licenses into the
>   LICENSE file.
> 
> All of the above are ok IMHO. I personally have a preference for the
> first variant. httpd uses the second. I think FOP uses the third.
> 
>   Best regards
>   Henning
> 
> On Mon, 2007-05-28 at 15:24 -0700, Henri Yandell wrote:
>> On 5/27/07, sebb <[EMAIL PROTECTED]> wrote:
>>> On 27/05/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:
 The license under which the code gets licensed to our end users is in
 LICENSE.txt.

 Copyright notices and optional third-party licenses under which the code
 got licensed to us is in NOTICE.
>>> Are you sure?
>>>
>>> That does not seem to agree with the sample NOTICE file:
>>>
>>> http://www.apache.org/licenses/example-NOTICE.txt
>>>
>>> Nor does it seem to agree with the way that httpd use the NOTICE and
>>> LICENSE files:
>>>
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/
>>>
>>> As I understand it, the NOTICE file is for attributions.
>>> The LICENSE file is for licenses.
>>> These may either be included inline, or in separate files referenced
>>> from the main LICENSE file.
>> That's how I understand it too.
>>
>> Hen

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

> 
> To those trying to preserve Jakarta I say 'let go of Commons'. Don't abuse 
> Commons to try and save Jakarta. If the Jakarta name is worth saving, people 
> and community will form to save it. If not, then it will die. Thats normal 
> and natural.
> 

Maybe not a reference to me, but in case it is, a reaction is probably needed. 
I am not abusing
commons to save Jakarta. I just don't want commons to claim the Jakarta name 
when it leaves, since
that would be abusing the other projects still present at Jakarta.

That's what my notes are about : if the commons goal is to become Jakarta, you 
shouldn't leave. (not
  saying that this is what you wanted, just my observation from the threads 
going on)

Mvgr,
Martin

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

Re: [VOTE] Commons moving to TLP

[Martin van den Bemt]

> 
> Added themselves to the TLP Proposal but didn't vote(?)
> 
> 1.  Jochen Wiedmann
> 2.  Martin van den Bemt(*)
> 3.  Matt Benson
> 4.  Rory Winston(*)
> 5.  Joerg Pietschmann
> 

I voted +1, unless the goal is that commons becomes Jakarta in the end.. (then 
I want commons to stay)

Mvgr,
Martin

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> It's pretty simple to solve this though (even though repeating myself
>> here) : Let (a
>> flattened) commons become Jakarta..
> 
> Then why the concern about the use of Apache Jakarta Commons as a
> project name?
> 
> When the time comes, we could just point  at
> .
> 

I am highly opposed to that because of the following reasons :

- If commons wants to be Jakarta they just should work *here* to achieve that.
- If commons is leaving to come back, they are just ignoring the other projects 
that are still here.
- It is solving the problem the wrong way
- The biggest (developer) community is in commons. We need them to still care 
and think about the
rest of Jakarta.

It's just like leaving your parent's home to live on your own to run away from 
your siblings and
then try to move back in when the siblings left the parental home. Big chance 
your parents will not
let you do that.

Going to bed now..

Mvgr,
Martin

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

Flattened means : jakarta.apache.org/commons becomes jakarta.apache.org :)

Mvgr,
Martin

Ted Husted wrote:
> On 5/21/07, Ted Husted <[EMAIL PROTECTED]> wrote:
>> On 5/21/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> > It's pretty simple to solve this though (even though repeating
>> myself here) : Let (a
>> > flattened) commons become Jakarta..
> 
> Actually, it might be helpful if you repeated yourself in full, to be
> sure we're not talking past each other. For example, I don't know what
> "flattened" means.
> 
> -Ted.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> One link to a separate page isn't a problem, since I prefer that no
>> major changes happen
>> to the main site at this stage.
>> Currently I am pretty much dedicated in keeping Jakarta as a brand.
>> And when that time
>> comes to worry about that, I'll work with the people who still have
>> the itch and the cycles
>> to spare. Starting to make it happen now feels like a waste of time,
>> since the future of
>> Jakarta is by no way set at this moment.
> 
> Why does it have to be and either/or proposition?
> 
> I would think that regardless of what anyone envisions the future of
> Jakarta to be, extending the home page to highlight *all* of the Java
> products at the ASF would be a Good Thing.

It's a good thing, but not now :)

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

It just removes focus from the tasks we have to deal with *now*.. And if 
Jakarta is going to still
be a project with code, I rather see the people involved in that project make 
the decisions.

Don't forget there are 2 outcomes for Jakarta (ignoring no Jakarta at all)
- Jakarta as just a website.
- Jakarta as a real Apache project, which means that project owns Jakarta. 
Since the Jakarta project
needs to be re-established, the current people on the PMC are not the people on 
the new PMC and can
therefor have a different opinion on being java at apache and undo all the work.


Mvgr,
Martin

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

That's quite problematic : Jakarta is responsible for jakarta.apache.org, not 
commons, sharing that
responsibility will just complicate things a lot.

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

Mvgr,
Martin

Ted Husted wrote:
> What if the proposal were to create the TLP for the purpose of
> reporting directly to the board, but nothing else changed? Would the
> project name "Apache Jakarta Commons" still be a problem for you if
> the physical infrastructure remained "here", under the Jakarta
> hostname?
> 
> -Ted.
> 
> On 5/21/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> Yep still feel that way. Projects that want to use the Jakarta name,
>> should just stay here
>> till they
>> are the only one left and after that re-establish the Jakarta Project.
>>
>> Mvgr,
>> Martin
>>
>> Ted Husted wrote:
>> > On 5/21/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> >> That *you* don't see a problem in using the Jakarta name, doesn't mean
>> >> no one has
>> >> expressed objections (you even responded to those objections)
>> >
>> > Yes, I looked back over the thread, and I stand corrected. You did say
>> > that the use of the Jakarta name in another TLP seemed premature. Do
>> > you still feel that way?
>> >
>> > -Ted.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

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

Mvgr,
Martin

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> > Then take it to the next stage. Update the Jakarta home page to
>> > include links to our other Java products that were never part of
>> > Jakarta, like iBATIS, and invite all ASF Java products to use our news
>> > feed. Open the door, and see if anyone walks in.
>>
>> I am on a different schedule, volunteering on my own terms. In my view
>> doing this now is
>> *way* too premature. I currently only want to invest my time and
>> energy on Jakarta and
>> it's current projects.
> 
> That's fair. Every volunteer should scratch their own itch :)
> 
> If other volunteers were ready to explore this course of action now,
> would you object to someone creating a "[EMAIL PROTECTED]" portal here by
> extending the Jakarta home page?
> 
> -Ted.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

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

Mvgr,
Martin

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> That *you* don't see a problem in using the Jakarta name, doesn't mean
>> no one has
>> expressed objections (you even responded to those objections)
> 
> Yes, I looked back over the thread, and I stand corrected. You did say
> that the use of the Jakarta name in another TLP seemed premature. Do
> you still feel that way?
> 
> -Ted.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>> It's not just you :) It's just too early to do that at this stage,
>> since if it is just some
>> commits
>> as Teds says, it will be a dead horse. I don't need something formal
>> or something, but at
>>  least get
>> some attention from the java projects out there if they are willing to
>> help out and also
>> have some
>> collaboration with David Reid / projects.a.o. It's not worth it if the
>> Apache java projects
>> don't
>> like the idea and help out at least with their project.
>> (not suggesting you are of a different opinion though Danny)
> 
> Then take it to the next stage. Update the Jakarta home page to
> include links to our other Java products that were never part of
> Jakarta, like iBATIS, and invite all ASF Java products to use our news
> feed. Open the door, and see if anyone walks in.
> 

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

Mvgr,
Martin

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

Danny Angus wrote:
> On 5/21/07, Ted Husted <[EMAIL PROTECTED]> wrote:
>> On 5/21/07, Danny Angus <[EMAIL PROTECTED]> wrote:
>> > Ok "Ownership" is perhaps the wrong word, if Jakarta is being
>> > disbanded who provides the oversight?
>>
>> The same people who provide oversight for any ASF project: The people
>> doing the work.
>>
>> If anyone wants Jakarta to be the ASF portal to all of our Java
>> assets, then make it so.
>>
>> A commit is the only vote that counts.
> 
> Yes, OK, and that's what I'm trying to find out. Does anyone? or is it
> just me?

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

Mvgr,
Martin

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

Ted Husted wrote:

> Worse case, the Commons group could always go with "Apache Jakarta
> Commons". No one has objected to the re-use of the word "Jakarta", and
> more than one person has affirmed that it could be used.  

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

Mvgr,
Martin

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

Re: [PROPOSAL] The future of Jakarta

[Martin van den Bemt]

My silence is because I think I made my preferred option quite clear way too 
many times.

Mvgr,
Martin

Danny Angus wrote:
> On 5/21/07, J Aaron Farr <[EMAIL PROTECTED]> wrote:
> 
>> This thread has been more quiet than I expected.
> 
> Actually, thinking about it, perhaps that's because we all think we
> know where this is inevitably going and we're just waiting for it all
> to settle out.
> 
> d.
> 
> -
> 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] Commons moving to TLP

[Martin van den Bemt]

If moving commons TLP is just a "twisted" (maybe a bad choice of a word) way to 
come back to
jakarta.apache.org in the end, I am -1 on the TLP move..

We currently have 2 projects moving TLP (Turbine and POI) and after that we 
need to start thinking
about every other project at Jakarta.

So if the goals is to make commons Jakarta, we should aim for that, instead of 
artificially trying
to accomplish that.

If I am not mistaken the real goals/questions are :

- Fix oversight issues
- Be more transparent for the board
- Move towards a community with the same focus (= eg reusable java components)
- Be able to say in one sentence what Jakarta is about (is consequence of above)
- See where we can fit project that are in maintenance mode or not actively 
supported anymore.
- How to handle projects that don't fit well within the new focus, but work 
pretty well as part of
Jakarta (are people waiting for being on eg 15 PMC's to be able to support 
these projects)
- And Apache wide : is there only a place for projects that have a "healthy" 
community ?

Mvgr,
Martin

Danny Angus wrote:
> On 5/14/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
>> As my random suggestion that Ted quoted points out, you can have a PMC
>> without their having to be TLP. Least I was told that a couple of
>> years ago either on board@ or face to face, so we could do the
>> following:
>>
>> * Create the Jakarta Commons PMC, without changing the website (or
>> even the svn maybe).
>> * Continue to encourage Jakarta subprojects to move to TLP, go into
>> maintenance or move over to other PMCs.
>> * Reach a point at which we can end the Jakarta PMC, or federate or
>> whatever.
> 
> Do you mean that the resources can then be handed over to the
> Jakarta-commons (or whatever) PMC?
> I'm in favour of that idea, jakarta==jakarta-commons is the option
> which I think makes most sense of all for the future of Jakarta.
> 
> 1/ it preserves a valuable brand
> 2/ commons embodies the original ethos of Jakarta
> 3/ commons (as we've seen hints of) still actively depends (c.f
> passively benefiting) upon the Jakarta brand.
> 
> To close down the project and hand the "brand" to another PMC would
> also meet all but the most draconian interpretation of what the reorg@
> discussions suggested needed to be done about the problem of Jakarta.
> 
> d.
> 
> -
> 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] Commons moving to TLP

[Martin van den Bemt]

Simon Kitching wrote:
> On Sun, 2007-05-13 at 01:06 +0200, Martin van den Bemt wrote:
>>> If the new TLP is java-only it seems very rude to take the name
>>> "commons.apache.org" : it's far too generic. Perhaps
>>> jakarta-commons.apache.org would be appropriate..
>> Leaving means not using the Jakarta name anymore.
> 
> I don't see why. As a member of the Jakarta PMC I'm willing to allow
> jakarta-commons.apache.org to use our trademark :-)

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

> 
> But if that's so then perhaps jcommons.apache.org? 
> Or commons4j.apache.org? (though that implies IBM to me...)

Or coffee.apache.org :)

Mvgr,
Martin

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

Re: [VOTE] Commons moving to TLP

[Martin van den Bemt]

> 
> If the new TLP is java-only it seems very rude to take the name
> "commons.apache.org" : it's far too generic. Perhaps
> jakarta-commons.apache.org would be appropriate..

Leaving means not using the Jakarta name anymore.

Mvgr,
Martin

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

Re: [VOTE] Commons moving to TLP

[Martin van den Bemt]

> I am not a Jakarta commiter, and also vote is not binding, but I want
> to ask something. What are the benefits for commons of moving to a

You are a Jakarta committer :)

Mvgr,
Martin

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

TLP proposal Turbine & POI for this board meeting and todo items.

[Martin van den Bemt]

Hi everyone,

The 16th of May is the next board meeting, so I was wondering if you were all 
ready to go TLP at
this stage or if you prefer to wait for next months board meeting ?
Getting the approval done will not mean you have to move over everything 
immediately (we are still
volunteers) and gives us a better time-line to help out with moving things 
over, set up redirects, etc..
There are a couple of things I like to see (re) checked :

- Have all people added their name to the TLP proposal ?
- Is the proposal setup according to
https://svn.apache.org/repos/private/committers/board/templates/subproject-tlp-resolution.txt
 ?
(this was just changed recently)

If everything is ok, ping me, so I can add it to the boards agenda.. Please 
remember that everything
that is added to the agenda needs to be < 80 characters on a line :)

Mvgr,
Martin

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

Re: [VOTE] Move POI to TLP

[Martin van den Bemt]

It helps if people who want to move with POI to TLP add their names to the 
proposal.

Mvgr,
Martin

David Fisher wrote:
> I was thinking he was asking the same thing as you, but after composing
> an email like yours, I realized Shawn was asking if after going to TLP
> he would remain as a committer to POI. I am sure that the answer is "yes
> all current POI committers remain POI committers."
> 
> After going to TLP it will be easier for others to become POI committers
> because then it will the POI PMC votes that will bring them into the fold.
> 
> If I am wrong then I hope someone with a better understanding will
> correct me.
> 
> Regards,
> Dave
> 
> On May 8, 2007, at 3:17 PM, Robert Burrell Donkin wrote:
> 
>> On Mon, 2007-05-07 at 15:36 -0500, Laubach, Shawn Contr 555 ACSS/GFLA1
>> wrote:
>>> So I can vote for this but then I'm not a committer anymore?  Just
>>> curious.
>>
>> anyone can vote (and please feel free to do so). however only some votes
>> are binding upon apache. in this case, it's Jakarta PMC votes. if POI
>> graduates then only Apache POI PMC votes will be binding.
>>
>> - robert
> 
> 
> -
> 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] Move POI to TLP

[Martin van den Bemt]

+1..

Mvgr,
Martin

Nick Burch wrote:
> Hi All
> 
> After lots of discussion within POI, and Jakarta in general, we think POI
> is ready to graduate to its own TLP. Thanks to the magic of ApacheCon,
> lots of people have been on-hand to help finalise the proposal for this,
> which is attached below.
> 
> So, now is the time to vote on the proposal:
> [ ] +1 I support the proposal
> [ ] +0 I don't care
> [ ] -1  I'm opposed to the proposal because...
> 
> Voting will close in one week.
> 
> Cheers
> Nick
> 
> 
> 
>WHEREAS, the Board of Directors deems it to be in the best
>interests of the Foundation and consistent with the
>Foundation's purpose to establish a Project Management
>Committee charged with the creation and maintenance of
>open-source software related to the continued implementation of
>the library for manipulating files in various business formats
>currently known as Apache POI for distribution at
>no charge to the public.
> 
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache POI Project", be and
>  hereby is established pursuant to Bylaws of the Foundation; and
>  be it further
> 
>RESOLVED, that the Apache POI Project be and hereby is
>  responsible for the creation and maintenance of software related
>  to creation and maintenance of open-source software and documentation
>related to the POI library based on software licensed to
>the Foundation; and be it further
> 
>RESOLVED, that the office of "Vice President, POI" be and
>hereby is created, the person holding such office to serve at
>the direction of the Board of Directors as the chair of the
>Apache POI Project, and to have primary responsibility for
>  management of the projects within the scope of responsibility of
>  the Apache POI Project; and be it further
> 
>RESOLVED, that the persons listed immediately below be and
>hereby are appointed to serve as the initial members of the
>POI PMC:
> 
>  * Nick Burch <[EMAIL PROTECTED]>
>  * Amol S. Deshmukh <[EMAIL PROTECTED]>
>  * Jason Height <[EMAIL PROTECTED]>
>  * Marc Johnson <[EMAIL PROTECTED]>
>  * Rainer Klute <[EMAIL PROTECTED]>
>  * Yegor Kozlov <[EMAIL PROTECTED]>
>  * Danny Muid <[EMAIL PROTECTED]>
>  * Andrew C. Oliver <[EMAIL PROTECTED]>
>  * Avik Sengupta <[EMAIL PROTECTED]>
>  * Glen Stampoultzis <[EMAIL PROTECTED]>
>  * Sean Sullivan <[EMAIL PROTECTED]>
> 
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Nick Burch
>be appointed to the office of Vice President, POI, to serve
>in accordance with and subject to the direction of the Board of
>Directors and the Bylaws of the Foundation until death,
>resignation, retirement, removal or disqualification, or until
>a successor is appointed; and be it further
> 
>RESOLVED, that all responsibility pertaining to the Apache
>POI sub-project and encumbered upon the Apache Jakarta
>PMC are hereafter discharged.
> 
> -
> 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 at 9 PM

[Martin van den Bemt]

This was yesterday evening at Apachecon Amsterdam.. We had a nice dinner and 
Niall really showed his
excellence in speaking French :)

Mvgr,
Martin

Jean Carlo Salas wrote:
> what?
> 
> On 5/2/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>>
>> Jakarta BOF is scheduled at 9 PM right after the Incubator BOF.
>>
>> Mvgr,
>> Martin
>>
>> -
>> 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]

Jakarta BOF at 9 PM

[Martin van den Bemt]

Jakarta BOF is scheduled at 9 PM right after the Incubator BOF.

Mvgr,
Martin

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

Re: [VOTE] Move Turbine to TLP

[Martin van den Bemt]

+1...

Mvgr,
Martin

Scott Eade wrote:
> The Turbine project has been discussing a proposal to the board that the
> Turbine projects leave the Jakarta umbrella and become their own top
> level project.  We are now at the point in the process that calls for a
> vote to take place.
> 
> The proposal is available at:
>http://wiki.apache.org/jakarta-turbine/TLPTurbine
> 
> For the interested, most of the discussion took place in the following
> thread:
>http://www.nabble.com/-DISCUSS--TLP--tf3574436.html
> 
> Here are the vote options:
> [ ] +1 I support the proposal
> [ ] +0 I don't care
> [ ] -1  I'm opposed to the proposal because...
> 
> Voting will close in one week.
> 
> Thanks,
> 
> Scott
> 
> -
> 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]

Apachecon Jakarta talks in fast feather tracks.

[Martin van den Bemt]

Hi everyone,

If someone wants to give a talk about a Jakarta project, there is an option of 
doing that during the
feather tracks on Friday.
So if you think you have something useful to say about a Jakarta project, 
please let me know (reply
to general is ok).
Even if it's just a single commons component, it's ok and I'll take it back to 
the Apacechon
planners to see if we can schedule the talks. (If you don't have a presentation 
yet, don't worry,
just let me know if you want to give a talk).

Nice candidates would be eg Turbine (lot of Turbine related people are coming), 
Robert with a talk
about RAT, etc, etc ;)
If you don't want to give a talk, but like to have someone else (co) present 
it, I am willing to
help out ..

Don't have an idea yet what the max time for a talk is (although if you talk 
fast, you can give a 5
hour presentation in 1 hour ahum)

Mvgr,
Martin

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

Jakarta - Internal project health audit..

[Martin van den Bemt]

Hi everyone,

A lot of things happening at Jakarta atm and even though I have some views on 
where Jakarta could
end up, things are in no way set.

On thing that I think needs to be done is to establish what the health of your 
project is. Which
means you have to look internal.

Things to consider :
 1) Number of *active* committers
 2) Do the active committers have a binding vote.
 3) Is your project able to do a release with just the *active* people.
 4) Are you investing time to *build* a developer community.
 5) Is there any possibility that a community can be build at all?

1 2 and 3 can be solved by 4 :)
5 could make 4 impossible or useless.

So please invest time in building a developer community so you are able to live 
on your own. Not
saying everyone has to live on their own, but if you *can* you are healthy :)

My feeling is that 4 is something we really need to work on and the only way to 
achieve that is
doing it while the developer community is still active.

Where I find the time, I will try to ping individual projects.

Mvgr,
Martin

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

Jakarta BOF at Apachecon EU ?

[Martin van den Bemt]

I've planned a Jakarta BOF for Apachecon EU.
Please increase the "Interested People Counter" on the
http://wiki.apache.org/apachecon/BirdsOfaFeatherEu07 page if you ar einterested 
on having a BOF.

Mvgr,
Martin

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

Jakarta Board Report

[Martin van den Bemt]

March 2007 Jakarta Board Report

Status

Activity seems to pick in projects that haven't been so active, so that's
really good news. Besides the releases and the code donation (see Cactus)
and the releases, there is nothing in particular that needs board attention
at this moment.
On a side note : I really hope we can go back to the 3 month schedule again.
If there is something out of the ordinary however, I will add an extra report.

Releases

* 13 February 2007 - Commons Fileupload 1.2 Released
* 17 March 2007 - Commons HttpClient 3.1-rc1 Released
* 18 March 2007 - Commons Transaction 1.2 Released
* 18 March 2007 - Jakarta Regexp 1.5 released

Community changes

Ant Elder - Voted as a committer for the BSF.
Stephen Kestle - Voted as a committer for Commons

BSF
Ant Elder - Voted as a committer for the BSF.

Cactus

Currently in the process of voting on a new committer (Petar Tahchiev).
After this vote a vote will be started to finish the code donation
by Petar, for more details of the code grant, please see
http://incubator.apache.org/ip-clearance/jakarta-cactus-tahchiev.html.

Commons FileUpload

The release 1.2 of Commons Fileupload 1.2 introduces a new streaming API,
which allows to use the library with arbitrarily large files and an extremely
low memory profile.

POI

Gearing up for a release of 3.0, which hopefully will be in a month or so's
time.

Regexp

Released 1.5 version of Regexp which brings number of known issues down to 3.
Dev and user lists are quiet.

Mvgr,
Martin

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

Re: [VOTE] Petar Tahchiev as Jakarta Committer

[Martin van den Bemt]

+1

I second Felipe's observations about Petar btw..

Mvgr,
Martin

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]

Last Call : Board report due..

[Martin van den Bemt]

Hi Everyone,

The board report is due again (hopefully we can move back to a 3 month schedule 
for the next time).
Please add anything noteworthy, like committer votes, releases (in the Release 
section + a bit more
detailed transcipt of the release under your component) and other things you 
want to share.

The current board report is *always* at 
http://wiki.apache.org/jakarta/JakartaBoardReport-current,
so if there is anything happening of importance, you are kind of expected to 
add information to this
page.

I will send out the report at the latest on Sunday.

Mvgr,
Martin

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

Re: An Official Request For Moving Cactus In The Incubator

[Martin van den Bemt]

>>
> All right,
> 
> I get it now. Thank you Martin. Yes, It sounds now more reasonable to move
> in the incubator.

Sorry you didn't get it :) (probably me though, mailing too much today). I was 
saying that I think
Cactus can gather enough votes in the current situation for eg a release (so 
without a need to go
through the incubator), so the Incubator path isn't needed (at least the way I 
look at it).
Exception of course is the legal part :), besides that we are taling about an 
existing Jakarta
codebase here.
If people think the cactus should go back to the incubator, because of a lack 
of vibrant community
and not being able to release, because of the 3 +1's, we probably shouldn't 
stop there , and start
shipping other Jakarta (sub and subsub) projects to the incubator.

In this case Felipe was keeping tabs on what you were doing  (and if I 
understood correctly Felipe
currently hasn't much time left to work on Cactus, but is still interested) and 
Kenney Westerhof
also worked on a cactus plugin for maven2, so he could also be a candidate to 
become active on cactus..

So the path will probable be (got no objections on this when sending this to 
private)

- Get your paperwork done (Code grant, icla, ccla)
- Have a vote on cactus-dev / general to accept your codebase into Cactus
- Do the incubator paperwork, start a vote there (based on lazy consensus, so 
if no one objects, the
code is accepted)
- Start a vote (on cactus-dev / general) to add you as a Jakarta committer.

No difference in this scenario with Mantissa/Luc path (to give an example)

Mvgr,
Martin


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

Re: An Official Request For Moving Cactus In The Incubator

[Martin van den Bemt]

>>
>> I know that you are busy, but I have another idea that came to me reading
>> the Matt Benson's post. In fact the guys are
>> dealing with a project that seems to be inspired the jakarta commons
>> Convert
>> project and so it would be possible to
>> accept the code without passing through the incubator. So why isnt' this
>> situation possible for Cactus (I mean I have refactored existing code and
>> added the maven xml files - it is not a new project).
>>
>> I also agree that passing through the incubator is the best solution
>> in the
>> great majority of cases, but in my opinion there are still some cases
>> (like
>> Cactus for instance) that are threatened of stalling even more.
> 
> Martin or others may answer this better - but AIUI one of the two
> primary goals of the incubator is building  community around code
> bases. This is not just a "nice thing" at Apache - its an absolute
> necessity. As an example under Apache rules without 3 votes from the
> PMC (project management committee) responsible for a project you can't
> release anything. Once a project falls below that critical level of
> involved people its basically dead in the water as far as releasing
> any software goes. In the case of a project like Cactus the main
> reason for going back to the incubator would be to re-create a viable
> community.
> 

>From what I understood from current people that have cactus on their radar and 
>have sufficient
"power" to vote, Cactus will be able to get a release out the door.
An another note : After incubation it could still be that you cannot get a 
release out the door if
you end up at Jakarta, depending on the fact if you actually make it on the 
Jakarta PMC.
This is also one of the reasons an Incubator project should have 3 mentors, so 
they can actually
release, without depending on the time of people not directly involved.

Mvgr,
Martin

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

Re: An Official Request For Moving Cactus In The Incubator

[Martin van den Bemt]

Hence the reason I wanted to wait for a response till I had more time (still 
busy).. My approach for
you would have been : get a software grant, ccla and icla on file and start a 
vote on you being a
committer for cactus, I just failed horribly to send out that mail (btw sending 
in those documents
is what legal incubation is about).

I will send you some links for this, if you didn't figure it out earlier or 
someone else beats me to
it..

Since there is still enough interest in Cactus I think that new activity will 
be enough to get more
people aboard and get the ball rolling again :)

Mvgr,
Martin

Petar Tahchiev wrote:
> On 3/7/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>>
>> will come back to this on friday..
>>
>> Mvgr,
>> Martin
>>
>> Petar Tahchiev wrote:
>> > Hello guys,
>> >
>> > first of all let me introduce myself. My name is Petar Tahchiev and
>> I am
>> > from Bulgaria.
>> >
>> > I wanted to enroll in the last-years Google Summer Of Code
>> > where I applied with the
>> > project of migrating the Cactus build system to Maven.
>> Unfortunatelly me
>> > and
>> > Felipe Leme (my mentor), who I would like to thank once again for the
>> > encouragement
>> > and the help he provided me, weren't qualified. Later I had a
>> > few personal issues to solve, but the point is that I continued to work
>> on
>> > my own and sooner I managed to
>> > migrate the Cactus project to be built with Maven.
>> >
>> > When everything was done I started submitting patches in the cactus
>> jira,
>> > for some known bugs. The problem with the patch of the build system was
>> > that
>> > it turned out to be very large so I couldn't apply it in the jira. Then
>> me
>> > and Felipe agreed that it would be better to move the cactus to a
>> separate
>> > repository
>> > and test the build system there (you understand that the new build
>> > structure
>> > was absolutely different from the old one and merging was a kind of a
>> tough
>> > task).
>> > So I got my work and imported it in my own repository at the
>> > sourceforge.netwhere we began testing. The point is that when we
>> > wanted to apply the
>> > changes in the
>> > cactus trunk in the Apache repository we were adviced by Martin van den
>> > Bemt
>> > that we have to ask that the project be moved in the incubator first
>> and
>> > then when the
>> > code is appropriate for the cactus's trunk move it in the trunk.
>> >
>> > Now the process of moving Cactus in the incubator is stalled, as
>> well as
>>
>> > our
>> > work on it, because I want to move it in the incubator, before I
>> > continue making
>> >
>> > additional changes and implementing new features.
>> >
>> > So my request to you guys is this: if anyone can help us move the code
>> in
>> > the incubator, he is more than wellcome.
>> > Thank you very much.
>> >
>> > P.S. You may find additional information of the whole process here:
>> >
>> > [1]
>> http://www.mail-archive.com/cactus-dev@jakarta.apache.org/msg08579.html
>> > [2] http://www.nabble.com/Question-About-the-Current-State-Of
>> > -Cactus-In-the-Incubator-t361.html
>> >
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> Ok, no problem.
> 
> I know that you are busy, but I have another idea that came to me reading
> the Matt Benson's post. In fact the guys are
> dealing with a project that seems to be inspired the jakarta commons
> Convert
> project and so it would be possible to
> accept the code without passing through the incubator. So why isnt' this
> situation possible for Cactus (I mean I have refactored existing code and
> added the maven xml files - it is not a new project).
> 
> I also agree that passing through the incubator is the best solution in the
> great majority of cases, but in my opinion there are still some cases (like
> Cactus for instance) that are threatened of stalling even more.
> 
> P.S. Personaly for me, I am happy with both of the solutions - with or
> without the incubator. My desire is to start working on the project as soon
> as possible because we are planning of implementing some new features and
> then releasing a RC.
> 
> Looking forward to your reply.

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

Re: Looking for an incubation champion

[Martin van den Bemt]

Niall Pemberton wrote:
> On 3/9/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>>
>> Matt Benson wrote:
>> > --- Niall Pemberton <[EMAIL PROTECTED]> wrote:
>> > [SNIP]
>> >> I didn't know whether this had been done before in
>> >> Commons - but seems
>> >> that it has for the Commons CSV component back in
>> >> December 2005:
>> >>
>> >>
>> > http://incubator.apache.org/ip-clearance/jakarta-commons-csv.html
>> >
>> > Actually I knew about this but thought I remembered
>> > someone (Henri?) saying later that having gotten the
>> > code in this way might not have been the best choice
>> > in retrospect.  Does that ring any bells with anyone?
>>
>> Yep that rings a bell and going down that route again, is not
>> something that has my support for
>> *new* components (which this is). If the code is destined for an
>> existing codebase, we could do the
>> IP route, else I would like to see some level of incubation (besides
>> handling ip). See the
>> discussion on not-yet-commons ssl.
> 
> I'm wondering why? Seems to me that this is a slightly different
> situation to either CSV or the SSL situations since one of the
> developers is an existing ASF and Commons committer.

There are new committers involved. With CSV Henri is a committer (not talking 
karma here) (and me
too, although we are both not very active). I think when new people are 
involved incubation (besides
legal) should occur (even though the community import isn't that big, compared 
to similar situation
like activemq, servicemix, etc, where the core developers are actually ASF 
Members)

In case of this scenario (and ssl) I "envision" this for incubation :

- Get the people on board as a committer on the initial proposal
- Have them *show* that they are here to stay for an x amount of time
- Ideally have the normal exit criteria, although I can imagine for commons a 
slightly weaker exit
strategy may be adapted (don't think the incubator thinks that eg 3 committers 
on a project is a
vibrant community, although within commons it definitely will be!).
- Get a release out.

If someone starts hacking on code in the sandbox I am ok with that, but rather 
not see new code
again hitting the sandbox, since we "don't" accept new committers on sandbox 
components and it
doesn't have the ability to have a release (disclaimer : I became committer in 
Jakarta because of a
sandbox component, ahum).

I highly prefer that incubating commons components to use the commons-dev and 
commons-user list,
since to do development however, since it would be quite a cultural shock when 
moving from incubator
specific lists to the commons ones.

Disclaimer : this is just a brain dump and I would love to see some new 
projects at Jakarta, but I
think we also need to figure out how we should handle that in a constructive 
way and prevent
feedparser and csv situations.

Mvgr,
Martin

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

Re: Looking for an incubation champion

[Martin van den Bemt]

> On another note : If there will be no mentors for the project from Jakarta, I 
> don't see a reason
> that Jakarta be the sponsor of the project. Not that this is a documented 
> Incubator policy however,
> but since 1) we have a lot of people who are allowed to be a member 

Replace member with mentor :) People who are allowed are normally members of 
the ASF.


Mvgr,
Martin

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

Re: Looking for an incubation champion

[Martin van den Bemt]

Matt Benson wrote:
> --- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> [SNIP]
>> I didn't know whether this had been done before in
>> Commons - but seems
>> that it has for the Commons CSV component back in
>> December 2005:
>>
>>
> http://incubator.apache.org/ip-clearance/jakarta-commons-csv.html
> 
> Actually I knew about this but thought I remembered
> someone (Henri?) saying later that having gotten the
> code in this way might not have been the best choice
> in retrospect.  Does that ring any bells with anyone?

Yep that rings a bell and going down that route again, is not something that 
has my support for
*new* components (which this is). If the code is destined for an existing 
codebase, we could do the
IP route, else I would like to see some level of incubation (besides handling 
ip). See the
discussion on not-yet-commons ssl.
On another note : If there will be no mentors for the project from Jakarta, I 
don't see a reason
that Jakarta be the sponsor of the project. Not that this is a documented 
Incubator policy however,
but since 1) we have a lot of people who are allowed to be a member and 2) the 
project should have
active guidance from the community where it is destined to end up (esp 
important in a commons
situation).

I am planning to start a thread on these kind of situations on incubator 
general to gather thoughts.

Mvgr,
Martin

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

Re: Looking for an incubation champion

[Martin van den Bemt]

It is short for the dutch "Met vriendelijke groeten", which translates to 
english as "With kind
regards" :)

Mvgr,
Martin

Matt Benson wrote:
> Thanks for the reply, Martin.  BTW, and not to derail
> my own topic, but what is "Mvgr?"  :)
> 
> -Matt
> 
> --- Martin van den Bemt <[EMAIL PROTECTED]> wrote:
> 
>> I've already have a promise to help out Julius with
>> incubation and am currently am mentor for
>> Trinidad, so I don't think it is wise for me to add
>> another effort to my list.
>>
>> Mvgr,
>> Martin
>>
>> Matt Benson wrote:
>>> @Members:
>>>   I have recently joined the development
>>> team of an OSS project, Morph, that captures the
>>> spirit of Jakarta commons-convert but where the
>>> convert project stagnated, Morph is a
>> well-evolved,
>>> though still not 100% complete, library whose
>>> development I feel would benefit greatly from The
>>> Apache Way and would make a worthy ASF project. 
>>> Object conversion seems to be a woefully
>> under-served
>>> subject in the Java OSS space, despite the
>> ubiquity of
>>> the need for it (however well-hidden it may tend
>> to
>>> be) in enterprise Java development.  I have
>> contacted
>>> a few of you personally already, but having
>> received
>>> no bites as yet I am widening my audience one last
>>> time before giving up on this.
>>>
>>> You can learn more about this library at:
>>>
>>> http://morph.sourceforge.net
>>>
>>> Thanks,
>>> Matt
>>>
>>>
>>>
>>>  
>>>
> 
>>> Don't get soaked.  Take a quick peek at the
>> forecast
>>> with the Yahoo! Search weather shortcut.
>>>
>> http://tools.search.yahoo.com/shortcuts/#loc_weather
>>>
> -
>>> 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]
>>
>>
> 
> 
> 
>  
> 
> Don't get soaked.  Take a quick peek at the forecast
> with the Yahoo! Search weather shortcut.
> http://tools.search.yahoo.com/shortcuts/#loc_weather
> 
> -
> 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: An Official Request For Moving Cactus In The Incubator

[Martin van den Bemt]

will come back to this on friday..

Mvgr,
Martin

Petar Tahchiev wrote:
> Hello guys,
> 
> first of all let me introduce myself. My name is Petar Tahchiev and I am
> from Bulgaria.
> 
> I wanted to enroll in the last-years Google Summer Of Code
> where I applied with the
> project of migrating the Cactus build system to Maven. Unfortunatelly me
> and
> Felipe Leme (my mentor), who I would like to thank once again for the
> encouragement
> and the help he provided me, weren't qualified. Later I had a
> few personal issues to solve, but the point is that I continued to work on
> my own and sooner I managed to
> migrate the Cactus project to be built with Maven.
> 
> When everything was done I started submitting patches in the cactus jira,
> for some known bugs. The problem with the patch of the build system was
> that
> it turned out to be very large so I couldn't apply it in the jira. Then me
> and Felipe agreed that it would be better to move the cactus to a separate
> repository
> and test the build system there (you understand that the new build
> structure
> was absolutely different from the old one and merging was a kind of a tough
> task).
> So I got my work and imported it in my own repository at the
> sourceforge.netwhere we began testing. The point is that when we
> wanted to apply the
> changes in the
> cactus trunk in the Apache repository we were adviced by Martin van den
> Bemt
> that we have to ask that the project be moved in the incubator first and
> then when the
> code is appropriate for the cactus's trunk move it in the trunk.
> 
> Now the process of moving Cactus in the incubator is stalled, as well as
> our
> work on it, because I want to move it in the incubator, before I
> continue making
> 
> additional changes and implementing new features.
> 
> So my request to you guys is this: if anyone can help us move the code in
> the incubator, he is more than wellcome.
> Thank you very much.
> 
> P.S. You may find additional information of the whole process here:
> 
> [1] http://www.mail-archive.com/cactus-dev@jakarta.apache.org/msg08579.html
> [2] http://www.nabble.com/Question-About-the-Current-State-Of
> -Cactus-In-the-Incubator-t361.html
> 

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

Re: Looking for an incubation champion

[Martin van den Bemt]

I've already have a promise to help out Julius with incubation and am currently 
am mentor for
Trinidad, so I don't think it is wise for me to add another effort to my list.

Mvgr,
Martin

Matt Benson wrote:
> @Members:
>   I have recently joined the development
> team of an OSS project, Morph, that captures the
> spirit of Jakarta commons-convert but where the
> convert project stagnated, Morph is a well-evolved,
> though still not 100% complete, library whose
> development I feel would benefit greatly from The
> Apache Way and would make a worthy ASF project. 
> Object conversion seems to be a woefully under-served
> subject in the Java OSS space, despite the ubiquity of
> the need for it (however well-hidden it may tend to
> be) in enterprise Java development.  I have contacted
> a few of you personally already, but having received
> no bites as yet I am widening my audience one last
> time before giving up on this.
> 
> You can learn more about this library at:
> 
> http://morph.sourceforge.net
> 
> Thanks,
> Matt
> 
> 
> 
>  
> 
> Don't get soaked.  Take a quick peek at the forecast
> with the Yahoo! Search weather shortcut.
> http://tools.search.yahoo.com/shortcuts/#loc_weather
> 
> -
> 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] Create [EMAIL PROTECTED] mailinglist..

[Martin van den Bemt]

Andrew C. Oliver wrote:
> I think it is a bad idea.  Either a project is alive or it is dead and
> most of the dead are not coming back.  The site, the project and
> everything else should reflect this.
> 
> I suggest that:
> 
> 1. ECS
> 2. ORO
> 3. Regexp


> 4. Alexandria (already does basically)

Was closed down about a year ago.


> 
> all have a page that looks like this one:
> http://avalon.apache.org/closed.html
> 
> Stating that the projects are dead and state what things have taken
> their place and provide links.  There is
> no need for an artificial "dev" list or "users" list.  Just close the
> lists.  (If you disagree look at the list archive for
> each over the last 6 months and see if you REALLY disagree in more than
> THEORY).

I know how the lists look like, I am subscribed to all Jakarta lists (bugzilla 
is the most active
developer on these lists ;).  These projects may be dead currently from a 
developer perspective
(ignoring Daniels mail here for a moment), but hardly from a user perspective. 
And there is
currently talk amongst users on eg ecs to potentially start activity. I like 
that to get more
visibility and opportunity, which is now "hidden" in the ecs lists.
Also I like the message on a website to contain something more than just the 
message "this project
is dead" with some links. I rather state how people can get active on these 
projects again and I
like to point them to a central dev list, instead a (potentially) forgotten dev 
list.

When you want to close down the user list, should we point people to the 
general list for their
support questions (which doesn't happen often, but it happens) ?

Mvgr,
Martin

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

Re: [PROPOSAL] Create [EMAIL PROTECTED] mailinglist..

[Martin van den Bemt]

Daniel F. Savarese wrote:
> In message <[EMAIL PROTECTED]>, Martin van den Bemt writes:
>> The strength of this list should be is that with a lot of hands the chance 
>> tha
>> t nothing happens when
>> there is activity is minimized. If someone has an hour to spare, it could 
>> very
>> well be useful to
>> apply a patch and mentor people.
> 
> Vadim has regexp covered and I have oro covered as far as maintenance
> requests go, but no, I don't think either project merits its own
> separate -dev and -user lists anymore.  The trick is getting users who
> want new features (as opposed to maintenance like bug fixing) to contribute
> new features instead of always expecting the maintainers to add them
> (e.g., Commons Net has been pretty successful in attracting user
> contributed features).  But regexp and oro are special cases which will
> likely see no new features in the future, having been rendered obsolete
> by standardization of the functionality they provide in the Java core api.

Good to hear it is covered.. So little happening atm that I didn't notice it :)

> 
>> Since I don't like to extend the scope of the general list, I prefer dev 
>> discu
>> ssion not to take
>> place there.
>>
>> Thoughts ?
> 
> As long as user traffic can go to general, it sounds okay.  Most, if not all,
> activity will be triggered by users (who won't be subscribed to dev), so
> I'd think at least some threads should be permitted to start on general
> and then migrate to dev if there is follow-on development related discussion.
> 

Maybe a [EMAIL PROTECTED] I see general as being the list for jakarta wide 
discussions and
not so much a list of asking specific questions about components..

Mvgr,
Martin

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

Re: [vote][conclusion] Re: [Vote] Where should "not-yet-commons-ssl" go?

[Martin van den Bemt]

Martin van den Bemt wrote:
> Not a vote result, since it is just a conclusion from my side.
> 
> 
> 
> Since there are more (Apache) projects interested in ssl, I think however we 
> can get enough people
> on board to do a successful incubation, so I offered to Julius to help him 
> out with incubation as
> the sponsor and the mentor.
> 

Correction : the sponsor will be the incubator PMC in this scenario.

Mvgr,
Martin

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

[vote][conclusion] Re: [Vote] Where should "not-yet-commons-ssl" go?

[Martin van den Bemt]

Not a vote result, since it is just a conclusion from my side.


Even though there are enough +1's to start sponsoring ssl, I think I want to 
see a lot more support
than what I currently see (I mean active support). So at this stage I don't 
think it is wise that
Jakarta should sponsor this project. Let's see where incubation takes ssl, 
without being destined
for Jakarta and only decide if ssl requests to be part of Jakarta when it wants 
to or is ready to
when it's time to leave the incubator.



Since there are more (Apache) projects interested in ssl, I think however we 
can get enough people
on board to do a successful incubation, so I offered to Julius to help him out 
with incubation as
the sponsor and the mentor.


If you strongly disagree with my conclusion, please step up to get actively 
involved, if not I will
start working with Julius on a personal basis to get this baby going.

Mvgr,
Martin


Julius Davies wrote:
> Hi, Jakarta-General,
> 
> Let's vote on where to put this code!  Here's the code right now:
> 
> http://juliusdavies.ca/commons-ssl/
> 
> Forgive my newbieness; I hope these are the right options:
> 
> [+1] Sub-module in Httpcomponents.
> [+1] Sandbox.
> [+1] Full Incubator.
> [-1] "not-yet-commons-ssl" is not a good project for Apache because...
> 
> I'm fine with majority rules, assuming there are no "-1" votes.
> 
> Some background:
> 
> http://wiki.apache.org/jakarta/JakartaBoardReport-February2007
> 
> "The code grant for the not yet commons SSL (formerly named
> commons-ssl), has been completed, so we can progress to having a vote
> where SSL should end up on general and based on that result take the
> correct incubator path (legal / full incubation)."
> 
> Let's just get this vote out of the way, and then we can move on to
> other issues in the appropriate venue (HttpComponents, or Sandbox, or
> Incubator).
> 
> My original proposal to "jakarta-general" about the project is here:
> http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html
> 
> Yesterday I released "not-yet-commons-ssl-0.3.7".  Changes described
> at the bottom of this email.  My intention is for 0.3.7 to be the last
> release outside of Apache.
> 
> 
> By the way, there's one undocumented feature of common-ssl that's been
> quite fun:
> 
> http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html
> 
> 
> :-)
> 
> 
> yours,
> 
> Julius
> 
> ps.  My vote is:
> 
> [+0] - Abstaining because I'm too much of a newb to really understand
> what I'm voting for.
> 
> 
> On 2/23/07, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
>> On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote:
>> > not-yet-commons-ssl-0.3.7 released!
>> >
>> > http://juliusdavies.ca/commons-ssl/download.html
>> >
>> >
>>
>> Hi Julius,
>>
>> What are your plans regarding not-yet-commons-ssl? Is there anything
>> still blocking the incubation process? There are already two Apache
>> projects (HttpComponents and Synapse) that can potentially benefit from
>> collaboration with not-yet-commons-ssl. So, there is a lot of interest
>> in seeing things moving forward.
>>
>> Oleg
>>
>>
> 
> Features as of not-yet-commons-ssl-0.3.7:
> 
> 1. useStrongCiphers() used by default.
> -
> 40 bit and 56 bit ciphers are now disabled by default. To turn them
> back on call useDefaultJavaCiphers().
> 
> 
> 2. addAllowedName() adds some flexibility to the CN verification.
> -
> Here's a code example using "cucbc.com" to connect, but anticipating
> "www.cucbc.com" in the server's certificate:
> 
>  SSLClient client = new SSLClient();
>  client.addAllowedName( "www.cucbc.com" );
>  Socket s = client.createSocket( "cucbc.com", 443 );
> 
> This technique is also useful if you don't want to use DNS, and want
> to connect using the IP address.
> 
> 
> 3. SSLServer can re-use a Tomcat-8443 private key if running from inside
> Tomcat.
> -
> SSLClient server = new SSLServer();
> server.useTomcatSSLMaterial();
> 
> 
> 4. RMI-SSL support improved.
> -
> Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server
> sockets. Anonymous server-sockets (port 0) will always be set to port
> 31099. Analyzes the server certificate CN field and tries to set
> "java.rmi.server.hostname" to something compatible with that. Probably
> the only free implementation around that does a good job on the
> hostname verification!
> 
> 
> 5. KeyMaterial constructor blows up earlier.
> -
> If a JKS or PKCS12 file is provided that isn't going to work (e.g. no
> private keys), the KeyMaterial constructor throws an exception right
> away.
> 
> 
> 6. getSSLContext() now available to help inter-op with Java 5

[PROPOSAL] Create [EMAIL PROTECTED] mailinglist..

[Martin van den Bemt]

Hi everyone,

For various reasons there are a couple of projects at Jakarta that currently 
don't have any
development community. I like these projects to have dev discussion move to 
[EMAIL PROTECTED],
so it is easier for us to give oversight and guide newbies to learn the Apache 
way.
The initial projects I have in mind are : oro, regexp and ecs (others are 
welcome too btw).

This idea sparked from 1) my thread about reviving inactive projects 2) the 
thread on ecs-user on
who is still using ECS and looking at the content it could very well be that 
some people will start
sending patches in the near future.

The strength of this list should be is that with a lot of hands the chance that 
nothing happens when
there is activity is minimized. If someone has an hour to spare, it could very 
well be useful to
apply a patch and mentor people.

I would kind of expect that every PMC member is also subscribed to this list 
(in the same way it is
kind of expected that you are subscribed to general), but as always cannot 
force anyone ;)

Since I don't like to extend the scope of the general list, I prefer dev 
discussion not to take
place there.

Thoughts ?

Mvgr,
Martin

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

Re: reinstatement

[Martin van den Bemt]

Send a request to infrastructure or root at apache dot org to have that done.. 
( I don't have karma
to do that)

Mvgr,
Martin

Michael Oliver wrote:
> Perhaps then it is just password needing to be reset.
> 
> 
> Michael Oliver
> Cell: 518-378-6154
> Skype: MikeOliverAZ
> Phone:702-866-9034
> 
> -----Original Message-
> From: Martin van den Bemt [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, March 03, 2007 6:23 AM
> To: Jakarta General List
> Subject: Re: reinstatement
> 
> What exactly is the problem ? You have karma on Jakarta so you should be
> able to commit...
> 
> Mvgr,
> Martin
> 
> Michael Oliver wrote:
>> Hi,
>>  
>> I am a committer on the slide project and have been inactive for more 
>> than six months and access is denied.
>>  
>> I now have several commits to make and need to be reinstated, 
>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> is my account.
>>  
>> Michael Oliver
>> Cell: 518-378-6154
>> Skype: MikeOliverAZ
>> Phone:702-866-9034
>>  
>>
>>
>> --
>> --
>>
>> -
>> 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: reinstatement

[Martin van den Bemt]

What exactly is the problem ? You have karma on Jakarta so you should be able 
to commit...

Mvgr,
Martin

Michael Oliver wrote:
> Hi,
>  
> I am a committer on the slide project and have been inactive for more
> than six months and access is denied.
>  
> I now have several commits to make and need to be reinstated,
> [EMAIL PROTECTED]  is my account.
>  
> Michael Oliver
> Cell: 518-378-6154
> Skype: MikeOliverAZ
> Phone:702-866-9034
>  
> 
> 
> 
> 
> -
> 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: [OT] Icons for Java application (JMeter)

[Martin van den Bemt]

Continuum has them..
See
http://svn.apache.org/repos/asf/maven/continuum/continuum-1.0.1/continuum-web/src/main/resources/images/

Mvgr,
Martin

sebb wrote:
> I'm looking for some icons suitable for use in a Swing JTree - so they
> need to be GIF or PNG (I don't think SVG works).
> 
> I need the following icons:
> 
> Success - perhaps a tick?
> Failure- perhaps a cross?
> 
> These are to be used on the tree entries to distinguish successful and
> unsuccessful samples.
> 
> At present the label is coloured red for failures, but this is not
> much use for colour-blind users (or indeed B+W printing).
> 
> There are lots of icon samples on the web, but I've not found one that
> is suitable.
> 
> Perhaps someone knows of some suitable icons already used by Apache
> products?
> 
> 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] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?

[Martin van den Bemt]

>>
>> Let's keep this statement your personal opinion on the fact that it is
>> not
>> relevant. I still like to
>> know the opinion of others.
> 
> 
> If you want opinions, don't use a vote to collect them. This is a vote
> thread, not an opinion thread. Votes within the ASF are for decision
> making,
> not opinion polls. Jakarta is well known, in a negative way, for being
> overly vote-happy, so we should be doing our best to confine our use of
> voting to things that really need to be voted on. That includes neither
> opinion polls or consensus building.
> 
> My statement was that the final destination of a project is not relevant
> for
> a vote on whether or not it should be accepted into the incubator. I
> consider that to be a simple fact about the way the incubator works, not an
> opinion.
> 

The difference of opinion here is that you see this as a vote about incubating 
ssl, which is simply
not our call. We can vote however on accepting ssl into Jakarta, which has the 
consequence that
Jakarta is going to be actively involved as a champion / sponsor role to have 
the Incubator accept
ssl. Say if the target is commons, we probably should have commons-ssl end up 
in the website of
commons, have Julius participate on the commons website, instead of having 
separate lists, separate
website and a separate PPMC and learning the commons way is pretty hard when 
you are actually not
integrated into the commons community to begin with.
We are talking about around 20 classes here and 1 new committer (afaik). What 
makes this case
special compared to eg webwork (came across this while wading through the 
incubator archives to find
similar scenario's) ?

Maybe it's just a different definition of the meaning of full incubation.
Things I want see solved during incubation here is (assuming commons is the 
target) :

- IP clearance (paperwork is done by the way)
- It contains crypto, so we probably need some legal advice on this (currently 
a discussion on legal
btw)
- Making sure Julius is here to stay (so preventing a new dead commons project)
- Getting enough support in commons, so it's not a one man project
- Everything takes place on the commons mailinglists (user and dev)
- Release votes needs to be the same as any other commons component, with the 
addition of an extra
incubator vote.
- Reuse of commons infrastructure, probably with the exception of svn (eg 
incubator svn and have
separate permissions, with the whole of jakarta being able to work there)

Thoughts welcome...

Mvgr,
Martin

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

Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?

[Martin van den Bemt]

Martin Cooper wrote:
> On 2/23/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>>
>> I prefer this vote to see where it should end up in Jakarta and based on
>> that result the path full
>> incubation / legal incubation is decided.
>>
>> So in my view the vote should be :
>>
>> [ ] Jakarta should sponsor (which effectively states we like to see the
>> code end up here)
> 
> 
> +1
> 
> [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP)
> 
> 
> No, it means that it still needs to find a Sponsor before it can be
> accepted
> into incubation. It says nothing about where it will end up after
> incubation
> or even if it will start incubation.
> 
> if accepted in Jakarta, it should end up in :
> 
> 
> This is not relevant. The final location of a project is not decided until
> it is ready to _exit_ incubation, so it's more than a little premature
> to be discussing this here.

Let's keep this statement your personal opinion on the fact that it is not 
relevant. I still like to
know the opinion of others. Main reason : it is very interesting to see to 
figure out what the exit
criteria should be for a small component like ssl (besides the IP stuff).
Would be nice to get Robert's view on this (I will start a discussion after the 
vote, so the vote
doesn't get too polluted). Could be that I am the only one seeing the 
difference during incubation
depending on the target within Jakarta, so if that's the case it's probably 
best for SSL that other
people step up as mentors and champions.

Mvgr,
Martin

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

Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?

[Martin van den Bemt]

Martin van den Bemt wrote:
> I prefer this vote to see where it should end up in Jakarta and based on that 
> result the path full
> incubation / legal incubation is decided.
> 
> So in my view the vote should be :
> 
> [X] Jakarta should sponsor (which effectively states we like to see the code 
> end up here)
> [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP)
> 
> if accepted in Jakarta, it should end up in :
> 
> [X] commons as a component
> [ ] httpcomponents as a component
> [ ] subproject directly under Jakarta
> [ ] integrate / merge code into project xxx (please replace x) (so not a 
> subcomponent of a project!)
> 
> And
> 
> [X] I am willing to mentor (you need to be on the Incubator PMC / Member of 
> the ASF)
> [ ] I want to get involved in coding
> [ ] No interest in getting involved.
> 
> 
> Reasoning :
> 
> 1) the first decides if Jakarta wants to sponsor this
> 2) we need to know the place it should end up in Jakarta (at least have some 
> kind of direction)
> 3) if no one is interested in getting involved or being a mentor (preferably 
> 3 mentors!), we can
> easily see if option 1 and 2 are viable at all.
> 
> The problem with the current vote is that I have to start yet another vote to 
> let us sponsor and
> where it should end up, best to do it in one go in my opninion...
> 
> So Martin and Ortwin could you please revote  ? (Sorry for the inconvenience)
> 
> Mvgr,
> Martin
> 
> Julius Davies wrote:
>> Hi, Jakarta-General,
>>
>> Let's vote on where to put this code!  Here's the code right now:
>>
>> http://juliusdavies.ca/commons-ssl/
>>
>> Forgive my newbieness; I hope these are the right options:
>>
>> [+1] Sub-module in Httpcomponents.
>> [+1] Sandbox.
>> [+1] Full Incubator.
>> [-1] "not-yet-commons-ssl" is not a good project for Apache because...
>>
>> I'm fine with majority rules, assuming there are no "-1" votes.
>>
>> Some background:
>>
>> http://wiki.apache.org/jakarta/JakartaBoardReport-February2007
>>
>> "The code grant for the not yet commons SSL (formerly named
>> commons-ssl), has been completed, so we can progress to having a vote
>> where SSL should end up on general and based on that result take the
>> correct incubator path (legal / full incubation)."
>>
>> Let's just get this vote out of the way, and then we can move on to
>> other issues in the appropriate venue (HttpComponents, or Sandbox, or
>> Incubator).
>>
>> My original proposal to "jakarta-general" about the project is here:
>> http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html
>>
>> Yesterday I released "not-yet-commons-ssl-0.3.7".  Changes described
>> at the bottom of this email.  My intention is for 0.3.7 to be the last
>> release outside of Apache.
>>
>>
>> By the way, there's one undocumented feature of common-ssl that's been
>> quite fun:
>>
>> http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html
>>
>>
>> :-)
>>
>>
>> yours,
>>
>> Julius
>>
>> ps.  My vote is:
>>
>> [+0] - Abstaining because I'm too much of a newb to really understand
>> what I'm voting for.
>>
>>
>> On 2/23/07, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
>>> On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote:
>>>> not-yet-commons-ssl-0.3.7 released!
>>>>
>>>> http://juliusdavies.ca/commons-ssl/download.html
>>>>
>>>>
>>> Hi Julius,
>>>
>>> What are your plans regarding not-yet-commons-ssl? Is there anything
>>> still blocking the incubation process? There are already two Apache
>>> projects (HttpComponents and Synapse) that can potentially benefit from
>>> collaboration with not-yet-commons-ssl. So, there is a lot of interest
>>> in seeing things moving forward.
>>>
>>> Oleg
>>>
>>>
>> Features as of not-yet-commons-ssl-0.3.7:
>>
>> 1. useStrongCiphers() used by default.
>> -
>> 40 bit and 56 bit ciphers are now disabled by default. To turn them
>> back on call useDefaultJavaCiphers().
>>
>>
>> 2. addAllowedName() adds some flexibility to the CN verification.
>> -
>> Here's a code example using "cucbc.com" to 

[VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?

[Martin van den Bemt]

I prefer this vote to see where it should end up in Jakarta and based on that 
result the path full
incubation / legal incubation is decided.

So in my view the vote should be :

[ ] Jakarta should sponsor (which effectively states we like to see the code 
end up here)
[ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP)

if accepted in Jakarta, it should end up in :

[ ] commons as a component
[ ] httpcomponents as a component
[ ] subproject directly under Jakarta
[ ] integrate / merge code into project xxx (please replace x) (so not a 
subcomponent of a project!)

And

[ ] I am willing to mentor (you need to be on the Incubator PMC / Member of the 
ASF)
[ ] I want to get involved in coding
[ ] No interest in getting involved.


Reasoning :

1) the first decides if Jakarta wants to sponsor this
2) we need to know the place it should end up in Jakarta (at least have some 
kind of direction)
3) if no one is interested in getting involved or being a mentor (preferably 3 
mentors!), we can
easily see if option 1 and 2 are viable at all.

The problem with the current vote is that I have to start yet another vote to 
let us sponsor and
where it should end up, best to do it in one go in my opninion...

So Martin and Ortwin could you please revote  ? (Sorry for the inconvenience)

Mvgr,
Martin

Julius Davies wrote:
> Hi, Jakarta-General,
> 
> Let's vote on where to put this code!  Here's the code right now:
> 
> http://juliusdavies.ca/commons-ssl/
> 
> Forgive my newbieness; I hope these are the right options:
> 
> [+1] Sub-module in Httpcomponents.
> [+1] Sandbox.
> [+1] Full Incubator.
> [-1] "not-yet-commons-ssl" is not a good project for Apache because...
> 
> I'm fine with majority rules, assuming there are no "-1" votes.
> 
> Some background:
> 
> http://wiki.apache.org/jakarta/JakartaBoardReport-February2007
> 
> "The code grant for the not yet commons SSL (formerly named
> commons-ssl), has been completed, so we can progress to having a vote
> where SSL should end up on general and based on that result take the
> correct incubator path (legal / full incubation)."
> 
> Let's just get this vote out of the way, and then we can move on to
> other issues in the appropriate venue (HttpComponents, or Sandbox, or
> Incubator).
> 
> My original proposal to "jakarta-general" about the project is here:
> http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html
> 
> Yesterday I released "not-yet-commons-ssl-0.3.7".  Changes described
> at the bottom of this email.  My intention is for 0.3.7 to be the last
> release outside of Apache.
> 
> 
> By the way, there's one undocumented feature of common-ssl that's been
> quite fun:
> 
> http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html
> 
> 
> :-)
> 
> 
> yours,
> 
> Julius
> 
> ps.  My vote is:
> 
> [+0] - Abstaining because I'm too much of a newb to really understand
> what I'm voting for.
> 
> 
> On 2/23/07, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
>> On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote:
>> > not-yet-commons-ssl-0.3.7 released!
>> >
>> > http://juliusdavies.ca/commons-ssl/download.html
>> >
>> >
>>
>> Hi Julius,
>>
>> What are your plans regarding not-yet-commons-ssl? Is there anything
>> still blocking the incubation process? There are already two Apache
>> projects (HttpComponents and Synapse) that can potentially benefit from
>> collaboration with not-yet-commons-ssl. So, there is a lot of interest
>> in seeing things moving forward.
>>
>> Oleg
>>
>>
> 
> Features as of not-yet-commons-ssl-0.3.7:
> 
> 1. useStrongCiphers() used by default.
> -
> 40 bit and 56 bit ciphers are now disabled by default. To turn them
> back on call useDefaultJavaCiphers().
> 
> 
> 2. addAllowedName() adds some flexibility to the CN verification.
> -
> Here's a code example using "cucbc.com" to connect, but anticipating
> "www.cucbc.com" in the server's certificate:
> 
>  SSLClient client = new SSLClient();
>  client.addAllowedName( "www.cucbc.com" );
>  Socket s = client.createSocket( "cucbc.com", 443 );
> 
> This technique is also useful if you don't want to use DNS, and want
> to connect using the IP address.
> 
> 
> 3. SSLServer can re-use a Tomcat-8443 private key if running from inside
> Tomcat.
> -
> SSLClient server = new SSLServer();
> server.useTomcatSSLMaterial();
> 
> 
> 4. RMI-SSL support improved.
> -
> Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server
> sockets. Anonymous server-sockets (port 0) will always be set to port
> 31099. Analyzes the server certificate CN field and tries to set
> "java.rmi.server.hostname" to something compatible with that. Probably
> the only free implementation

Re: Jakarta board Report February

[Martin van den Bemt]

I am actually maintaining that, although at a pace that makes you fall a sleep 
;)

Mvgr,
Martin

Niall Pemberton wrote:
> Previous Board reports have been archived here:
> 
> http://jakarta.apache.org/site/pmc/board-reports.html
> 
> Would be good to continue this IMO.
> 
> Niall
> 
> On 2/19/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>>
>> Jakarta Board Report
>>
>> Status
>>
>> This board report was mainly constructed by other people than me,
>> which is a big improvement (thanks everyone). I also moved the board
>> report to a fixed location on the wiki
>> (http://wiki.apache.org/jakarta/JakartaBoardReport-current), so it's
>> easier to locate for people. The code grant for the not yet commons
>> SSL (formerly named commons-ssl), has been completed, so we can
>> progress to having a vote where SSL should end up on general and
>> based on that result take the correct incubator path (legal /
>> full incubation).
>>
>> What is not completely clear for me at this point, is the board
>> report schedule. An extra report was requested (lack of commons
>> projects in the report). Reporting next month again will be a lot of
>> work, since my goal is to report on every subproject (even if there
>> is no or hardly any activity).
>>
>> Inactive projects
>>
>> Disclaimer : we have lot's of active projects !
>>
>> Definition list :
>>
>> Inactive project = a project that has no *developer* community.
>>
>> The Apache Way :
>>
>> To become committer on a project you have to earn that right, you
>> have to stand out, submit patches, show you care, learn the apache
>> way and have to get noticed by the current committers who can
>> nominate such a person.
>>
>> Problem :
>>
>> If that didn't happen enough in the past, it can happen that at a
>> certain point no developer community is active anymore.
>>
>> Which causes :
>>
>> A catch22 situation. Since there is no developer community, no one
>> is able to determine if people deserve to become a committer. Even if
>> you are monitoring such a list (such as I do for all Jakarta lists),
>> it is hard to determine if people deserve committership.
>>
>> Solution :
>>
>> The only thing we know for sure : inactive projects needs someone to
>> mentor the project to become active again. This goes for all possible
>> scenario's :
>>
>> 1. Actively support forks and when they show they are capable to work
>>on the project, get the code back (needs mentoring, grants, etc)
>> 2. More liberal in getting committers on board
>> 3. Actively following the user / dev lists and issue trackers to see
>>if there is someone ready for committer ship. (is the normal way,
>>although the focus here is not if patches etc are technically
>>correct)
>>
>> I like to prevent Jakarta becoming some kind of collection with
>> inactive project, so the first goal is preventing that this scenario
>> occurs on our current subprojects where possible. So I would like to
>> ask the current active developers to invest a little bit more time in
>> looking what others are doing.
>>
>> I think this discussion is also useful to have on the incubator list.
>> Releases
>>
>> * 13 February 2007 Commons Lang 2.3
>> * 13 February 2007 Commons IO 1.3.1
>> * 30 January 2007 Commons IO 1.3
>> * 30 December 2006 Commons Betwixt 0.8
>> * 30 December 2006 Commons VFS 1.0
>> * 19 December 2006 Commons SCXML 0.6
>>
>> Community changes
>>
>> New committers, pmc persons, asf members and departures.
>>
>> PMC Members
>>
>> * Yoav Shapira resigned from the PMC
>>
>> The following new commiters were voted in:
>>
>> * Yegor Kozlov (POI)
>> * Luc Maisonobe (Commons Math)
>> * Matt Benson (Commons JXPath)
>>
>> Infrastructure news
>>
>> Started to investigate the moderators we have and contacting all the
>> moderators asking if they are still active. If there are gaps, I will
>> try to fill the void by finding volunteers. This way we prevent that
>> lists aren't moderated.
>>
>> Subproject news
>>
>> Sections with a prefix of MvdB are notes added by the chair
>>
>> BCEL
>>
>> MvdB :
>>
>> Some user questions, further no action taken on the future of BCEL
>> (on the list is contacting the 2 currently exising forks out there,
>> to see if there is interenst in moving 

Re: [Jakarta Wiki] Update of "JakartaBoardReport-current" by RolandWeber

[Martin van den Bemt]

I've added it to the board template :)

Mvgr,
Martin

Apache Wiki wrote:
> Dear Wiki user,
> 
> You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for 
> change notification.
> 
> The following page has been changed by RolandWeber:
> http://wiki.apache.org/jakarta/JakartaBoardReport-current
> 
> The comment on the change is:
> Martin, you might want to update your template
> 
> --
>   
>   ''!FileUpload''
>   
> - ''!HttpClient''
> - 
>   ''IO''
>   
>   ''Jelly''
> @@ -105, +103 @@
> 
>    ECS 
>   
>    HttpComponents 
> +  ''including !HttpClient''
>   
>    JCD 
>   
> 
> -
> 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]

Jakarta board Report February

[Martin van den Bemt]

Jakarta Board Report

Status

This board report was mainly constructed by other people than me,
which is a big improvement (thanks everyone). I also moved the board
report to a fixed location on the wiki
(http://wiki.apache.org/jakarta/JakartaBoardReport-current), so it's
easier to locate for people. The code grant for the not yet commons
SSL (formerly named commons-ssl), has been completed, so we can
progress to having a vote where SSL should end up on general and
based on that result take the correct incubator path (legal /
full incubation).

What is not completely clear for me at this point, is the board
report schedule. An extra report was requested (lack of commons
projects in the report). Reporting next month again will be a lot of
work, since my goal is to report on every subproject (even if there
is no or hardly any activity).

Inactive projects

Disclaimer : we have lot's of active projects !

Definition list :

Inactive project = a project that has no *developer* community.

The Apache Way :

To become committer on a project you have to earn that right, you
have to stand out, submit patches, show you care, learn the apache
way and have to get noticed by the current committers who can
nominate such a person.

Problem :

If that didn't happen enough in the past, it can happen that at a
certain point no developer community is active anymore.

Which causes :

A catch22 situation. Since there is no developer community, no one
is able to determine if people deserve to become a committer. Even if
you are monitoring such a list (such as I do for all Jakarta lists),
it is hard to determine if people deserve committership.

Solution :

The only thing we know for sure : inactive projects needs someone to
mentor the project to become active again. This goes for all possible
scenario's :

1. Actively support forks and when they show they are capable to work
   on the project, get the code back (needs mentoring, grants, etc)
2. More liberal in getting committers on board
3. Actively following the user / dev lists and issue trackers to see
   if there is someone ready for committer ship. (is the normal way,
   although the focus here is not if patches etc are technically
   correct)

I like to prevent Jakarta becoming some kind of collection with
inactive project, so the first goal is preventing that this scenario
occurs on our current subprojects where possible. So I would like to
ask the current active developers to invest a little bit more time in
looking what others are doing.

I think this discussion is also useful to have on the incubator list.
Releases

* 13 February 2007 Commons Lang 2.3
* 13 February 2007 Commons IO 1.3.1
* 30 January 2007 Commons IO 1.3
* 30 December 2006 Commons Betwixt 0.8
* 30 December 2006 Commons VFS 1.0
* 19 December 2006 Commons SCXML 0.6

Community changes

New committers, pmc persons, asf members and departures.

PMC Members

* Yoav Shapira resigned from the PMC

The following new commiters were voted in:

* Yegor Kozlov (POI)
* Luc Maisonobe (Commons Math)
* Matt Benson (Commons JXPath)

Infrastructure news

Started to investigate the moderators we have and contacting all the
moderators asking if they are still active. If there are gaps, I will
try to fill the void by finding volunteers. This way we prevent that
lists aren't moderated.

Subproject news

Sections with a prefix of MvdB are notes added by the chair

BCEL

MvdB :

Some user questions, further no action taken on the future of BCEL
(on the list is contacting the 2 currently exising forks out there,
to see if there is interenst in moving development back to Jakarta.
Afaik Findbugs and AspectJ have forks.

BSF

MvdB :

They are currently planning for a 3.0 release and for jsr223 they
are investigating to get the TCK. Geir is in the process of
arranging things.

Cactus

MvdB :

Cactus development was stalled and recently Petar Tahchiev sent a
mail to the list, saying he had continued development of cactus on
https://mamouth.svn.sourceforge.net/svnroot/mamouth. I
(=Martin van den Bemt) am currently in the process of informing
Petar on what actions to take (eg Code Grants/CLA/CCLA) to move
development back to the cactus project. When the paperwork is there,
we will run the code base through the incubator (at a minimum legal).


Commons

Switching from Maven-1 to Maven-2 gets closer - we can now build the
website from Maven-2. Next we need to look at how we would do a
release under Maven-2 and whether it passes our requirements.

Key:

* Inactive - No activity, no one watching it. Candidate for dormancy.
* Maintenance - No activity, someone watching it.

There are thirty-two components in the Commons 'Proper', that is the
released components.

Attributes

Inactive - however the last release had an issue so a new release
ideally needs to be done.

BeanUtils

Maintenance. A 1.8.0 release is slowly being worked on. Struts were a
major user, howeve

List moderator cleanup..

[Martin van den Bemt]

Hi everyone,

Since I had reason to believe that not all lists are moderated (some mails are 
just not coming
through), I thought I do an "audit" on what lists are moderated by who.
I will mail all the moderators individually to ask if they are still active, in 
the mean while I
asked to be added as a moderator for the jcs lists, which don't seem to be 
covered atm (there is a
moderator, but unlikely to be active).

Mvgr,
Martin

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

Site update

[Martin van den Bemt]

Hi everyone,

I updated the site to have a link to apachecon amsterdam and messed up the 
style of the site :(.
By accident I committed a local change that shouldn't have ended up in 
subversion.
All fixed now, waiting for it to become live (just update 
/www/jakarta.apache.org on people.

I also fixed the mail2.html, where all links were broken (archives were all 
pointing the
mail-archives.eu.apache.org which is kind of broken :)

Mvgr,
Martin

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

Last call for board report additions!

[Martin van den Bemt]

Last call for board report additions, I will post it on Sunday..

The current board report "in progress" will always be at
http://wiki.apache.org/jakarta/JakartaBoardReport-current

Mvgr,
Martin

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

heads up

[Martin van den Bemt]

Doesn't seem much, but haven't done anything with mail since Wednesday, so I am 
seriously behind.
Will try to catch up during the weekend..

Mvgr,
Martin

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

Re: Howto revive inactive projects ?

[Martin van den Bemt]

Hi Julius (learning here :),

Thanx for the comprehensive and well thought out mail..

Julius Davies wrote:
> Thanks for your reply, Martin!
> 
> To reiterate (hopefully more clearly this time), I see two dilemmas
> and two problems:
> 
> Dilemma #1:
> --
> You can't stop people from forking.  Forking is the "lowest barrier"
> way for a committer-less community to revive an inactive project.  So
> should you fight the fork, or roll with the fork?  Keep in mind that
> forking itself is not an insignificant act!  To learn the code, create
> new code, setup a new SVN, host a new domain - these are all real
> work.  So I think a "fork" should be recognized as a sign of
> significant community interest in reviving the project.  A fork, while
> the "lowest barrier", is still not something to be dismissed.

Goal is not to stop forking. A lot of code is forked (even I do it, although 
normally not complete
codebases), although I like to prevent forking for the wrong reasons, which in 
this case means a
project that is inactive.

> 
> Dilemma #2 (Martin's dilemma)
> --
> To keep things in the family (avoiding the fork), you need a
> committer.  On an inactive project a committer cannot be created
> without lowering Apache's standards.  Lowering standards, while
> problematic in itself, is politically infeasible, since it debases the
> status of being a fully fledged "committer".  (Some people will not
> care about this, but some people will, and I think "@apache.org" email
> addresses are an important status symbol in the IT world, and not
> worth debasing.)  (If I may be bold, I would cry out to you all,
> "Don't be ashamed of the status!"  You have established an IT
> "peerage" of sorts, and it's quite miraculous to see it both community
> and meritocracy based!).

There are acutually 2 problems : 1 is reviving and 2 prevent projects from 
being inactive. Both can
be achieved without lowering Apache standards I think.

> 
> (The aside that lowering standards "is problematic in itself" points
> to other problems that I hope are obvious, and are perhaps as big a
> deal as any status issues mentioned above).
> 
> (I wonder if I love parentheses so much because I am a programmer?)
> 
> 
> Problem #1
> --
> Code developed outside Apache will not have Apache's strong guarantee
> that the code is not stolen, and is indeed available for use under
> ASL.  (As someone trying to donate "not-yet-commons-ssl" - let me tell
> you - Apache is serious about this stuff!).  So it's hard to bring any
> forked code back in.

It isn't that hard, just legal paperwork and a legal check (see
http://incubator.apache.org/ip-clearance/ip-clearance-template.html for more 
info)
You are kind of in a different spot, since you have an original work created by 
you (/ the company
you work for), which depending on where it will end up could require full 
incubation or just ip
clearance. The paperwork as far as Apache goes (for not-yet-commons-ssl) is 
already in place.
As said I will restart the discussion on this when your employer is happy.

> 
> Problem #2
> --
> Any solution that requires an existing committer become more busy than
> they already are will not work.  I find that existing committers are
> extremely busy.  Imagine a perfect solution where all that is needed
> is that an existing committer scratch their nose once.  I think such a
> solution will fail because committers (and contributors as well) are
> already too busy.

Ok what you are saying here is that reviving a project is effectively not 
possible. To notice new
committer "material" you have to invest some time, after a vote, you have to 
mentor them. Now let's
assume there is fork. When you want to bring the fork back, we need to do a lot 
more work than just
that, clear ip, vote to get the codebase back in and also do the same as 
getting a new committer on
board. So in the end it will mean twice as much work.

> 
> 
> My Solution
> --
> I think it's important to ride the community wave.  With inactive
> projects, the community has no committer, so I believe they are
> essentially forced into a fork in this case.  I think Apache should
> try to create a procedure that leverages as much of the existing
> committer-less community momentum as possible.  For inactive projects,
> try to become "fork friendly".

Or to become more friendly to people who want to get involved..

> 
> How much external code can the fork generate before it's time to bring
> it back into the family?  I figure 95% - 99% of the pre-existing code
> will remain.  A simple diff will make this apparent.  Full incubation
> is too heavy when you know that 95% of the code is already pure Apache
> already!

It doesn't matter if the code new is 0.1% or 50%. The amount of work is the 
same (though if you want
to review every change, the 50% thing takes more time of course)

Re: Howto revive inactive projects ?

[Martin van den Bemt]

Hi Julies,

Julius Davies wrote:
> Hi, Martin, and Everyone,
> 
> If someone is interested in taking over a truly inactive project,
> maybe they should fork and start their own SVN repository from their
> own domain.  The person should make it clear that their fork is in no
> way sanctioned by Apache.

That's a requirement, since it cannot be called the same as the Apache project 
name.

> 
> The only responsibility Apache might have in this situation, if so
> inclined, is to include a link from "[inactive-project].apache.org" to
> the fork, with some warnings that Apache's higher standards with
> respect to intellectual property are not in effect if you follow the
> link.

Don't agree here. Our current code base is our responsibility, even though 
there are no active
developers. Better information on the project status could be useful however.

> 
> If the fork proves popular, and the person wants to bring it back into
> the family, the person could write an email to Jakarta-General asking
> to be nominated, become a committer, and then merge the fork back in.

They will have to come through the incubator to come back to us, because of 
legal issues. The
problem most of the time that there isn't even someone asking to take over.. A 
fork may also not use
 our project name. So I prefer to get momentum back here :)

> 
> I'm assuming that a reactivated project with only one committer is
> still better than an inactive one with none  I'm also assuming that
> the majority of "inactive" projects are smaller ones which probably
> only had one main committer / benevolent-dictator in the first place:
> 
> http://blog.generationjava.com/roller/bayard/entry/enterprise_communities_episode_2
> 
> 
> 
> Commons is a very interesting case study here. Here's a pretty obvious
> white elephant - nearly every Commons component is running under the
> dictator model. You can point to any component and as long as it's
> active, it's "So and so's" baby.
> 
> 
> Martin, can you provide some example projects that are running into
> this catch22?  Is it quite a rare situation?

Slide is the current case at hand, which is far from a small component (and has 
quite a complex code
base from what I understood). Currently we have one committer there who is 
still learning his way
into the code base (please correct me Antoine if this is a false statement).

Cactus has a bit of the scenario you described btw (external code), but I 
prefer people working
here, instead of forking, so people can see the project is alive and no legal 
stuff needs to be
dealt with when returning the code.

Another project is BCEL, which actually has got 2 forks.

So it's not really a rare scenario and could surface any time when there aren't 
enough committers
left to get new people aboard.


Mvgr,
Martin

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

Howto revive inactive projects ?

[Martin van den Bemt]

Hi everyone,

Moving this from the private list to general (this is actually a spin of from a 
thread about adding
a committer to an inactive project, hence that it was on private).

Definition list :

Inactive project = a project that has no *developer* community.

The Apache Way :

To become committer on a project you have to earn that right, you have to stand 
out, submit patches,
show you care, learn the apache way and have to get noticed by the current 
committers who can
nominate such a person.

Problem :

If that didn't happen enough in the past, it can happen that at a certain point 
no developer
community is active anymore.

Which causes :

A catch22 situation. Since there is no developer community, no one is able to 
determine if people
deserve to become a committer. Even if you are monitoring such a list (such as 
I do for all Jakarta
lists), it is hard to determine if people deserve committership.

Solution :

I don't have one specifically :)
Part of the solution is always that a project needs a kind of mentor that is 
willing to invest time
in a project, teach the Apache way, etc..

Let's come up with a way to get around the catch22 scenario..

Mvgr,
Martin




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

Re: Nightly builds docu?

[Martin van den Bemt]

Gump doesn't build against the versions of the dependencies specified in the 
pom / project.xml, but
builds against the latest of everything, which could mean other trouble if you 
are using those jars.

Mvgr,
Martin

Andrew C. Oliver wrote:
> Ummwhy not out of Gump?
> 
> Phil Steitz wrote:
>> 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]
>>
>>
>>
>>   
> 
> 

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

Re: My svn account

[Martin van den Bemt]

You received Joes mail ?

Mvgr,
Martin

Andrew C. Oliver wrote:
> [EMAIL PROTECTED] :cat /usr/local/bin/svnpasswd
> #!/bin/sh
> echo "Please visit https://svn.apache.org/change-password";
> 
> 
> robert burrell donkin wrote:
>> On Wed, 2007-01-10 at 16:44 -0500, Andrew C. Oliver wrote:
>>  
>>> IIRC, this is my 4th attempt to resolve this (I try like every 3-4
>>> months).  I would like to commit something.  My SVN account is not
>>> working.  per the instructions off the SVN page I emailed [EMAIL PROTECTED] 
>>>  I
>>> got no response.  I am still able to log in to people.apache.org.
>>> 
>>
>> svnpasswd...?
>>
>> - robert
>>
>>
>>
>> -
>> 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: My svn account

[Martin van den Bemt]

:) Can you give me the error that you are getting, so I can ping infra with 
something specific. I
checked your account in the svn authorization and couldn't find any mistakes 
there, so probably has
to do with your password setting.

Mvgr,
Martin

Andrew C. Oliver wrote:
> IIRC, this is my 4th attempt to resolve this (I try like every 3-4
> months).  I would like to commit something.  My SVN account is not
> working.  per the instructions off the SVN page I emailed [EMAIL PROTECTED]  
> I got
> no response.  I am still able to log in to people.apache.org.
> 
> Suggestions for resolution?  Account name: acoliver.  Any help would be
> appreciated.  I will consider requests for bribes.
> 
> -andy
> 

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

Re: A chart/graph Library suite

[Martin van den Bemt]

Geir Magnusson Jr. wrote:
> 
> On Jan 7, 2007, at 8:55 AM, J.Pietschmann wrote:
> 
>> Senthil S wrote:
>>> Expecting a chart/graph making library from Apache
>>> that is similar to jfreechart and has enhanced features to create
>>> live and interactive graphs.
>>
>> The question is: why do you think there should be another
>> charting/graphing library? Do you have problems with the
>> JFreeChart license (LGPL)?
> 
> Wasn't it a BSD license before?

Are you confusing it with JChart maybe ?

Mvgr,
Martin

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

Re: POI TLP -- constructively

[Martin van den Bemt]

Thanx for your reply :) See inline for one comment..

Nick Burch wrote:
> On Mon, 18 Dec 2006, Martin van den Bemt wrote:
> 
> What I'm not a fan of are the "one user and one dev list for jakarta" type
> proposals. If the option was that, or TLP, I'd start writing the TLP
> supporting docs right now. Oh, but that's not an invition to suggest it,
> just to get us out ;-)
> 

This wasn't being proposed, but something along those lines is (probably) going 
to be proposed for
at least some Jakarta subprojects (you could think of ORO, Regexp, ECS). But 
those project actually
have about 3 messages a month combined.. But I will wait with new proposals 
till the next year.

Mvgr,
Martin

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

Re: POI TLP -- constructively

[Martin van den Bemt]

Need to add here that for the TLP Proposal you also need a vote from Jakarta..
I'll try to shut up now :)

Mvgr,
Martin

Martin van den Bemt wrote:
> See inline.
> 

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

Re: POI TLP -- constructively

[Martin van den Bemt]

Is this just your proposal or do other POI committers back this up ? (probably 
in the text, but not
as clear as I like it to be).
If poi committers agree with this proposal, I like to "hear" them :)

Mvgr,
Martin


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

Re: POI TLP -- constructively

[Martin van den Bemt]

See inline.

Andrew C. Oliver wrote:
> 
> It is fair to say that not many POI people participate in Jakarta. 
> However, to add perspective we never joined the "Jakarta as it is" -- we
> joined Jakarta as it was...and one day this formed around us.  It is
> fair to criticize our build...it is pretty rusty and yucky.  I do
> however thing focusing too much on it is a bit well...mean.  Nick has
> been doing a great job and a lot of work.  (I on the other hand will
> have to merge my patches into SVN before I can even commit them since
> they're off of CVS :-P ).  However it was his first release.  Moreover,
> Apache's "release policies" have evolved considerably since the last
> official release and none of us have a valid signed key...that needs to
> be rectified (laziness, don't like conventions where all the cool key
> signing parties).  We're not the only one's guilty of kinds of neglect. 
> Our own Marc Johnson (who cofounded the project) has been extremely
> frustrated at the lack of responsiveness in getting his access/etc in
> order and no one at POI seems to be able to jerk the right chain in
> Apache to make that happen (and I think he requested from this PMC with
> no effect).  So much that he's given up!

First of all : Nick is not the one that got blamed and was given credit for the 
good work he is
doing at POI. The real point here was oversight, which sparked the idea of 
mentoring.

I didn't have a clue about Marc Johnson to be honest. And POI shouldn't jerk 
the right chain the VP
of Jakarta should do that, only this VP didn't know about Marc Johnson :) 
(maybe just bad reading on
my part though). I prefer to restart a vote to get him aboard, or you can do 
the honors yourself
(meaning POI) when POI is TLP (although if you take that path that process will 
take even longer)

> 
> In any case, legal issues aside (which have to a good degree abated, but
> 

Let's leave that aside for the moment.

> I therefore propose this:
> 
> * Jakarta PMC has the responsibility to not call more votes on
> restructuring POI during the next X months.  (Access or otherwise)

We need to set a date on this (see below about the board). BTW this was the 
only vote that was in my
  planning to be called, so no other votes will be called :) The steps after 
this vote was passed,
wouldn't need any votes (as far as I can oversee now).

> 
> * POI committers have responsibility for achieving the proper oversight
> procedures and putting out a new release in the next X months

That is what every project does / should do. The problem was that this was not 
happening. As Stephen
already said, the Jarkarta PMC (and me personally) are responsible for whatever 
you do at POI  as
long you are at Jakarta. So with vote results, the actual release, new 
committers and other issues,
you need to inform the PMC, so they have the ability to check that everything 
is ok.
(just want to add this specifically, although I don't think you meant to 
specifically exclude this)

> 
> * POI committers have responsibility for putting together a TLP proposal
> and working out a consensus.

Agreed. Maybe we should poll the board if they have any conditions, since they 
are the actual body
that needs to approve the establishment of the POI Project. I'll ping them and 
see if they have time
to talk about this on Wednesday.

I'll let everyone know if there is anything to report from that front.


Mvgr,
Martin

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

Re: [VOTE] Remove POI svn restrictions.

[Martin van den Bemt]

If you are lost in bad sentences let me know :)
Forgot to proof read :(

Mvgr,
Martin

Martin van den Bemt wrote:
> 
> Avik Sengupta wrote:
>> I "dont care" about this vote (any more). I do care deeply about POI. I
>> do care about Apache and Jakarta. I resent the opposite presumption on
>> less than rock-hard grounds, because it is a pretty big accusation.
> 
> As noted in my analyses, I stated that I could be misinterpreting things.
> 
>> The fact that the POI and remaining jakarta communties are separate is a
>> FACT. Most people on this thread seems to have turned it into a
>> JUDGEMENT. If that does not gel well with what the 'oversight'
>> requirements, we need to find a way to work WITH the community, rather
>> than attack it.
> 
> See my reply to the board report (where you stated the wording was harsh).
> 
>> All open source project projects contributors go thru highs and lows of
>> contribution. Commiters come and go, some permanently, some temporarily.
>> (I recall reading a well written account of this from either Brian or
>> Stefano.. cant remember... anyone have a link). At POI, we're lucky
>> enough to have fresh blood coming in at regular intevals (as with most
>> open source projects, usually from nowhere, surprising you with their
>> commitment and great code..). Once again, we need to work with this
>> phenomenon, rather than condemn the whole project on that basis.
> 
> Condemning the project isn't what my goal is. And I think I made clear in 
> other mails that POI is
> pretty healthy with development, user base, etc. (Since I am not a user of 
> POI, I cannot judge it
> technically, although I assume you wouldn't have any users if it was 
> technically bad).
> 
>> The charge of insularity can go both ways. This thread is only about SNV
>> access. Can I not ask how many of the indignant correspondents on this
>> thread have taken the effort to come and help us get things right on the
>> poi dev lists? However, that's an argument that wont get us anywhere, so
>> lets not go down that path.
> 
> There were efforts in the past (see my board report reply) and I was thinking 
> of taking a different
> approach, which I described in the board report too.
> 
>> So in reply to every other offer of help, welcome! But I dont
>> understand, why do people want to  be an officially anointed 'mentor'
>> before helping out? I thought the Apache way was about  the 'doing' ...
>> he who does ... etc.  Please join the POI dev lists, and show us where
> 
> I joined the dev and user list before I became VP. And I thought hey the vote 
> thread isn't finished
> yet. Hence my e-mail to poi / private list about the release. After that 
> offer you could have asked
> for help (which was offered) and state "we are on it" or something (about the 
> release itself not
> being checked).
> 
>> we go wrong. We'd even instituted a policy to open the svn access to all
>> jakarta committers for only asking.
> 
> If you read this thread Andy gave a very different explanation of this policy 
> to me (although I
> could have misread him).
> 
>> Permit me to get personal to illustrate my point. When Henry noticed a
>> few issues with the release, he wrote back saying what they were. Some
>> we've pushed back, other's we've promised to fix, and in the meanwhile,
>> he's offered to fix some of them himself, an offer that's been very
>> gratefully accepted.
> 
> I read the thread.
> 
>> This thread, on the other hand, has degenerated into complete POI
>> bashing. Once again, I'd be happy to discuss the merits of this svn
>> proposal... its the subsequent bashing that completely baffles me.
> 
> Just speaking for myself here : I just wanted to open up svn karma as a first 
> step to improve
> things. Maybe it should have been the last vote in the process. When there 
> was asked about the
> reasoning behind the vote, I just added the same thing I already said in the 
> mail about the release
> (about PMC members giving oversight) and trying to get to bounce the ball 
> back to the project to get
> some answers on eg the legal issue, which still remains partially unanswered.
> 
> If POI bashing is what I did, my apologies, although after rereading the 
> thread, the negativity
> comes from both sides and I also seen a lot of messages with positive 
> attitude, so let's focus on
> that :)
> 
>> Finally Martin, you say "If you have anything positive to
>> contribute..."; dont know if you mean me personally or the project as 

Re: [VOTE] Remove POI svn restrictions.

[Martin van den Bemt]

Avik Sengupta wrote:
> I "dont care" about this vote (any more). I do care deeply about POI. I
> do care about Apache and Jakarta. I resent the opposite presumption on
> less than rock-hard grounds, because it is a pretty big accusation.

As noted in my analyses, I stated that I could be misinterpreting things.

> 
> The fact that the POI and remaining jakarta communties are separate is a
> FACT. Most people on this thread seems to have turned it into a
> JUDGEMENT. If that does not gel well with what the 'oversight'
> requirements, we need to find a way to work WITH the community, rather
> than attack it.

See my reply to the board report (where you stated the wording was harsh).

> 
> All open source project projects contributors go thru highs and lows of
> contribution. Commiters come and go, some permanently, some temporarily.
> (I recall reading a well written account of this from either Brian or
> Stefano.. cant remember... anyone have a link). At POI, we're lucky
> enough to have fresh blood coming in at regular intevals (as with most
> open source projects, usually from nowhere, surprising you with their
> commitment and great code..). Once again, we need to work with this
> phenomenon, rather than condemn the whole project on that basis.

Condemning the project isn't what my goal is. And I think I made clear in other 
mails that POI is
pretty healthy with development, user base, etc. (Since I am not a user of POI, 
I cannot judge it
technically, although I assume you wouldn't have any users if it was 
technically bad).

> 
> The charge of insularity can go both ways. This thread is only about SNV
> access. Can I not ask how many of the indignant correspondents on this
> thread have taken the effort to come and help us get things right on the
> poi dev lists? However, that's an argument that wont get us anywhere, so
> lets not go down that path.

There were efforts in the past (see my board report reply) and I was thinking 
of taking a different
approach, which I described in the board report too.

> 
> So in reply to every other offer of help, welcome! But I dont
> understand, why do people want to  be an officially anointed 'mentor'
> before helping out? I thought the Apache way was about  the 'doing' ...
> he who does ... etc.  Please join the POI dev lists, and show us where

I joined the dev and user list before I became VP. And I thought hey the vote 
thread isn't finished
yet. Hence my e-mail to poi / private list about the release. After that offer 
you could have asked
for help (which was offered) and state "we are on it" or something (about the 
release itself not
being checked).

> we go wrong. We'd even instituted a policy to open the svn access to all
> jakarta committers for only asking.

If you read this thread Andy gave a very different explanation of this policy 
to me (although I
could have misread him).

> 
> Permit me to get personal to illustrate my point. When Henry noticed a
> few issues with the release, he wrote back saying what they were. Some
> we've pushed back, other's we've promised to fix, and in the meanwhile,
> he's offered to fix some of them himself, an offer that's been very
> gratefully accepted.

I read the thread.

> 
> This thread, on the other hand, has degenerated into complete POI
> bashing. Once again, I'd be happy to discuss the merits of this svn
> proposal... its the subsequent bashing that completely baffles me.

Just speaking for myself here : I just wanted to open up svn karma as a first 
step to improve
things. Maybe it should have been the last vote in the process. When there was 
asked about the
reasoning behind the vote, I just added the same thing I already said in the 
mail about the release
(about PMC members giving oversight) and trying to get to bounce the ball back 
to the project to get
some answers on eg the legal issue, which still remains partially unanswered.

If POI bashing is what I did, my apologies, although after rereading the 
thread, the negativity
comes from both sides and I also seen a lot of messages with positive attitude, 
so let's focus on
that :)

> 
> Finally Martin, you say "If you have anything positive to
> contribute..."; dont know if you mean me personally or the project as a
> whole, I find that a wee bit offensive... sorry if I'm misunderstanding.
> POI is in active development, used by thousands , 

Never disputed that, I even said that in the message you are replying to. I 
wanted to make clear
with that statement (the positive part) that in that respect the project is 
doing more than well
(which I stated in other parts of the thread as well). I was kind of missing 
that in the responses
from, in this case, you.

it doesn't need a
> mandate from the PMC to be successful project, does it?

It does need a mandate to be a successful project, which is the thing I am 
trying to solve here,
that most requests/vote announcements don't get a response is because the vote 
and release is
because we have lazy consensus

Re: [VOTE] Remove POI svn restrictions.

[Martin van den Bemt]

Martin van den Bemt wrote:
>> -1 from me.
>>
>> Harmony doesn't let anyone commit on their project unless they they
>> sign a statement saying they haven't looked at Sun's source code[1].
>> AFAIK this is a similar issue and the POI policy [2] is designed to
>> protect POI, which as a user of POI is a good thing IMO. Even if this
>> fear is actually unfounded seems like a sensible policy to err on the
>> side of caution.
> 
> Just FYI, the policy doesn't mean anything legally, so it doesn't help 
> anyone. We have the ICLA that
> covers that. Keeping POI SVN closed, is as far as I could see, just based on 
> the assumption that it
>   means something. Besides that if this is a policy of some kind, where are 
> the records ?

Ouch rereading this I meant : The POI policy of course :) (in case it is 
misread)

Mvgr,
Martin

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

Re: [VOTE] Remove POI svn restrictions.

[Martin van den Bemt]

> So.. I think we need to:
> 
> 1) Get the fixed POI release out. Fixed source headers, vote on the
> files etc.
> 
> 2) Sort out the legal statement so that it's more official and
> organized (copying Harmony seems good). While everything I'm hearing
> when I ask legal-internal, legal vp, secretary etc (and same for
> Martin afaik) says we don't _have_ to do anything; I can see the
> points of the arguments for playing it safe. Effectively it's Jakarta
> PMC policy rather than legal requirement so we need to make it so.
> Apologies again to Andy for suggesting the legal statement was a
> policy he initiated rather than ancient and lost Jakarta PMC policy.

We definitely need to do something with that, but just solving it at the PMC 
level, doesn't help.
I am not in favor of gathering useless documents, so if we come up with 
something it actually has to
*mean* something legally, else we are just keeping books to keep books (even 
though I am from the
Netherlands, where we like bureaucracy, doesn't mean that I like it).

Mvgr,
Martin

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

Re: [VOTE] Remove POI svn restrictions.

[Martin van den Bemt]

Tetsuya Kitahata wrote:
>> [+1] Open up POI svn commit access.
>> [-1] Don't open POI svn commit access, because...
> 
> As long as the ASF (entity)/ Jakarta PMC have an "WILL" to protect
> and can protect the developers from the Legal Issues,
> I am willing to put +1 to this vote.

The biggest problem is that if we need protection, there is currently nothing 
in place (even though
you need to swear something). There are no records, no signed documents and 
such thing needs to be
organised at a PMC / Apache level.

> 
> -- I, personally, hope I can live happily and peacefully
> in this wonderful jakarta land (and the apache land).

+1 to that ;)

> 
> -- Tetsuya <[EMAIL PROTECTED]>
> 
> P.S.
> Mvgr> Don't forget the vote in March where everyone voted +1
> Mvgr> except the POI committers.
> Seems that I could not catch up this thread (in [EMAIL PROTECTED] / March)
> at that time. Sorry.
> 

http://marc.theaimsgroup.com/?l=jakarta-general&m=114344584424864&w=2 is the 
start of the thread / vote.

Mvgr,
Martin

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

Re: Board Report December

[Martin van den Bemt]

Just a reminder : the board report was written by me (completely) and the 
feeling is something I
have and doesn't necessarily mean the whole of Jakarta agrees with that. The 
board is aware that it
is my personal report.

Don't forget that in the first place this feeling (/ observation of this 
disconnect) is expressed by
POI people themselves (the complete thread) and was offered help by Henri (at 
that time VP Jakarta)
to help fix the situation :
http://www.mail-archive.com/poi-dev@jakarta.apache.org/msg11492.html.
The vote for Nick to be added to the PMC, didn't give me a good signal either. 
It showed that
Jakarta PMC members representing POI had a hard time to vote, probably causing 
that (almost) no one
at Jakarta felt the need to vote or invest energy to see who Nick is. Since I 
don't believe people
feel that Nick shouldn't be on the PMC shows that there is a disconnect between 
Jakarta and POI.
If you add that with the svn karma exception with the legal NDA stuff (which 
isn't something that
the PMC is officially aware of), the release vote withouth result, not 
notifying the pmc of the
release, not sending mail to eg announcements of release, not adding the 
releases to the main
jakarta page, you can probably see the reason for my feeling that POI is not 
part of Jakarta or Apache.

That being said : I don't have any doubts that the intentions are good and we 
are happy to help out,
but it helps to be proactive. A good start would accepting Marks offer :)



Mvgr,
Martin

Rainer Klute wrote:
> Avik Sengupta schrieb:
>>> It feels like they are acting as a separate entity in Jakarta and
>>> even the ASF itself
>> Let me put on record my severe objection to this statement.
> 
> Yes, the wording is quite harsh. However, following the arguments in the
> POI thread, we indeed seem not to act as we should - be it
> deliberately or not. I must admit I didn't follow the Apache politics
> closely in the past for the lack of time, but it seems we have to invest
> some time to get back on track. I am sure Apache fellows will help us by
> pointing us into the right direction.
> 
> Best regards
> Rainer Klute
> 
>Rainer Klute IT-Consulting GmbH
>   Dipl.-Inform.
>   Rainer Klute E-Mail:  [EMAIL PROTECTED]
>   Körner Grund 24  Telefon: +49 172 2324824
> D-44143 Dortmund   Telefax: +49 231 5349423
> 
> OpenPGP fingerprint: E4E4386515EE0BED5C162FBB5343461584B5A42E
> 
> 

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

Re: [Jakarta Wiki] Trivial Update of "JakartaBoardReport-March2007" by RolandWeber

[Martin van den Bemt]

Feel free to remove it from commons and add it to HttpComponents. It was just a 
dumb copy & paste
from the commons webpage :) While you are at it, you could also add this to the 
template (+ httpcode
and httpasync)

Mvgr,
Martin

Apache Wiki wrote:
> Dear Wiki user,
> 
> You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for 
> change notification.
> 
> The following page has been changed by RolandWeber:
> http://wiki.apache.org/jakarta/JakartaBoardReport-March2007
> 
> The comment on the change is:
> HttpComponents project is responsible for maintaining Commons HttpClient
> 
> --
>   
>   ''!FileUpload''
>   
> - ''!HttpClient''
> + ''!HttpClient'' - see !HttpComponents project below
>   
>   ''IO''
>   
> 
> -
> 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]

Board reports.

[Martin van den Bemt]

Hi everyone,

The official way board reports should be handled has 2 parts : 1 part that is 
edited by the the
committers (= the people who know best about there projects) and after that the 
VP can add his
personal notes to the report.
So starting from now I would like to see that people add the things they want 
in the report to this
page :
http://wiki.apache.org/jakarta/JakartaBoardReport-March2007

Some things need to be in the board report :

- New committers
- New PMC Members
- Releases (under the release section at the top) and a more detailed 
explenation of the release
under the project section (not too detailed please, a summary will do).

Besides that I would also like to see feedback for individual commons 
components (in proper).
Especially interesting is the developer involvement and the user list 
interaction over the last 3
months.

If you want to share anything else that you think is important for the board to 
know, please do so
at above page.

Thanx for your help :)

Mvgr,
Martin

PS There are more subprojects with subprojects, besides commons, though eg 
Taglibs has only 2 or 3
components with activity. I leave that to the respective projects to decide if 
a distinction in
subprojects is needed, although it would be appreciated that you at least 
identify that there are
subprojects in your projects.

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

Re: [VOTE] Remove POI svn restrictions.

[Martin van den Bemt]

> made a proposal to promote POI now, I would expect the board
> to reject it and tell us "make POI work in Jakarta before you
> promote it to TLP".

That is was my feeling as well, but I understood from the board that they 
rather prefer that things
are not hidden in subprojects, which is something that can easily happen with 
big projects like
Jakarta (and I can imagine that no one actually had any real idea of the number 
of projects over
here). Based on that I started with this report giving information about all 
projects, so they still
have the opportunity to intervene. This also means that board reports should be 
more open and
preferably identify issues and problems, as well as the positive things 
happening. We should make
the job easier for the board to determine if Jakarta is healthy.


Mvgr,
Martin


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