Re: [ALL] Volunteers for a Math IPMC?

2016-06-18 Thread Matt Benson 
On Jun 18, 2016 2:05 PM, "Gilles"  wrote:
>
> On Sat, 18 Jun 2016 11:00:34 -0700, Ted Dunning wrote:
>>
>> On Sat, Jun 18, 2016 at 4:29 AM, Gilles 
>> wrote:
>>
>>> ...
>>> I'm asking, again, whether I need to initiate a VOTE that would allow me
>>> to set up a workspace ("git", etc.) and transfer some code from CM over
>>> there.
>>>
>>
>> Nothing is stopping you from setting something up.  Github is usually the
>> easiest way.
>>
>> It doesn't sound like that is what you want, however. I don't understand
>> why not.
>
>
> And I don't understand that Apache would indeed prefer that code be forked
> rather than evolved here...
>
>
>>> It may be that incubation is a good thing for Commons Math, but it
doesn't

 seem valid to say that incubation is necessary because CM is being
kicked
 out of Commons.

>>>
>>> Never said so.
>>>
>>
>> Hmm... I must have misunderstood the comment about CM not being
interested
>> in hosting "these components".
>
>
> Commons is NOT interested in hosting the new components.
> That much was made clear in Matt Benson's last post. [Maybe not
cross-posted
> to the incubator's ML.]
>

I am one person. Personally I don't understand what is so offensive to you
about retaining a hierarchical level between Commons and math-focused
artifacts; I simply feel that a preponderance of math-focused components
dilutes the Commons "brand."

br,
Matt

>
>>> There is a confusion here: *I* say that CM is dead.
>>>
>>
>> Strong words. Such statements are often frustrating to others.
>
>
> Not strong, just factual.
>
> Maybe it will be revived in the future.
> Until then, I proposed to *do* something while the others seem to only
> want to wait.
> Strange that the latter proposal seems more acceptable than mine.
>
>
>> It does
>> sound like the community has dwindled, perhaps beyond repair.
>
>
> It sure sounds like it.
> In fewer words: CM is dead.
>
>
>> The development situation *will* change because the context *has* changed
>>>
>>> (unsupported code). CM cannot go on as it did before the fork.
>>>
>>
>> You can never go home. No project stays the same.
>
>
> Well, some people in CM for years did their best to avoid change.
> I didn't like that view and argue with them because they were
> important contributors to CM.
>
> I still have to argue, but now with non-contributors.
> *This* makes no sense.
>
>
>>> Everybody (developers, users, Commons PMC) would be better off with a
>>> selected set of new (supported) components because this is something we
>>> can easily do *now* (RERO, etc.).
>>>
>>
>> This was your assertion in the long email thread. It seemed that there
was
>> significant counter-positions.
>
>
> By non-contributors, using arguments that do not fit the CM history.
>
>
>>> I'm OK to go through the incubator to do that; but I don't see that it
>>> is an easier path.  Surely it looks longer.  And it seems that even the
>>> incubator people doubt that it will lead anywhere.
>>>
>>
>> The incubator is for building community and adapting to Apache. If you
>> don't have a seed community, then incubator is the wrong place. You need
to
>> have more than just you.
>
>
> That's fair, but there are a few others; that was mentioned.
>
>
>>>
>>> Given the uncertain outcome, going through the incubator would be an
>>> attempt at rethinking the development of the currently unsupported
>>> code.  See e.g.
>>>   https://issues.apache.org/jira/browse/MATH-172
>>> [Or is that out of scope for an incubation proposal?]
>>
>>
>>
>> Incubator is not a place to rethink code. It is primarily for building
>> community.
>
>
> I thought so.
> So, that leaves us with TLP.  Back to square one.
>
>
>
> Gilles
>
>>>
>>>
>>> On Fri, Jun 17, 2016 at 3:35 PM, Gilles 

 wrote:

 On Fri, 17 Jun 2016 08:51:36 -0700, Ted Dunning wrote:
>
>
> Excuse me?
>>
>>
>> See inline.
>>
>>
>>
>> On Fri, Jun 17, 2016 at 7:50 AM, Gilles 
>> wrote:
>>
>> Hi all.
>>
>>>
>>> On Tue, 14 Jun 2016 11:01:13 -0700, Ralph Goers wrote:
>>>
>>> I thought this had been made clear.  Several months Commons voted to
>>>
 make Math a TLP. But shortly after that most of the people involved
 with Commons Math felt that a TLP at the ASF would not work for
them,
 so they forked the project and left, effectively voiding the TLP
vote
 since the proposed PMC is no longer valid.  There is one person
left
 who was very involved in Commons Math and a few other people who
have
 expressed interest in joining the new community.

 So this is a situation where we have an already existing code base
 where a lot of the people left are not familiar with quite a bit of
 it.  The new group of people who are interested are trying to
 determine how they should

Re: [PROPOSAL] Weave for Apache Incubator

2013-10-29 Thread Matt Benson 
Hi,
  I am concerned about potential confusion with Apache Commons Weaver [1].

Matt

[1] https://commons.apache.org/proper/commons-weaver/


On Tue, Oct 29, 2013 at 2:53 PM, Andreas Neumann a...@apache.org wrote:

 I would like to propose Weave, an abstraction over Apache Hadoop® YARN to
 reduce the complexity of developing distributed applications, as an
 Apache Incubator
 podling.

 The proposal is included in plain text. I would also like to put this on
 the wiki, but I appear to lack privileges to create pages. What do I need
 to do to get permission?

 -Andreas.

 Abstract
 

 Weave is an abstraction over Apache Hadoop® YARN that reduces the
 complexity of developing distributed applications, allowing developers to
 focus more on their business logic.

 Proposal
 

 Weave is a set of libraries that reduces the complexity of developing
 distributed applications. It exposes the distributed capabilities of Apache
 Hadoop® YARN via a simple and intuitive programming model similar to Java
 threads. Weave also has built-in capabilities required by many distributed
 applications, such as real-time application logs and metrics collection,
 application lifecycle management, and network service discovery.

 Background
 ==

 Hadoop YARN is a generic cluster resource manager that supports any type of
 distributed application. However, YARN’s interfaces are too low level for
 rapid application development. It requires a great deal of boilerplate code
 even for a simple application, creating a high ramp up cost that can turn
 developers away.

 Weave is designed to improve this situation with a programming model that
 makes running distributed applications as easy as running Java threads.
 With the abstraction provided by Weave, applications can be executed in
 process threads during development and unit testing and then be deployed to
 a YARN cluster without any modifications.

 Weave also has built-in support for real-time application logs and metrics
 collection, delegation token renewal, application lifecycle management, and
 network service discovery. This greatly reduces the pain that developers
 face when developing, debugging, deploying and monitoring distributed
 applications.

 Weave is not a replacement for YARN, it’s a framework that operates on top
 of YARN.

 Rationale
 =

 Developers who write YARN applications typically find themselves
 implementing the same (or similar) boilerplate code over and over again for
 every application. It makes sense to distill this common code into a
 reusable set of libraries that is perpetually maintained and improved by a
 diverse community of developers.

 Weave’s simple thread-like programming model will enable many Java
 programmers to develop distributed applications. We believe that this
 simplicity will attract developers who would otherwise be discouraged by
 complexity, and many new use cases will emerge for the usage of YARN.

 Incubating Weave as an Apache project makes sense because Weave is a
 framework built on top of YARN, and Weave uses Apache Zookeeper, HDFS,
 Kafka, and other Apache software (see the External Dependencies section).

 Current Status
 ==

 Weave was initially developed at Continuuity. The Weave codebase is
 currently hosted in a public repository at github.com, which will seed the
 Apache git repository.

 Meritocracy
 ---
 Our intent with this incubator proposal is to start building a diverse
 developer community around Weave following the Apache meritocracy model.
 Since Weave was initially developed in early 2013, we have had fast
 adoption and contributions within Continuuity. We are looking forward to
 new contributors. We wish to build a community based on Apache's
 meritocracy principles, working with those who contribute significantly to
 the project and welcoming them to be committers both during the incubation
 process and beyond.

 Community
 -
 Weave is currently being used internally at Continuuity and is at the core
 of our products. We hope to extend our contributor base significantly and
 we will invite all who are interested in simplifying the development of
 distributed applications to participate.

 Core Developers
 ---
 Weave is currently being developed by five engineers at Continuuity:
  Terence Yim, Andreas Neumann, Gary Helmling, Poorna Chandra and Albert
 Shau.
 Terence Yim is an Apache committer for Helix, Andreas is an Apache
 committer and PMC member for Oozie, and Gary Helmling is an Apache
 committer and PMC member for HBase. Poorna Chandra and Albert Shau have
 made many contributions to Weave.

 Alignment
 -
 The ASF is the natural choice to host the Weave project as its goal of
 encouraging community-driven open source projects fits with our vision for
 Weave.

 Additionally, many other projects with which we are familiar and expect
 Weave to integrate with, such as ZooKeeper, YARN, HDFS, log4j, and others
 mentioned in

Re: [VOTE] BatchEE as an incubated project

2013-09-30 Thread Matt Benson 
+1 (binding)

Matt


On Sun, Sep 29, 2013 at 11:52 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Since discussion about the BatchEE seems done, I'd like to call a vote for
 BatchEE to
 become an incubated project.

 The proposal is pasted below, and also available at:
 https://wiki.apache.org/incubator/BatchEEProposal

 Let's keep this vote open for three business days, closing the voting on
 Thursday 10/03.

 [ ] +1 Accept BatchEE into the Incubator
 [ ] +0 Don't care.
 [ ] -1 Don't accept BatchEE because...


 = BatchEE, JBatch Implementation =

 === Abstract ===

 BatchEE will be an ASL-licensed implementation of the JBatch Specification
 which is defined as JSR-352 (for version 1.0).

 === Proposal ===

 BatchEE specification is an effort for defining a standard API and way to
 write batches in Java. It is integrated with JavaEE (JTA, CDI) but
 works out of the box in a standalone environment.


 BatchEE Project is responsible for implementing the runtime container
 contract for the JBatch specification. Besides the implementation, BatchEE
 Project will implement the core built-in components that further simplifies
 the developer complex interactions with other Java EE specific enterprise
 operations. For example, it will define default reader/processor/writer for
 jdbc, jpa, xml/json/flat files...

 === Background ===

 Until today writing batches in java meant using a proprietary framework and
 link to JavaEE was quite limited (or missing). JBatch defines an API fixing
 this issue and now developpers need a fix.

 === Rationale ===

 Current JBatch specificatin is released, and only the reference
 implementation is available but not really intended to be maintained.
 Moreover multiple Apache projects (geronimo, TomEE, ...) will need an
 Apache compatible Jbatch implementation to go ahread and implement JavaEE
 7.


 === Initial Goals ===

 The initial goals of the BatchEE Project are

  * Fully implement the JSR-352 specification.
  * Attracts a community around the current code base.
  * Active relationship with the other dependent projects to further develop
 some useful batch components.

 == Current Status ==

 === Meritocracy ===

 Initial developer of the project is familiar with the meritocracy
 principles of Apache. He knows that the open source gets power from its
 great developers and freedom. He also developed some other open source
 projects. We will follow the normal meritocracy rules also with other
 potential contributors.

 === Community ===

 There is a great community within the OpenEJB, OpenWebBeans, Geronimo and
 TomEE Apache projects. BatchEE project is very related with these projects
 and in the some cases, it enhances these projects. We are thinking that
 BatchEE project gets strong community because it complete the needed
 frameworks of a java developper and unifies the using of these projects. It
 simplifies the developer effort for building complex enterprise
 applications batches.

 === Core Developers ===

 BatchEE project has been developing by the IBM then forked by Romain
 Manni-Bucau as a sole contributor.

 === Alignment ===

 BacthEE project will be a candidate for use in Geronimo AS and TomEE as a
 default JBatch implementation. Other projects could benefit from the
 BatchEE project as a general purpose component and context management.

 BatchEE project is closely aligned with the OpenEJB and OpenWebBeans
 projects perfectly. It depends on these projects to satisfy its
 requirements (mainly tests).

 == Known Risks ==

 === Orphaned products ===

 Even if the initial committer of the project has no plan to leave the
 active development, it must necessary to get other committers for the
 project. So that it less dependent on the single developer. The source code
 of the project is well documented and new committers could easily grasp the
 details. Initial committer continues to support actively this project.

 === Inexperience with Open Source ===

 Initial developer have worked on open source project before, including
 OpenEJB/TomEE, OpenWebBeans, XBean...

 === Homogeneous Developers ===

 Altough the initial committer of the project is single, developer team may
 be increased within the active project lifecycle from the different
 locations.

 === Reliance on Salaried Developers ===

 Project currently has no salaried developers. All the commitment is done by
 the volunteer developer.

 === Relationships with Other Apache Products ===

 BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans
 could bring added value for tests and integration with CDI. OpenEJB will be
 great to pass EE tests (JTA is mandatory and CDi a must have).

 === An Excessive Fascination with the Apache Brand ===

 BatchEE project initial committer is the strong supporter of the open
 source projects. Initial committer of the project thinks that ASF has great
 place that provides wider colloboration and support of the open source
 project and it respects

Re: [PROPOSAL] BatchEE to implement JBatch @apache

2013-09-19 Thread Matt Benson 
JSR 352 is part of Java EE 7, so BatchEE is IMO warranted.  Plus the
rhyming of Apache BatchEE is silly and fun.

$0.02,
Matt


On Thu, Sep 19, 2013 at 10:08 AM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 easybatch is used by others already.

 regards,
 gerhard



 2013/9/19 Romain Manni-Bucau rmannibu...@gmail.com

  Ok guys, if I have 2 others +1 I update the proposal ;) (I think you are
  right, that's why i proposed it)
 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau https://twitter.com/rmannibucau*
  *Blog: **http://rmannibucau.wordpress.com/*
  http://rmannibucau.wordpress.com/
  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
  *Github: https://github.com/rmannibucau*
 
 
 
  2013/9/19 Jean-Baptiste Onofré j...@nanthrax.net
 
   +1, to be honest, I prefer EasyBatch as BatchEE sounds like related to
   JavaEE which can be confusing for the users.
  
   Regards
   JB
  
  
   On 09/19/2013 01:31 PM, Romain Manni-Bucau wrote:
  
   Discussing with a colleague he proposed me another name: EasyBatch.
   Personally I like BatchEE but EasyBatch sounds quite fun even if maybe
   too close to RestEasy ;)
  
   wdyt?
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.**com/
  http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/**rmannibucau
  http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
  
   2013/9/18 Romain Manni-Bucau rmannibu...@gmail.com:
  
   Added you , thks
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.**com/
  http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/**rmannibucau
  http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
  
   2013/9/18 Olivier Lamy ol...@apache.org:
  
   Sounds interesting.
   Add me as mentor if needed.
  
   Cheers
   --
   Olivier
   On Sep 17, 2013 8:22 PM, Romain Manni-Bucau 
 rmannibu...@gmail.com
   wrote:
  
Dear ASF members,
  
   I would like to propose the BatchEE project to the Incubator.
  
   The BatchEE proposal is available at:
   https://wiki.apache.org/**incubator/BatchEEProposal
  https://wiki.apache.org/incubator/BatchEEProposal
  
   I welcome your feedbacks and suggestions.
  
   Thanks!
  
   Here is a copy of the proposal:
  
   = BatchEE, JBatch Implementation =
  
   === Abstract ===
  
   BatchEE will be an ASL-licensed implementation of the JBatch
   Specification which is defined as JSR-352 (for version 1.0).
  
   === Proposal ===
  
   BatchEE specification is an effort for defining a standard API and
  way
   to write batches in Java. It is integrated with JavaEE (JTA,
 CDI)
   but works out of the box in a standalone environment.
  
  
   BatchEE Project is responsible for implementing the runtime
 container
   contract for the JBatch specification. Besides the implementation,
   BatchEE Project will implement the core built-in components that
   further simplifies the developer complex interactions with other
 Java
   EE specific enterprise operations. For example, it will define
  default
   reader/processor/writer for jdbc, jpa, xml/json/flat files...
  
   === Background ===
  
   Until today writing batches in java meant using a proprietary
   framework and link to JavaEE was quite limited (or missing). JBatch
   defines an API fixing this issue and now developpers need a fix.
  
   === Rationale ===
  
   Current JBatch specificatin is released, and only the reference
   implementation is available but not really intended to be
 maintained.
   Moreover multiple Apache projects (geronimo, TomEE, ...) will need
 an
   Apache compatible Jbatch implementation to go ahread and implement
   JavaEE 7.
  
  
   === Initial Goals ===
  
   The initial goals of the BatchEE Project are
  
 * Fully implement the JSR-352 specification.
 * Attracts a community around the current code base.
 * Active relationship with the other dependent projects to
 further
   develop some useful batch components.
  
   == Current Status ==
  
   === Meritocracy ===
  
   Initial developer of the project is familiar with the meritocracy
   principles of Apache. He knows that the open source gets power from
   its great developers and freedom. He also developed some other open
   source projects. We will follow the normal meritocracy rules also
  with
   other potential contributors.
  
   === Community ===
  
   There is a great community within the OpenEJB, OpenWebBeans,
 Geronimo
   and TomEE Apache projects. BatchEE project is very related with
 these
   projects and in the some cases, it enhances these projects. We are
   thinking that BatchEE project gets strong community because it
   complete the needed frameworks of a java developper and unifies the
   using of these projects. It simplifies the developer effort for
   building complex enterprise applications batches.
  
   === Core Developers ===
  
   BatchEE project has been

Re: [PROPOSAL] BatchEE to implement JBatch @apache

2013-09-19 Thread Matt Benson 
I discussed this with Romain and someone else (can't recall who) before he
submitted this proposal.  My knee-jerk response was that a software grant
would be required, but then recalled the discussion at [1].  This leaves
the impression that the podling could proceed with merely IBM's good will,
which has been established at [2].

Regards,
Matt

[1] http://markmail.org/message/ajmuxmxfdrcurswp
[2] http://markmail.org/message/5mvf5pzyiuakob4w


On Thu, Sep 19, 2013 at 10:25 AM, John D. Ament john.d.am...@gmail.comwrote:

 Just wondering, even though the RI is ASL2, do we need to get IP
 clearance to fork?

 I think this last came up with BeanShell.

 John

 On Thu, Sep 19, 2013 at 11:20 AM, Matt Benson gudnabr...@gmail.com
 wrote:
  JSR 352 is part of Java EE 7, so BatchEE is IMO warranted.  Plus the
  rhyming of Apache BatchEE is silly and fun.
 
  $0.02,
  Matt
 
 
  On Thu, Sep 19, 2013 at 10:08 AM, Gerhard Petracek 
  gerhard.petra...@gmail.com wrote:
 
  easybatch is used by others already.
 
  regards,
  gerhard
 
 
 
  2013/9/19 Romain Manni-Bucau rmannibu...@gmail.com
 
   Ok guys, if I have 2 others +1 I update the proposal ;) (I think you
 are
   right, that's why i proposed it)
  
   *Romain Manni-Bucau*
   *Twitter: @rmannibucau https://twitter.com/rmannibucau*
   *Blog: **http://rmannibucau.wordpress.com/*
   http://rmannibucau.wordpress.com/
   *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
   *Github: https://github.com/rmannibucau*
  
  
  
   2013/9/19 Jean-Baptiste Onofré j...@nanthrax.net
  
+1, to be honest, I prefer EasyBatch as BatchEE sounds like related
 to
JavaEE which can be confusing for the users.
   
Regards
JB
   
   
On 09/19/2013 01:31 PM, Romain Manni-Bucau wrote:
   
Discussing with a colleague he proposed me another name: EasyBatch.
Personally I like BatchEE but EasyBatch sounds quite fun even if
 maybe
too close to RestEasy ;)
   
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.**com/
   http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/**rmannibucau
   http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
   
   
   
2013/9/18 Romain Manni-Bucau rmannibu...@gmail.com:
   
Added you , thks
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.**com/
   http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/**rmannibucau
   http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
   
   
   
2013/9/18 Olivier Lamy ol...@apache.org:
   
Sounds interesting.
Add me as mentor if needed.
   
Cheers
--
Olivier
On Sep 17, 2013 8:22 PM, Romain Manni-Bucau 
  rmannibu...@gmail.com
wrote:
   
 Dear ASF members,
   
I would like to propose the BatchEE project to the Incubator.
   
The BatchEE proposal is available at:
https://wiki.apache.org/**incubator/BatchEEProposal
   https://wiki.apache.org/incubator/BatchEEProposal
   
I welcome your feedbacks and suggestions.
   
Thanks!
   
Here is a copy of the proposal:
   
= BatchEE, JBatch Implementation =
   
=== Abstract ===
   
BatchEE will be an ASL-licensed implementation of the JBatch
Specification which is defined as JSR-352 (for version 1.0).
   
=== Proposal ===
   
BatchEE specification is an effort for defining a standard API
 and
   way
to write batches in Java. It is integrated with JavaEE (JTA,
  CDI)
but works out of the box in a standalone environment.
   
   
BatchEE Project is responsible for implementing the runtime
  container
contract for the JBatch specification. Besides the
 implementation,
BatchEE Project will implement the core built-in components that
further simplifies the developer complex interactions with other
  Java
EE specific enterprise operations. For example, it will define
   default
reader/processor/writer for jdbc, jpa, xml/json/flat files...
   
=== Background ===
   
Until today writing batches in java meant using a proprietary
framework and link to JavaEE was quite limited (or missing).
 JBatch
defines an API fixing this issue and now developpers need a fix.
   
=== Rationale ===
   
Current JBatch specificatin is released, and only the reference
implementation is available but not really intended to be
  maintained.
Moreover multiple Apache projects (geronimo, TomEE, ...) will
 need
  an
Apache compatible Jbatch implementation to go ahread and
 implement
JavaEE 7.
   
   
=== Initial Goals ===
   
The initial goals of the BatchEE Project are
   
  * Fully implement the JSR-352 specification.
  * Attracts a community around the current code base.
  * Active relationship with the other dependent projects to
  further
develop some useful batch components.
   
== Current Status

Re: [VOTE] recommend Apache DeltaSpike for graduating out of the incubator

2013-04-01 Thread Matt Benson 
+1 (binding)

Matt


On Sat, Mar 30, 2013 at 11:54 AM, Mark Struberg strub...@yahoo.de wrote:

 Hi!

 The Apache DeltaSpike podling is a project which contains common CDI
 Extensions which are portable among many different Java EE containers and
 even run on standalone CDI containers.

 We are now incubating since December 2011 and believe we are ready for
 graduation. We've shipped 3 releases and already see wide adoption in the
 industry.
 We've already done an internal VOTE on the proposal which passed with a
 big majority [1].


 The voices who raised concerns were mainly afraid of DeltaSpike not being
 'finished' yet. But graduation doesn't mean that the product is final and
 switches to maintenance, but that it is vital and there is an active
 community around it. And this is certainly the case as shown by the 21
 votes we got the last days.


 Our status file [2] got updated recently and I consider the podling
 namesearch task as completed [3].


 Thus I'd like to ask the IPMC to VOTE on recommending the attached
 graduation proposal to the board.

 [+1] yes, go forward

 [+0] meh, don't care
 [-1] nope, because there's a blocker ${blocker_reason}


 The VOTE is open for 72h


 txs and LieGrue,
 strub



 [1] http://markmail.org/message/bmhr5woxidmgheco
 [2] http://incubator.apache.org/projects/deltaspike.html

 [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31

 

 Proposed Board Resolution Report
 X. Establish the Apache DeltaSpike Project

 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 creating a set
 of portable CDI (JSR-299) Extensions
 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 DeltaSpike Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

 RESOLVED, that the Apache DeltaSpike Project be and hereby is
 responsible for the creation and maintenance of open-source
 software related to creating a set of portable CDI Extensions;
 and be it further

 RESOLVED, that the office of Vice President, Apache DeltaSpike 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 DeltaSpike Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache DeltaSpike 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
 Apache DeltaSpike Project:

 Gerhard Petracek gpetracek at apache.org
 Mark Struberg struberg at apache.org
 Pete Muir pmuir at redhat.com
 Jason Porter lightguard.jp at gmail.com
 Shane Bryzak sbryzak at gmail.com
 Rudy de Busscher rdebusscher at apache.org
 Christian Kaltepoth christian at kaltepoth.de
 Arne Limburg arne.limburg at openknowledge.de
 Charles Moulliard cmoulliard at gmail.com
 Cody Lerum cody.lerum at gmail.com
 Romain Mannu-Buccau rmannibucau at gmail.com
 Matthew Jason Benson mbenson at apache.org
 Jim Jagielski jim at apache.org
 David Blevins dblevins at apache.org
 Ken Finnigan ken at kenfinnigan.me
 John D. Ament johndament at apache.org

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
 be appointed to the office of Vice President, Apache DeltaSpike, 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 the initial Apache DeltaSpike PMC be and hereby is
 tasked with the creation of a set of bylaws intended to
 encourage open development and increased participation in the
 Apache DeltaSpike Project; and be it further

 RESOLVED, that the Apache DeltaSpike Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator DeltaSpike podling; and be it further

 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator DeltaSpike podling encumbered upon the Apache Incubator
 Project are hereafter discharged.



 https://cwiki.apache.org/confluence/display/DeltaSpike/Graduation+Proposal

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

Re: Shepherd for EasyAnt

2012-07-06 Thread Matt Benson 
On Thu, Jul 5, 2012 at 1:27 PM, Dave Fisher dave2w...@comcast.net wrote:

 On Jul 5, 2012, at 10:54 AM, Nicolas Lalevée wrote:


 Le 5 juil. 2012 à 06:35, Stefan Bodewig a écrit :

 On 2012-07-04, Dave Fisher wrote:

 On Jul 3, 2012, at 12:06 PM, Nicolas Lalevée wrote:
 Le 3 juil. 2012 à 19:00, Jukka Zitting a écrit :
 On Tue, Jul 3, 2012 at 6:44 PM, Nicolas Lalevée
 nicolas.lale...@hibnet.org wrote:

 The primary target for Easyant will be being a subproject of Ant.

 This may be EasyAnt's goal, I'm not entirely sure it matches Ant's goal.

 At one point in time every project entering incubation had to be
 sponsored by an existing TLP or the board and it didn't imply the
 podling would graduate to the existing TLP at all.  The you need a
 sponsoring TLP notion seems to have gone now.  By the time EasyAnt
 entered incubation Ant became the sponsoring TLP so there was one, not
 because Ant was comitted to accept it as a sub-project IIRC.

 I'm not saying Ant would reject it, but it is not a no-brainer either.
 This part of the discussion should be held on dev@ant 8-)

 I guess I'm the one who just misunderstood the Ant sponsoring thing.
 Let's to it properly yes. Let's start asking to EasyAnt dev first.

 Since Apache Ivy and Apache IvyDE are sub-projects of Apache Ant there is 
 some sense in EasyAnt having a place in the Apache Ant project. I see that 
 dev@ant did VOTE for sponsorship on a thread that you started [1], but I did 
 not see a lot of discussion about what made sense to the Apache Ant community.

 A few months earlier you pushed for the donation of Bushel into Ivy [2] which 
 was done.

 I see that EasyAnt has an old Google Group ML and this thread describes the 
 process from the EasyAnt community's perspective. [3]

 There is mention of Apache Ivy in the incubator four years prior, and we know 
 it ended up within the Apache Ant project.

Surely you're not suggesting that because Ant has *once* (A) sponsored
a podling's incubation and (B) subsequently adopted that podling as a
subproject that it is bound to do B for *every* A?

Matt


 Regards,
 Dave

 [1] 
 http://mail-archives.apache.org/mod_mbox/ant-dev/201101.mbox/%3C3A73C5DA-E4A2-4CB6-8423-0A985246FA8E%40hibnet.org%3E
 [2] 
 http://mail-archives.apache.org/mod_mbox/ant-dev/201010.mbox/%3cb53d948c-5da9-48d8-b81d-2f8c44dba...@hibnet.org%3E
 [3] 
 https://groups.google.com/group/easyant/browse_thread/thread/a8a87867cb42a5a5



 Nicolas


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



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


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

Re: Fw: [VOTE] Release Apache DeltaSpike-0.2-incubating

2012-04-20 Thread Matt Benson 
On Wed, Apr 18, 2012 at 12:09 PM, Mark Struberg strub...@yahoo.de wrote:
 Hi IPMC folks!

 I'd like to call the 2nd round (IPMC review/vote) for our 
 DeltaSpike-0.2-incubating release!

 See the attached thread for the release artifacts and the podling VOTE 
 results.

 We have 14 +1 inclucing 2 IPMC +1 so far: gpetracek, struberg.

 Here is a more readable form:
 http://markmail.org/thread/orik7hucchqfbhzr


 IPMC VOTE is open for 72h
 [+1] all fine, ship it

 [+0] puh, don't care
 [-1] nah, because ${problem}


+1 (binding)

Matt


 txs and LieGrue,
 strub



 - Forwarded Message -
 From: Mark Struberg strub...@yahoo.de
 To: deltaspike-...@incubator.apache.org 
 deltaspike-...@incubator.apache.org
 Cc:
 Sent: Wednesday, April 18, 2012 7:02 PM
 Subject: Re: [VOTE] Release Apache DeltaSpike-0.2-incubating

 Hi folks!

 The internal DeltaSpike project VOTE passed with the following

 binding +1:  Mark Struberg, Gerhard Petracek, John Ament, Cody Lerum, Antoine
 Sabot-Durand, Ken Finnigan, Jason Porter, Shane Bryzak,


 non-binding +1: Łukasz Dywicki, Bruno Oliveira, Boleslaw Dawidowicz, Paul 
 Dijou,
 Lincoln Baxter III, Mehdi Heidarzadeh

 +0: none
 -1: none


 I'll move this now over to the Incubator PMC to approve our release.


 txs 4 all who voted!
 LieGrue,
 strub



 PS: for the record again, here is my gpg key
 http://www.apache.org/dist/openwebbeans/KEYS
 Will update our section asap.



 - Original Message -
  From: Mark Struberg strub...@yahoo.de
  To: deltaspike deltaspike-...@incubator.apache.org
  Cc:
  Sent: Sunday, April 15, 2012 10:30 PM
  Subject: [VOTE] Release Apache DeltaSpike-0.2-incubating

  Hi folks, I'd like to call a VOTE on releasing Apache DeltaSpike
  0.2-incubating. The Maven staging repository:
  https://repository.apache.org/content/repositories/orgapachedeltaspike-051/

  Source release:

 https://repository.apache.org/content/repositories/orgapachedeltaspike-051/org/apache/deltaspike/deltaspike-project/0.2-incubating/deltaspike-project-0.2-incubating-source-release.zip

  Here are the md5 and sha1:

 https://repository.apache.org/content/repositories/orgapachedeltaspike-051/org/apache/deltaspike/deltaspike-project/0.2-incubating/


  I've pushed the GIT release branch to my github account:

 https://github.com/struberg/incubator-deltaspike/tree/deltaspike-0.2-incubating
  (The branch will be pushed and merged to master after the VOTE passed.)

  The TAG can be found here:

 https://github.com/struberg/incubator-deltaspike/zipball/deltaspike-project-0.2-incubating

  Please note:
  This vote is majority approval with a minimum of three +1 votes
 of
  PPMC members.
  This vote is open for 72 hours.

  [+1] all fine, ship it
  [+0] I don't care but smells fine
  [-1] stop it, this stuff contains a blocker ${insertname}



  LieGrue,
  strub



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


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

Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)

2012-02-11 Thread Matt Benson 
On Thu, Feb 9, 2012 at 9:16 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 Hi Folks,

 OK there has been enough discussion here. It's time to VOTE for a new IPMC
 chair and it looks like the remaining folks (including me) that were in the 
 running
 have aligned beyond the following nominee: Jukka Zitting. Suffice to say, he 
 was
 *my first choice* :)

 In the interest of moving the current discussion matters forward, please VOTE
 on this recommendation to the board by the IPMC. I'll leave the VOTE open
 for at least the next 72 hours:

 [ ] +1 Recommend Jukka Zitting for the IPMC chair position.
 [ ] +0 Don't care.
 [ ]  -1 Don't recommend Jukka Zitting for the IPMC chair position because...


+1 (binding)

Matt

 Note that only VOTEs from the Incubator PMC members are binding, but
 all are welcome to voice their opinion and it will be recorded in the final
 tallies.

 Finally, just to note, these VOTEs on personnel are normally the only
 thing in Apache that is discussed in private (human/social issues), but
 in the interest of openness and transparency that has been demonstrated
 here during these discussions, I will hold this VOTE on the public list.

 Thanks!

 Cheers,
 Chris

 P.S. Here's my +1. Thanks buddy.

 On Feb 8, 2012, at 3:11 PM, Benson Margulies wrote:

 I am happy to step out of the way for Jukka. He was clever enough to
 stay out of the email s*** storm, and that alone, in my mind, renders
 him most qualified.

 On Wed, Feb 8, 2012 at 6:02 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 I already mentioned that I would have nominated you, and so I am
 delighted to read your message. It will be very difficult to choose
 between all these strong candidates.

 Cheers

 On Wed, Feb 8, 2012 at 11:49 PM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 Hi,

 After consideration and some convincing (thanks!), I've decided to
 throw also my hat into the ring as a candidate to be the next chairman
 of the IPMC.

 I believe in that role I could be more effective in focusing more of
 our collective attention at where I think it would do most good - at
 the actual podlings we're here to help.

 That said, the current incubation process clearly has problems and I
 very much support efforts to improve the way we work (even if the
 result is to replace the Incubator with something better). However,
 I'd like to leave the leadership on these efforts to others and, as
 mentioned elsewhere, rather try to act as a balancing force that helps
 achieve consensus where possible.

 Should I be elected, I'd resign as the chairman of the Jackrabbit PMC.
 In fact I think it's in any case high time for Jackrabbit to be
 rotating that role.

 Finally, if elected (and assuming the IPMC still exists), I'd serve
 for at most two years before calling for a re-election, or possibly
 much less if I don't find enough free cycles to perform the duty as
 well as it should.

 BR,

 Jukka Zitting



 ++
 Chris Mattmann, Ph.D.
 Senior Computer Scientist
 NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
 Office: 171-266B, Mailstop: 171-246
 Email: chris.a.mattm...@nasa.gov
 WWW:   http://sunset.usc.edu/~mattmann/
 ++
 Adjunct Assistant Professor, Computer Science Department
 University of Southern California, Los Angeles, CA 90089 USA
 ++


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


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

Re: [DISCUSS] Apache BVal as a TLP

2012-02-08 Thread Matt Benson 
On Wed, Feb 8, 2012 at 8:32 AM, Mohammad Nour El-Din
nour.moham...@gmail.com wrote:
 Hi...

 On Tue, Feb 7, 2012 at 11:01 PM, Matt Benson gudnabr...@gmail.com wrote:

 On Tue, Feb 7, 2012 at 3:57 PM, Ralph Goers ralph.go...@dslextreme.com
 wrote:
  Is this a discussion thread or a vote thread?  If it is a vote thread
  please restart it with [VOTE]. If you want to discuss whether the project
  should graduate then we can do that.

 This is a quick (formal) discussion.  We'd like to proceed to the
 actual VOTE off quite soon (e.g. tomorrow), barring any opposition.
 Since we already went to a vote once before, we don't anticipate that
 anything would preclude this.


 OK, it seems that there are objections so far, so that encourages me to go
 and start a [VOTE] on general@.

*No* objections, you mean, of course.  ;)

Matt




 Thanks,
 Matt

 
  Ralph
 
  On Feb 7, 2012, at 3:29 AM, Mohammad Nour El-Din wrote:
 
  Hi...
 
    It has been discussed, since a while, about the graduation of Apache
  BVal, whether to graduate to a TLP or Subproject and whether it is time
  or
  not, [1], [2] and [3].
  In the past few weeks there has been a [VOTE], [4], which formally
  discussed the graduation to a TLP project. Result announcement can be
  found
  here, [5]. It also has been decided to name the project Apache BVal
  [6].
  The resolution charter content has been discussed and reviewed here
  [7].
 
  The Apache Bean Validation community sees it is time to request an IPMC
  [VOTE] on recommending this resolution [8] to the ASF board.
 
  Accordingly, would you please cast your vote:
 
  [ ] +1 to recommend Bean Validation's graduation
  [ ]  0 don't care
  [ ] -1 no, don't recommend yet, (because...)
 
  The vote will be open for 72 hours.
 
  [1] - http://s.apache.org/oTC
  [2] - http://s.apache.org/I8C
  [3] - http://s.apache.org/EQE
  [4] - http://s.apache.org/rU
  [5] - http://s.apache.org/7Sw
  [6] - http://s.apache.org/tY
  http://markmail.org/message/kzqgd7ff7t6p62va
  [7] - *http://s.apache.org/49R*
  [8] - see below:
 
  ## Resolution to create a TLP from graduating Incubator podling
 
     X. Establish the Apache BVal Project
 
  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 Bean Validation
  Specification and its implementation as Apache BVal
  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 BVal Project,
  be and hereby is established pursuant to Bylaws of the
  Foundation; and be it further
 
  RESOLVED, that the Apache BVal Project be and hereby is
  responsible for the creation and maintenance of software
  related to creating an implementation compliant with the
  Bean Validation Specification and a library of pre-developed
  validators and extensions; and be it further
 
  RESOLVED, that the office of Vice President, Apache BVal 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 BVal Project, and to have primary responsibility
  for management of the projects within the scope of
  responsibility of the Apache BVal 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
  Apache BVal Project:
 
    - Albert Lee allee8...@apache.org
    - Carlos Vara Callau carlosv...@apache.org
    - David Jencks djen...@apache.org
    - Donald Woods dwo...@apache.org
    - Gerhard Petracek gpetra...@apache.org
    - Jeremy Bauer jrba...@apache.org
    - Kevan Lee Miller ke...@apache.org
    - Luciano Resende lrese...@apache.org
    - Matthias Wessendorf mat...@apache.org
    - Matthew Jason Benson mben...@apache.org
    - Mohammad Nour El-Din mn...@apache.org
    - Niall Pemberton nia...@apache.org
    - Roman Stumm romanst...@apache.org
    - Simone Tripodi simonetrip...@apache.org
    - Mark Struberg strub...@apache.org
 
  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson
  be appointed to the office of Vice President, Apache BVal, 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 the initial Apache BVal PMC be and hereby is
  tasked with the creation of a set of bylaws intended to
  encourage open development and increased participation in the
  Apache BVal Project; and be it further
 
  RESOLVED, that the Apache BVal Project be and hereby
  is tasked with the migration and rationalization of the Apache
  Incubator Bean Validation podling; and be it further
 
  RESOLVED, that all

Re: [VOTE] Apache BVal as a TLP

2012-02-08 Thread Matt Benson 
On Wed, Feb 8, 2012 at 8:39 AM, Mohammad Nour El-Din mn...@apache.org wrote:
 Hi...

   It has been discussed, since a while, about the graduation of Apache
 BVal, whether to graduate to a TLP or Subproject and whether it is time or
 not, [1], [2] and [3].
 In the past few weeks there has been a [VOTE], [4], which formally
 discussed the graduation to a TLP project. Result announcement can be found
 here, [5]. It also has been decided to name the project Apache BVal [6].
 The resolution charter content has been discussed and reviewed here [7].

 *NOTE*: As per Niall's request, his name has been removed from the proposed
 PMC [8].

 The Apache Bean Validation community sees it is time to request an IPMC
 [VOTE] on recommending this resolution [9] to the ASF board.

 Accordingly, would you please cast your vote:

 [X] +1 to recommend Bean Validation's graduation
 [ ]  0 don't care
 [ ] -1 no, don't recommend yet, (because...)

+1 (binding)

Matt


 The vote will be open for 72 hours.

 [1] - http://s.apache.org/oTC
 [2] - http://s.apache.org/I8C
 [3] - http://s.apache.org/EQE
 [4] - http://s.apache.org/rU
 [5] - http://s.apache.org/7Sw
 [6] - http://s.apache.org/tY
 http://markmail.org/message/kzqgd7ff7t6p62va
 [7] - *http://s.apache.org/49R*
 [8] - http://s.apache.org/JYS
 [9] - See below:

 ## Resolution to create a TLP from graduating Incubator podling

    X. Establish the Apache BVal Project

  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 Bean Validation
 Specification and its implementation as Apache BVal
 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 BVal Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

 RESOLVED, that the Apache BVal Project be and hereby is
 responsible for the creation and maintenance of software
 related to creating an implementation compliant with the
 Bean Validation Specification and a library of pre-developed
 validators and extensions; and be it further

 RESOLVED, that the office of Vice President, Apache BVal 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 BVal Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache BVal 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
 Apache BVal Project:

   - Albert Lee allee8...@apache.org
   - Carlos Vara Callau carlosv...@apache.org
   - David Jencks djen...@apache.org
   - Donald Woods dwo...@apache.org
   - Gerhard Petracek gpetra...@apache.org
   - Jeremy Bauer jrba...@apache.org
   - Kevan Lee Miller ke...@apache.org
   - Luciano Resende lrese...@apache.org
   - Matthias Wessendorf mat...@apache.org
   - Matthew Jason Benson mben...@apache.org
   - Mohammad Nour El-Din mn...@apache.org
   - Roman Stumm romanst...@apache.org
   - Simone Tripodi simonetrip...@apache.org
   - Mark Struberg strub...@apache.org

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson
 be appointed to the office of Vice President, Apache BVal, 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 the initial Apache BVal PMC be and hereby is
 tasked with the creation of a set of bylaws intended to
 encourage open development and increased participation in the
 Apache BVal Project; and be it further

 RESOLVED, that the Apache BVal Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator Bean Validation podling; and be it further

 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator Bean Validation podling encumbered upon the Apache Incubator
 Project are hereafter discharged.
 --
 Thanks
 - Mohammad Nour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein

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

Re: [VOTE] Release DeltaSpike 0.1-incubating

2012-02-07 Thread Matt Benson 
On Tue, Feb 7, 2012 at 1:20 PM, Gerhard Petracek gpetra...@apache.org wrote:
 Hi,

 This is the first incubator release for Apache DeltaSpike, with the
 artifacts being versioned as 0.1-incubating.

 We have received 16 binding +1 votes (including 4 votes of IPMC members)
 during the release voting on deltaspike-dev.

 Vote thread:
 http://s.apache.org/Ta2

 Result:
 http://s.apache.org/8I3

 Git release branch:
 http://s.apache.org/PbX
 (It will be pushed to our Apache Git repository after this vote passed.)

 Git release tag:
 http://s.apache.org/uC
 (It will be pushed to our Apache Git repository after this vote passed.)

 Release notes:
 http://s.apache.org/DeltaSpike_01incubating

 Release artifacts:
 http://s.apache.org/5hU

 PGP release file (key 2FDB81B1):
 http://s.apache.org/wW

 This vote is open for 72 hours.

 
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 

+1

Matt

 Thanks,
 Gerhard

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

Re: [DISCUSS] Apache BVal as a TLP

2012-02-07 Thread Matt Benson 
On Tue, Feb 7, 2012 at 3:57 PM, Ralph Goers ralph.go...@dslextreme.com wrote:
 Is this a discussion thread or a vote thread?  If it is a vote thread please 
 restart it with [VOTE]. If you want to discuss whether the project should 
 graduate then we can do that.

This is a quick (formal) discussion.  We'd like to proceed to the
actual VOTE off quite soon (e.g. tomorrow), barring any opposition.
Since we already went to a vote once before, we don't anticipate that
anything would preclude this.

Thanks,
Matt


 Ralph

 On Feb 7, 2012, at 3:29 AM, Mohammad Nour El-Din wrote:

 Hi...

   It has been discussed, since a while, about the graduation of Apache
 BVal, whether to graduate to a TLP or Subproject and whether it is time or
 not, [1], [2] and [3].
 In the past few weeks there has been a [VOTE], [4], which formally
 discussed the graduation to a TLP project. Result announcement can be found
 here, [5]. It also has been decided to name the project Apache BVal [6].
 The resolution charter content has been discussed and reviewed here [7].

 The Apache Bean Validation community sees it is time to request an IPMC
 [VOTE] on recommending this resolution [8] to the ASF board.

 Accordingly, would you please cast your vote:

 [ ] +1 to recommend Bean Validation's graduation
 [ ]  0 don't care
 [ ] -1 no, don't recommend yet, (because...)

 The vote will be open for 72 hours.

 [1] - http://s.apache.org/oTC
 [2] - http://s.apache.org/I8C
 [3] - http://s.apache.org/EQE
 [4] - http://s.apache.org/rU
 [5] - http://s.apache.org/7Sw
 [6] - http://s.apache.org/tY
 http://markmail.org/message/kzqgd7ff7t6p62va
 [7] - *http://s.apache.org/49R*
 [8] - see below:

 ## Resolution to create a TLP from graduating Incubator podling

    X. Establish the Apache BVal Project

 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 Bean Validation
 Specification and its implementation as Apache BVal
 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 BVal Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

 RESOLVED, that the Apache BVal Project be and hereby is
 responsible for the creation and maintenance of software
 related to creating an implementation compliant with the
 Bean Validation Specification and a library of pre-developed
 validators and extensions; and be it further

 RESOLVED, that the office of Vice President, Apache BVal 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 BVal Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache BVal 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
 Apache BVal Project:

   - Albert Lee allee8...@apache.org
   - Carlos Vara Callau carlosv...@apache.org
   - David Jencks djen...@apache.org
   - Donald Woods dwo...@apache.org
   - Gerhard Petracek gpetra...@apache.org
   - Jeremy Bauer jrba...@apache.org
   - Kevan Lee Miller ke...@apache.org
   - Luciano Resende lrese...@apache.org
   - Matthias Wessendorf mat...@apache.org
   - Matthew Jason Benson mben...@apache.org
   - Mohammad Nour El-Din mn...@apache.org
   - Niall Pemberton nia...@apache.org
   - Roman Stumm romanst...@apache.org
   - Simone Tripodi simonetrip...@apache.org
   - Mark Struberg strub...@apache.org

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson
 be appointed to the office of Vice President, Apache BVal, 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 the initial Apache BVal PMC be and hereby is
 tasked with the creation of a set of bylaws intended to
 encourage open development and increased participation in the
 Apache BVal Project; and be it further

 RESOLVED, that the Apache BVal Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator Bean Validation podling; and be it further

 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator Bean Validation podling encumbered upon the Apache Incubator
 Project are hereafter discharged.
 --
 Thanks
 - Mohammad Nour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein


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

DeltaSpike IP clarifications

2012-01-17 Thread Matt Benson 
Hi, all--per [1], Generally, the mentors of a new project will need
to consult with general@incubator.apache.org or the Apache legal team
about the particular circumstances.  So, here I am.

The situation can be read in detail at [2], but in short is this:
DeltaSpike is intended to amalgamate best of add-on solutions from
the Java EE community with regard to the Contexts and Dependency
Injection for the Java EE platform (CDI) specification.  Thus its
sources may incorporate code originating from numerous sources, but
due to a number of reasons including e.g. anticipated feature overlap,
it does not seem appropriate to include whole codebases under software
grants.  The specific question at the moment regards code to which Red
Hat holds the copyright.  The ASF has a filed CCLA from Red Hat, but I
have been taking the position that we still need some form of
assurance that code relating to CDI (primarily embodied in the Solder
and Seam) projects is *specifically* approved for contribution to
DeltaSpike.  I'll present the basic question in multiple-choice form
(with options shown in order of difficulty):

What do we need to show provenance?
  a.  Nothing.  Stop being so damned paranoid.  The CCLA is enough.
  b.  DeltaSpike's Red Hat-employed committers' assurance that their
employer is on board.
  c.  A signed statement from Red Hat to the effect that their
employees are authorized to contribute CDI-related code.
  d.  A software grant for any codebase, even if we only intend to
cherry-pick from it.
  e.  Jim Whitehurst's eternal soul.
  f.  Something else, namely _.

Thanks,
Matt on behalf of DeltaSpike

[1] http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
[2] http://markmail.org/thread/g65yi42mdzvq5bu2

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

Re: DeltaSpike IP clarifications

2012-01-17 Thread Matt Benson 
On Tue, Jan 17, 2012 at 12:43 PM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
 Sorry for jumping in in the middle.

 Code contributed to Apache must be under some form of an agreement. If the
 code was authored by an individual and that individual has an ICLA on file
 then they can contribute the software under their ICLA. If a group of
 developers developed something and all have ICLAs on file and want to
 contribute it, I believe it would be acceptable but still should have a
 Software Grant to identify all the individuals and the fact that they were
 all under an ICLA. If a group of developers created something for their
 employer and they don't have ICLAs on file then the employer needs to
 submit a software grant.

 From the facts below it sounds like a software grant should be filed.

Hi, Ralph--thanks for your participation!  For much of DeltaSpike's IP
going forward, the situation will very likely be as you have stated.
However, in this case, I notice you didn't mention Red Hat's CCLA.  We
have stated assurances from Red Hat counsel and management on
deltaspike-private to the effect that they are on board, in addition
to the link to the very public affirmation of this fact provided by
Gerhard.  These would seem to indicate satisfactorily that Red Hat's
CCLA does cover these contributions, and I am therefore intending to
call the matter of Red Hat's contributions to DeltaSpike closed.

Thanks again,
Matt


 Ralph



 On Tue, Jan 17, 2012 at 9:45 AM, Gerhard Petracek gpetra...@apache.orgwrote:

 hi matt,

 imo we have to care about it in case of other external contributions we are
 going to get quite soon.

 however, in case of seam3 i don't see any issue at all.
 #1 redhat has a ccla on file
 #2 they contacted us [1] to join forces (and they found out that the asf is
 also a great place for them to do so) and they announced it as well [2]
 #3 their employees who wrote the original source-code do the initial import
 after we agreed on it from a technical point of view
 #4 basically there isn't a license issue at all, because the source-code is
 AL v2 licensed already (@our higher quality standard: see #1-#3)

 if we think that #1-#4 isn't enough, imo it's faster to ask redhat to write
 a formal letter that they grant us access explicitly.

 for sure that's just my personal opinion.

 regards,
 gerhard

 [1] http://goo.gl/u3ewl
 [2] http://planet.jboss.org/post/seam_next_announcement



 2012/1/16 Matt Benson gudnabr...@gmail.com

  It may also be pertinent to note that the codebases here in question
  are also ALv2 licensed.
 
  Matt
 
  On Mon, Jan 16, 2012 at 1:49 PM, Matt Benson mben...@apache.org wrote:
   Hi, all--per [1], Generally, the mentors of a new project will need
   to consult with general@incubator.apache.org or the Apache legal team
   about the particular circumstances.  So, here I am.
  
   The situation can be read in detail at [2], but in short is this:
   DeltaSpike is intended to amalgamate best of add-on solutions from
   the Java EE community with regard to the Contexts and Dependency
   Injection for the Java EE platform (CDI) specification.  Thus its
   sources may incorporate code originating from numerous sources, but
   due to a number of reasons including e.g. anticipated feature overlap,
   it does not seem appropriate to include whole codebases under software
   grants.  The specific question at the moment regards code to which Red
   Hat holds the copyright.  The ASF has a filed CCLA from Red Hat, but I
   have been taking the position that we still need some form of
   assurance that code relating to CDI (primarily embodied in the Solder
   and Seam) projects is *specifically* approved for contribution to
   DeltaSpike.  I'll present the basic question in multiple-choice form
   (with options shown in order of difficulty):
  
   What do we need to show provenance?
    a.  Nothing.  Stop being so damned paranoid.  The CCLA is enough.
    b.  DeltaSpike's Red Hat-employed committers' assurance that their
   employer is on board.
    c.  A signed statement from Red Hat to the effect that their
   employees are authorized to contribute CDI-related code.
    d.  A software grant for any codebase, even if we only intend to
   cherry-pick from it.
    e.  Jim Whitehurst's eternal soul.
    f.  Something else, namely _.
  
   Thanks,
   Matt on behalf of DeltaSpike
  
   [1]
 http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
   [2] http://markmail.org/thread/g65yi42mdzvq5bu2
 


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

IP clearance for compatibly-licensed software WAS Re: DeltaSpike IP clarifications

2012-01-17 Thread Matt Benson 
This thread brings up another issue.  During this process we have
encountered the sentiment that the ASF's insistence on (arguably)
extensive documentation to import e.g. ALv2-licensed code seems to
express a lack of confidence in its own license on the part of the
ASF.  My response has been, paraphrased, that the ASF, in the interest
of protecting its projects, may go above and beyond with regard to
IP clearance.  With his permission, I'll paste what Red Hat's Richard
Fontana had to say on the matter:

RF:
  I must say that I am in strong agreement with those who expressed
  puzzlement at the apparent insufficiency of the Apache License 2.0 --
  I understand this to mean that the ASF has no confidence in its own
  license, at least when that license comes from third parties. If the
  ASF isn't confident in that license when it comes from others, why
  should anyone be confident in that same license when it comes from the
  ASF? �I don't want to make a big deal out of this, I just want to add
  my support as a lawyer to a viewpoint you're hearing from
  developers. I have, in fact, raised this very question before, in a
  number of contexts.

Now, before anyone says how dare he! he also went on to say:

RF:
 I don't mind the ASF choosing to have such IP policies,
 because of the unique role of the ASF and my very high degree of trust
 and confidence in the ASF. It's really in non-ASF contexts where I've
 raised the issue (for example, I recently made some comments along
 these lines on the OpenStack developers' mailing list). And we've been
 criticized on the other side, for example with Fedora.  I guess the
 only points of tension come about in situations like this where we
 have Red Hat code migrating to Apache incubator status. But, as a
 personal matter, and as a Red Hat employee, I am very pleased to see
 this happening

So I am satisfied to accept that this is the way it is, toe the
line, and put on the brave external face.  But so I don't look like an
idiot saying it is what it is, is there an authoritative explanation
of the motivation behind our policies to which future querents should
be directed?

Matt

On Tue, Jan 17, 2012 at 1:54 PM, Sam Ruby ru...@intertwingly.net wrote:
 On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @dslextreme.com
 ralph.go...@dslextreme.com wrote:
 I didn't mention CCLA's on purpose. A corporation will have a CCLA on file
 to either a) declare that certain employees are permitted to contribute
 software or b) declare that certain software is contributed to the ASF.  A
 CCLA that is on file that only includes Schedule A doesn't grant the ASF
 permission to use specific software created by the company. If the company
 is donating the software they need to specify it. If the software is being
 contributed via an ICLA then the CCLA simply says the company is giving the
 contributor the right to contribute software that normally the company
 would own. However, an individual should never contribute software under
 their ICLA that they didn't author, unless they have explicit permission
 from the other authors. For a significant contribution a software grant
 is typically the best way to do it.

 I concur.

 Either an (additional|updated) CCLA with a concurrent software grant
 (Schedule B) for the code in question -or- simply a separate Software
 Grant would be appreciated.

 If RedHat is on board with this (and everything in this conversations
 indicated that that is indeed the case), then that shouldn't be a
 problem?

 - Sam Ruby

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


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

Re: IP clearance for compatibly-licensed software WAS Re: DeltaSpike IP clarifications

2012-01-17 Thread Matt Benson 
Thanks for the simple example, Ralph.  :)

Matt

On Tue, Jan 17, 2012 at 2:25 PM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
 I don't have the link in hand at the moment, but lets pretend that someone
 wrote some code under the GPL, LGPL or some other non-Apache license.
 Someone else takes that code and simply changes the license header to the
 Apache license. You then, with all good intent, pick up that software and
 commit it to an Apache project. This would open up the project to lots of
 bad consequences.

 We require IP clearance to prevent exactly this situation, or variants of
 it.

 Ralph


 On Tue, Jan 17, 2012 at 12:11 PM, Matt Benson gudnabr...@gmail.com wrote:

 This thread brings up another issue.  During this process we have
 encountered the sentiment that the ASF's insistence on (arguably)
 extensive documentation to import e.g. ALv2-licensed code seems to
 express a lack of confidence in its own license on the part of the
 ASF.  My response has been, paraphrased, that the ASF, in the interest
 of protecting its projects, may go above and beyond with regard to
 IP clearance.  With his permission, I'll paste what Red Hat's Richard
 Fontana had to say on the matter:

 RF:
   I must say that I am in strong agreement with those who expressed
   puzzlement at the apparent insufficiency of the Apache License 2.0 --
   I understand this to mean that the ASF has no confidence in its own
   license, at least when that license comes from third parties. If the
   ASF isn't confident in that license when it comes from others, why
   should anyone be confident in that same license when it comes from the
   ASF? �I don't want to make a big deal out of this, I just want to add
   my support as a lawyer to a viewpoint you're hearing from
   developers. I have, in fact, raised this very question before, in a
   number of contexts.

 Now, before anyone says how dare he! he also went on to say:

 RF:
  I don't mind the ASF choosing to have such IP policies,
  because of the unique role of the ASF and my very high degree of trust
  and confidence in the ASF. It's really in non-ASF contexts where I've
  raised the issue (for example, I recently made some comments along
  these lines on the OpenStack developers' mailing list). And we've been
  criticized on the other side, for example with Fedora.  I guess the
  only points of tension come about in situations like this where we
  have Red Hat code migrating to Apache incubator status. But, as a
  personal matter, and as a Red Hat employee, I am very pleased to see
  this happening

 So I am satisfied to accept that this is the way it is, toe the
 line, and put on the brave external face.  But so I don't look like an
 idiot saying it is what it is, is there an authoritative explanation
 of the motivation behind our policies to which future querents should
 be directed?

 Matt

 On Tue, Jan 17, 2012 at 1:54 PM, Sam Ruby ru...@intertwingly.net wrote:
  On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @dslextreme.com
  ralph.go...@dslextreme.com wrote:
  I didn't mention CCLA's on purpose. A corporation will have a CCLA on
  file
  to either a) declare that certain employees are permitted to contribute
  software or b) declare that certain software is contributed to the ASF.
   A
  CCLA that is on file that only includes Schedule A doesn't grant the
  ASF
  permission to use specific software created by the company. If the
  company
  is donating the software they need to specify it. If the software is
  being
  contributed via an ICLA then the CCLA simply says the company is giving
  the
  contributor the right to contribute software that normally the company
  would own. However, an individual should never contribute software
  under
  their ICLA that they didn't author, unless they have explicit
  permission
  from the other authors. For a significant contribution a software
  grant
  is typically the best way to do it.
 
  I concur.
 
  Either an (additional|updated) CCLA with a concurrent software grant
  (Schedule B) for the code in question -or- simply a separate Software
  Grant would be appreciated.
 
  If RedHat is on board with this (and everything in this conversations
  indicated that that is indeed the case), then that shouldn't be a
  problem?
 
  - Sam Ruby
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 

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



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

Re: DeltaSpike IP clarifications

2012-01-17 Thread Matt Benson 
Adding deltaspike-dev back to the distribution:

On Tue, Jan 17, 2012 at 3:01 PM, Gerhard Petracek gpetra...@apache.org wrote:
 ok - matt and i just had a short talk with sam to ensure that we are
 talking about the same.
 it isn't the only way, but to resolve it once and for all it's easier to
 handle it via a software grant.

 @matt:
 it would be great if you can contact them again.

Done, copying deltaspike-private.

Matt


 @sam:
 thx for your help

 regards,
 gerhard



 2012/1/17 Gerhard Petracek gpetra...@apache.org

 hi,

 in general - fyi:
 we don't have a huge import. we discuss single features and if we agree on
 one, one of the members (of the original project) commits it. all authors
 have their icla on file, joined the project and participate in the
 discussion and the release votes.

 regards,
 gerhard



 2012/1/17 Sam Ruby ru...@intertwingly.net

 On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @dslextreme.com
 ralph.go...@dslextreme.com wrote:
  I didn't mention CCLA's on purpose. A corporation will have a CCLA on
 file
  to either a) declare that certain employees are permitted to contribute
  software or b) declare that certain software is contributed to the ASF.
  A
  CCLA that is on file that only includes Schedule A doesn't grant the ASF
  permission to use specific software created by the company. If the
 company
  is donating the software they need to specify it. If the software is
 being
  contributed via an ICLA then the CCLA simply says the company is giving
 the
  contributor the right to contribute software that normally the company
  would own. However, an individual should never contribute software under
  their ICLA that they didn't author, unless they have explicit permission
  from the other authors. For a significant contribution a software
 grant
  is typically the best way to do it.

 I concur.

 Either an (additional|updated) CCLA with a concurrent software grant
 (Schedule B) for the code in question -or- simply a separate Software
 Grant would be appreciated.

 If RedHat is on board with this (and everything in this conversations
 indicated that that is indeed the case), then that shouldn't be a
 problem?

 - Sam Ruby

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




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

Re: DeltaSpike IP clarifications

2012-01-17 Thread Matt Benson 
Hi all,

We have another question on this topic... RH counsel wants to know why
clause 4 rather than clause 7 of the ICLA doesn't serve our purposes
here.*  My inexpert answer would be that the ICLA, with the exception
of clause 7, deals with original works, which is intended to exclude
code that was developed outside of the ASF SVN repository and our
public mailing lists to quote from
http://incubator.apache.org/ip-clearance/index.html .  Am I on the
right track here?

Thanks,
Matt

* for context, we are speaking about bits and pieces that will be
cherry-picked from the Solder and Seam 3 codebases; thus a software
grant is a bit of overkill, but saves committers having to disclaim
each commit as clause 7 would do.

On Tue, Jan 17, 2012 at 3:08 PM, Matt Benson gudnabr...@gmail.com wrote:
 Adding deltaspike-dev back to the distribution:

 On Tue, Jan 17, 2012 at 3:01 PM, Gerhard Petracek gpetra...@apache.org 
 wrote:
 ok - matt and i just had a short talk with sam to ensure that we are
 talking about the same.
 it isn't the only way, but to resolve it once and for all it's easier to
 handle it via a software grant.

 @matt:
 it would be great if you can contact them again.

 Done, copying deltaspike-private.

 Matt


 @sam:
 thx for your help

 regards,
 gerhard



 2012/1/17 Gerhard Petracek gpetra...@apache.org

 hi,

 in general - fyi:
 we don't have a huge import. we discuss single features and if we agree on
 one, one of the members (of the original project) commits it. all authors
 have their icla on file, joined the project and participate in the
 discussion and the release votes.

 regards,
 gerhard



 2012/1/17 Sam Ruby ru...@intertwingly.net

 On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @dslextreme.com
 ralph.go...@dslextreme.com wrote:
  I didn't mention CCLA's on purpose. A corporation will have a CCLA on
 file
  to either a) declare that certain employees are permitted to contribute
  software or b) declare that certain software is contributed to the ASF.
  A
  CCLA that is on file that only includes Schedule A doesn't grant the ASF
  permission to use specific software created by the company. If the
 company
  is donating the software they need to specify it. If the software is
 being
  contributed via an ICLA then the CCLA simply says the company is giving
 the
  contributor the right to contribute software that normally the company
  would own. However, an individual should never contribute software under
  their ICLA that they didn't author, unless they have explicit permission
  from the other authors. For a significant contribution a software
 grant
  is typically the best way to do it.

 I concur.

 Either an (additional|updated) CCLA with a concurrent software grant
 (Schedule B) for the code in question -or- simply a separate Software
 Grant would be appreciated.

 If RedHat is on board with this (and everything in this conversations
 indicated that that is indeed the case), then that shouldn't be a
 problem?

 - Sam Ruby

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




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

Re: DeltaSpike IP clarifications

2012-01-16 Thread Matt Benson 
It may also be pertinent to note that the codebases here in question
are also ALv2 licensed.

Matt

On Mon, Jan 16, 2012 at 1:49 PM, Matt Benson mben...@apache.org wrote:
 Hi, all--per [1], Generally, the mentors of a new project will need
 to consult with general@incubator.apache.org or the Apache legal team
 about the particular circumstances.  So, here I am.

 The situation can be read in detail at [2], but in short is this:
 DeltaSpike is intended to amalgamate best of add-on solutions from
 the Java EE community with regard to the Contexts and Dependency
 Injection for the Java EE platform (CDI) specification.  Thus its
 sources may incorporate code originating from numerous sources, but
 due to a number of reasons including e.g. anticipated feature overlap,
 it does not seem appropriate to include whole codebases under software
 grants.  The specific question at the moment regards code to which Red
 Hat holds the copyright.  The ASF has a filed CCLA from Red Hat, but I
 have been taking the position that we still need some form of
 assurance that code relating to CDI (primarily embodied in the Solder
 and Seam) projects is *specifically* approved for contribution to
 DeltaSpike.  I'll present the basic question in multiple-choice form
 (with options shown in order of difficulty):

 What do we need to show provenance?
  a.  Nothing.  Stop being so damned paranoid.  The CCLA is enough.
  b.  DeltaSpike's Red Hat-employed committers' assurance that their
 employer is on board.
  c.  A signed statement from Red Hat to the effect that their
 employees are authorized to contribute CDI-related code.
  d.  A software grant for any codebase, even if we only intend to
 cherry-pick from it.
  e.  Jim Whitehurst's eternal soul.
  f.  Something else, namely _.

 Thanks,
 Matt on behalf of DeltaSpike

 [1] http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
 [2] http://markmail.org/thread/g65yi42mdzvq5bu2

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

Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP

2012-01-09 Thread Matt Benson 
On Mon, Jan 9, 2012 at 5:08 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 +1 to graduate, with the following note:

 On Sun, Jan 8, 2012 at 10:04 PM, Mark Struberg strub...@yahoo.de wrote:
 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 creating an implementation
 compliant with JSR-303 and a library of pre-developed validators
 and extensions for distribution at no charge to the public.

 As noted by others, the project scope could use some clarification.

 Also, rather than referring specifically to JSR-303, it would
 probably be better to refer to the Bean Validation API to avoid
 tying the project to a specific version of the API. For example the
 Apache Jackrabbit resolution [1] referred to the Content Repository
 for Java Technology API instead of JSR-170 which would by now (with
 JSR-283 and JSR-333 defining updated API versions) be outdated.


What are the formal mechanics of refining the project description as
suggested here and elsewhere, mid-vote?  Or would a new vote be
required?

Matt

 [1] 
 http://www.apache.org/foundation/records/minutes/2006/board_minutes_2006_03_15.txt

 BR,

 Jukka Zitting

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


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

Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP

2012-01-08 Thread Matt Benson 
+1

Matt

On Sun, Jan 8, 2012 at 3:04 PM, Mark Struberg strub...@yahoo.de wrote:


 Dear IPMC, dear Community!

 The Apache Bean-Validation project provides an ALv2 licensed implementation 
 of the JSR-303 Bean Validation Specification and would like to start a VOTE 
 on graduating as a TLP.
 The podling is in the incubator since 2010 and successfully shipped 3 
 releases and established an active community.

 The internal PPMC VOTE has decided with 11 +1 (see [1]) that we would like to 
 propose graduation as a TLP.
 We also went through the graduation checklist and made sure that we fulfilled 
 all requirements.

 We would like to thank our Mentors and the board for their continued support 
 and also Roman Stumm and his team for contributing this project to the ASF!

 We are happy to finally start the VOTE about the recommendation to the board 
 about graduating BVAL to a TLP with the Board Resolution Report attached 
 below.
 For better readability, the Resolution text is also available in our WIKI [2]

 Please VOTE on recommending BVAL as a TLP

 [+1] graduate BVAL as a TLP

 [+0] don't care

 [-1] nope, because (fill in)

 The VOTE is open for 72h.

 Incubator Page : http://incubator.apache.org/bval

 Status Page    : http://incubator.apache.org/projects/beanvalidation.html

 thanks,

 the BVAL PPMC


 Board Resolution Report
 --

 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 creating an implementation
 compliant with JSR-303 and a library of pre-developed validators
 and extensions 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 Bean Validation Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further


 RESOLVED, that the Apache Bean Validation Project be and hereby is
 responsible for the creation and maintenance of software
 related to creating an implementation compliant with JSR-303
 and a library of pre-developed validators and extensions; and be it further


 RESOLVED, that the office of Vice President, Apache Bean Validation 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 Bean Validation Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache Bean Validation 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
 Apache Bean Validation Project:
 * Albert Lee allee8...@apache.org
 * Carlos Vara Callau carlosv...@apache.org
 * David Jencks djen...@apache.org
 * Donald Woods dwo...@apache.org
 * Gerhard Petracek gpetra...@apache.org
 * Jeremy Bauer jrba...@apache.org
 * Kevan Lee Miller ke...@apache.org
 * Luciano Resende lrese...@apache.org
 * Matthias Wessendorf mat...@apache.org
 * Matthew Jason Benson mben...@apache.org
 * Mohammad Nour El-Din mn...@apache.org
 * Niall Pemberton nia...@apache.org
 * Roman Stumm romanst...@apache.org
 * Simone Tripodi simonetrip...@apache.org
 * Mark Struberg strub...@apache.org


 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson
 be appointed to the office of Vice President, Apache Bean Validation, 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 the initial Apache Bean Validation PMC be and hereby is
 tasked with the creation of a set of bylaws intended to
 encourage open development and increased participation in the
 Apache Bean Validation Project; and be it further


 RESOLVED, that the Apache Bean Validation Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator Bean Validation podling; and be it further
 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator Bean Validation podling encumbered upon the Apache Incubator
 Project are hereafter discharged.






 [1] 
 http://mail-archives.apache.org/mod_mbox/incubator-bval-dev/20.mbox/%3CCAOvkMoZ6EVNDZ2SNq44L992JTr_oquoJV2Oun-fKhpYX03DPiQ%40mail.gmail.com%3E
 [2] 
 https://cwiki.apache.org/confluence/display/BeanValidation/Graduation+Proposal


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


-
To unsubscribe,

Re: [DISCUSS] Apache Bean Validation as a TLP

2012-01-03 Thread Matt Benson 
+1

Matt

On Tue, Jan 3, 2012 at 9:17 AM, Mohammad Nour El-Din mn...@apache.org wrote:
 Hi...

   It has been discussed, since a while, about the graduation of Apache
 Bean Validation, whether to graduate to a TLP or Subproject and whether it
 is time or not, [1], [2] and [3].
 In the past few weeks there has been a [VOTE], [4], which formally
 discussed the graduation to a TLP project. Result announcement can be found
 here, [5]. The resolution charter content has been discussed and reviewed
 here [6].

 The Apache Bean Validation community sees it is time to request an IPMC
 [VOTE] on recommending this resolution [7] to the ASF board.

 Accordingly, would you please cast your vote:

 [ ] +1 to recommend Bean Validation's graduation
 [ ]  0 don't care
 [ ] -1 no, don't recommend yet, (because...)

 The vote will be open for 72 hours.

 [1] - http://s.apache.org/oTC
 [2] - http://s.apache.org/I8C
 [3] - http://s.apache.org/EQE
 [4] - http://s.apache.org/rU
 [5] - http://s.apache.org/7Sw
 [6] - http://s.apache.org/S5F
 [7] - see below:

 ## Resolution to create a TLP from graduating Incubator podling

    X. Establish the Apache Bean Validation Project

       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 creating an implementation
       compliant with JSR-303 and a library of pre-developed validators
       and extensions 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 Bean Validation Project,
       be and hereby is established pursuant to Bylaws of the
       Foundation; and be it further

       RESOLVED, that the Apache Bean Validation Project be and hereby is
       responsible for the creation and maintenance of software
       related to creating an implementation compliant with JSR-303
       and a library of pre-developed validators and extensions; and be it
 further

       RESOLVED, that the office of Vice President, Apache Bean
 Validation 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 Bean Validation Project, and to have primary
 responsibility
       for management of the projects within the scope of
       responsibility of the Apache Bean Validation 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
       Apache Bean Validation Project:

         * Albert Lee allee8...@apache.org
         * Carlos Vara Callau carlosv...@apache.org
         * David Jencks djen...@apache.org
         * Donald Woods dwo...@apache.org
         * Gerhard Petracek gpetra...@apache.org
         * Jeremy Bauer jrba...@apache.org
         * Kevan Lee Miller ke...@apache.org
         * Luciano Resende lrese...@apache.org
         * Matthias Wessendorf mat...@apache.org
         * Matthew Jason Benson mben...@apache.org
         * Mohammad Nour El-Din mn...@apache.org
         * Niall Pemberton nia...@apache.org
         * Roman Stumm romanst...@apache.org
         * Simone Tripodi simonetrip...@apache.org
         * Mark Struberg strub...@apache.org

       NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson
       be appointed to the office of Vice President, Apache Bean
 Validation, 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 the initial Apache Bean Validation PMC be and hereby
 is
       tasked with the creation of a set of bylaws intended to
       encourage open development and increased participation in the
       Apache Bean Validation Project; and be it further

       RESOLVED, that the Apache Bean Validation Project be and hereby
       is tasked with the migration and rationalization of the Apache
       Incubator Bean Validation podling; and be it further

       RESOLVED, that all responsibilities pertaining to the Apache
       Incubator Bean Validation podling encumbered upon the Apache
 Incubator
       Project are hereafter discharged.


 Looking forward to your feedback and reply :)

 --
 Thanks
 - Mohammad Nour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein

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

Re: [VOTE] DeltaSpike to join the Incubator

2011-12-04 Thread Matt Benson 
 

     * Shane Bryzak (sbryzak at gmail.com)
     * Jason Porter (lightguard.jp at gmail.com)
     * Stuart Douglas (stuart.w.douglas at gmail.com)
     * Jozef Hartinger (jozefhartinger at gmail.com)
     * Brian Leathem (bleathem at gmail.com)
     * Ken Finnigan (ken at kenfinnigan.me)
     * Marius Bogoevici (mariusb at redhat.com)
     * George Gastaldi (gegastaldi at gmail.com)
     * John Ament (john.d.ament at gmail.com)
     * Cody Lerum (cody.lerum at clearfly.net)
     * Antoine Sabot-Durand (antoine at sabot-durand.net)
     * Pete Royle (pete at screamingcoder.com)
     * Pete Muir (pmuir at redhat.com)
     * Mark Struberg (struberg at apache dot org)
     * Gerhard Petracek (gpetracek at apache dot org)
     * David Blevins (dblevins at apache dot org)
     * Matthias Wessendorf (matzew at apache dot org)
     * Jakob Korherr (jakobk at apache dot org)
     * Andy Gibson (contact at andygibson.net)
     * Rick Hightower (richardhightower at gmail.com)

 Affiliations
 

 The following contributors are full time employees of Red Hat:
     * Shane Bryzak
     * Jason Porter
     * Stuart Douglas
     * Jozef Hartinger
     * Brian Leathem
     * Ken Finnigan
     * Marius Bogoevici
     * Pete Muir

 Sponsors
 

 Champion
 

     * Mark Struberg

 Nominated Mentors
 

     * Mark Struberg
     * Gerhard Petracek
     * David Blevins
     * Matthias Wessendorf
     * Matt Benson

 Sponsoring Entity
 

     * Apache MyFaces PMC

 Project Name
 
 While DeltaSpike is intended to be used as the project’s code name during
 the
 incubation  process, it is intended that we will solicit suggestions
 from the  greater community for a more suitable name before it becomes a
 top level  project at Apache.


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




 --
 Joseph Echeverria
 Cloudera, Inc.
 443.305.9434

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


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

Re: Incubator PMC/Board report for Dec 2011 ([ppmc])

2011-12-01 Thread Matt Benson 
That would explain why he claimed to have mailed BeanValidation-dev,
and our yet having failed AFAIK to receive the notification.

Matt

On Thu, Dec 1, 2011 at 9:49 AM, Francis De Brabandere
franci...@gmail.com wrote:
 Same thing on empire-db-dev@ I suppose Marvin (bot) somehow mailed the
 wrong projects.

 Cheers,
 F

 On Thu, Dec 1, 2011 at 2:57 AM, Michael Stroucken
 stroucki+apa...@andrew.cmu.edu wrote:
 The tashi-dev mailing list just got the following message from an
 unreplyable Marvin. The Tashi project reports in January, April, July and
 October.

 Can this be ignored, or is our reporting schedule changing?

 Thanks,
 Michael.


 Marvin wrote:

 Dear podling,

 This email was sent by an automated system on behalf of the Apache
 Incubator PMC.
 It is an initial reminder to give you plenty of time to prepare your
 quarterly
 board report.

 The board meeting is scheduled for Wed, 21 December 2011, 10:00:00 PST.
 The report for your podling will form a part of the Incubator PMC report.
 The Incubator PMC requires your report to be submitted 2 weeks before the
 board meeting, to allow sufficient time for review and submission (Wed, Dec
 7th).

 Please submit your report with sufficient time to allow the incubator PMC,
 and subsequently board members to review and digest. Again, the very latest
 you should submit your report is 2 weeks prior to the board meeting.



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




 --
 http://www.somatik.be
 Microsoft gives you windows, Linux gives you the whole house.

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


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

Re: Incubator PMC/Board report for Dec 2011 ([ppmc])

2011-12-01 Thread Matt Benson 
On Thu, Dec 1, 2011 at 9:52 AM, Matt Benson gudnabr...@gmail.com wrote:
 That would explain why he claimed to have mailed BeanValidation-dev,
 and our yet having failed AFAIK to receive the notification.


Er, strike that--we got it after all.

 Matt

 On Thu, Dec 1, 2011 at 9:49 AM, Francis De Brabandere
 franci...@gmail.com wrote:
 Same thing on empire-db-dev@ I suppose Marvin (bot) somehow mailed the
 wrong projects.

 Cheers,
 F

 On Thu, Dec 1, 2011 at 2:57 AM, Michael Stroucken
 stroucki+apa...@andrew.cmu.edu wrote:
 The tashi-dev mailing list just got the following message from an
 unreplyable Marvin. The Tashi project reports in January, April, July and
 October.

 Can this be ignored, or is our reporting schedule changing?

 Thanks,
 Michael.


 Marvin wrote:

 Dear podling,

 This email was sent by an automated system on behalf of the Apache
 Incubator PMC.
 It is an initial reminder to give you plenty of time to prepare your
 quarterly
 board report.

 The board meeting is scheduled for Wed, 21 December 2011, 10:00:00 PST.
 The report for your podling will form a part of the Incubator PMC report.
 The Incubator PMC requires your report to be submitted 2 weeks before the
 board meeting, to allow sufficient time for review and submission (Wed, Dec
 7th).

 Please submit your report with sufficient time to allow the incubator PMC,
 and subsequently board members to review and digest. Again, the very latest
 you should submit your report is 2 weeks prior to the board meeting.



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




 --
 http://www.somatik.be
 Microsoft gives you windows, Linux gives you the whole house.

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


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

Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project

2011-11-30 Thread Matt Benson 
Mmm, shouldn't voting be carried out in a separate [VOTE] Accept
DeltaSpike... thread?

Matt

On Wed, Nov 30, 2011 at 10:21 AM, Matthias Wessendorf mat...@apache.org wrote:
 +1 (binding)

 -Matthias

 On Wed, Nov 30, 2011 at 1:24 PM, Jim Jagielski j...@jagunet.com wrote:
 +1 (binding)

 PS: Updated the proposal to re-add myself as Mentor...

 On Nov 29, 2011, at 6:40 PM, Mark Struberg wrote:

 Hi!

 JBoss, The Apache MyFaces CODI team and CDISource would like to propose the 
 Apache DeltaSpike project to the Incubator.

 We have added the initial proposal to the Wiki[1] and its content is also 
 included
 below for convenience.
 There are already a few people who expressed interest in contributing 
 additional CDI Extensions and would like to join this effort. Of course, we 
 are thankful for every helping hand!


 We are looking forward to feedback and/or questions on the proposal.

 We already have five mentors, but would very much welcome
 additional volunteers to help steer Apache DeltaSpike through the incubation
 process.




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




 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

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


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

Re: Mentoring projects

2011-09-03 Thread Matt Benson 
Certainly you can... typically you would drop a mail requesting
membership in the Incubator PMC to go along with your mentor status,
on this very list IIRC.

Matt

On Sat, Sep 3, 2011 at 9:14 AM, Simone Tripodi simonetrip...@apache.org wrote:
 Hi all guys,
 this mail for asking for clarification if, having been recently voted
 as a new ASF member, I can be enlisted as a mentor in incubation
 projects.
 Many thanks in advance, all the best!
 Simo

 http://people.apache.org/~simonetripodi/
 http://www.99soft.org/

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



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

Re: [VOTE] Release Bean Validation 0.3-incubating

2011-04-07 Thread Matt Benson 
On Thu, Apr 7, 2011 at 2:38 PM, sebb seb...@gmail.com wrote:
 On 7 April 2011 18:14, Donald Woods dwo...@apache.org wrote:
 This is the third release of Apache Bean Validation.

 We have already received 4 binding IPMC votes during the PPMC voting
 below, so I'm requesting a 72 hour lazy consensus before releasing the
 artifacts.


 Thanks,
 Donald

  Original Message 
 Subject: [RESULT] [VOTE] Release Bean Validation 0.3-incubating
 Date: Sun, 03 Apr 2011 07:35:44 -0400
 From: Donald Woods dwo...@apache.org
 Reply-To: bval-...@incubator.apache.org
 To: bval-...@incubator.apache.org, priv...@incubator.apache.org

 Vote passed with the following:
    +1 Donald Woods, Mark Struberg, Kevan Miller, Niall Pemberton,
        Albert Lee, Jeremy Bauer,
     0 Gerhard Petracek
 There were no -1 votes.

 Following +1 votes were from IPMC members:
    Donald Woods, Mark Struberg, Kevan Miller, Niall Pemberton


 For the IPMC, please review and I'll conclude the vote after the 72 hour
 review period.


 Thanks,
 Donald


 On 2/3/11 11:02 PM, Donald Woods wrote:
 A Bean Validation 0.3-incubating release candidate has been created with
 the following artifacts up for a vote:

 SVN source tag (r1067061):
 https://svn.apache.org/repos/asf/incubator/bval/tags/0.3-incubating/

 NOTICE: Copyright date still 2010; agimatec = Agimatec

 Not a blocker for this release, but should be fixed before the next.

Fixed in trunk; thanks Seb!

Matt


 Otherwise from a brief poke around it all looks fine.

 BTW, I like the way the website handles the disclaimer and Incubator
 references - very clear.


 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachebval-033/

 Source release:
 https://repository.apache.org/content/repositories/orgapachebval-033/org/apache/bval/bval-parent/0.3-incubating/bval-parent-0.3-incubating-source-release.zip

 Javadoc staging site:
 http://people.apache.org/~dwoods/bval/0.3-incubating/staging-site/apidocs/

 PGP release keys (signed using D018E6B1):
 https://svn.apache.org/repos/asf/incubator/bval/KEYS


 Vote will be open for 72 hours.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)


 Thanks,
 Donald



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



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



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

Re: [VOTE] Accept OpenNLP for incubation

2010-11-19 Thread Matt Benson 

On Nov 19, 2010, at 3:48 AM, Jörn Kottmann wrote:

 Hi,
 
 lets vote on the acceptance of the OpenNLP Project for incubation
 at the Apache Incubator.
 
 The proposal is on the wiki
 http://wiki.apache.org/incubator/OpenNLPProposal
 and a copy is included below.
 
 The discussion thread can be found here:
 http://mail-archives.apache.org/mod_mbox/incubator-general/201011.mbox/%3c4ce4f1f4.3010...@gmail.com%3e
 
 Please cast your votes:
 
 [X] +1 Accept OpenNLP for incubation
 [ ] +0 Don't care
 [ ] -1 Reject for the following reason:
 

-Matt


 The vote is open for at least 72 hours.
 
 Thanks!
 Jörn
 
 = OpenNLP Proposal =
 The following is a proposal for a new top-level project within the ASF.
 
 == Abstract ==
 OpenNLP is a Java machine learning toolkit for natural language processing 
 (NLP).
 
 == Proposal ==
 OpenNLP is a machine learning based toolkit for the processing of natural 
 language text.  It supports the most common NLP tasks, such as tokenization, 
 sentence segmentation, part-of-speech tagging, named entity extraction, 
 chunking, parsing, and coreference resolution.  These tasks are usually 
 required to build more advanced text processing services.
 
 The goal of the OpenNLP project will be to create a mature toolkit for the 
 abovementioned tasks.  An additional goal is to provide a large number of 
 pre-built models for a variety of languages, as well as the annotated text 
 resources that those models are derived from.
 
 == Background ==
 OpenNLP was started in 2000 by Jason Baldridge and Gann Bierner while they 
 were graduate students in the Division of Informatics at the University of 
 Edinburgh. OpenNLP, broadly speaking, was meant to be a high-level 
 organizational unit for various open source software packages for natural 
 language processing; more practically, it provided a high-level package name 
 for various Java packages of the form opennlp.*. The first OpenNLP software 
 package was the Grok natural language parsing toolkit, which was also the 
 genesis of what is now called the OpenNLP Toolkit. The software released on 
 the OpenNLP sourceforge site (started in 2000, along with Grok) was simply a 
 set of interfaces defined in the package opennlp.common and referred to as 
 the OpenNLP Java API. The actual implementations of natural language 
 processing components were provided in Grok, along with code for sentence 
 parsing with Combinatory Categorial Grammar. This code was used heavily in 
 both Baldridge's and Biern
 er's dissertations. The first paper that used Grok, and especially the 
 components that would become the OpenNLP Toolkit is 
 [[http://comp.ling.utexas.edu/jbaldrid/papers/hockenmaier_etal_ESSLLI2000.pdf|Hockenmaier,
  Bierner and Baldridge (2000)]] (later updated as the journal article 
 [[http://comp.ling.utexas.edu/jbaldrid/papers/HockenmaierEtal2004.pdf|Hockenmaier,
  Bierner, and Baldridge (2004)]]).
 
 In 2003, it was decided to remove the NLP infrastructure from Grok as there 
 was a clear separation between the basic text processing components and the 
 syntactic and semantic analysis components. At the same time, Grok was 
 rebranded as OpenCCG (openccg.sf.net). The final release of the OpenNLP Java 
 API was made in March 2003; the new OpenNLP Toolkit was created from the API 
 and the Grok text processing components, with version 1.0 being released in 
 April 2004. The OpenNLP Toolkit and OpenCCG have evolved independently since 
 then and have mostly independent and active developer and user communities. 
 OpenCCG is primarily used in the academic community, while OpenNLP has 
 considerable use in both academia and industry. As in indication of the 
 academic impact of OpenNLP, a search on Google scholar (done in March 2010) 
 returned about 650 publications citing the package. Some of these include the 
 OpenNLP website and a few non-publications plus some self-citations. Based on 
 a scan of
 these results, we estimate that about 500 actual publications have used 
 OpenNLP in their work, and there are an addition 50 or so quasi-publications 
 like surveys and instruction manuals.
 
 The activity level of the OpenNLP project has fluctuated over that past 10+ 
 years, with a large uptick in the last two years especially. Most recently, 
 due both to the availability of new documentation and the release of version 
 1.5 , there have been many more downloads and page views for the OpenNLP 
 project. In fact, September 2010 had the most downloads (1,561) and project 
 web hits (226,391) of any month since the project's beginning in 2000, and 
 October is keeping pacing with that figure so far. As a result, OpenNLP has 
 gone from being in the 2000th to 4000th ranked project (between January and 
 May, 2010) to being ranked 570, 314, 181 and 439 for July, August, September, 
 and October respectively. Full details are available on the Sourceforge 
 statistics page for OpenNLP.  (There are 240,000 projects hosted on 
 SourceForge, though

Re: [DISCUSS] Poddling new committer process

2010-11-16 Thread Matt Benson 

On Nov 12, 2010, at 2:20 AM, ant elder wrote:

 I'd like to propose that the process for Incubator poddlings to make
 someone a new committer is simplified so that all that is needed are
 votes from poddling committers and that there is no longer any need
 for votes from Incubator PMC members or a separate Incubator PMC vote.
 
 As justification, this is the process that was in place some years ago
 and it worked fine like that, there is the experiment currently in
 place with some poddlings doing this which seems to be working ok, and
 the board has said they're ok with it.
 

+1

Matt

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


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

Re: [VOTE] experimental delegation of new committer votes to PPMC

2010-08-19 Thread Matt Benson 

On Aug 18, 2010, at 6:11 PM, Joe Schaefer wrote:

 Now that the board has declared there are no legal
 obstacles to what I have proposed, I'd like to
 restart the vote.
 

+1

-Matt

 Thanks for your patience and consideration.
 
 
 
 - Original Message 
 From: Joe Schaefer joe_schae...@yahoo.com
 To: general@incubator.apache.org
 Sent: Mon, August 16, 2010 1:44:08 PM
 Subject: [VOTE] experimental delegation of new committer votes to PPMC
 
 I have come to the realization that I'm not
 going to convince Noel to see  things my way
 any time soon, so I'd like to now ask for a
 formal majority  consensus vote on relaxed rules
 for the 3 aforementioned  projects.
 
 Specifically, for thrift, sis, and esme, I wish to
 remove  the current rule that requires 3 votes from
 IPMC members to approve a vote on  a new committer,
 effectively delegating the decision to the  PPMC.
 Additionally the pre-ack would be removed, but no
 other process  changes are anticipated.
 
 Here's my +1.
 
 
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


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

Re: an experiment

2010-08-11 Thread Matt Benson 

On Aug 11, 2010, at 4:14 PM, Joe Schaefer wrote:

 
 
 - Original Message 
 
 From: Davanum Srinivas dava...@gmail.com
 To: general@incubator.apache.org
 Sent: Wed, August 11, 2010 5:07:33 PM
 Subject: Re: an experiment
 
 +1 to IPMC delegates to the PPMC the decision-making
 process for voting in new  committers (one question,
 would they need an ACK from IPMC - similar to how  PMC's
 send a note to the board for an ACK for new pmc members)?
 
 That certainly sounds like a reasonable thing to do, sure.
 

+1

 In the  2nd question, significant committers, are we asking
 mentors to identify such  candidates for addition to IPMC, 
 especially release managers for example? if  so, +1 for that
 as well.
 

I was also curious as to the mechanism for determining significance--I would 
be satisfied with mentors' recommendation as outlined by dims.  I wonder if 
there should be some limit/function to determine the number of non-Member 
representatives a given podling may have on the IPMC.

-Matt

 Absolutely, especially RM's that have gotten into the habit
 of running RAT themselves.
 
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


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

Re: Commons issues WAS RE: [PROPOSAL] Commons Incubator

2009-04-16 Thread Matt Benson 



--- On Thu, 4/16/09, Niclas Hedhman nic...@hedhman.org wrote:

 From: Niclas Hedhman nic...@hedhman.org
 Subject: Re: Commons issues WAS RE: [PROPOSAL] Commons Incubator
 To: general@incubator.apache.org
 Date: Thursday, April 16, 2009, 4:47 AM
 On Thu, Apr 16, 2009 at 12:07 AM,
 Matt Benson gudnabr...@yahoo.com
 wrote:
 
   * IPMC informally agrees that the opinion of any TLP
 prospectively admitting a graduating podling as a subproject
 is of great weight with regard to whether the aggregate
 community situation would meet volume + diversity
 requirements (apologies if this is hard to parse).
 
 Ok, I think the IPMC already is considering this to be a
 good idea, on
 a case by case basis.
 
 Is everything settled then? ;-)
 

Insomuch as this mitigates the concern that it might be difficult to graduate a 
podling to Commons, I think so.  I'll consider your assessment of the community 
consensus as gospel unless I hear otherwise.  ;)

Going once...

-Matt

 
 Cheers
 -- 
 Niclas Hedhman, Software Developer
 http://www.qi4j.org - New Energy for Java
 
 I  live here; http://tinyurl.com/2qq9er
 I  work here; http://tinyurl.com/2ymelc
 I relax here; http://tinyurl.com/2cgsug
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 


  

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

RE: Commons issues WAS RE: [PROPOSAL] Commons Incubator

2009-04-16 Thread Matt Benson 



--- On Thu, 4/16/09, Noel J. Bergman n...@devtech.com wrote:

 From: Noel J. Bergman n...@devtech.com
 Subject: RE: Commons issues WAS RE: [PROPOSAL] Commons Incubator
 To: general@incubator.apache.org
 Date: Thursday, April 16, 2009, 11:30 AM
 Matt Benson wrote:
 
  I'll apologize in advance because I will probably
 sound like a total dick
 in this email being
  that I'm irritated for unrelated reasons at the
 moment.
 
 LOL Sorry to hear it, but I must have missed the part where
 you were so
 acting.
 

I felt like my tone might have been a little short below:

  let it now be known that Commons will not become a
 dumping ground.
  So can we drop this issue and return to the actual
 subject at hand?
 
 I hope so.  We *all* seem to be in violent agreement
 on the subject.
 
  the permanent part was mostly targeted at the issue
 of reducing
 repetitive infra tasks on behalf of podlings
  slated to become Commons components.
 
 I am, for the moment, dismissing the infra issues. 
 Not that I am missing
 the point, but becaue we already have a very old precedent
 for it: the
 projects@ mailing list.  So we can probably adopt a
 similar approach with
 Commons.
 

I am not familiar with this...

  I created the new subject in response to Noel's
 statement that
 (paraphrasing) the IPMC would
  like to work with Commons to address its valid issues,
 but that the
 proposal was a false start.
 
  With respect to bringing in new components from
 preexisting source with
 new-to-the-ASF committers,
  Commons would like to use incubator practices but we
 are concerned whether
 the community exit
  requirements are achievable for the typical Commons
 component.
 
 Should not be, no.  Consider your comment:
 
  IPMC informally agrees that the opinion of any TLP
 prospectively admitting
 a graduating podling
  as a subproject is of great weight with regard to
 whether the aggregate
 community situation
  would meet volume + diversity requirements (apologies
 if this is hard to
 parse).
 
 That's long settled.  :-)  If a PMC votes that
 they are going to take
 collective responsibility for a project, we have always
 considered that to
 resolve the diveristy requirement.

I hadn't seen any canon to the effect, beyond one somewhat noncommittal quote 
from Leo S. in 2005 when Hen was working on bringing [csv] in.  By the way, 
that project AFAICT came through IP clearance with no bundled committers and 
continues to languish in the sandbox.  :|

 
 Components intended for Commons should come through
 Incubation, but
 depending on the nature of the offering and the
 desire/willingness of
 Commons:
 
  1) Use IP clearance; admit the new committers to Commons
 and train them
 there to be good ASF citizens, alongside their Commons
 peers.
 
  2) Bring them through Incubation, as we've done (for
 example) with
 Sanselan.

Overall I think approach #2 is most in tune with what the Commons community 
wants to see.

 
 Do we agree?  Is there anything unsettled except for
 the infra issue?

As we've really done nothing but clarify intent wrt community exit requirements 
I feel that it's safe for me to accept this as our resolution on behalf of 
Commons.  I think all interested PMC members are tuned in anyway.  So what's 
the deal with the projects@ ML?

Thanks all,
Matt

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


  

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

Re: PROPOSAL to graduate Sanselan into Commons Incubator

2009-04-15 Thread Matt Benson 

Two comments:

(1) A Commons Incubator in the form put forth in the incubation proposal of the 
same name does not seem likely to happen, given the feedback on this list so 
far.

(2) If Commons would accept Sanselan, it having already been through the 
incubator would graduate as a proper, or possibly sandbox* component, AFAIK, so 
the Commons Incubator concept would be irrelevant here.  :)

* I'm just throwing ideas around, but the Commons PMC could theoretically 
decide to accept a graduating component into the sandbox if for example there 
were just not enough developers (3) available for immediate care and feeding of 
the prospective graduate podling.

Regards,
Matt

--- On Wed, 4/15/09, Carsten Ziegeler cziege...@apache.org wrote:

 From: Carsten Ziegeler cziege...@apache.org
 Subject: Re: PROPOSAL to graduate Sanselan into Commons Incubator
 To: general@incubator.apache.org
 Date: Wednesday, April 15, 2009, 8:54 AM
 Seems like perfect timing :)
 
 We just discussed our options last week in the Sanselan
 project. As
 Craig already summarized this, Sanselan has these options:
 graduate into
 commons (incubator), indefinite incubation, expulsion from
 Apache or
 incorporation into another TLP. Of course in theory it
 could become a
 TLP by itself, but I don't think that this will ever happen
 :)
 Expulsion or indefinite incubation are bad options as well
 and we don't
 see any other TLP than commons fit for the purpose of
 Sanselan.
 
 So, by crossing out all other options :) graduating to
 commons incubator
 seems like a good way forward.
 
 Carsten
 
 
 -- 
 Carsten Ziegeler
 cziege...@apache.org
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 


  

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

Re: Commons issues WAS RE: [PROPOSAL] Commons Incubator

2009-04-14 Thread Matt Benson 



--- On Tue, 4/14/09, Jochen Wiedmann jochen.wiedm...@gmail.com wrote:

 From: Jochen Wiedmann jochen.wiedm...@gmail.com
 Subject: Re: Commons issues WAS RE: [PROPOSAL] Commons Incubator
 To: general@incubator.apache.org
 Date: Tuesday, April 14, 2009, 1:22 AM
 On Tue, Apr 14, 2009 at 4:42 AM,
 Niclas Hedhman nic...@hedhman.org
 wrote:
 
  There seems to be some concern in Commons that
 committers are a threat
  to the existing codebase.
 
 I know the concerns you mention and felt them very much in
 the
 discussion about JSch. But, at least for me personally, I
 don't think
 that's my concern.
 
 Commons is working *now*. Just as Jakarta was working once.
 But
 Commons will most likely no longer work when it is growing
 too much.
 And the things discussed here (making Commons the target of
 many new
 subprojects, which aren't integrated into Commons, thus
 must likely
 will never be) are clearly implying this danger. That's not
 about
 external committers. It is about too many committers.
 
 
  I am still of the opinion that it can be handled
 within Commons, with
  IP Clearance registrations at the Incubator.
 
 Disagreed. Assuming that the Incubator changes its policy
 to have
 projects exiting without community: Why can't another
 project be the
 target (depending on the projects topic, of course). Why
 should this
 be so special to Commons?
 

Well, right... rules should never be made with explicit reference to any 
project.  Commons is special because it is a single community acting as 
custodian of several projects.  Any TLP-to-subproject structure, where a larger 
community pledges to take responsibility for the graduating podling, should be 
considered similarly.  This may already be acceptable in practice, but I'd at 
least like to see some explicit assurance of that fact.

-Matt

 
 Jochen
 
 
 -- 
 I have always wished for my computer to be as easy to use
 as my
 telephone; my wish has come true because I can no longer
 figure out
 how to use my telephone.
 
 -- (Bjarne Stroustrup,
 http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 


  

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

Commons issues WAS RE: [PROPOSAL] Commons Incubator

2009-04-13 Thread Matt Benson 

Received 3 declarations of intent to -1 (vote not in progress yet) from IPMC 
members so perhaps it's time to step back and talk about requirements since the 
proposed solution seems to sit unfavorably with several people on this list.  
Further commentary below:

--- On Sun, 4/12/09, Noel J. Bergman n...@devtech.com wrote:

 From: Noel J. Bergman n...@devtech.com
 Subject: RE: [PROPOSAL] Commons Incubator
 To: general@incubator.apache.org
 Date: Sunday, April 12, 2009, 9:49 PM
 Justin Erenkrantz wrote:
 
  Matt Benson gudnabr...@yahoo.com
 wrote:
   The Commons Incubator would act as a perpetual
 podling or
   mini-Incubator overseeing the influx of
 components to be
   adopted into Apache Commons.
 
  -1 (vote, not veto).
 
 -1 from me, at least for now, for the same reasons:
 
  If Commons PMC wants to import code, then it can file
 IP clearances.
  If it wants to incubate communities, then it needs to
 follow the rest
  of the Incubator procedures.
 
 That said, we want to work with Apache Commons to address
 its valid issues.
 But the proposal appears to be a false step.

Fair enough.

another Noel quote:
 Keep in mind that Committers in the Incubator are not provisional.
 The projects are, but not the people.  We can definitely talk about
 incubating a project before it moves into Apache Commons, especially
 larger ones.

You say that podling committers are not provisional; I'll turn that around and 
reword that as a committer to a TLP is not 'more real' a committer than a 
person who only has commit access to a podling/s.  But in the rare event that 
the IPMC declares a given incubation failed what happens to those committers? 
 They're still real committers; they just happen not to have access to commit 
to anything?  I'm an ASF committer.  Really?  What project do you work on?  
Oh, I don't have access to commit to any projects; I just AM a committer.  :P 
 That little bit of strangeness aside, I'll try to boil down the situation:

The primary obstacle to Commons using the normal Incubator practices is the 
community exit requirements.  We feel that, due to the small size/scope of a 
Commons component, a podling graduating into Commons should be able to do so 
with a minimal community PROVIDED that there is a total of at least three 
guardians (to play on the orphan concept) including the podling committers 
(becoming full Commons committers, with all that implies) in addition to 
existing Commons committers who explicitly declare themselves interested and 
available to support the graduating component.

The other issue we had is that it seems a waste of resources to go through the 
infra side of incubation for such small components, but that's not much skin 
off our proverbial nose in any case...

Can the IPMC agree on a solution to address our issue(s)?

Thanks,
Matt

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


  

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

Re: [PROPOSAL] Commons Incubator

2009-04-10 Thread Matt Benson 



--- On Fri, 4/10/09, Torsten Curdt tcu...@apache.org wrote:

 From: Torsten Curdt tcu...@apache.org
 Subject: Re: [PROPOSAL] Commons Incubator
 To: general@incubator.apache.org
 Date: Friday, April 10, 2009, 5:32 AM
 Well, the point is: we are 
 talking about small libraries.
 
 Imagine there is library X which was developed by only 2
 developers.
 They want to bring this code to Commons. What to do? IP
 clearance is
 one thing. But what about the 2 developers? Just make them
 committers
 while they have no clue about Apache? Doesn't sound like a
 good idea.
 Just accepting their code and make them send patches until
 we feel
 they are ready? Feels not appropriate since they are the
 authors of
 the code. On the other hand going through the normal
 incubator is a
 bit over the top for a project that is so small that it is
 not
 targeting to become it's own project. Building a community
 is not
 really that applicable in this case. It's rather about
 integrating it
 into an existing community.
 

Thanks Torsten--I think you've pointed out the proverbial Scylla and Charybdis 
here:

 * IP clearance means reducing the original authors of codebase X to 
contributor status.  It could be argued that this is a way of teaching them 
that within the context of the ASF, the direction of their code will be 
determined by the community.  More likely, however, they will simply opt to 
take their ball and go home.  Surely there are better ways to teach the Apache 
way.

 * full Incubation sets a small component up for failure to graduate due to 
not gaining a community large or diverse enough to satisfy Incubator graduation 
requirements, when, were the same code to begin life in the Commons sandbox, 
originated by ANY existing ASF committer, it would be subject to somewhat less 
stringent graduation (to Commons proper) requirements.

The other problem with full incubation, inordinate effort to set up _n_ 
relatively tiny podlings, really affects infrastructure more than it affects 
Commons.

The current state of affairs makes it highly impractical for any codebase that 
includes IP from a non-ASF-committer to enter Apache Commons.  What we are 
asking for could be alternately seen as the Incubator's blessing to establish a 
decontamination chamber much like our sandbox but where community members can 
commit prior to their component being accepted into Commons proper and their 
consequentially becoming true ASF committers.  Note that some of my wording 
reflects a perception on my part that there is a difference between a podling 
committer and a committer to some TLP (or TLP subproject).  If that is not the 
case, I'd be interested to know that, but I don't believe it affects the 
overall argument here either way.  We need an officially sanctioned concept for 
Commons podling committer.

[SNIP]
  On Fri, Apr 10, 2009 at 11:59 AM, Justin Erenkrantz
  jus...@erenkrantz.com
 wrote:
[SNIP]
 
  -1 (vote, not veto).

Finally, I'm apparently not familiar enough with incubator procedures to 
understand when a -1 is not a veto.  Can anyone provide any more info on 
that?  :)

Regards,
Matt

[SNIP]



  

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

[PROPOSAL] Commons Incubator

2009-04-09 Thread Matt Benson 

Note: Resending due to my having neglected the [PROPOSAL] subject line earlier.

==

Commons Incubator Proposal

ABSTRACT

The Commons Incubator would act as a perpetual podling or mini-Incubator 
overseeing the influx of components to be adopted into Apache Commons.


BACKGROUND

Apache Commons, a conglomerate of smallish Java libraries, lacks a good 
procedure for importing preexisting codebases.


RATIONALE

  The typical ASF top-level project (TLP) absorbs code donations by means of a 
software grant.  Clearly delineated subprojects (usually partially or 
completely dependent on the TLP) often enter instead through the Incubator.  
Commons, as a project that has no code other than that of its subprojects, is 
essentially a microcosm of the ASF itself.  Commons has long offered a
sandbox area for the development of new ideas, similar to the approach now 
taken in Apache Labs.  With regard to the creation of new subprojects from 
preexisting codebases, however, the PMC is in agreement that procedures similar 
to those in practice in the ASF Incubator are more appropriate
than the software grant approach, given that the Incubator has already 
formalized much the same process as would need to be taken to guarantee the 
acceptability of donated code.  Unfortunately the processes of the Incubator 
proper are not a perfect fit.

  With regard to community exit requirements, a typical podling requires a 
heterogenous community of three or more developers.  Commons is an open 
community in the sense that all Commons committers have karma to all 
components, thus any component to graduate into Commons proper inherits an 
existing, diverse community.  This greatly mitigates any component's risk of 
orphanhood.  The PMC envisions Commons' incubator space as functioning in a 
manner similar to that in which its development sandbox currently operates:  
all ASF committers are welcome to participate in the Commons sandbox, and would 
be welcome to contribute to incubating components, subject to a natural 
consensus-building process.  Active contributors to graduating components would 
be accepted into the project as full Commons committers with shared karma.

  Another aspect of existing Incubator practices that is suboptimal for 
Commons' requirements is the fact that, a Commons component being a relatively 
small entity, it is difficult to justify expending the
same effort to set one up as would typically be required for a normal-sized 
podling.  For this reason it would be advantageous to keep incubating Commons 
components under a single Subversion tree, and as subcomponents of a single 
JIRA project.  Finally, the existing Commons communications lists could be 
utilized.  Component setup would thus be minimal.

  Having established that setting up a Commons Incubator separate from the 
Apache Incubator would be counterproductive and quite a duplication of effort, 
Commons would like to see established on its behalf a special case podling or 
miniature Incubator whose exit criteria parallel those Commons uses to gauge 
the propriety of a sandbox component's promotion to proper status, namely:

  * The component is ready for its first ASF release.
  * At least three people are available for development/maintenance.
  * All Incubator legal checks have been passed.


INITIAL GOALS

  Prove/hone the Commons Incubator approach on several candidates that have 
been proposed as new Apache Commons subprojects, and for which a PMC vote 
indicates willingness to incubate.


CURRENT STATUS

  (Applicable at incubating component level)

Meritocracy:

Community:

Core Developers:

Alignment:


KNOWN RISKS

  (Where applicable, at incubating component level)

Orphaned Products:

  N/A

Inexperience with Open Source:

Homogenous Developers:

  N/A

Reliance on Salaried Developers:

  N/A

No Ties to Other Apache Products:

A Fascination with the Apache Brand:


DOCUMENTATION

  (Applicable at incubating component level)


INITIAL SOURCE

  (Applicable at incubating component level)


EXTERNAL DEPENDENCIES
  Optimally any non-optional dependencies for Commons components will be other 
Commons
  components.  Failing that, normal ASF third-party licensing policies to be 
enforced.


REQUIRED RESOURCES

Mailing Lists:
  Commons lists

Subversion Directory:
  Umbrella under Commons or Incubator

Issue Tracking:
  JIRA project with subcomponents to be managed by Mentors a la Commons Sandbox


INITIAL COMMITTERS

  (Applicable at incubating component level)


AFFILIATIONS

  (Applicable at incubating component level)


SPONSORS

Champion:  Henri Yandell

Nominated Mentors:  Henri Yandell, Matt Benson(, need volunteer/s)

Sponsoring Entity:  Commons PMC


April 9, 2009


  

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

Fw: Commons Incubator proposal

2009-04-07 Thread Matt Benson 

Oops; accidentally sent to general-subscribe:

--- On Tue, 4/7/09, Matt Benson gudnabr...@yahoo.com wrote:

 From: Matt Benson gudnabr...@yahoo.com
 Subject: Commons Incubator proposal
 To: incubator-general general-subscr...@incubator.apache.org
 Cc: priv...@commons.apache.org
 Date: Tuesday, April 7, 2009, 10:10 AM
 
 Below is the proposal to be found at 
 http://wiki.apache.org/incubator/CommonsIncubatorProposal
 .  For example, this would (subject to community
 approval, of course) be an acceptable avenue for incubation
 in Commons of the JEHA project proposed in the past few
 days.  Commons is more or less unable to accept
 components of external origin until this proposal or a
 suitable alternative is adopted.  Please voice any
 concerns or propose any such alternatives.
 
 Thanks,
 Matt
 
 == 
 
 Commons Incubator Proposal
 
 ABSTRACT
 
 The Commons Incubator would act as a perpetual podling or
 mini-Incubator overseeing the influx of components to be
 adopted into Apache Commons.
 
 
 BACKGROUND
 
 Apache Commons, a conglomerate of smallish Java libraries,
 lacks a good procedure for importing preexisting codebases.
 
 
 RATIONALE
 
   The typical ASF top-level project (TLP) absorbs code
 donations by means of a software grant.  Clearly
 delineated subprojects (usually partially or completely
 dependent on the TLP) often enter instead through the
 Incubator.  Commons, as a project that has no code
 other than that of its subprojects, is essentially a
 microcosm of the ASF itself.  Commons has long offered
 a
 sandbox area for the development of new ideas, similar to
 the approach now taken in Apache Labs.  With regard to
 the creation of new subprojects from preexisting codebases,
 however, the PMC is in agreement that procedures similar to
 those in practice in the ASF Incubator are more appropriate
 than the software grant approach, given that the Incubator
 has already formalized much the same process as would need
 to be taken to guarantee the acceptability of donated
 code.  Unfortunately the processes of the Incubator
 proper are not a perfect fit.
 
   With regard to community exit requirements, a
 typical podling requires a heterogenous community of three
 or more developers.  Commons is an open community in
 the sense that all Commons committers have karma to all
 components, thus any component to graduate into Commons
 proper inherits an existing, diverse community.  This
 greatly mitigates any component's risk of orphanhood. 
 The PMC envisions Commons' incubator space as functioning in
 a manner similar to that in which its development sandbox
 currently operates:  all ASF committers are welcome to
 participate in the Commons sandbox, and would be welcome to
 contribute to incubating components, subject to a natural
 consensus-building process.  Active contributors to
 graduating components would be accepted into the project as
 full Commons committers with shared karma.
 
   Another aspect of existing Incubator practices that
 is suboptimal for Commons' requirements is the fact that, a
 Commons component being a relatively small entity, it is
 difficult to justify expending the
 same effort to set one up as would typically be required
 for a normal-sized podling.  For this reason it would
 be advantageous to keep incubating Commons components under
 a single Subversion tree, and as subcomponents of a single
 JIRA project.  Finally, the existing Commons
 communications lists could be utilized.  Component
 setup would thus be minimal.
 
   Having established that setting up a Commons
 Incubator separate from the Apache Incubator would be
 counterproductive and quite a duplication of effort, Commons
 would like to see established on its behalf a special case
 podling or miniature Incubator whose exit criteria parallel
 those Commons uses to gauge the propriety of a sandbox
 component's promotion to proper status, namely:
 
   * The component is ready for its first ASF release.
   * At least three people are available for
 development/maintenance.
   * All Incubator legal checks have been passed.
 
 
 INITIAL GOALS
 
   Prove/hone the Commons Incubator approach on several
 candidates that have been proposed as new Apache Commons
 subprojects, and for which a PMC vote indicates willingness
 to incubate.
 
 
 CURRENT STATUS
 
   (Applicable at incubating component level)
 
 Meritocracy:
 
 Community:
 
 Core Developers:
 
 Alignment:
 
 
 KNOWN RISKS
 
   (Where applicable, at incubating component level)
 
 Orphaned Products:
 
   N/A
 
 Inexperience with Open Source:
 
 Homogenous Developers:
 
   N/A
 
 Reliance on Salaried Developers:
 
   N/A
 
 No Ties to Other Apache Products:
 
 A Fascination with the Apache Brand:
 
 
 DOCUMENTATION
 
   (Applicable at incubating component level)
 
 
 INITIAL SOURCE
 
   (Applicable at incubating component level)
 
 
 EXTERNAL DEPENDENCIES
   Optimally any non-optional dependencies for Commons
 components will be other

site updated

2008-09-11 Thread Matt Benson 
...for IP clearance; could someone push the updated
site out to p.a.o?

Thanks,
Matt


  

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

[IP CLEARANCE] commons-flatfile

2008-09-11 Thread Matt Benson 
The Commons PMC have voted [1] to accept a
contribution [2] of a Java library for the handling of
flat data structures.

The required paperwork has been recorded by the ASF
Secretary, and the IP form completed in the incubator
website [3].

Please inform me of any issues you see.

[1] http://markmail.org/message/3b7xc76lvmurzkqe
[2]
http://svn.apache.org/repos/asf/incubator/donations/commons-pmc/flatfile/
[3]
http://incubator.apache.org/ip-clearance/commons-flatfile.html

Thanks,
Matt



  

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

Re: seeking clarification wrt ip-clearance processes

2008-09-10 Thread Matt Benson 
--- Craig L Russell [EMAIL PROTECTED] wrote:

 What the incubator guides currently say about
 importing code

http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
 
   implies that the code that's imported has the old
 license text, and  
 it's cleaned up in the incubation process.
 
 For an existing TLP, the guide doesn't apply. But
 since best practice  
 in incubation seems to be to import exactly what was
 in the external  
 repo, I don't see that an existing project should
 have an issue. I  
 would put the imported code into a special part of
 the TLP's  
 repository (e.g. tlp/import next to tlp/trunk) just
 to make sure it  
 isn't accidentally shipped.


Thanks for the info, Craig!

-Matt



 
 Of course, running RAT on the release would catch it
 but still...
 
 Craig
 
 On Sep 9, 2008, at 7:47 PM, Matt Benson wrote:
 
  I am processing the IP clearance for a code
 donation
  to the Commons TLP; commons-flatfile.  I am
 somewhat
  confused by the requirement to apply the Licensed
 to
  the Apache Software Foundation headers to the
 code
  _before_ the IP clearance template is considered
 to
  have been filled out.  The very act of applying
 the
  headers will invalidate the checksums; what is the
  procedure I am supposed to implement here?  I.e.
  where do I apply the headers?
 
  Thanks,
  Matt
 
 
 
 
 

-
  To unsubscribe, e-mail:
 [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 
 Craig L Russell
 Architect, Sun Java Enterprise System
 http://db.apache.org/jdo
 408 276-5638 mailto:[EMAIL PROTECTED]
 P.S. A good JDO? O, Gasp!
 
 



  

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

Multiple hats for members wrt a podling

2008-01-31 Thread Matt Benson 
I'm looking for general feedback about the group's
perception of incubated projects and the number of
roles that may be assumed by a foundation member in
one.  Can I view RAT as an example that it would be
considered kosher for a member to be both champion of
and an initial committer on a given proposal?  And in
contrast, that it _would_ be considered a conflict of
interest/logistical impossibility for a committer to
be a mentor?

Thanks,
Matt


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


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

Re: Multiple hats for members wrt a podling

2008-01-31 Thread Matt Benson 
Thanks all for the responses received so far (as well
as any yet to come)!

-Matt

--- Yoav Shapira [EMAIL PROTECTED] wrote:

 On Jan 31, 2008 2:36 PM, Jukka Zitting
 [EMAIL PROTECTED] wrote:
  On Jan 31, 2008 9:20 PM, Matt Benson
 [EMAIL PROTECTED] wrote:
   I'm looking for general feedback about the
 group's
   perception of incubated projects and the number
 of
   roles that may be assumed by a foundation member
 in
   one.
 
  I don't see a problem with people wearing many
 hats. I'm both a mentor
  and a committer of the Tika podling, and so far
 I've experienced no
  cases where the roles would be in a conflict.
 
 +1, and by now I think I have a pretty healthy
 amount of incubated
 projects as experience ;)
 
 Yoav
 

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



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

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

Re: [Vote] Accept JRS project for incubation

2007-06-29 Thread Matt Benson 
Another non-binding +1 here.

-Matt

--- Martijn Dashorst [EMAIL PROTECTED]
wrote:

 +1 (non-binding)
 
 Martijn
 
 -- 
 Wicket joins the Apache Software Foundation as
 Apache Wicket
 Join the wicket community at irc.freenode.net:
 ##wicket
 Wicket 1.2.6 contains a very important fix. Download
 Wicket now!
 http://wicketframework.org
 

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



   

Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for 
today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  

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

Re: [Proposal] Java Resource Simulator (JRS)

2007-06-25 Thread Matt Benson 

--- robert burrell donkin
[EMAIL PROTECTED] wrote:

 On 6/25/07, Martijn Dashorst
 [EMAIL PROTECTED] wrote:
 
  From an incubator point of view, I think having
 the sources available
  is not yet necessary. Having a clear proposal what
 the project is
  going to do, and who is going to do it is more
 important, especially
  with a third party donation. I think we should
 focus more on diversity
  of the community rather than the actual code.
 
 
 +1
 
 The code can be cleaned and cleared inside the
 incubator afiac.
 

A little late into the conversation, but if the
original intent was to make it possible to see some of
the concrete ideas being promoted, would providing the
javadoc, perhaps even only of a few top-level packages
and/or interfaces, be a possible compromise involving
significantly less work than actually modifying all
the necessary code headers?

-Matt

 
 +1
 
 - robert
 



   

Choose the right car based on your needs.  Check out Yahoo! Autos new Car 
Finder tool.
http://autos.yahoo.com/carfinder/

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