Re: [PROPOSAL] BatchEE to implement JBatch @apache

[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 
>
> > 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 *
> > *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é 
> >
> > > +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 :
> > >>
> > >>> 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 :
> > >>>
> >  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

Re: [PROPOSAL] BatchEE to implement JBatch @apache

[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 wrote:

> 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 
> 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 
> >>
> >> > 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é 
> >> >
> >> > > +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 :
> >> > >>
> >> > >>> 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 :
> >> > >>>
> >> > >>>> 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>
> >> > >>>>

Re: [VOTE] BatchEE as an incubated project

[Matt Benson]

+1 (binding)

Matt


On Sun, Sep 29, 2013 at 11:52 PM, Romain Manni-Bucau
wrote:

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

Re: [PROPOSAL] Weave for Apache Incubator

[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  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 ex

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

[Matt Benson]

+1 (binding)

Matt


On Sat, Mar 30, 2013 at 11:54 AM, Mark Struberg  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 
> Mark Struberg 
> Pete Muir 
> Jason Porter 
> Shane Bryzak 
> Rudy de Busscher  Christian Kaltepoth 
> Arne Limburg 
> Charles Moulliard 
> Cody Lerum 
> Romain Mannu-Buccau 
> Matthew Jason Benson 
> Jim Jagielski 
> David Blevins 
> Ken Finnigan 
> John D. Ament 
>
> 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: [VOTE] Release Bean Validation 0.3-incubating

[Matt Benson]

On Thu, Apr 7, 2011 at 2:38 PM, sebb  wrote:
> On 7 April 2011 18:14, Donald Woods  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 
>> 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: Mentoring projects

[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  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: an experiment

[Matt Benson]

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

> 
> 
> - Original Message 
> 
>> From: Davanum Srinivas 
>> 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: [VOTE] experimental delegation of new committer votes to PPMC

[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 
>> 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: [DISCUSS] Poddling new committer process

[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] Accept OpenNLP for incubation

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

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

[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  wrote:
> +1 (binding)
>
> -Matthias
>
> On Wed, Nov 30, 2011 at 1:24 PM, Jim Jagielski  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: Incubator PMC/Board report for Dec 2011 ([ppmc])

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

[Matt Benson]

On Thu, Dec 1, 2011 at 9:52 AM, Matt Benson  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
>  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
>>  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: [VOTE] DeltaSpike to join the Incubator

[Matt Benson]

quired.
>>>
>>> Initial Source
>>> 
>>>
>>> Source  code contributions for the Apache DeltaSpike project would be made
>>> from  its member projects, and the initial goal would be to provide a
>>> common core extension which contains a number of features considered
>>> essential for building other extensions.  Tests for this common core will be
>>> developed  using the Arquillian integration testing framework, allowing
>>> the  extension to be automatically tested extensively across various CDI
>>> implementations and EE servers in the interest of providing a stable
>>> foundation for building other extensions.
>>> The ongoing goal of the project will be to gradually incorporate
>>> additional  features as determined by the PPMC, extending on the
>>> foundation  features provided by the common core.
>>>
>>> Source and IP Submission Plan
>>> 
>>>
>>> The following resources will be moved to Apache infrastructure under the
>>> Apache DeltaSpike project name:
>>>     * Core JBoss Seam 3 codebase.  Seam 3 is already licensed under the
>>> Apache License V2.
>>>     * Seam Core Reference Documentation
>>>     * Apache MyFaces CODI codebase
>>>     * Apache MyFaces CODI documentation
>>>     * CDISource codebase under the Apache License V2
>>> The existing Seam, MyFaces CODI and CDISource trademarks will be retained
>>> by their respective owners.
>>>
>>> External Dependencies
>>> 
>>>
>>> The following external dependencies have been identified:
>>>     * Apache Maven - Java based build tool - Apache License 2.0,
>>> (non-runtime)
>>>     * Arquillian - Java EE integration testing framework - Apache License
>>> 2.0, (non-runtime)
>>>     * Shrinkwrap - Java deployment packaging - Apache License 2.0
>>> (non-runtime)
>>>     * various Java EE API packages - all Apache License 2.0 (non-runtime)
>>>
>>>
>>>
>>> Required Resources
>>> --
>>>
>>>
>>> Mailing Lists
>>> 
>>>
>>>     * deltaspike-us...@incubator.apache.org
>>>     * deltaspike-...@incubator.apache.org
>>>     * deltaspike-comm...@incubator.apache.org
>>>     * deltaspike-priv...@incubator.apache.org
>>>
>>> Version Control
>>> 
>>>
>>> It  is proposed that the source code for the Apache DeltaSpike project be
>>> hosted in the Apache Git repository, under the following directory:
>>>     * incubator/deltaspike/
>>>
>>> Issue Tracking
>>> 
>>>
>>> The following JIRA project would be required to track issues for the Apache
>>> DeltaSpike project:
>>>     * DELTASPIKE
>>>
>>> Initial Committers
>>> 
>>>
>>>     * 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: [DISCUSS] Apache Bean Validation as a TLP

[Matt Benson]

+1

Matt

On Tue, Jan 3, 2012 at 9:17 AM, Mohammad Nour El-Din  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 
>         * Carlos Vara Callau 
>         * David Jencks 
>         * Donald Woods 
>         * Gerhard Petracek 
>         * Jeremy Bauer 
>         * Kevan Lee Miller 
>         * Luciano Resende 
>         * Matthias Wessendorf 
>         * Matthew Jason Benson 
>         * Mohammad Nour El-Din 
>         * Niall Pemberton 
>         * Roman Stumm 
>         * Simone Tripodi 
>         * Mark Struberg 
>
>       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] Recommend graduating Apache Bean-Validation (BVAL) as a TLP

[Matt Benson]

+1

Matt

On Sun, Jan 8, 2012 at 3:04 PM, Mark Struberg  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 
> * Carlos Vara Callau 
> * David Jencks 
> * Donald Woods 
> * Gerhard Petracek 
> * Jeremy Bauer 
> * Kevan Lee Miller 
> * Luciano Resende 
> * Matthias Wessendorf 
> * Matthew Jason Benson 
> * Mohammad Nour El-Din 
> * Niall Pemberton 
> * Roman Stumm 
> * Simone Tripodi 
> * Mark Struberg 
>
>
> 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, 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

[Matt Benson]

On Mon, Jan 9, 2012 at 5:08 AM, Jukka Zitting  wrote:
> Hi,
>
> +1 to graduate, with the following note:
>
> On Sun, Jan 8, 2012 at 10:04 PM, Mark Struberg  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: DeltaSpike IP clarifications

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

DeltaSpike IP clarifications

[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

[Matt Benson]

On Tue, Jan 17, 2012 at 12:43 PM, ralph.goers @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 wrote:
>
>> 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 
>>
>> > 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  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

[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  wrote:
> On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @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

[Matt Benson]

Thanks for the simple example, Ralph.  :)

Matt

On Tue, Jan 17, 2012 at 2:25 PM, ralph.goers @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  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  wrote:
>> > On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @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.
>> >
&g

Re: DeltaSpike IP clarifications

[Matt Benson]

Adding deltaspike-dev back to the distribution:

On Tue, Jan 17, 2012 at 3:01 PM, Gerhard Petracek  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 
>
>> 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 
>>
>>> On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @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

[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  wrote:
> Adding deltaspike-dev back to the distribution:
>
> On Tue, Jan 17, 2012 at 3:01 PM, Gerhard Petracek  
> 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 
>>
>>> 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 
>>>
>>>> On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @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

[Matt Benson]

On Tue, Jan 17, 2012 at 4:52 PM, Sam Ruby  wrote:
> On Tue, Jan 17, 2012 at 5:17 PM, Matt Benson  wrote:
>> 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?
>
> Point them to clause 5.  But perhaps a phone call is in order?  I am
> likely in the same timezone as the RH counsel, in fact, I may even be
> in the same city.
>

I am told he is in EST.  I am in CST (no idea whether my participation
would actually be beneficial, but so far I've been the primary point
of contact between the incubator and Red Hat counsel on this).  I will
refer them to clause 5, make my usual halting attempt to explain what
I think you're saying it's saying, and tell them you are willing to
have the call if it would be helpful.

Thanks, Sam!

Matt

>> 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.
>
> - Sam Ruby
>
>> On Tue, Jan 17, 2012 at 3:08 PM, Matt Benson  wrote:
>>> Adding deltaspike-dev back to the distribution:
>>>
>>> On Tue, Jan 17, 2012 at 3:01 PM, Gerhard Petracek  
>>> 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 
>>>>
>>>>> 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 
>>>>>
>>>>>> On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @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: [VOTE] Release DeltaSpike 0.1-incubating

[Matt Benson]

On Tue, Feb 7, 2012 at 1:20 PM, Gerhard Petracek  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

[Matt Benson]

On Tue, Feb 7, 2012 at 3:57 PM, Ralph Goers  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
>> 
>> [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 
>>   - Carlos Vara Callau 
>>   - David Jencks 
>>   - Donald Woods 
>>   - Gerhard Petracek 
>>   - Jeremy Bauer 
>>   - Kevan Lee Miller 
>>   - Luciano Resende 
>>   - Matthias Wessendorf 
>>   - Matthew Jason Benson 
>>   - Mohammad Nour El-Din 
>>   - Niall Pemberton 
>>   - Roman Stumm 
>>   - Simone Tripodi 
>>   - Mark Struberg 
>>
>> 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: [DISCUSS] Apache BVal as a TLP

[Matt Benson]

On Wed, Feb 8, 2012 at 8:32 AM, Mohammad Nour El-Din
 wrote:
> Hi...
>
> On Tue, Feb 7, 2012 at 11:01 PM, Matt Benson  wrote:
>>
>> On Tue, Feb 7, 2012 at 3:57 PM, Ralph Goers 
>> 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 
>> >>   - Carlos Vara Callau 
>> >>   - 

Re: [VOTE] Apache BVal as a TLP

[Matt Benson]

On Wed, Feb 8, 2012 at 8:39 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].
>
> *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
> 
> [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 
>   - Carlos Vara Callau 
>   - David Jencks 
>   - Donald Woods 
>   - Gerhard Petracek 
>   - Jeremy Bauer 
>   - Kevan Lee Miller 
>   - Luciano Resende 
>   - Matthias Wessendorf 
>   - Matthew Jason Benson 
>   - Mohammad Nour El-Din 
>   - Roman Stumm 
>   - Simone Tripodi 
>   - Mark Struberg 
>
> 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] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)

[Matt Benson]

On Thu, Feb 9, 2012 at 9:16 AM, Mattmann, Chris A (388J)
 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  
>> 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  
>>> 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: Fw: [VOTE] Release Apache DeltaSpike-0.2-incubating

[Matt Benson]

On Wed, Apr 18, 2012 at 12:09 PM, Mark Struberg  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 
>> To: "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 
>>>  To: deltaspike 
>>>  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: Shepherd for EasyAnt

[Matt Benson]

On Thu, Jul 5, 2012 at 1:27 PM, Dave Fisher  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
>>  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

Multiple hats for members wrt a podling

[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

[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: seeking clarification wrt ip-clearance processes

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

site updated

[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

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

Fw: Commons Incubator proposal

[Matt Benson]

Oops; accidentally sent to general-subscribe:

--- On Tue, 4/7/09, Matt Benson  wrote:

> From: Matt Benson 
> Subject: Commons Incubator proposal
> To: "incubator-general" 
> 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 inc

[PROPOSAL] Commons Incubator

[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

Re: [PROPOSAL] Commons Incubator

[Matt Benson]

--- On Fri, 4/10/09, Torsten Curdt  wrote:

> From: Torsten Curdt 
> 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
> > 
> 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

Commons issues WAS RE: [PROPOSAL] Commons Incubator

[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  wrote:

> From: Noel J. Bergman 
> Subject: RE: [PROPOSAL] Commons Incubator
> To: general@incubator.apache.org
> Date: Sunday, April 12, 2009, 9:49 PM
> Justin Erenkrantz wrote:
> 
> > Matt Benson 
> 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: Commons issues WAS RE: [PROPOSAL] Commons Incubator

[Matt Benson]

--- On Tue, 4/14/09, Jochen Wiedmann  wrote:

> From: Jochen Wiedmann 
> 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 
> 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

Re: PROPOSAL to graduate Sanselan into Commons Incubator

[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  wrote:

> From: Carsten Ziegeler 
> 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

[Matt Benson]

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.  Now 
I'll attempt to steer this beast of a thread back on course while it's still 
possible to do so:

--- On Wed, 4/15/09, Jochen Wiedmann  wrote:

> From: Jochen Wiedmann 
> Subject: Re: Commons issues WAS RE: [PROPOSAL] Commons Incubator
> To: general@incubator.apache.org
> Date: Wednesday, April 15, 2009, 3:34 AM
> On Wed, Apr 15, 2009 at 9:56 AM,
> Niclas Hedhman 
> wrote:
> > On Tue, Apr 14, 2009 at 2:22 PM, Jochen Wiedmann
> > 
> wrote:
> >
> >> 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.
> >
> > Ah! I sure can relate to this, but isn't this a
> different issue altogether?
> 
> It possibly is, if my understanding of a "Commons
> Incubator" being
> related to the Commons project is wrong.
> 

I don't see how the potential issue of too many committers relates either.  It 
is an issue, but one that is not germane to this conversation as I see it.  
Relevant or not, 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?

> 
> > And in what sense would a "permanent commons
> incubation project" help with this?
> 
> It wouldn't. I am opposing such a project.
> 

FTR, the "permanent" part was mostly targeted at the issue of reducing 
repetitive infra tasks on behalf of podlings slated to become Commons 
components.  But the subject of this thread has changed; "Commons Incubator" is 
only referenced to show the thread from whence this thread spun off.  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.  This thread pretends such a proposal was never 
made, and presents Commons' issues with wide-eyed innocence for suggested 
solutions.  Since the thread has been thrust so far off-course I'll restate the 
situation:

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.

Some possible solutions:

 * Use IP clearance; make authors "earn" commit rights through sustained 
contribution as though they were just anybody.  Considered offensive to code 
donors.

 * Use IP clearance; admit the new committers to Commons and train them there 
to be good ASF citizens.  Concerns include culture shock (Commons is accustomed 
to creating committers out of sustained contributors) and extra 
incubation-esque mail traffic on d...@commons (already shared amongst all 
components).

 * 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).

Glad to hear other ideas,
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

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

[Matt Benson]

--- On Thu, 4/16/09, Niclas Hedhman  wrote:

> From: Niclas Hedhman 
> 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 
> 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

[Matt Benson]

--- On Thu, 4/16/09, Noel J. Bergman  wrote:

> From: Noel J. Bergman 
> 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] Java Resource Simulator (JRS)

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

Re: [Vote] Accept JRS project for incubation

[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: [ALL] Volunteers for a Math IPMC?

[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 move forward. There is some talk of
breaking
 Commons Math into smaller components and possibly dropping some
wher