Re: [DISCUSS] [REVISED] Mentor neutrality policy

[Alan D . Cabrera]

> On Oct 11, 2015, at 2:39 PM, Daniel Gruno  wrote:
> 
> The revised edition, as partly suggested by Sam (and echoed by Bertrand)

> was:
> 
> - Binding votes on incubation, graduation and/or retirement are only
> valid when given by members of the IPMC who are independent from the
> podling in question. Mentors are free to recommend such actions, but
> cannot cast a vote themselves.

I’m think I get it.  There are so many ways to make an end run around this, 
that I feel it would give us a false sense of security.  

If you have a problem with a specific individual I would ask, "how did an 
untrustworthy mentor make it into the 'system’?”  Also, that indicates that 
you, personally, have work to do with the VP of the IPMC.

You indicated that you have a specific concern with an individual.  Are you 
also saying that the problem is systemic?

> I don't believe I mentioned MIA mentors anywhere - is that something you
> wish to discuss as well?

No, sorry, catching up on emails over the Columbus weekend and I got mixed up…  
:(


Regards,
Alan


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

Re: [VOTE] Accept Concerted into the Apache Incubator

[Alan D. Cabrera]

I’m not sure this needs to be resolved before the polling can be accepted into 
the Incubator.


Regards,
Alan


> On Oct 9, 2015, at 2:01 PM, Julian Hyde  wrote:
> 
> I have agreed to be a mentor to Concerted and I think it is an
> interesting idea. I am inclined to vote for it entering the incubator.
> 
> However since the project has not released any source code yet, there
> are a couple of questions I'd like to get answered for the record:
> 
> 1. How many lines of existing code are there? What is their approximate age?
> 
> 2. Concerted is in C/C++ but you mention interfacing with JVM-based
> products like Hive. How you would interface with other languages? Is
> it a goal of the project to create APIs to other languages such as
> Java? Would access from those languages be as efficient as native
> access?
> 
> I apologize that I didn't bring these up in the discussion thread.
> 
> Julian
> 
> 
> On Fri, Oct 9, 2015 at 11:53 AM, Ayrton Gomesz  wrote:
>> +1
>> @henry.saputra thanks man
>> On Oct 9, 2015 5:50 PM, "Henry Saputra"  wrote:
>> 
>>> +1 (binding)
>>> Good luck guys!
>>> 
>>> On Fri, Oct 9, 2015 at 8:55 AM, Atri Sharma  wrote:
 Hi all,
 
 Following the discussion about Concerted I would like to call a vote for
 accepting Concerted as a new incubator project.
 
 The proposal text is included below, and available on the wiki:
 
 https://wiki.apache.org/incubator/ConcertedProposal
 
 The vote is open for 72 hours:
 
 [ ] +1 accept Concerted in the Incubator
 [ ] ±0
 [ ] -1 (please give reason)
 
 Regards,
 
 Atri
 
 = Abstract =
 
 Concerted is an in memory write less read more engine aimed to provide
 extreme read performance with very high degree of concurrency and
 scalability and focus on minimizing own resource footprint.
 
 = Proposal =
 Concerted is built on the principal that a new type of workload is
 dominating the scene and is now needed to be supported. These are the
>>> large
 data set analytical workloads being analyzed or used on large clusters or
 high power machines. Large analytical workloads depend on the ability to
 query large data sets efficiently and in high concurrency while
>>> maintaining
 semantics such as immediate consistency. An in memory engine designed to
 support extreme read queries while providing support for aggregation
 through various features (such as multidimensional representation of
 tuples) will accelerate many usecases around large scale analytics.
 
 Concerted believes that best understanding of user application lies with
 user application developer. The need for massive read scaling should be
>>> on
 demand and should be flexible to the level that user can decide as to
>>> which
 representation and access of data suits his/her current requirements.
 Hence, Concerted is not built in a traditional client/server model.
 Concerted provides users with an API which can be used to load, read,
 update and delete data. User chooses which data structure has to be used
 for his current requirements. All API access is covered by Concerted's
 internal systems like lock manager, transaction manager and cache manager
 which ensure that reads scale to high level in every API call.
 
 Concerted is a Do It Yourself in memory platform for making in memory
 supporting engines. The use case we think of is supporting big data
 warehouses like Hive, but there are endless use cases for a custom,
>>> highly
 scalable in memory platform.
 
 The goal of this proposal is to leverage an existing code base available
>>> on
 Github and licensed under the Apache License 2.0 to build a community
 around the project. Currently the community consists of existing hackers
>>> of
 Concerted as well as people who have been following and associated with
>>> the
 project since a while as well as database experts who are excited about
 building a project like this. We are hoping that entering into Apache
>>> would
 help us attract more contributors as well as connect with existing big
>>> data
 projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
 Spark, Apache Geode to leverage their community base while assisting in
 their use cases with Concerted. We had a discussion with founders of
>>> Apache
 Tajo and they showed interest in using Concerted for some of their use
 cases.
 = Background =
 Relational databases were built with the cost of physical memory in mind.
 The cost is no longer very relevant and physical memory is now available
>>> on
 demand. Another driving factor behind Concerted is that there is a
>>> paradigm
 shift with big data coming into picture. Disk IO speeds are more of a
 bottleneck than ever 

Re: [VOTE] Accept Concerted into the Apache Incubator

[Alan D. Cabrera]

+1 - binding


Regards,
Alan

> On Oct 9, 2015, at 8:55 AM, Atri Sharma  wrote:
> 
> Hi all,
> 
> Following the discussion about Concerted I would like to call a vote for
> accepting Concerted as a new incubator project.
> 
> The proposal text is included below, and available on the wiki:
> 
> https://wiki.apache.org/incubator/ConcertedProposal
> 
> The vote is open for 72 hours:
> 
> [ ] +1 accept Concerted in the Incubator
> [ ] ±0
> [ ] -1 (please give reason)
> 
> Regards,
> 
> Atri
> 
> = Abstract =
> 
> Concerted is an in memory write less read more engine aimed to provide
> extreme read performance with very high degree of concurrency and
> scalability and focus on minimizing own resource footprint.
> 
> = Proposal =
> Concerted is built on the principal that a new type of workload is
> dominating the scene and is now needed to be supported. These are the large
> data set analytical workloads being analyzed or used on large clusters or
> high power machines. Large analytical workloads depend on the ability to
> query large data sets efficiently and in high concurrency while maintaining
> semantics such as immediate consistency. An in memory engine designed to
> support extreme read queries while providing support for aggregation
> through various features (such as multidimensional representation of
> tuples) will accelerate many usecases around large scale analytics.
> 
> Concerted believes that best understanding of user application lies with
> user application developer. The need for massive read scaling should be on
> demand and should be flexible to the level that user can decide as to which
> representation and access of data suits his/her current requirements.
> Hence, Concerted is not built in a traditional client/server model.
> Concerted provides users with an API which can be used to load, read,
> update and delete data. User chooses which data structure has to be used
> for his current requirements. All API access is covered by Concerted's
> internal systems like lock manager, transaction manager and cache manager
> which ensure that reads scale to high level in every API call.
> 
> Concerted is a Do It Yourself in memory platform for making in memory
> supporting engines. The use case we think of is supporting big data
> warehouses like Hive, but there are endless use cases for a custom, highly
> scalable in memory platform.
> 
> The goal of this proposal is to leverage an existing code base available on
> Github and licensed under the Apache License 2.0 to build a community
> around the project. Currently the community consists of existing hackers of
> Concerted as well as people who have been following and associated with the
> project since a while as well as database experts who are excited about
> building a project like this. We are hoping that entering into Apache would
> help us attract more contributors as well as connect with existing big data
> projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
> Spark, Apache Geode to leverage their community base while assisting in
> their use cases with Concerted. We had a discussion with founders of Apache
> Tajo and they showed interest in using Concerted for some of their use
> cases.
> = Background =
> Relational databases were built with the cost of physical memory in mind.
> The cost is no longer very relevant and physical memory is now available on
> demand. Another driving factor behind Concerted is that there is a paradigm
> shift with big data coming into picture. Disk IO speeds are more of a
> bottleneck than ever before. Combining the read dominance of analytical
> workload with the speed of in memory structures, Concerted fits the current
> scene. Also, supporting OLAP workloads with in memory support for faster
> read constant queries and joins will be useful.
> 
> = Rationale =
> As explained above, large analytical workloads need an in memory
> lightweight engine which supports massive read concurrency, ground level
> support for aggregations and analytics, extreme scalability and high read
> performance, along with the engine being very light itself. Concerted aims
> to solve these needs. Concerted is designed and built with three goals as
> objectives:
> 
> 
> Performance
>To provide high performance access to data from a large number of rows,
> Concerted uses efficient representation and in memory indexing of data
> coupled with high performance transactions, custom transactions and
> lightweight locking and lockless techniques and an intelligent locking
> manager.
> 
> Scalability
>Concerted is built with extreme concurrency and scalability in mind.
> 
> Efficiency
>Concerted aims to give expected performance under vast variety of
> workloads and aims to have as low footprint as possible.
> 
> = Initial Goals =
> The initial goal is to leverage an existing code base and invest in
> building a community around the project. We anticipate a lot of initial
> restructuring 

Re: Require projects to have solid API docs

[Alan D. Cabrera]

Should != Must


Regards,
Alan

> On Oct 11, 2015, at 11:49 AM, Julian Hyde  wrote:
> 
> Per [1], "Apache projects should provide sufficient documentation [… so that 
> … ] users can both make use of our software freely”.
> 
> And: "users of Apache software should be able to find our software, learn how 
> to use it, and actually apply it to all its common use cases solely by going 
> to the Apache project’s own website”.
> 
> So: there should be some documentation about how to use the project on the 
> project web site. That documentation does not need to be in any particular 
> form, such as javadoc.
> 
> Julian
> 
> [1] https://community.apache.org/projectIndependence.html
> 
> 
>> On Oct 11, 2015, at 9:29 AM, Luciano Resende  wrote:
>> 
>> On Sun, Oct 11, 2015 at 9:15 AM, Ross Gardler 
>> wrote:
>> 
>>> No. That’s not the role of the foundation. However, ensuring people
>>> contributing to the docs are recognized like any other contributor is the
>>> role of the foundation. Can you help contribute to such docs?
>>> 
>>> 
>>> 
>> +1
>> 
>> -- 
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
> 
> 
> -
> 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] Mentor neutrality policy

[Alan D. Cabrera]

> On Oct 9, 2015, at 8:36 AM, Ross Gardler  wrote:
> 
> Personally I would focus more on better oversight of podling and mentor 
> activity. The goal is to catch the occasional problem case rather than put 
> restrictions in place. I'm not sure how to do that though. I and others have 
> made many suggestions over the years. They can be found here 
> http://wiki.apache.org/incubator/IncubatorIssues2013 
>  (you might want to add 
> your proposal there).

Even more oversight?  We already have a role that provides oversight of the 
shepherds who provide oversight of the mentors who provide oversight of the 
podling.  Spreading responsibility for getting something done is a sure way to 
make sure that it does not get done.  Just my 2 cents.


Regards,
Alan

Re: [DISCUSS] Mentor neutrality policy

[Alan D. Cabrera]

I’m -1 on on this.  The whole premise of the ASF is that it is a meritocracy 
and that volunteers at various “levels” of the organization have attained their 
status because they are trustworthy.  Without this premise, the ASF falls apart.

Finally, it’s not clear to me that this addresses the problem of MIA mentors.  
If they were supposedly tied in some manner to the incubation and graduation of 
a podling,  then they are definitely active during its incubation; I have no 
problem with that because in my book, they are trustworthy.

I’ve made proposals to solve the problems listed below, the causes of which 
are, imo, volunteerism and a free ride into a project and its PMC.  My proposal 
was after 3 missed votes, the mentor is automatically removed with simple 
no-fuss reinstatement procedures should the mentor wish to redeem themselves.  
Mentors cannot stay with the podling when it graduates.


Regards,
Alan

> On Oct 9, 2015, at 8:07 AM, Daniel Gruno  wrote:
> 
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 
> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Re: [DISCUSS] Mentor neutrality policy

[Alan D. Cabrera]

> On Oct 9, 2015, at 11:02 AM, Sam Ruby  wrote:
> 
> On Fri, Oct 9, 2015 at 1:25 PM, Bertrand Delacretaz
>  wrote:
>> Hi,
>> 
>> On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
>>> ...Furthermore, I would like to see this extended to votes on graduating or
>>> retiring podlings,..
>> 
>> IMO this is where independence is important. We could require that 3
>> "organizationally independent" IPMC members review each podling before
>> graduating or retiring. Those people do not need to be project
>> mentors.
> 
> I much prefer a formulation of "3 independent" over "no financial
> ties", and would prefer such a criteria be considered whenever the
> impulse arises to ensure that NO involved individual has a vested
> interest.
> 
> I'll go further and say that financial interests are but one way in
> which individuals have a vested interest in the success of a project,
> and echoing a statement by Ross -- having a vested interest is not a
> bad thing.
> 
> Finally, I would prefer a model whereby those that have achieved ASF
> member status are given the benefit of the doubt in matters involving
> a group vote when it comes to their ability to separate their ASF role
> from their relationship with their employee.  Nothing wrong with still
> requiring 3 completely independent votes, but having a rule that
> excludes participation by those that have demonstrated their merit as
> ASF members just seems wrong.


IMO, adding more policy of this sort does not address the core concerns that 
Daniel details in his proposal, i.e. MIA mentors.  Let’s not rush to add more 
bureaucracy and rules.


Regards,
Alan


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

Re: [DISCUSS] Mentor neutrality policy

[Alan D. Cabrera]

> On Oct 9, 2015, at 12:18 PM, Daniel Gruno  wrote:
> 
> I would imagine no one would object to a policy that says you cannot
> have a binding vote if you have a financial interest in graduating a
> podling,

I would.  People on the IPMC and ASF are supposed to be trustworthy out of the 
gate.

If you have specific problems with specific mentors then bring it up w/ the 
IPMC or IPMC VP privately.  Let’s not spray even more rules and bureaucracy 
into the Incubator.


Regards,
Alan

Re: Require projects to have solid API docs

[Alan D. Cabrera]

> On Oct 11, 2015, at 9:20 PM, Julian Hyde <jh...@apache.org> wrote:
> 
> On Sun, Oct 11, 2015 at 1:11 PM, Alan D. Cabrera <l...@toolazydogs.com> wrote:
>> Should != Must
> 
> Yes, I know. But I didn't want to have everyone leap into yet another
> long-winded debate with no one even having mentioned that there is
> existing policy on this matter.

:)



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

Re: [POLL] Using this list to discuss pTLP proposals, ok?

[Alan D. Cabrera]

 On Mar 22, 2015, at 9:32 AM, Marvin Humphrey mar...@rectangular.com wrote:
 
 My preference would be to ask pTLP advocates which public list they want to
 use.  Creating a new public mailing list is an option, though the low
 visibility of a new list makes such an option less than ideal and the usual
 arguments against Yet Another Mailing List apply.  As far as I am concerned,
 they would be welcome to use general@incubator if that's their choice.  Maybe
 dev@community would be OK though I would be surprised if the ComDev PMC were
 amenable.

The mailing lists derive their power from being focused on specific topics.  
They relieve the subscribers from having to troll through voluminous amounts of 
mail to find those threads that are meaningful and relevant to them.

With that said, pTLP and direct-to-TLP issues have no business being on the 
Incubator lists since they are not under the purvey of the Incubator.  Using 
the same reasoning, pTLP and direct-to-TLP issues have no business being on the 
ComDev lists since they are not under the purvey of ComDev.

It’s the 21st century and making, managing, subscribing, etc, mailing lists is 
no big deal.  I propose that we create a list called percola...@apache.org for 
the purposes of shepherding all manner of “out of band” items such as pTLPs, 
direct-to-TLPs, future revolutions, etc.


Regards,
Alan

Re: [APPROVE] The March MRQL report

[Alan D. Cabrera]

Crikey, this went into my junk mail folder.  Signed off.


Regards,
Alan

 On Mar 7, 2015, at 6:04 AM, Leonidas Fegaras fega...@cse.uta.edu wrote:
 
 Dear MRQL mentors,
 This is a reminder to approve the MRQL report.
 Please edit it and approve it at:
 
 https://wiki.apache.org/incubator/March2015
 
 Thanks
 Leonidas
 


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

Re: [VOTE] Accept Apache Singa as incubator project

[Alan D. Cabrera]

+1


Regards,
Alan

 On Mar 10, 2015, at 7:33 AM, Thejas Nair thejas.n...@gmail.com wrote:
 
 The Singa Incubator Proposal document has been updated based on
 feedback in the proposal thread.
 
 This vote is proposing the inclusion of Apache Singa as incubator project.
 The vote will run for at least 72 hours.
 
 [ ] +1 Accept Apache Singa into the Incubator
 [ ] +0 Don’t care.
 [ ] -1 Don’t accept Apache Singa into the Incubator because..
 
 Please vote !
 
 Here is my +1 .
 
 Link to version of proposal being voted on :
 https://wiki.apache.org/incubator/SingaProposal?action=recallrev=10
 
 The text is below
 --
 
 = Singa Incubator Proposal =
 == Abstract ==
 SINGA is a distributed deep learning platform.
 
 == Proposal ==
 SINGA is an efficient, scalable and easy-to-use distributed platform
 for training deep learning models, e.g., Deep Convolutional Neural Network and
 Deep Belief Network. It parallelizes the computation (i.e., training) onto a
 cluster of nodes by distributing the training data and model automatically to
 speed up the training. Built-in training algorithms like Back-Propagation and
 Contrastive Divergence are implemented based on common abstractions of deep
 learning models. Users can train their own deep learning models by simply
 customizing these abstractions like implementing the Mapper and
 Reducer in Hadoop.
 
 == Background ==
 Deep learning refers to a set of feature (or representation) learning models
 that consist of multiple (non-linear) layers, where different layers learn
 different levels of abstractions (representations) of the raw input data.
 Larger (in terms of model parameters) and deeper (in terms of number of 
 layers)
 models have shown better performance, e.g., lower image classification error 
 in
 Large Scale Visual Recognition Challenge. However, a larger model requires 
 more
 memory and larger training data to reduce over-fitting. Complex
 numeric operations
 make the training computation intensive. In practice, training large
 deep learning
 models takes weeks or months on a single node (even with GPU).
 
 == Rational ==
 Deep learning has gained a lot of attraction in both academia and
 industry due to
 its success in a wide range of areas such as computer vision and
 speech recognition.
 However, training of such models is computationally expensive,
 especially for large
 and deep models (e.g., with billions of parameters and more than 10
 layers). Both
 Google and Microsoft have developed distributed deep learning systems
 to make the
 training more efficient by distributing the computations within a
 cluster of nodes.
 However, these systems are closed source softwares. Our goal is to leverage 
 the
 community of open source developers to make SINGA efficient, scalable
 and easy to
 use. SINGA is a full fledged distributed platform, that could benefit the
 community and also benefit from the community in their involvement in
 contributing
 to the further work in this area. We believe the nature of SINGA and our 
 visions
 for the system fit naturally to Apache's philosophy and development framework.
 
 == Initial Goals ==
 We have developed a system for SINGA running on a commodity computer
 cluster. The initial goals include,
 * improving the system in terms of scalability and efficiency, e.g.,
 using Infiniband for network communication and multi-threading for one
 node computation. We would consider extending SINGA to GPU clusters
 later.
 * benchmarking with larger datasets (hundreds of millions of training
 instances) and models (billions of parameters).
 * adding more built-in deep learning models. Users can train the
 built-in models on their datasets directly.
 
 
 == Current Status ==
 === Meritocracy ===
 We would like to follow ASF meritocratic principles to encourage more 
 developers
 to contribute in this project. We know that only active and excellent 
 developers
 can make SINGA a successful project. The committer list and PMC will be 
 updated
 based on developers' performance and commitment. We are also improving the
 documentation and code to help new developers get started quickly.
 
 === Community ===
 SINGA is currently being developed in the Database System Research Lab at the
 National University of Singapore (NUS) in collaboration with Zhejiang
 University in China.
 Our lab has extensive experience in building database related systems, 
 including
 distributed systems. Six PhD students and research assistants (Jinyang Gao,
 Kaiping Zheng, Sheng Wang, Wei Wang, Zhaojing Luo and Zhongle Xie) , a 
 research
 fellow (Anh Dinh) and three professors (Beng Chin Ooi, Gang Chen, Kian Lee 
 Tan)
 have been working for a year on this project. We are open to recruiting more
 developers from diverse backgrounds.
 
 === Core Developers ===
 Beng Chin Ooi, Gang Chen and Kian Lee Tan are professors who have worked on
 distributed systems for more than 20 years. They have collaborated with the
 

Re: [VOTE] Accept CommonsRDF into the Apache Incubator

[Alan D. Cabrera]

+1 - binding


Regards,
Alan

 On Feb 27, 2015, at 11:19 AM, Lewis John Mcgibbney 
 lewis.mcgibb...@gmail.com wrote:
 
 The VOTE is therefore as follows
 
 [ ] +1 I am happy with Commons RDF entering incubation
 [ ] +0/-0 I am neither yay or nay
 [ ] -1 I am not happy with this proposal because
 

Re: Dudes: save some of your pTLP energy and review this friggin' release!!!!

[Alan D. Cabrera]

Binding IPMC member votes always carry over.  

Many thanks for helping us!


Regards,
Alan

 On Feb 25, 2015, at 7:27 AM, John D. Ament johndam...@apache.org wrote:
 
 Technically, you only have 2.  If you'd like to copy your binding IPMC vote
 to general@ that would help ;-)
 
 John
 
 On Wed, Feb 25, 2015 at 10:20 AM Alan D. Cabrera l...@toolazydogs.com
 wrote:
 
 Pretty please?  :D
 
 
 Regards,
 Alan
 
 On Feb 24, 2015, at 4:42 AM, Leonidas Fegaras fega...@cse.uta.edu
 wrote:
 
 Hello,
 This vote is open for more than a week and we still need one more IPMC
 vote.
 Could somebody help us her?
 Thanks
 Leonidas Fegaras
 
 On 02/22/2015 01:00 PM, Alan D. Cabrera wrote:
 Ping :)
 
 
 Regards,
 Alan
 
 On Feb 18, 2015, at 7:22 PM, Leonidas Fegaras fega...@cse.uta.edu
 wrote:
 
 Hello,
 This release still needs one more IPMC vote.
 (We got +1 IPMC votes from Alan Cabrera and Justin Mclean).
 It would be greatly appreciated If someone could take a look
 at our release and vote.
 Thank you
 Leonidas Fegaras
 
 
 On 02/15/2015 05:19 PM, Leonidas Fegaras wrote:
 Hello,
 This is a call for a vote on Apache MRQL 0.9.4 incubating.
 Apache MRQL is a query processing and optimization system for
 large-scale, distributed data analysis, built on top of Apache Hadoop,
 Hama, Spark, and Flink. This is our third release.
 A vote was held on the MRQL developer mailing list and it passed with
 four +1 PPMC votes, no -1 votes, and no 0 votes (see the vote thread
 [1] and result thread [2]), and now requires a vote on this list.
 The vote will be open for at least 72 hours and passes if a majority
 of at least three +1 IPMC votes are cast.
 
 [ ] +1 Release this package as Apache MRQL 0.9.4-incubating
 [ ] -1 Do not release this package because ...
 
 The release tarballs, including signatures, digests, etc can be found
 at:
 https://dist.apache.org/repos/dist/dev/incubator/mrql/0.9.4-
 incubating-RC2/
 The release candidate consists of the following source distribution
 archives:
 - apache-mrql-0.9.4-incubating-src.[tar.gz|zip]
   SHA1 of TGZ: 9B21 81B9 7CAB D1D4 B58F  49B3 C013 5841 B439 D590
   SHA1 of ZIP: B08F C4DE A84F F203 8EEA  C124 727A 1A53 76FA 34F3
 You can compile the sources using 'mvn clean install'.
 In addition, the following supplementary binary distributions are
 provided for user convenience at the same location:
 - apache-mrql-0.9.4-incubating-bin.[tar.gz|zip]
   SHA1 of TGZ: F25B A476 D095 8C01 AEA3  4F94 4800 01AB 9FA4 BCBF
   SHA1 of ZIP: AF61 F9E3 F84A 11CA CE39  B769 B490 D963 C495 C5DD
 
 A staged Maven repository is available for review at:
 https://repository.apache.org/content/repositories/orgapachemrql-1003
 
 The release candidate has been signed through the key 798764F1 in:
 http://www.apache.org/dist/incubator/mrql/KEYS
 
 The release candidate is based on the sources tagged with
 MRQL-0.9.4-incubating-RC2 in:
 https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.
 git;a=commit;h=6bf94302fb5aa8a5bd7f60362fe0fe8505da6ebb
 
 The list of fixed issues:
 https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.
 git;a=blob_plain;f=RELEASE_NOTES;hb=6bf94302fb5aa8a5bd7f60362fe0fe
 8505da6ebb
 
 To learn more about Apache MRQL, please visit:
 http://wiki.apache.org/mrql/
 Thanks,
 Leonidas Fegaras
 
 [1] http://markmail.org/message/dm2n2ljgdlztsdsf
 [2] http://markmail.org/message/4hajddzyqlcwijyj
 
 
 -
 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
 
 
 
 -
 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

Dudes: save some of your pTLP energy and review this friggin' release!!!!

[Alan D. Cabrera]

Pretty please?  :D


Regards,
Alan

 On Feb 24, 2015, at 4:42 AM, Leonidas Fegaras fega...@cse.uta.edu wrote:
 
 Hello,
 This vote is open for more than a week and we still need one more IPMC vote.
 Could somebody help us her?
 Thanks
 Leonidas Fegaras
 
 On 02/22/2015 01:00 PM, Alan D. Cabrera wrote:
 Ping :)
 
 
 Regards,
 Alan
 
 On Feb 18, 2015, at 7:22 PM, Leonidas Fegaras fega...@cse.uta.edu wrote:
 
 Hello,
 This release still needs one more IPMC vote.
 (We got +1 IPMC votes from Alan Cabrera and Justin Mclean).
 It would be greatly appreciated If someone could take a look
 at our release and vote.
 Thank you
 Leonidas Fegaras
 
 
 On 02/15/2015 05:19 PM, Leonidas Fegaras wrote:
 Hello,
 This is a call for a vote on Apache MRQL 0.9.4 incubating.
 Apache MRQL is a query processing and optimization system for
 large-scale, distributed data analysis, built on top of Apache Hadoop,
 Hama, Spark, and Flink. This is our third release.
 A vote was held on the MRQL developer mailing list and it passed with
 four +1 PPMC votes, no -1 votes, and no 0 votes (see the vote thread
 [1] and result thread [2]), and now requires a vote on this list.
 The vote will be open for at least 72 hours and passes if a majority
 of at least three +1 IPMC votes are cast.
 
 [ ] +1 Release this package as Apache MRQL 0.9.4-incubating
 [ ] -1 Do not release this package because ...
 
 The release tarballs, including signatures, digests, etc can be found at:
 https://dist.apache.org/repos/dist/dev/incubator/mrql/0.9.4-incubating-RC2/
 The release candidate consists of the following source distribution
 archives:
 - apache-mrql-0.9.4-incubating-src.[tar.gz|zip]
SHA1 of TGZ: 9B21 81B9 7CAB D1D4 B58F  49B3 C013 5841 B439 D590
SHA1 of ZIP: B08F C4DE A84F F203 8EEA  C124 727A 1A53 76FA 34F3
 You can compile the sources using 'mvn clean install'.
 In addition, the following supplementary binary distributions are
 provided for user convenience at the same location:
 - apache-mrql-0.9.4-incubating-bin.[tar.gz|zip]
SHA1 of TGZ: F25B A476 D095 8C01 AEA3  4F94 4800 01AB 9FA4 BCBF
SHA1 of ZIP: AF61 F9E3 F84A 11CA CE39  B769 B490 D963 C495 C5DD
 
 A staged Maven repository is available for review at:
 https://repository.apache.org/content/repositories/orgapachemrql-1003
 
 The release candidate has been signed through the key 798764F1 in:
 http://www.apache.org/dist/incubator/mrql/KEYS
 
 The release candidate is based on the sources tagged with
 MRQL-0.9.4-incubating-RC2 in:
 https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=commit;h=6bf94302fb5aa8a5bd7f60362fe0fe8505da6ebb
 
 The list of fixed issues:
 https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=blob_plain;f=RELEASE_NOTES;hb=6bf94302fb5aa8a5bd7f60362fe0fe8505da6ebb
 
 To learn more about Apache MRQL, please visit:
 http://wiki.apache.org/mrql/
 Thanks,
 Leonidas Fegaras
 
 [1] http://markmail.org/message/dm2n2ljgdlztsdsf
 [2] http://markmail.org/message/4hajddzyqlcwijyj
 
 
 -
 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
 


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

Re: [VOTE] Release of Apache MRQL 0.9.4 incubating (RC2)

[Alan D. Cabrera]

Ping :)


Regards,
Alan

 On Feb 18, 2015, at 7:22 PM, Leonidas Fegaras fega...@cse.uta.edu wrote:
 
 Hello,
 This release still needs one more IPMC vote.
 (We got +1 IPMC votes from Alan Cabrera and Justin Mclean).
 It would be greatly appreciated If someone could take a look
 at our release and vote.
 Thank you
 Leonidas Fegaras
 
 
 On 02/15/2015 05:19 PM, Leonidas Fegaras wrote:
 Hello,
 This is a call for a vote on Apache MRQL 0.9.4 incubating.
 Apache MRQL is a query processing and optimization system for
 large-scale, distributed data analysis, built on top of Apache Hadoop,
 Hama, Spark, and Flink. This is our third release.
 A vote was held on the MRQL developer mailing list and it passed with
 four +1 PPMC votes, no -1 votes, and no 0 votes (see the vote thread
 [1] and result thread [2]), and now requires a vote on this list.
 The vote will be open for at least 72 hours and passes if a majority
 of at least three +1 IPMC votes are cast.
 
 [ ] +1 Release this package as Apache MRQL 0.9.4-incubating
 [ ] -1 Do not release this package because ...
 
 The release tarballs, including signatures, digests, etc can be found at:
 https://dist.apache.org/repos/dist/dev/incubator/mrql/0.9.4-incubating-RC2/
 The release candidate consists of the following source distribution
 archives:
 - apache-mrql-0.9.4-incubating-src.[tar.gz|zip]
SHA1 of TGZ: 9B21 81B9 7CAB D1D4 B58F  49B3 C013 5841 B439 D590
SHA1 of ZIP: B08F C4DE A84F F203 8EEA  C124 727A 1A53 76FA 34F3
 You can compile the sources using 'mvn clean install'.
 In addition, the following supplementary binary distributions are
 provided for user convenience at the same location:
 - apache-mrql-0.9.4-incubating-bin.[tar.gz|zip]
SHA1 of TGZ: F25B A476 D095 8C01 AEA3  4F94 4800 01AB 9FA4 BCBF
SHA1 of ZIP: AF61 F9E3 F84A 11CA CE39  B769 B490 D963 C495 C5DD
 
 A staged Maven repository is available for review at:
 https://repository.apache.org/content/repositories/orgapachemrql-1003
 
 The release candidate has been signed through the key 798764F1 in:
 http://www.apache.org/dist/incubator/mrql/KEYS
 
 The release candidate is based on the sources tagged with
 MRQL-0.9.4-incubating-RC2 in:
 https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=commit;h=6bf94302fb5aa8a5bd7f60362fe0fe8505da6ebb
 
 The list of fixed issues:
 https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=blob_plain;f=RELEASE_NOTES;hb=6bf94302fb5aa8a5bd7f60362fe0fe8505da6ebb
 
 To learn more about Apache MRQL, please visit:
 http://wiki.apache.org/mrql/
 Thanks,
 Leonidas Fegaras
 
 [1] http://markmail.org/message/dm2n2ljgdlztsdsf
 [2] http://markmail.org/message/4hajddzyqlcwijyj
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


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

Re: [VOTE] Accept Apache AsterixDB in to the Incubator

[Alan D. Cabrera]

+1 binding


Regards,
Alan

 On Feb 19, 2015, at 9:38 PM, Mattmann, Chris A (3980) 
 chris.a.mattm...@jpl.nasa.gov wrote:
 
 That said, I would like to propose Apache AsterixDB as an
 Incubator project. I am now calling a VOTE to accept AsterixDB
 into the Apache Incubator. This VOTE will run for at least 72 hours.
 
 [ ] +1 Accept Apache AsterixDB into the Incubator
 [ ] +0 Don’t care.
 [ ] -1 Don’t accept Apache AsterixDB into the Incubator because..

Re: [VOTE] Accept Myriad into the Apache Incubator

[Alan D. Cabrera]

+1 binding

Regards,
Alan

 On Feb 21, 2015, at 9:34 PM, Adam Bordelon a...@mesosphere.io wrote:
 
 Hello friends,
 
 After receiving a positive response on the discussion thread, and even a
 new Mentor (Luciano), I would like to call a VOTE to accept Myriad into the
 Apache Incubator. I will end the vote after 7 days.
 
 https://wiki.apache.org/incubator/MyriadProposal?action=recallrev=7
 
 [ ] +1 Accept Myriad into the Incubator
 [ ] +0 Don’t care.
 [ ] -1 Don’t accept Myriad into the Incubator because..
 
 I am clearly a +1.
 
 Thanks,
 -Adam-
 me@apache


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

Re: my pTLP view

[Alan D. Cabrera]

 On Jan 27, 2015, at 6:58 AM, Bertrand Delacretaz bdelacre...@apache.org 
 wrote:
 
 On Tue, Jan 27, 2015 at 3:38 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 In short, the pTLP designation is a bit too opaque
 
 So you mean all TLPs should have status labels?
 
 Might be useful...probatory, active, low activity, attic candidate...why not.

Yeah, these coupled w/ ComDev’s maturity model would help people grok at a 
glance what’s generally going on w/ the project instead of being forced to go 
on an easter egg hunt through Jira issues, mailing lists, and commit logs, to 
try to access the general character of a project.


Regards,
Alan


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

Re: [DISCUSS] Solicitation for IPMC Chair nomination

[Alan D. Cabrera]

 On Jan 26, 2015, at 10:45 AM, Roman Shaposhnik r...@apache.org wrote:
 
 Hi!
 
 after making sure that there's still an Incubator
 to be managed for the next 6-12 months, I'd like
 to open up a discussion thread on soliciting
 nominations for the next IPMC Chair.
 
 Feel free to self-nominate or nominate folks who
 you know. Provide a summary of your 'program'
 or not. At this point, we want as much feedback
 and discussion as possible. The VOTE thread will
 come in a few weeks.
 
 Things to keep in mind while thinking about nominating
 yourself or others:
   1. This is a 6-12 months commitment that, based on my
personal experience, would require you to allocate 7-10
hours per week.
 
2. This is a rotating Chair and you would be expected to
start a similar thread in 12 months.

FYI, this is a tradition, not a rule; albeit a very good tradition.

3. From where I sit, the most important job for the new
Chair for the next few months would be to help shape
the incremental, actionable plan for improving the
mentoring situation in the Incubator.
 
4. The situation around 'professional student' podlings
is not improving nearly quick enough (4 years without
a single release? really?). Anybody who has actionable
ideas on how to improve it would get my support.
 
 Now, to get the ball rolling, here are the two folks I'd
 like to suggest as future IPMC Chairs:
* Ted Dunning
* Henry Saputra
 In my view, both have demonstrated an exceptional
 understanding of the 'Apache Way', dedication to
 mentoring podlings they are responsible for and enthusiasm
 around bringing new communities into the ASF family.
 On top of that, both have exercised a remarkable skill
 in conducting public discussions and driving towards
 consensus.
 
 Thanks,
 Roman.
 
 -
 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] Solicitation for IPMC Chair nomination

[Alan D. Cabrera]

 On Jan 26, 2015, at 10:57 AM, Roman Shaposhnik r...@apache.org wrote:
 
 On Mon, Jan 26, 2015 at 10:49 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 Things to keep in mind while thinking about nominating
 yourself or others:
  1. This is a 6-12 months commitment that, based on my
   personal experience, would require you to allocate 7-10
   hours per week.
 
   2. This is a rotating Chair and you would be expected to
   start a similar thread in 12 months.
 
 FYI, this is a tradition, not a rule; albeit a very good tradition.
 
 True, but FWIW: anybody NOT firmly sharing this
 expectation will fail to receive support of a few IPMC
 members (including yours truly).

And me as well!  :)


Regards,
Alan



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

Re: my pTLP view

[Alan D. Cabrera]

TL;DR I think this is a good idea.

I thought long and hard about this during the weekend and I’ve changed my mind 
about this; I’ll spare you my handwringing thought processes.  Some things that 
I personally would like to see:

- do away w/ the pTLP name, just make it a regular TLP
- ComDev should be charged w/ augmenting their maturity model with “profiles” 
which can be applied to such TLPs, e.g.
- committers==PMC
- codebase going through IP clearance
- PMC considers TLP properly diverse
- PMC considers TLP properly active
- item 2 is too strict


Regards,
Alan


 On Jan 23, 2015, at 5:42 AM, Greg Stein gst...@gmail.com wrote:
 
 Roman kicked off a query about  next steps, with links to several wiki
 pages on possibilities. The IncubatorV2 page which describes a
 probationary TLP is nothing like I have thought about.
 
 In my mind, a pTLP looks *exactly* like any other PMC. They report directly
 to the Board, they have infrastructure like any other project (eg.
 FOO.apache.org). But they have two significant differences:
 
 1. probationary text is prominent, much like we require incubating to be
 prominent in various locations/messages for podlings
 
 2. the initial PMC is comprised of only ASF Members. committers can be
 chosen however the community decides. but the *project* is reviewed by
 people with (hopefully/theoretically) experience with the Foundation and
 its views on communities
 
 That's it. By creating a PMC that understands what is needed, then they can
 groom new PMC members, and use the standard process for adding them to the
 PMC. The Board doesn't care about committership, so the pTLP can do
 whatever it wants in that regard.
 
 The Board might not accept a pTLP resolution because it wants more
 greybeards on there, to help the community. Removing the probationary
 label, is up to the pTLP to request, and the Board to approve. It is
 usually pretty obvious when a community has reached that point, if you are
 talking about active ASF/PMC Members. But the Board would apply its own
 level of trust.
 
 There is a big element here, which didn't exist 12 years ago: the Board's
 ability to review many projects. Before the Incubator, there weren't that
 many projects. The Directors didn't have a lot of experience with a lot of
 breadth. Nowadays, we review the work of *dozens* of projects every month.
 If one is a pTLP instead of a regular TLP? Not a big deal. They have some
 operational restrictions, but the report should be showing us a typical
 Apache community.
 
 The other aspect is IP clearance and management, which also didn't exist a
 dozen years ago (and the Incubator was basically started in response to
 some IP problems). We have a much better understanding there. Today, we
 have the Incubator performing that, but no reason we can't have pTLPs
 managing that process. We file forms about clearance with the Incubator,
 but really: that should be filed $somehow defined by the VP of Legal
 Affairs (and *that* position/process didn't exist until years after the
 Incubator was established).
 
 TLPs are a recognition of a community. We can create probationary
 communities, supported by ComDev, Legal, other communities, and reviewed by
 the Board.
 
 Speaking as a Director of the ASF, if a Resolution arrived on the Board's
 Agenda to create such a pTLP, then I would be supportive. The pTLP
 construct is independent of the Apache Incubator. Anybody is free to define
 how they want to approach it, and then ask the Board if they are willing to
 try it.
 
 Cheers,
 -g

Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)

[Alan D. Cabrera]

 On Jan 21, 2015, at 3:39 AM, Benson Margulies bimargul...@gmail.com wrote:
 
 On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas cdoug...@apache.org wrote:
 On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz 
 bdelacre...@apache.org javascript:; wrote:
 How is that different from pruning the current IPMC membership by
 removing inactive members?
 
 Doing *that* would be straightforward. Take the set of mentors on currently
 incubating projects, add the other half dozen who review releases, and set
 everyone else to voluntary emeritus status. Done
 
 Agreed - but I don't see how that improves things anyway, I don't see
 any problem caused by those inactive members.
 
 The near-ad-hominem tone of this thread has extracted a reply in my own 
 defense.
 
 It is a misunderstanding, verging on willful, to claim that the V2
 proposal is primarily intended to remove either inactive or noisy
 persons from the group. it is a fabrication that there is any idea
 that some person other than the board  might select an initial set of
 people to further some particular agenda. The idea here of the small
 group, extracted from something Ross wrote on the Wiki in 2013, is
 that an incubator committee doesn't need to be big and it doesn't need
 to grow via merit, if its only job is to accept the board's delegation
 of a limited set of supervisory tasks. If you make a smaller group, it
 might still contain vigorous disagreement, but on a scale where they
 can manageably reach consensus. It would think less of the board if
 they failed to select people likely to have some significant
 disagreements.

I resent your and Chris’ characterization of this thread.  All that’s been 
taking place is a frank and civil discussion of opinions as to what the 
implication of some proposals mean.  Your, and Chris’, attempt to characterize 
them as taking on an ad-hominem tone suggest to me that we are poking at the 
Achilles heal of the Iv2 proposal and Chris’ impromptu proposal to fork the 
Incubator.

At the heart of both there is a culling of IPMC members.  Sure, the new IPMC 
may have Oscar Madison” and “Felix Ungar” tossed into the same bag but that’s 
a distraction from the real problem that I, and maybe Bertrand, are trying to 
point out.

At the proposals' core is that there are IPMC members who want to participate 
but would be left out and in the end the “problems” with the Incubator would 
not be resolved since, as Chris accurately puts it, we will have distilled 
dysfunction. 

But is it dysfunctional?  Only when it tries to be like a school of business 
and come up with new and improved processes for bringing in new projects 
instead of focusing on the core problems which don’t go away, tooling and 
mentor accountability.  Otherwise, I think we do a pretty good job.  We make 
mistakes, sure, but mistakes will always be made and I think we’ve made good, 
focused, incremental pivots to address their causes.


Regards,
Alan

Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)

[Alan D. Cabrera]

 On Jan 19, 2015, at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org 
 wrote:
 
 On Tue, Jan 20, 2015 at 1:37 AM, Chris Douglas cdoug...@apache.org wrote:
 ...So make a list of the IPMC members
 you believe should judge the other 90%, and submit a proposal to the
 board to start a new project. Fork the incubator
 
 How is that different from pruning the current IPMC membership by
 removing inactive members?
 
 I don't think those inactive folks are a problem, but if people think
 they are it's easy to ask them if they want to stay, and remove those
 who reply no or don't reply.

No one is saying that the problem is inactive IPMC members.  

No one.

Isn’t it obvious what the above and IncubatorV2 proposal are about?  
Consolidating like minded individuals into a new IPMC and shutting out the 
other inconvenient members until they come to their senses”.

Frankly, if there are IPMC members that are a real problem then it’s the job of 
the VP of the Incubator to have a “chat” with them.  Are there really so many 
that it warrants a reboot of the IPMC itself?


Regards,
Alan

Re: [PROPOSAL] Apache AsterixDB Incubator

[Alan D. Cabrera]

Should be fine.


Regards,
Alan

 On Jan 19, 2015, at 8:27 PM, Till Westmann t...@westmann.org wrote:
 
 Thank you.
 So for we’ve added 3 slots for mentors on the proposal - I hope that’ll be 
 sufficient even for the relatively large number of new committers.
 
 Till
 
 On Jan 19, 2015, at 8:17 PM, Henry Saputra henry.sapu...@gmail.com wrote:
 
 Thanks Till,
 
 Will try to solicit more mentors to help.
 Especially with initial committers mostly have not been exposed to
 contributing the Apache way.
 
 - Henry
 
 On Mon, Jan 19, 2015 at 5:28 PM, Till Westmann t...@westmann.org wrote:
 Hi Henry,
 
 thanks! It’s great that you’ve seen (and liked) AsterixDB before.
 
 Even if your time is very limited we would be very happy to have you on 
 board as a mentor.
 I’ll add you to the proposal.
 
 Cheers,
 Till
 
 On Jan 19, 2015, at 10:26 AM, Henry Saputra henry.sapu...@gmail.com 
 wrote:
 
 +1 This is GREAT News!
 
 Was watching and trying AsterixDB last year and looked in awesome shape.
 
 I have my plate full but would love to help mentor this project to get
 it going to ASF if needed!
 
 - Henry
 
 On Wed, Jan 14, 2015 at 6:21 PM, Mattmann, Chris A (3980)
 chris.a.mattm...@jpl.nasa.gov wrote:
 Hi Folks,
 
 I am pleased to bring forth the Apache AsterixDB proposal to the
 Apache Incubator as Champion, working in collaboration with the
 team. Please find the wiki proposal here:
 
 https://wiki.apache.org/incubator/AsterixDBProposal
 
 
 Full text of the proposal is below. Please discuss and enjoy. I’ll
 leave the discussion open for a week, and then look to call a VOTE
 hopefully end of next week if all is well.
 
 Cheers!
 Chris Mattmann
 
 =
 Apache AsterixDB Proposal
 
 Abstract
 
 Apache AsterixDB is a scalable big data management system (BDMS) that
 provides storage, management, and query capabilities for large
 collections of semi-structured data.
 
 Proposal
 
 AsterixDB is a big data management system (BDMS) that makes it
 well-suited to needs such as web data warehousing and social data
 storage and analysis. Feature-wise, AsterixDB has:
 
 * A NoSQL style data model (ADM) based on extending JSON with object
 database concepts.
 * An expressive and declarative query language (AQL) for querying
 semi-structured data.
 * A runtime query execution engine, Hyracks, for partitioned-parallel
 execution of query plans.
 * Partitioned LSM-based data storage and indexing for efficient
 ingestion of newly arriving data.
 * Support for querying and indexing external data (e.g., in HDFS) as
 well as data stored within AsterixDB.
 * A rich set of primitive data types, including support for spatial,
 temporal, and textual data.
 * Indexing options that include B+ trees, R trees, and inverted
 keyword index support.
 * Basic transactional (concurrency and recovery) capabilities akin to
 those of a NoSQL store.
 
 
 Background and Rationale
 
 In the world of relational databases, the need to tackle data volumes
 that exceed the capabilities of a single server led to the
 development of “shared-nothing” parallel database systems several
 decades ago. These systems spread data over a cluster based on a
 partitioning strategy, such as hash partitioning, and queries are
 processed by employing partitioned-parallel divide-and-conquer
 techniques. Since these systems are fronted by a high-level,
 declarative language (SQL), their users are shielded from the
 complexities of parallel programming. Parallel database systems have
 been an extremely successful application of parallel computing, and
 quite a number of commercial products exist today.
 
 In the distributed systems world, the Web brought a need to index and
 query its huge content. SQL and relational databases were not the
 answer, though shared-nothing clusters again emerged as the hardware
 platform of choice. Google developed the Google File System (GFS) and
 MapReduce programming model to allow programmers to store and process
 Big Data by writing a few user-defined functions. The MapReduce
 framework applies these functions in parallel to data instances in
 distributed files (map) and to sorted groups of instances sharing a
 common key (reduce) -- not unlike the partitioned parallelism in
 parallel database systems. Apache's Hadoop MapReduce platform is the
 most prominent implementation of this paradigm for the rest of the
 Big Data community. On top of Hadoop and HDFS sit declarative
 languages like Pig and Hive that each compile down to Hadoop
 MapReduce jobs.
 
 The big Web companies were also challenged by extreme user bases
 (100s of millions of users) and needed fast simple lookups and
 updates to very large keyed data sets like user profiles. SQL
 databases were deemed either too expensive or not scalable, so the
 “NoSQL movement” was born. The ASF now has HBase and Cassandra, two
 popular key-value stores, in this space. MongoDB and Couchbase are
 other open source alternatives (document 

Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)

[Alan D. Cabrera]

Can you add your concerns to the end each of the wiki pages?

I intend to update my proposal to clear up the apprehensions that you seem to 
have.  You can then remove/amend your concerns from the wiki proposal.  I will 
quickly state that “naughty lists” are not part of the mentor-reboot proposal.


Thanks!


Regards,
Alan

 On Jan 19, 2015, at 3:55 PM, Andrew Purtell apurt...@apache.org wrote:
 
 I think the cures are all problematic and might be worse than the disease.
 
 
 On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik r...@apache.org 
 mailto:r...@apache.org wrote:
 
 On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik r...@apache.org wrote:
 Hi!
 
 at this point we have had a few lively threads
 discussing three somewhat different proposals:
   #1 mentor re-boot
   #2 pTLP
   #3 Ross's strawman http://s.apache.org/8eS
 it feels to me that all three need additional work
 to be done before we can have any reasonable
 consensus around them (let alone voting).
 
 Wearing my chair hat, I would like to suggest that
 the next step should be: for each proposal we identify
 points that are going to block consensus (AKA would
 result in -1 vote if it comes to a vote). I suggest we
 do it on the wiki pages themselves (I'll wikify Ross's
 proposal tonight). Not editing the wikis but simply
 collecting this feedback as the last section in each
 proposal. The idea would be to identify all such
 points in a week or so.
 
 Sounds good?
 
 To follow up. Each of the proposals:
https://wiki.apache.org/incubator/MentorRebootProposal
 
 
 ​​An active mentor is removed from a podling if that mentor does not
 review/sign off on a release.
 
 ​The above implies the foundation has a pool of mentors able to
 consistently meet every reporting requirement in a timely manner, without
 regard to personal or professional obstacles.​ I don't see it. For an
 organization almost entirely made up of volunteers this seems overly
 optimistic. There is only a small core membership who are capable and
 willing to do this as evidenced by a skim of history of general@incubator
 and members@. Perhaps this core group will end up shouldering the
 incubation load in its entirety. Although sadly this is more or less the
 current state of affairs, individual podlings do come with new mentors not
 part of the professional membership motivated to see at least that
 specific podling through. It's also risky to expect mentors kicked from a
 podling to be okay with it and want to try again, especially if listed on
 some naughty list to the board.
 
 
 
 
https://wiki.apache.org/incubator/Strawman 
 https://wiki.apache.org/incubator/Strawman
 
 
 ​​Only ASF members on the PPMC will have binding votes for the releases.
 
 ​This proposal seems better than the others in my estimation, but doesn't
 allow podlings full investment in their own release management. The members
 on the PPMC who have binding votes will drive the release process out of
 necessity. Once the podling graduates and the members on the PPMC leave to
 resume other interests or duties, only then for the first time is the
 project running their own releases. I think it was better to let the
 podling own their release process but have the IPMC (or equivalent) have an
 up-or-down vote afterward as a check on their activities.
 
 
 
 
https://wiki.apache.org/incubator/IncubatorV2 
 https://wiki.apache.org/incubator/IncubatorV2
 
 
 This proposal revokes merit earned by existing IPMC members and reboots
 incubator supervision as a sub-board limited to 15 members. How members
 apply to this board is not specified. It is suggested the current board
 make recommendations to the board for their replacements, a very
 unmeritocratic suggestion that is quite surprising. It's not clear at all
 how the membership can address issues with this sub-board as they can
 with the Board. I think this proposal takes the likely outcome of the first
 proposal, that only a small core group of professional membership can
 manage sufficient activity as mentors to not be kicked from podlings, and
 codifies it with new structure and bylaws. Maybe in the end this is
 admitting reality. However, discussion of this proposal also floated the
 idea that the sub-board be later given authority to supervise the affairs
 of established TLPs, which is deeply problematic* and I suspect still
 hovers in the wings. I would hope not.
 
 All proposals for new ASF projects must include an initial PMC chair and
 an initial set of PMC members. These people must be acceptable to the
 board. It is the responsibility of the Incubator Committee to vett these
 people. All of them must have experience on existing PMCs
 
 This doubles down on the aspect of the Strawman proposal where PPMC members
 are powerless to vote on releases. Here they are powerless to make any and
 all project management decisions about their own software they brought to
 Apache. It's not mentoring if you make all of the decisions for them.
 
 ​* - Find 

Is there a place I can programmatically pull in PPMC members?

[Alan D. Cabrera]

Is there a place I can programmatically pull in PPMC members?


Regards,
Alan


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

Re: Is there a place I can programmatically pull in PPMC members?

[Alan D. Cabrera]

This seems to get me the IPMC members, not the PPMC members of podlings.  Am I 
misinterpreting the page?


Regards,
Alan

 On Jan 20, 2015, at 11:04 AM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 See the code behind Whimsy (https://whimsy.apache.org/technology.html)
 
 The part you looking for produces 
 https://whimsy.apache.org/roster/committee/incubator
 
 Microsoft Open Technologies, Inc.
 A subsidiary of Microsoft Corporation
 
 -Original Message-
 From: Alan D. Cabrera [mailto:l...@toolazydogs.com] 
 Sent: Tuesday, January 20, 2015 10:58 AM
 To: infrastructure-...@apache.org; general@incubator.apache.org
 Subject: Is there a place I can programmatically pull in PPMC members?
 
 Is there a place I can programmatically pull in PPMC members?
 
 
 Regards,
 Alan
 
 
 -
 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: Is there a place I can programmatically pull in PPMC members?

[Alan D. Cabrera]

 On Jan 20, 2015, at 11:36 AM, jan i j...@apache.org wrote:
 
 On 20 January 2015 at 20:29, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com mailto:ross.gard...@microsoft.com wrote:
 
 Sorry misread your request as IPMC
 
 Ross
 
 Microsoft Open Technologies, Inc.
 A subsidiary of Microsoft Corporation
 
 -Original Message-
 From: Alan D. Cabrera [mailto:a...@toolazydogs.com]
 Sent: Tuesday, January 20, 2015 11:17 AM
 To: infrastructure-...@apache.org
 Cc: general@incubator.apache.org
 Subject: Re: Is there a place I can programmatically pull in PPMC members?
 
 This seems to get me the IPMC members, not the PPMC members of podlings.
 Am I misinterpreting the page?
 
 The only place that information is kept is in the project status xml files
 (of course also in the maillist setups but I guess that is harder to look
 at).
 
 https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/ 
 https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/

Ok, those sources of information do not provide an entirely accurate picture.  
I’ll start updating podlings.xml though, ideally, the podlings would be treated 
the same way that PMCs are.  Does that make better sense, i.e. start creating 
LDAP groups?

 
 good luck
 jan i.
 
 
 
 
 Regards,
 Alan
 
 On Jan 20, 2015, at 11:04 AM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 See the code behind Whimsy (https://whimsy.apache.org/technology.html)
 
 The part you looking for produces
 https://whimsy.apache.org/roster/committee/incubator
 
 Microsoft Open Technologies, Inc.
 A subsidiary of Microsoft Corporation
 
 -Original Message-
 From: Alan D. Cabrera [mailto:l...@toolazydogs.com]
 Sent: Tuesday, January 20, 2015 10:58 AM
 To: infrastructure-...@apache.org; general@incubator.apache.org
 Subject: Is there a place I can programmatically pull in PPMC members?
 
 Is there a place I can programmatically pull in PPMC members?
 
 
 Regards,
 Alan
 
 
 -
 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 
 mailto:general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org 
 mailto:general-h...@incubator.apache.org

Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)

[Alan D. Cabrera]

 On Jan 16, 2015, at 3:04 PM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 Or we could just do it
 
 We debated plenty. Three proposals came out of it (two if you look at mine as 
 the strawman it was intended to be).
 
 Those proposals are not mutually exclusive.
 
 I say record them in the wiki. Run them for a while. Then compare against the 
 problems document we drew up a couple of years back and see how effective 
 they are.

Where is this problems document?


Regards,
Alan

Re: Final draft of IPMC report for January 2015

[Alan D. Cabrera]

 On Jan 14, 2015, at 11:37 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 With that said, I do agree that a board report is not the appropriate venue 
 for the Weegee paddy wagon parade. What would be more useful and more easily 
 digested is a general top level opaque metric, e.g. 55% of the mentors signed 
 off on reports, and then for each podling a similar metric.  
 

podling mentors signoff percent
Aurora  4   3   75%
Brooklyn10  5   50%
Calcite 3   3   100%
Corinthia   2   2   100%
DataFu  3   2   67%
HTrace  6   4   67%
Ignite  5   4   80%
Kalumet 4   2   50%
Kylin   3   3   100%
Lens3   3   100%
MRQL3   2   67%
NiFi7   5   71%
NPanday 2   0   0%
ODF Toolkit 4   1   25%
Parquet 5   3   60%
Ranger  5   3   60%
SAMOA   4   1   25%
Samza   3   2   67%
Tamaya  4   2   50%
Taverna 5   3   60%
Usergrid6   4   67%
Zeppelin5   4   80%
total   96  61  64%

Re: Final draft of IPMC report for January 2015

[Alan D. Cabrera]

 On Jan 14, 2015, at 10:56 AM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 What does it mean to didn't sign-off does it mean they refused to sign-off 
 or that they simply didn't tick a box? Does it mean they didn't even read the 
 report or that they didn't tick a box?
 
 I've said it before, I see no value in having a naughty list like this. 
 What I care about (with my Director hat on) is whether the mentors are 
 engaged with the project.
 
 If the IPMC wants to maintain a didn't sign off list for some internal 
 management reasons that's fine. But putting it in the public minutes of the 
 foundation is a completely different thing altogether (in fact it is already 
 there, it's just that individuals names are not singled out like this).
 
 When the data is incorrect as this thread shows it's even more of an issue.


TL;DR naughty list” metrics are useful and the various scenarios listed above 
are “red herrings”.   General and podling specific “opaque metrics on mentor 
sign-off are just as useful and more easily digested.

Mentors who refuse to sign-off are obviously engaged and would update the 
report to reflect their refusal and, likely, reasons for not signing as this 
would be a very notable event.  I trust Roman to not include those mentors in 
the naughty list”.

Tooling issues aside.  (If anything, the list has caused naughty list” mentors 
to make sure the report is accurate.  Frankly, I would never rescan the final 
report for my podlings otherwise.) I think that it’s reasonable to expect that 
if a mentor read a report then they would have ticked the box.  

Finally, it is a useful metric that provides some visibility into the amount of 
oversight that’s taking place.  Sure, it’s a metric and does not provide total 
transparency and understanding but it is useful never the less.

With that said, I do agree that a board report is not the appropriate venue for 
the Weegee paddy wagon parade. What would be more useful and more easily 
digested is a general top level opaque metric, e.g. 55% of the mentors signed 
off on reports, and then for each podling a similar metric.  Anyone interested 
in catching me in my best herringbone wool skirt can inspect the report at 
individual podling level.


Regards,
Alan

Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)

[Alan D. Cabrera]

 On Jan 14, 2015, at 8:48 AM, Roman Shaposhnik r...@apache.org wrote:
 
 Hi!
 
 at this point we have had a few lively threads
 discussing three somewhat different proposals:
   #1 mentor re-boot

https://wiki.apache.org/incubator/MentorRebootProposal 
https://wiki.apache.org/incubator/MentorRebootProposal

   #2 pTLP

http://wiki.apache.org/incubator/IncubatorV2 
http://wiki.apache.org/incubator/IncubatorV2

   #3 Ross's strawman http://s.apache.org/8eS
 it feels to me that all three need additional work
 to be done before we can have any reasonable
 consensus around them (let alone voting).
 
 Wearing my chair hat, I would like to suggest that
 the next step should be: for each proposal we identify
 points that are going to block consensus (AKA would
 result in -1 vote if it comes to a vote). I suggest we
 do it on the wiki pages themselves (I'll wikify Ross's
 proposal tonight). Not editing the wikis but simply
 collecting this feedback as the last section in each
 proposal. The idea would be to identify all such
 points in a week or so.
 
 Sounds good?

Thanks for picking this up. 

Does it make sense to make a matrix to compare them?  I’m happy to take a crack 
at it.  Could you field offline questions about #2 for me?


Regards,
Alan

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[Alan D. Cabrera]

+1 binding


Regards,
Alan

 On Jan 5, 2015, at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com wrote:
 
 I call a vote to accept OpenAz as a new Incubator project.
 
 The proposal can be found here: 
 https://wiki.apache.org/incubator/OpenAZProposal
 
 and is included below in this email.
 
 Voting will remain open until at least January 20, 2015 23:00 ET.
 
 Hal Lockhart
 
 ---
 
 Abstract
 
 OpenAz is a project to create tools and libraries to enable the development 
 of Attribute-based Access Control (ABAC) Systems in a variety of languages. 
 In general the work is at least consistent with or actually conformant to the 
 OASIS XACML Standard.
 
 Proposal
 
 Generally the work falls into two categories: ready to use tools which 
 implement standardized or well understood components of an ABAC system and 
 design proposals and proof of concept code relating to less well understood 
 or experimental aspects of the problem.
 
 Much of the work to date has revolved around defining interfaces enabling a 
 PEP to request an access control decision from a PDP. The XACML standard 
 defines an abstract request format in xml and protocol wire formats in xaml 
 and json, but it does not specify programmatic interfaces in any language. 
 The standard says that the use of XML (or JSON) is not required only the 
 semantic equivalent.
 
 The first Interface, AzAPI is modeled closely on the XACML defined interface, 
 expressed in Java. One of the goals was to support calls to both a PDP local 
 to the same process and a PDP in a remote server. AzAPI includes the 
 interface, reference code to handle things like the many supported datatypes 
 in XACML and glue code to mate it to the open source Sun XACML implementation.
 
 Because of the dependence on Sun XACML (which is XACML 2.0) the interface was 
 missing some XACML 3.0 features. More recently this was corrected and WSo2 
 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to 
 support calling a remote PDP. WSo2 is also pursuing this capability.
 
 A second, higher level interface, PEPAPI was also defined. PEPAPI is more 
 intended for application developers with little knowledge of XACML. It allows 
 Java objects which contain attribute information to be passed in. Conversion 
 methods, called mappers extract information from the objects and present it 
 in the format expected by XACML. Some implementers have chosen to implement 
 PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi 
 defined a C++ interface which closely matches the Java one.
 
 Examples of more speculative work include: proposals for registration and 
 dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs 
 how to retrieve attributes and PIP code to implement it, discussion of PoC 
 code to demonstrate the use of XACML policies to drive OAuth interations and 
 a proposal to use XACML policies to express OAuth scope.
 
 ATT has recently contributed their extensive XACML framework to the project.
 
 The ATT framework represents the entire XACML 3.0 object set as a collection 
 of Java interfaces and standard implementations of those interfaces. The ATT 
 PDP engine is built on top of this framework and represents a complete 
 implementation of a XACML 3.0 PDP, including all of the multi-decision 
 profiles. In addition, the framework also contains an implementation of the 
 OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP 
 API includes annotation functionality, allowing application developers to 
 simply annotate a Java class to provide attributes for a request. The 
 annotation support removes the need for application developers to learn much 
 of the API.
 
 The ATT framework also includes interfaces and implementations to 
 standardize development of PIP engines that are used by the ATT PDP 
 implementation, and can be used by other implementations built on top of the 
 ATT framework. The framework also includes interfaces and implementations 
 for a PAP distributed cloud infrastructure of PDP nodes that includes support 
 for policy distribution and pip configurations. This PAP infrastructure 
 includes a web application administrative console that contains a XACML 3.0 
 policy editor, attribute dictionary support, and management of PDP RESTful 
 node instances. In addition, there are tools available for policy simulation.
 
 Background
 
 Access Control is in some ways the most basic IT Security service. It 
 consists of making a decision about whether a particular request should be 
 allowed and enforcing that decision. Aside from schemes like permission bits 
 and Access Control Lists (ACLs) the most common way access control is 
 implemented is as code in a server or application which typically intertwines 
 access control logic with business logic, User interface and other software. 
 This makes it difficult to 

Re: [VOTE] Release Apache REEF 0.10.0-incubating

[Alan D. Cabrera]

 On Jan 10, 2015, at 7:14 PM, Byung-Gon Chun bgc...@gmail.com wrote:
 
 The Apache REEF PPMC has voted to release Apache REEF 0.10.0-incubating
 based on the release candidate described below. Now it is the IPMC's turn
 to vote.
 
 Here's the PPMC voting result (five binding +1 votes):
 http://mail-archives.apache.org/mod_mbox/incubator-reef-dev/201501.mbox/%3CCADq0cj7YNbVLYX5dUZtd0U4Cafi%3DDRB-%3DfxoiufHSOHcBdzCDQ%40mail.gmail.com%3E
 
 The source tarball, including signatures, digests, etc can be found at:
 http://people.apache.org/~bgchun/apache-reef-0.10.0-incubating-rc1/ 
 http://people.apache.org/~bgchun/apache-reef-0.10.0-incubating-rc1/

The source does not build unless you have protobufs installed.  Not a big deal 
but something you may want to add this fact to your README.md for the next 
subsequent release.

Source builds and tests fine after protobufs is installed.

mvn rat:check does not pass but they are just false positives; the PPMC vote 
thread seems to say that it passes.  Not a big deal.

 The Git tag is release-0.10.0-incubating-rc1
 The Git commit ID is 76147ea7a4a7b6114bee9d1b8b4d1d588b4f0ce2
 https://git-wip-us.apache.org/repos/asf?p=incubator-reef.git;a=commit;h=76147ea7a4a7b6114bee9d1b8b4d1d588b4f0ce2
 
 Checksums of apache-reef-0.10.0-incubating-rc1.tar.gz:
 MD5: e112edbfe15a67710ad697ab529c4816
 SHA1: 654dc4b7a386ed17e1a8084aa45682ac6c17f159
 SHA512:
 a92a9f6eb4c6c25a3a83843bcd39da462107a10d573705e977744afa498a25a8e0c508d97480661b5ddb5724edc39ea4c84c555c2154c323acd25d74f36bcb51

My checksums don’t match what’s in this email, nor the email in the PPMC vote, 
but they do match what’s in 

http://people.apache.org/~bgchun/apache-reef-0.10.0-incubating-rc1 
http://people.apache.org/~bgchun/apache-reef-0.10.0-incubating-rc1

MD5: fa0de47ab4916a950a077d253a9be783
SHA1: 3b5abfb3447ac9787014211e736be10aa3219d1c
SHA512: 
25a913a5f6ce1e76c145fbf703e49b1716669df7876bead9a025e9d9e26a745ef47ec9d8b2eae072829215017a6c3cc4d8126160e0b7c63613b83989253af03b

IMO, the above public declaration is good enough though others participates of 
this vote, and PPMC vote, will probably have to re-confirm the checksums that 
they actually voted on.

 Release artifacts are signed with the following key:
 https://people.apache.org/keys/committer/bgchun.asc
 
 KEYS file available here:
 https://dist.apache.org/repos/dist/release/incubator/reef/KEYS
 
 Test binaries have been published to Maven's staging repository, and
 are available here:
 https://repository.apache.org/content/repositories/orgapachereef-1000 
 https://repository.apache.org/content/repositories/orgapachereef-1000

Signatures verified.

 41 issues were closed/resolved for this release:
 https://issues.apache.org/jira/browse/REEF-84?jql=project%20%3D%20REEF%20AND%20(status%3Dclosed%20OR%20status%3Dresolved)
 
 The vote will be open for 72 hours.
 
 [ ] +1 Release this package as Apache REEF 0.10.0-incubating
 [ ] +0 no opinion
 [ ] -1 Do not release this package because …


+1 - binding


Regards,
Alan

Re: [VOTE][Proposal] TinkerPop: A Graph Computing Framework [RE-SUBMISSION]

[Alan D. Cabrera]

+1 binding


Regards,
Alan

 On Jan 9, 2015, at 8:58 AM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 
 +1
 
 From the conversation with Marko, he intended to submit this as a formal 
 vote, but didn't use the regular voting template.
 
 Voting will remain open until at least January 15, 2015 18:00 ET.
 
 Cheers,
 Hadrian
 
 
 On 01/09/2015 11:35 AM, Marko Rodriguez wrote:
 Hello everyone,
 
 Over the last 2 weeks, TinkerPop's proposal has been worked on with support 
 from:
 * David Nalley (champion)
 * Rich Bowen (mentor)
 * Hadrian Zbarcea (mentor)
 * Daniel Gruno (mentor)
 * Marko Rodriguez (submitting on behalf of TinkerPop)
 
 We feel it is now in prime shape from submission to vote. Enjoy!.
 (URL to wiki version: https://wiki.apache.org/incubator/TinkerPopProposal)
 
 
 
A. Abstract
 
 TinkerPop http://tinkerpop.com/ is a graph computing framework written in 
 Java. A graph http://en.wikipedia.org/wiki/Graph_%28mathematics%29 is a 
 data structure composed of vertices and edges and is useful for modeling 
 complex domains with arbitrary relations (edges, links, lines) between 
 entities (vertices, objects, dots). TinkerPop 
 https://wiki.apache.org/incubator/TinkerPop provides a core API that graph 
 system vendors can implement. There are various types of graph systems 
 including in-memory graph libraries, OLTP graph databases, and OLAP graph 
 processors (see On Graph Computing 
 http://markorodriguez.com/2013/01/09/on-graph-computing/ for more 
 information). Once the core interfaces are implemented, the underlying graph 
 system can be queried using the graph traversal language Gremlin and 
 processed withTinkerPop 
 https://wiki.apache.org/incubator/TinkerPop-enabled algorithms. For many, 
 TinkerPop https://wiki.apache.org/incubator/TinkerPop is seen as the JDBC 
 http://en.wikipedia.org/wiki/Java_Database_Connectivity of the graph 
 computing community.
 
 
B. Proposal
 
 TinkerPop https://wiki.apache.org/incubator/TinkerPop was formed in 2009 
 and is currently in the milestone series of 3.0.0. From the start, TinkerPop 
 https://wiki.apache.org/incubator/TinkerPop has provided its software open 
 source and free to use for which ever reason (commercial or otherwise). 
 Initially the license was BSD, but as of TinkerPop3 
 https://wiki.apache.org/incubator/TinkerPop3, the license was changed to 
 Apache2. The TinkerPop https://wiki.apache.org/incubator/TinkerPop team is 
 composed of developers, evangelists, and representatives from graph system 
 vendors (see TinkerPop Contributors 
 http://www.tinkerpop.com/docs/3.0.0-SNAPSHOT/#tinkerpop-contributors for 
 more information). TinkerPop https://wiki.apache.org/incubator/TinkerPop 
 has done its best to remain vendor agnostic and works closely with all 
 vendors to ensure that the constructs within TinkerPop 
 https://wiki.apache.org/incubator/TinkerPop are able to accommodate the 
 requirements of the underlying graph system. To date, 12 TinkerPop 
 https://wiki.apache.org/incubator/TinkerPop recognized graph system 
 vendors provide TinkerPop https://wiki.apache.org/incubator/TinkerPop 
 implementations. We believe that by joining The Apache Software Foundation, 
 our vendors, users, and contributors will feel more comfortable in terms of 
 legal protected, in terms of wider-adoption, and in terms of project 
 stability.
 
 
C. Background
 
 TinkerPop https://wiki.apache.org/incubator/TinkerPop has had steady, 
 active development since 2009 when it was founded. Over the years, the 
 Gremlin query language within TinkerPop 
 https://wiki.apache.org/incubator/TinkerPop has been adopted by various 
 JVM languages and as such, there exists Gremlin-Groovy, Gremlin-Scala, 
 Gremlin-Clojure, Gremlin-JavaScript 
 https://wiki.apache.org/incubator/JavaScript, and the like. In many ways, 
 Gremlin is seen as a traversal style that can be readily adopted within the 
 programming constructs of the developer's native language --- both on and 
 off the JVM. TinkerPop https://wiki.apache.org/incubator/TinkerPop is not 
 bound to the JVM in that developers wishing to interact with a TinkerPop 
 https://wiki.apache.org/incubator/TinkerPop-enabled graph system can 
 leverage Gremlin Server which provides over the wire communication as well 
 as the entry point for non-JVM language bindings. TinkerPop 
 https://wiki.apache.org/incubator/TinkerPop is being used is production 
 graph-based applications around the world and is only getting better with 
 age.
 
 
D. Rationale
 
 The graph computing space has grown over the years to encompass numerous 
 graph database and graph processing systems. TinkerPop 
 https://wiki.apache.org/incubator/TinkerPop was created as a unifying 
 framework for interoperability, language standardization, and data model 
 standardization. This framework makes it simple to plug and play the 
 back-end graph implementation without affecting the developer's code. This 
 is analogous to the way in which the JDBC allows 

Re: proposal: mentor re-boot

[Alan D. Cabrera]

 On Jan 8, 2015, at 10:06 AM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 +1
 
 All we care about is that the podling has an active mentor who knows when to 
 ask for support and gets that support when they need it.


Following that statement to a logical conclusion, all podlings need to make a 
release is for one mentor to +1 it.  That doesn’t match what we do today.

How do you reconcile the minimum +1 voting requirement for releases we have to 
day with what you state above?

Or are you guys saying that the podling can do everything but release w/ one 
active mentor, they need two to perform a release?


Regards,
Alan

Re: proposal: mentor re-boot

[Alan D. Cabrera]

 On Jan 7, 2015, at 8:18 PM, Marvin Humphrey mar...@rectangular.com wrote:
 
 What has changed in the
 last year and a half is that we no longer ignore it when podlings fail to
 report -- we put them into monthly and review the situation month to month.
 Between that and requiring Mentor checkoff, we'll notice 90% of podlings that
 go adrift.

This really has no teeth and effectively just gives the mentors and podlings a 
“bye” for the month.


Regards,
Alan

Re: proposal: mentor re-boot

[Alan D. Cabrera]

 On Jan 7, 2015, at 12:13 PM, Marvin Humphrey mar...@rectangular.com wrote:
 
 On Wed, Jan 7, 2015 at 9:42 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 https://wiki.apache.org/incubator/MentorRebootProposal
 
 From that page:
 
People who wish to become mentors that are not in the IPMC must be a
novice mentor, whose mentorship is not counted as an active mentor, for at
least one podling's incubation. ASF members can become IPMC members.
Non-ASF members must mentor a project before becoming an IPMC member.
 
 No more layers.
 
 Looks to me like the proposal invents a new layer: the novice mentor”.

It’s not a layer.  It’s a phase that mentors need to go through.  This is not 
new and it’s something we currently do.  I’ve just made it more explicit.

 I deeply dislike how this proposal erects barriers to keep us from electing
 people onto the IPMC.  One of reasons the Incubator is functioning well these
 days is because we've welcomed lots of new people who have brought lots of
 energy!

And if our process/roll churn died down, what use is the IPMC other than 
mentoring podlings through incubation?  IMO, you are either “here” to directly 
help podlings incubate or your here to contribute to process/roll churn.

I’m all for energy.  Great.  I want that energy directed toward facilitating 
successful incubations.  If you don’t want to be a mentor then why are you here?

Mentoring and vetting is what the incubator is all about.

 If anything, I'd rather go the opposite route: no more automatic joining for
 ASF members.  (I'm not proposing that, I just think it's less bad.)

I thought about that.  The thinking is that ASF members are already 
“trustworthy”.   Maybe we should remove it and see if the proposal still flies. 
 Anyone else have an opinion on that?

 Similarly, this proposal effectively prevents us from elevating outstanding
 podling contributors onto the IPMC, undoing the wildly successful reforms Joe
 Schaefer championed that have gotten podlings like Thrift, ManifoldCF and
 Allura unstuck.  Why discard that crucial tool from the toolbox?

Would not these outstanding podling contributors be considered podling novices 
who have been vetted by “one” podling incubation?

 The Incubator has made important progress.
 
 *   We're not chronically losing track of podlings the way we once did.

I’m not so sure.  Isn’t the lack of reporting and the need for shepherds 
symptomatic of us chronically losing track of podlings?

 *   Our report is consistently on-time and well-put-together, and it's
become a team effort that starts great conversations and doesn't
burn out the Chair.

I’m confused.  Automated reporting does not mean we have a handle on things

While the Incubator report itself is consistently on time, mentors have 
consistently not signed off on podling reports, if the reports get filed at 
all.  The problem is so endemic that we “needed to create the role of 
shepherds.  Now, we need people to review the shepherds to make sure they 
review the mentors who were supposed to review the podlings.

Some podlings are graduating w/ no clear understanding of the Apache Way.

This is all symptomatic of MIA mentors.

 *   Releases are getting approved faster, with fewer RC cycles and with
less arguing.

That’s a function of how much spare time people in the IPMC have…  I would not 
say the problem has been solved.

 I keep hearing how the IPMC is too large to achieve consensus so we have
 to keep people out.  But the people who have brought back these radical
 overhaul proposals and are inundating general@incubator with dozens of
 emails each day are the same discontented core who were doing it two
 years ago.

I do not claim that the IPMC is too large and those that do do not understand 
the fundamental problems we have, imo.

We do have problems; see above.  This is what precipitated the recent few 
proposals.

With that said, my proposal is not a radical overhaul.  The proposal is not 
rebooting the IPMC.  The proposal is making things more explicit and 
transparent while not changing the amount of expected responsibilities.


Regards,
Alan



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

Re: proposal: mentor re-boot

[Alan D. Cabrera]

 On Jan 7, 2015, at 11:35 AM, Upayavira u...@odoko.co.uk wrote:
 
 
 
 On Wed, Jan 7, 2015, at 06:46 PM, jan i wrote:
 On 7 January 2015 at 19:32, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 
 On Jan 7, 2015, at 10:13 AM, Branko Čibej br...@apache.org wrote:
 
 On 07.01.2015 18:42, Alan D. Cabrera wrote:
 I’ve written up a more comprehensive proposal that would not only hold
 mentors accountable but also give them a fair bit of autonomous authority
 during releases.
 
 https://wiki.apache.org/incubator/MentorRebootProposal 
 https://wiki.apache.org/incubator/MentorRebootProposal
 
 
 Being put on hold means that no committers can be added, no PPMC members
 can be added, and no releases can be performed
 This would be a no go for me. If a podling has lost a mentor, but are
 actively seeking a new mentor, the IPMC must step in to accept a new
 committer, PPMC member or release. The IPMC has accepted the podling, so
 it
 is very unfair, to punish a podling, that does a active job to replace a
 mentor.
 
 The IPMC *cannot* replace a mentor. We have no power to make someone
 take on that role. Alan, please add a section to your doc about the fact
 that podlings retain responsibility for engaging with their mentors, and
 for recruiting replacements should a mentor quit or go AWOL.

A very good idea.  Though I will quickly add that I think that Jan meant to say 
“it is unfair to make the podling recruit a new mentor to replace the removed 
mentor”.

 It is great to clarify the responsibilities of mentors, but please let's
 set the expectations and responsibilities of podling members, otherwise
 we keep this idea that the Incubator PMC is a body that has power to do
 things (like make someone step up as a mentor for a project), which it
 doesn't.


Yes, definitely.  This is the document that I alluded to in the proposal, 
mentors must acknowledge that they will perform their duties as out lined in a 
clearly defined document.  I wanted to garner consensus on the broad strokes 
before filling it in, but since the initial reaction seems to generally 
favorable, I should probably create that now.


Regards,
Alan

Re: proposal: mentor re-boot

[Alan D. Cabrera]

 On Jan 7, 2015, at 12:54 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 The Incubator has made important progress.

I want to quickly acknowledge that we have made immense, immense, progress 
thanks in no small part to our IPMC chairs over the years.  A lot of hard work 
was done and that produced very good results.


Regards,
Alan

Re: proposal: mentor re-boot

[Alan D. Cabrera]

 On Jan 7, 2015, at 1:45 PM, Henry Saputra henry.sapu...@gmail.com wrote:
 
 One wording that could confuse people:
 after which they are removed from the PMC unless they are committers.
 
 If someone already a PMC, he or she is also a committer. In ASF a
 committer is someone who can commit code into the repository.

Yes, that is how we currently setup committership but it doesn’t have to happen 
that way for a podling.

 If a mentor asked to stay as PMC after graduation just for the sake of
 continue mentoring,

I think I account for that.

 I am not sure how can the community ask the mentor
 to leave the PMC because he/ she is by default a committer.

Again, being a committer by default is a description of what happens now.  It 
doesn’t have to be that way and if it does then you are describing a problem 
with the tooling.


Regards,
Alan


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

Re: proposal: mentor re-boot

[Alan D. Cabrera]

 On Jan 7, 2015, at 10:13 AM, Branko Čibej br...@apache.org wrote:
 
 On 07.01.2015 18:42, Alan D. Cabrera wrote:
 I’ve written up a more comprehensive proposal that would not only hold 
 mentors accountable but also give them a fair bit of autonomous authority 
 during releases.
 
 https://wiki.apache.org/incubator/MentorRebootProposal 
 https://wiki.apache.org/incubator/MentorRebootProposal
 
 What we would gain is transparency and simplicity.  There would be no false 
 expectations.  Podlings would know where they stand.  Work would be 
 equitably distributed.
 
 No more layers.  No more additional roles and confusing/diluted 
 responsibilities.  No more shuffling.
 
 What you're proposing, then, is that we institute mentor licenses with
 requirements over and above those for ASF membership. In effect, you'd
 create an additional level of earned merit for mentors ... which is
 probably a good thing.

I don’t think that I’m following.  Mentors need to be members of the IPMC but 
that doesn’t mean they need to be ASF members.

 What I don't understand is this: where's the motivation for anyone to
 submit to this additional burden? There's a lot of stick in your
 proposal, but a woeful lack of carrot ... so, most likely not going to
 work for a bunch of volunteers.

What extra burden?  The proposal is not asking mentors to do anything more than 
what they shouldn’t already be doing.  All the proposal does is hold the 
mentors accountable for their inactivity and to add more of an incentive for 
PPMCs to be proactive in their relationships w/ mentors; something that the 
PPMCs shouldn’t already be doing.

The carrot for both podlings and mentors is that there is no second gauntlet of 
voting/review by the IPMC for releases.


Regards,
Alan



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

proposal: mentor re-boot

[Alan D . Cabrera]

I’ve written up a more comprehensive proposal that would not only hold mentors 
accountable but also give them a fair bit of autonomous authority during 
releases.

https://wiki.apache.org/incubator/MentorRebootProposal 
https://wiki.apache.org/incubator/MentorRebootProposal

What we would gain is transparency and simplicity.  There would be no false 
expectations.  Podlings would know where they stand.  Work would be equitably 
distributed.

No more layers.  No more additional roles and confusing/diluted 
responsibilities.  No more shuffling.  


Regards,
Alan

Re: Incubator report sign-off

[Alan D. Cabrera]

 On Dec 29, 2014, at 6:40 AM, Rich Bowen rbo...@rcbowen.com wrote:
 
 3. patch the current process with starting to drop the mentors from
 the project who don't sign off. This will essentially serve
 as a heartbeat for mentors (now, in my opinion it'll quickly
deteriorate into mindless tick-offs -- but at least it does not harm).
 
 
 ... who don't sign off N times, perhaps? Missing one should be a warning, two 
 a scolding, three the boot, perhaps?


+1


Regards,
Alan

Re: pTLP, concretely

[Alan D. Cabrera]

 On Jan 5, 2015, at 4:20 AM, Benson Margulies bimargul...@gmail.com wrote:
 
 For your reading and wrangling pleasure, I offer:
 https://wiki.apache.org/incubator/IncubatorV2.
 
 The goal of this exercise is to turn the idea of the pTLP into a
 practical alternative. By 'practical', I mean: 'based on the
 constraints as I see them'; the board and comdev are not going to find
 a little bottle labelled 'drink this' and swig away at new
 responsibilities.
 
 I'm not offering this to advocate for it, or against it. My purpose is
 more to argue that it would be a ton of work. 'Mentors in the Project'
 in the existing, messy, noisy, IPMC would be a lot less work and has
 the potential to deliver comparable results on the important issues.
 
 But if people want to take this up, or if someone wants to campaign
 for chair using this as a platform, that would be more productive that
 discussing the pTLP alternative in the abstract.


IMO, the “noise” comes from the IPMC discussing new processes, roles, etc., 
when mentors fail to do their jobs.

This proposal is essentially a re-boot with the hopes that bad mentors don’t 
make it into the new world order.

What we really need is less rules, less trial bureaucracy mechanisms, less 
roles, and simple mechanisms to hold mentors accountable to the task that they 
signed up to perform.


Regards,
Alan


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

Re: Incubator report sign-off

[Alan D. Cabrera]

 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:
 
1. get rid of IPMC altogether and move to the pTLP model

This is effectively an IPMC reboot.  I don’t really see anything substantially 
different. 

2. make this a poddling issue: if a poddling fails to hunt down ALL
the mentors for a sign-off -- reject its report

This tactic has no teeth.  If the mentors are MIA do you think that they would 
care if a report were rejected?

3. patch the current process with starting to drop the mentors from
the project who don't sign off. This will essentially serve
as a heartbeat for mentors (now, in my opinion it'll quickly
   deteriorate into mindless tick-offs -- but at least it does not harm).

How is it that a mentor became an IPMC member and do such an unethical thing 
such as a mindless tick-off?


Regards,
Alan

Re: Incubator report sign-off

[Alan D. Cabrera]

 On Dec 19, 2014, at 9:10 AM, Rich Bowen rbo...@rcbowen.com wrote:
 
 I noted in my comments on the recent Incubator board report that I am 
 concerned, month after month, at the number of podlings that have no mentor 
 sign-off at all, as well as the ones where a minority of the mentors sign-off.
 
 I certainly don't expect that every mentor has their full attention on a 
 podling every month, but I do expect that a podling that cares about its 
 incubation will seek out that mentor sign-off, and that the mentors who have 
 committed to help a podling into the family will have a few moments every few 
 months to look in and approve a report.
 
 The result, unfortunately, is that we have projects graduating with no notion 
 of the importance of reporting, and so we have TLPs that look at reporting as 
 a checkbox, submit exactly the same cut-and-paste report each month, some of 
 them without even changing stats and dates, or skip their reporting entirely.
 
 I don't mean to point fingers here - this is a problem that has existed 
 literally since the beginning of the Incubator, and I'm not innocent of it 
 myself. Indeed, I don't show up often enough even on this list.
 
 But I wonder if we might, as the Board does, reject reports that have no 
 sign-off, and force projects to report again the following month, in an 
 attempt to require them to engage with their mentor(s) a little more? This 
 seems like a small, easily reversible, step, that has a good chance of 
 achieving something.
 
 Thoughts?


A while back I proposed to make the podlings and mentors accountable.

Podlings would be required to have a minimum of two active mentors.  A mentor 
is free to become inactive but must explicitly state this else the mentor risks 
being removed for not performing their duties.  Podlings that do not have the 
minimum of two active mentors are put on hold until they find enough mentors to 
fill the quota.  Being put on hold means that no committers can be added, no 
PPMC members can be added, and no releases can be performed.  It does not stop 
development.

Mentors who do not review and vote on a podlings releases are marked inactive.

Mentors who do not review and sign board reports are marked inactive.


Regards,
Alan

Re: Volunteer to Shepherd

[Alan D. Cabrera]

 On Dec 18, 2014, at 9:32 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 On Thu, Dec 18, 2014 at 7:53 PM, Marvin Humphrey mar...@rectangular.com 
 wrote:
 On Thu, Dec 18, 2014 at 7:33 PM, P. Taylor Goetz ptgo...@apache.org wrote:
 
 I’d like to volunteer to help out as a shepherd.
 
 Super! I hope you find the experience broadening.
 
 Huge +1 to that! We are always in need of shepherds.

My perspective, the entire IPMC cannot hope to mentor every podling and so that 
task is assigned to mentors.  Now, since there is no accountability for the 
mentors we have shepherds to monitor the mentors; if we always had fantastic 
mentors the relatively new role of shepherds would not exist. 

Now, we must monitor the shepherds.  Effectively monitoring the monitors who 
monitor the monitors who monitor the podlings…

We are placing our focus on the wrong problem, jmho.


Regards,
Alan


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

Re: pTLP, concretely

[Alan D. Cabrera]

On Jan 5, 2015, at 6:15 AM, Benson Margulies bimargul...@gmail.com wrote:

 On Mon, Jan 5, 2015 at 8:41 AM, Alan Cabrera l...@toolazydogs.com wrote:
 
 
 On Jan 5, 2015, at 5:38 AM, Bertrand Delacretaz bdelacre...@apache.org 
 wrote:
 
 On Jan 5, 2015, at 4:20 AM, Benson Margulies bimargul...@gmail.com 
 wrote:
 
 For your reading and wrangling pleasure, I offer:
 https://wiki.apache.org/incubator/IncubatorV2. ...
 
 IIUC the main difference (besides subtle naming changes) is that pTLPs
 vote on their own releases, based on pTLP PMC members who have been
 accepted by the board?
 
 So more work for the board, and each pTLP needs to form an acceptable
 PMC roster with at least 4-5 members?
 
 My thoughts exactly. What this proposal effectively does is pawn off the 
 responsibility of holding mentors accountable to the board.
 
 No. The original uncooked pTLP scheme did that. This scheme locates
 that responsibility in the renamed committee, which serves the board
 by supervising the pTLPs. They aren't mentors, they are PMC members.

A rose by any other name?


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

Re: [DISCUSS] Rolling shepherds?

[Alan D. Cabrera]

On Dec 9, 2014, at 6:30 PM, John D. Ament johndam...@apache.org wrote:

 The following shepherds either did not provide, or did provide but saw no
 issues to comment on within their podlings:
 
 - Alan Cabrera

I am committed to reviewing the podlings for which I am a mentor.  For other 
podlings, not so much.  When I am a shepherd and I have time to review a 
podling, I will.  Often, I do not have that time.

If this criteria is inadequate for me being a shepherd then feel free to remove 
me from the rotating list.


Regards,
Alan

Re: Incubator report sign-off

[Alan D. Cabrera]

On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:
 
   1. get rid of IPMC altogether and move to the pTLP model
 
 This is effectively an IPMC reboot.  I don’t really see anything 
 substantially different.
 
 At this point, I'm convinced this is the only fruitful path forward,
 the rest is a shell game with responsibility. See the other thread.
 
   3. patch the current process with starting to drop the mentors from
   the project who don't sign off. This will essentially serve
   as a heartbeat for mentors (now, in my opinion it'll quickly
  deteriorate into mindless tick-offs -- but at least it does not harm).
 
 How is it that a mentor became an IPMC member and do such an unethical thing 
 such as a mindless tick-off?
 
 We're talking about human being here. The one who never
 ever cut corners in his life can cast the first stone.

I think that you misunderstood my rhetorical question.  It is my 
experience/understanding that if a mentor makes an effort to review 
reports/releases then this mentor is actually doing a good job at it.  It is my 
experience/understanding that the overwhelming problem is that mentors simply 
go MIA and do nothing at all.

I am in favor of #3 since it holds mentors accountable.  #1 is simply a washing 
of our hands and pawning the problem off on the board simple because some of us 
are unwilling to do uncomfortable things.


Regards,
Alan






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

Re: Reflections from the outgoing Chair

[Alan D. Cabrera]

On Dec 31, 2014, at 5:26 PM, Roman Shaposhnik r...@apache.org wrote:

 when a honor of the IPMC chair was bestowed on
 me beginning of 2014 it was crucial  that the
 position remains to be rotated among IPMC members.
 As an aside: while Marvin felt that the ideal rotation period
 was 6 month my personal belief was that 12 months
 makes it long enough to be able to accomplish something,
 while short enough to still accomplish the goals of a
 rotating chair.

Thank you for your awesome term of service!


Regards,
Alan

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

[Alan D. Cabrera]

On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 The tracking part is easy, though. What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here.

There’s no silver bullet here, if a podling cannot whip up a mentor it’s 
because:
the podling is not popular and should probably be retired anyway, being put on 
hold will provide impetus for the podling to seek out a new venue
there are not enough mentors
There is no way to magically solve the latter.


Regards,
Alan

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

[Alan D. Cabrera]

On Jan 5, 2015, at 9:14 AM, Bertrand Delacretaz bdelacre...@apache.org wrote:

 Hi,
 
 I'm resending Alan's proposal with a new subject as I think it
 deserves more attention.
 
 On Mon, Jan 5, 2015 at 1:57 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 ...Podlings would be required to have a minimum of two active mentors.  A 
 mentor is free to become inactive
 but must explicitly state this else the mentor risks being removed for not 
 performing their duties.  Podlings that
 do not have the minimum of two active mentors are put on hold until they 
 find enough mentors to fill the quota.
 Being put on hold means that no committers can be added, no PPMC members can 
 be added, and no
 releases can be performed.  It does not stop development...
 
 I like it very much...it's a small, reversible step that puts the
 burden on podlings and mentors, which are the ones who should be
 concerned about podlings going forward.
 
 It's also consistent with podlings having to find mentors to join the
 Incubator - they just have to keep on making sure their mentors are
 active, or ask for new ones when needed.
 
 As for measuring the mentors activity, I suggest simply adding a
 question to the podling reports, who are your two active mentors and
 are you happy with their activity along with requiring report
 sign-off from those two mentors.

Thanks Bertrand.  It’s a snippet of what I sent out over a year or so ago.  
I’ll resend it.


Regards,
Alan




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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

[Alan D. Cabrera]

On Jan 5, 2015, at 10:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Mon, Jan 5, 2015 at 10:08 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 The tracking part is easy, though. What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here.
 
 There’s no silver bullet here, if a podling cannot whip up a mentor it’s 
 because:
 the podling is not popular and should probably be retired anyway, being put 
 on
 hold will provide impetus for the podling to seek out a new venue
 there are not enough mentors
 There is no way to magically solve the latter.
 
 I've always been +1 on adding a feedback question to the poddling reporting
 template. I'll do it shortly now that there's more consensus around the idea
 compared to when I first proposed it.
 
 I'm strongly -1 on adding yet another state to the Incubator state transition
 diagram. In my book shifting responsibility to a poddling achieves no useful
 purposes and is going to clutter Incubator with half-alive poddlings.

But that’s what we have today; we have virtually this state already.  All my 
proposal does is make things more explicit and adds accountability to mentors.

 The way I see this: once a poddling gets accepted it becomes an IPMC
 responsibility to make sure we empower it to be successful. It is true
 that circumstances change, but at that point it still needs to be an IPMC
 responsibility to either ponny up required mentorship resources or make
 a tough call of retirement. No need to chop the proverbial tail bit-by-bit.

This neatly sidesteps my assertion that there is no magical way to solve the 
problem of the dearth of active mentors.  pTLP does not solve it either.


Regards,
Alan


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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

[Alan D. Cabrera]

On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:

 On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
 javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:
 
 
 On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 The tracking part is easy, though. What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here.
 
 There’s no silver bullet here, if a podling cannot whip up a mentor it’s
 because:
 the podling is not popular and should probably be retired anyway, being
 put on hold will provide impetus for the podling to seek out a new venue
 there are not enough mentors
 There is no way to magically solve the latter.
 
 
 You mean popular within the pool of mentors (IPMC), the project can still
 be popular on several other scales.

I’m not speaking of popularity of mentors; I regret that choice of words.  I am 
stating that active and healthy podlings seem to have no trouble attracting 
active mentors.

The converse seems to be true.  Unhealthy podlings seem to attract mentors who 
have signed up out of pity and subsequently go MIA.

Before anyone replies, I understand this is not a hard and fast rule but an 
imperfect qualitative observation on my part.

Anyway, active and responsible mentors will eventually get to all podlings.

 I might lack experience, but why do more active mentors guarantee that the
 podling will be a better TLP ?

I’m not sure who’s making that assertion.

 We try to solve the problem of mentors not being active but adding more
 volume. I don't believe that is the right cure.

We’re not adding volume.  The volume is already there.  We’re just making the 
state of affairs more explicit and transparent and adding culpability for MIA 
mentors.

 I do agree with bernard that it is the podling that should ask for
 helpbut the IPMC should solve it.,

Yes, it should help solve problems but if there are no mentors available there 
are no mentors available.


Regards,
Alan


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

Re: [VOTE] Graduate Samza from the Incubator

[Alan D. Cabrera]

+1 binding


Regards,
Alan

On Dec 12, 2014, at 3:54 PM, Jakob Homan jgho...@gmail.com wrote:

 [ ] +1 Graduate Apache Samza from the Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't graduate Apache Samza from the Incubator because ...

Re: [VOTE] accept SAMOA into incubator

[Alan D. Cabrera]

+1 binding


Regards,
Alan

On Dec 11, 2014, at 10:02 AM, Daniel Dai dai...@gmail.com wrote:

 Following the discussion earlier, I'm calling a vote to accept SAMOA as a
 new Incubator project.
 
 [ ] +1 Accept SAMOA into the Incubator
 [ ] +0 Indifferent to the acceptance of SAMOA
 [ ] -1 Do not accept SAMOA because ...


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

Re: Mail command to allow marvin emails

[Alan D. Cabrera]

On Nov 25, 2014, at 3:03 AM, Tim Ellison t.p.elli...@gmail.com wrote:

 On 24/11/14 17:39, John D. Ament wrote:
 On Mon Nov 24 2014 at 10:29:02 AM Tim Ellison t.p.elli...@gmail.com wrote:
 
 On 24/11/14 14:35, John D. Ament wrote:
 Does anyone know the mail command to send out to allow marvin emails
 to get to a list without moderation?
 
 If the mail hits moderation then I/some other mod will allow it through
 and add Marvin to the allowed senders' list.
 
 
 Are you referring to general@ or something else? I'm specifically referring
 to dev@tamaya.i.a.o and I was hoping to white list marvin (the board report
 email reminder). 
 
 Well I can moderate general@ requests, but other moderators can do the
 equivalent for lists they oversee.
 
 I can't seem to find instructions on how to white list
 people anywhere.
 
 When you get the MODERATE mail you should replyAll and send the
 acknowledgement to the *-accept-* and *-allow-tc.* addresses.
 
 The 'accept' permits the current e-mail through, and the 'allow' address
 will add the sender to the whitelist for future mails.  There are other
 command to remove the sender if you change your mind later.
 
 See http://www.apache.org/dev/committers.html#mail-moderate
 
 If you're saying that only you can white list Marvin.. please white list
 Marvin on the listed mail alias.
 
 No, it requires a moderator for dev@tamaya.i.a.o to do that, and an
 incoming moderation request.


It’s too bad that this can’t be automated when a podling is added.  I have a 
ticket waiting in INFRA to add a REST API to Hermes to allow such a thing. 

https://issues.apache.org/jira/browse/INFRA-8006

Maybe people can up-vote it?  :)


Regards,
Alan

Roman or IPMC members who are VPs...

[Alan D. Cabrera]

Only Roman or IPMC members who are VPs can run the commands outlined in

 http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account


Regards,
Alan


On Nov 24, 2014, at 4:11 PM, Edward J. Yoon edwardy...@apache.org wrote:

 Mentors, if incubator project can use the Jenkins, Please add fegaras and
 moon to Jenkins.
 
 -- Forwarded message --
 From: David Nalley (JIRA) j...@apache.org
 Date: Mon, Nov 24, 2014 at 11:10 PM
 Subject: [jira] [Closed] (INFRA-8696) Access to Jenkins
 To: edwardy...@apache.org
 
 
 
 [
 https://issues.apache.org/jira/browse/INFRA-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]
 
 David Nalley closed INFRA-8696.
 ---
Resolution: Not a Problem
 
 Granting access to Jenkins is not an infra task. Please talk to your PMC
 Chair and refer him/her to:
 http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account
 
 
 Access to Jenkins
 -
 
Key: INFRA-8696
URL: https://issues.apache.org/jira/browse/INFRA-8696
Project: Infrastructure
 Issue Type: Wish
 Components: Jenkins
   Reporter: Edward J. Yoon
 
 Can someone please add fegaras and moon to Jenkins.
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)
 
 
 
 -- 
 Best Regards, Edward J. Yoon


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

Re: Access to incubator wiki.

[Alan D. Cabrera]

Ahh! Same here.

The odd thing is that it seems to remember my “old” userid and so I’m able to 
edit the Incubator wiki pages.


Regards,
Alan

On Nov 25, 2014, at 10:10 AM, John D. Ament johndam...@apache.org wrote:

 Hmmm that happened to you too?
 
 I found that my account was missing from the wiki earlier this week.
 re-registering fixed it and put me back in the contributors group.
 
 Is this a normal thing?
 
 On Tue, Nov 25, 2014 at 1:07 PM, jan i j...@apache.org wrote:
 Hi.
 
 Can I please have access (actually I think the right word is restored) to
 incubator wiki.
 
 My userid is janIversen.
 
 thanks in advance
 rgds
 jan i.
 
 -
 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: SVN Access Rights question

[Alan D. Cabrera]

I suspect that only Roman and other VPs can do this.


Regards,
Alan

On Nov 25, 2014, at 10:23 AM, John D. Ament johndam...@apache.org wrote:

 Hi,
 
 Does anyone know what access rights are required to be able to add a
 podling to SVN here: http://svn.apache.org/repos/asf/incubator/
 
 I tried adding tamaya but it came back with an error that I wasn't authorized.
 
 John
 
 -
 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: Mail command to allow marvin emails

[Alan D. Cabrera]

It’s too bad that this can’t be automated when a podling is added.  I have a 
ticket waiting in INFRA to add a REST API to Hermes to allow such a thing. 

https://issues.apache.org/jira/browse/INFRA-8006

Maybe people can up-vote it?  :)


Regards,
Alan


On Nov 24, 2014, at 7:28 AM, Tim Ellison t.p.elli...@gmail.com wrote:

 On 24/11/14 14:35, John D. Ament wrote:
 Does anyone know the mail command to send out to allow marvin emails
 to get to a list without moderation?
 
 If the mail hits moderation then I/some other mod will allow it through
 and add Marvin to the allowed senders' list.
 
 Tim
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

Re: Incubator website guide

[Alan D. Cabrera]

On Nov 24, 2014, at 1:49 PM, Benson Margulies bimargul...@gmail.com wrote:

 Following http://incubator.apache.org/guides/website.html, I ran 'ant' (and
 also build.sh) after adding nifi to podlings.xml and added the nifi.xml
 fille. It didn't produce any changed files to commit.
 
 Is the guide behind? Am I confused?


python3 clutch.py
ant
svn ci -m Run clutch.
ssh -t a...@people.apache.org publish.pl incubator adc

works for me.


Regards,
Alan

Re: Proposals - wiki required?

[Alan D. Cabrera]

On Nov 22, 2014, at 6:16 PM, John D. Ament john.d.am...@gmail.com wrote:

 All,
 
 The current way the proposal page is written, the wiki for proposals is
 optional.  I don't think this is the case any longer, since it looks like
 we request that all proposals get put there first.

Other IPMC member’s strongly held opinions should not be interpreted as hard 
rules.

 Does anyone mind if I rephrase the page to make it mandatory to use the
 wiki for proposals?

I’m sorry I was “out the past few weeks.  What proposal attempted to post a 
proposal that was not on the wiki?  What problem did that cause?

IMO, it doesn’t matter so long as the original vote to accept the proposal 
includes the entire proposal.  We should always be thinking less rules, less 
process, less roles.


Regards,
Alan


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

Re: Proposals - wiki required?

[Alan D. Cabrera]

Yep, I think I understood which proposal page to which you refer to.

My opinion is still the same.  It doesn’t matter so long as the original vote 
to accept the proposal includes the entire proposal.  We should always be 
thinking less rules, less process, less roles.

Incubation is already a bewildering experience for podlings and the solution is 
not more rules and codification.  We need to be fostering a culture of letting 
the non-critical things slide by.

jmho  :D


Regards,
Alan


On Nov 23, 2014, at 6:50 AM, John D. Ament john.d.am...@gmail.com wrote:

 Alan,
 
 I'm referring to [1], where under Developing The Proposal and The Vote it
 seems to list the wiki as one solution or an option rather than the
 proper place to put proposals.  Not any specific proposal that has come up
 recently.
 
 John
 
 [1]: http://incubator.apache.org/guides/proposal.html#formulating
 
 On Sun Nov 23 2014 at 9:42:28 AM Alan D. Cabrera l...@toolazydogs.com
 wrote:
 
 
 On Nov 22, 2014, at 6:16 PM, John D. Ament john.d.am...@gmail.com wrote:
 
 All,
 
 The current way the proposal page is written, the wiki for proposals is
 optional.  I don't think this is the case any longer, since it looks like
 we request that all proposals get put there first.
 
 Other IPMC member’s strongly held opinions should not be interpreted as
 hard rules.
 
 Does anyone mind if I rephrase the page to make it mandatory to use the
 wiki for proposals?
 
 I’m sorry I was “out the past few weeks.  What proposal attempted to post
 a proposal that was not on the wiki?  What problem did that cause?
 
 IMO, it doesn’t matter so long as the original vote to accept the proposal
 includes the entire proposal.  We should always be thinking less rules,
 less process, less roles.
 
 
 Regards,
 Alan
 
 
 -
 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

How do reporting groups get assigned?

[Alan D. Cabrera]

How do reporting groups get assigned to podlings?


Regards,
Alan


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

Re: Report Timeline Report Manager for December

[Alan D. Cabrera]

On Nov 22, 2014, at 7:16 PM, John D. Ament john.d.am...@gmail.com wrote:

 I know this is a few days early, but considering we have a few
 holidays popping up I wanted to send it earlier than later.  If we get
 any new podlings in the next few days we can add them to the report.
 
 I'm wondering if anyone's willing to help with some of the report
 manager responsibilities this month?  To see some of the required
 steps, run this in the incubator site svn repo:
 
 ./report_runbook.py --apache-id  your apache id  --month 12

I’m willing to help.

Ironically, you and I were running the same steps from the run book at the same 
time.  ;)

I finished off the bits for November.  Thanks for generating December’s wiki 
template.


Regards,
Alan

Re: [VOTE] accept NiFi into the incubator

[Alan D. Cabrera]

+1 - binding

On Nov 21, 2014, at 10:55 AM, Benson Margulies bimargul...@gmail.com wrote:

 http://wiki.apache.org/incubator/NiFiProposal has elicited a cheerful and
 positive conversation, so I offer this vote.
 
 Vote will be open for the usual 72 hours ...
 
 Here is my [+1]


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

Re: [VOTE] Accept Kylin into the Apache Incubator

[Alan D. Cabrera]

+1 binding


Regards,
Alan

On Nov 20, 2014, at 2:31 PM, Luke Han luke...@gmail.com wrote:

 Following the discussion earlier in the thread:
 
 http://mail-archives.apache.org/mod_mbox/incubator-general/201411.mbox/%3ccakmqrob22+n+r++date33f3pcpyujhfoeaqrms3t-udjwk6...@mail.gmail.com%3e
 
 I would like to call a VOTE for accepting Kylin as a new incubator project.
 
 The proposal is available at:
 https://wiki.apache.org/incubator/KylinProposal
 
 and posted the text of the proposal below also.
 
 Vote is open until 24th November 2014, 23:59:00 UTC
 
 [ ] +1 accept Kylin in the Incubator
 [ ] ±0
 [ ] -1 because...
 


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

Re: [VOTE] Graduation of Apache MetaModel from the Incubator

[Alan D. Cabrera]

+1 - binding 

On Nov 13, 2014, at 9:39 PM, Henry Saputra henry.sapu...@gmail.com wrote:

 Hi All,
 
 The Apache MetaModel community has wrapped up the VOTE to propose for
 graduation from Apache incubator. The VOTE passed with result:
 9 binding +1s
 zero 0s
 zero -1s
 (http://bit.ly/1u8n8eo)
 
 Apache MetaModel came into ASF incubator on 2013 and since then have
 grown into small but active community.
 
 We have made several good releases with different release managers,
 and also add new PPMC/committers [1].
 The project also has good traffic on the dev mailing list [2].
 
 We would like to propose graduation of Apache MetaModel from ASF
 incubator to top level project.
 
 
 [ ] +1 Graduate Apache MetaModel from the Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't graduate Apache MetaModel from the Incubator because.. .
 
 
 The VOTE will open for 72 hours (11/17/2014)
 
 
 Here is the proposal for the board resolution for graduation:
 
 
 === Board Resolution ==
 
 Establish the Apache MetaModel 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, for distribution at no charge to
 the public, related to providing an implementation of a
 Platform-as-a-Service Framework.
 
 NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
 (PMC), to be known as the Apache MetaModel Project, be and hereby is
 established pursuant to Bylaws of the Foundation; and be it further
 
 RESOLVED, that the Apache MetaModel Project be and hereby is
 responsible for the creation and maintenance of software related to
 providing an implementation of a Platform-as-a-Service Framework; and
 be it further
 
 RESOLVED, that the office of Vice President, MetaModel 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 MetaModel
 Project, and to have primary responsibility for management of the
 projects within the scope of responsibility of the Apache MetaModel
 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 MetaModel
 Project:
 
 * Alberto Rodriguez ardlema at apache dot org
 * Ankit Kumar ankitkumar2711 at apache dot org
 * Arvind Prabhakar arvind at apache dot org
 * Henry Saputra hsaputra at apache dot org
 * Juan Jose van der Linden delostilos at apache dot org
 * Kasper Sørensen kaspersor at apache dot org
 * Matt Franklin mfanklin at apache dot org
 * Noah Slater nslater at apache dot org
 * Sameer Arora sarora at apache dot org
 * Tomasz Guzialek tomaszguzialek at apache dot org
 
 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Kasper Sørensen be
 appointed to the office of Vice President, MetaModel, 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 MetaModel 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 MetaModel
 Project; and be it further
 
 RESOLVED, that the Apache MetaModel Project be and hereby is tasked
 with the migration and rationalization of the Apache Incubator
 MetaModel podling; and be it further
 
 RESOLVED, that all responsibilities pertaining to the Apache Incubator
 MetaModel podling encumbered upon the Apache Incubator Project are
 hereafter discharged.
 
 
 
 
 Thanks,
 
 Henry
 On behalf of Apache MetaModel incubating PPMCs
 
 [1] http://incubator.apache.org/projects/metamodel.html
 [2] http://mail-archives.apache.org/mod_mbox/metamodel-dev
 
 -
 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] Apache Tamaya for Incubation

[Alan D. Cabrera]

+1


Regards,
Alan

On Nov 10, 2014, at 4:19 PM, Anatole Tresch atsti...@gmail.com wrote:

 Hi all,
 
 Thanks for the feedback thus far on the Tamaya proposal.  Based on prior
 discussion, I'd like to start the vote for Tamaya to be accepted as a new
 incubator project.
 
 The proposal can be found here
 https://wiki.apache.org/incubator/TamayaProposal as well as copied below.
 
 Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC
 
 [ ] +1 accept Tamaya in the Incubator
 [ ] ±0
 [ ] -1 because...
 
 Thanks and Best Regards
 Anatole
 
 
 
 -- 
 *Anatole Tresch*
 Java Engineer  Architect, JSR Spec Lead
 Glärnischweg 10
 CH - 8620 Wetzikon
 
 *Switzerland, Europe Zurich, GMT+1*
 *Twitter:  @atsticks*
 *Blogs: **http://javaremarkables.blogspot.ch/
 http://javaremarkables.blogspot.ch/*
 
 *Google: atsticksMobile  +41-76 344 62 79*
 
 =
 
 = Apache Tamaya - Proposal =
 
 == Abstract ==
 Tamaya is a highly flexible configuration solution based on an
 modular, extensible and
 injectable key/value based design, which should provide a minimal but
 extendible
 modern and functional API leveraging SE, ME and EE environments.
 
 ''Tamaya'' hereby translates into ''in the middle'', which is exactly,
 what configuration should be. It should be
 in the middle between your code and your runtime.
 
 '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend''
 or ''Orenda=magic force''.
 
 
 == Proposal ==
 Tamaya is a highly flexible configuration API based on an modular,
 extensible and
 injectable key/value based design. The basic building blocks hereby are:
 
 * ''property providers'' implementing a small and easily
 implementable subset of a `MapString,String`.
 * support for configuration injection
 * a type-safe configuration template mechanism
 * serializable and remote configuration support
 * a JMX/Rest based management console
 * Configuration will follow the GoF composite pattern and support
 several combination strategies.
 * An extendible and adaptable environment model, so configuration can
 be provided dependent of the environment currently active.
 * extension points and a powerful SPI to seamlessly add additional
 logic to the API, such as secured views, multi-valued validation
 schemes, en-/decryption etc.
 * Configuration (and property providers) are designed and implemented
 as indirectly mutable types, providing thread-safe and performant to
 configuration.
 * Configuration changes can be observed by listening on `ConfigChange` events.
 
 The API's focus is on simplicity and ease of use. Developers should
 only have to know a minimal set of artifacts to work with the
 solution.
 The API is built on latest Java 8 features and therefore fit perfectly
 with the functional features of Java 8.
 
 Additionally Apache Tamaya will provide
 * A Java SE based implementation with minimal features and dependencies.
 * A Java EE extension module for integration with Java EE and Apache
 Deltaspike.
 * Once Java ME supports Lambdas, default methods, method references
 and functional interfaces an implementation targeting Java ME should
 be provided as well.
 * Extension modules for different features.
 * Adapter/inter-operation modules for other configuration solutions
 including Apache commons-config
 
 == Background ==
 There is a global initiative running now for about a year lead by
 Anatole Tresch (Credit Suisse)
 with the target of standardizing configuration in Java EE and SE. Due
 to several reasons it
 seems currently most sensible to start an OSS project on the topic to
 join forces that actively
 want to contribute to the project. It is highly probably that
 standardization will be restarted
 at a later point once we have a widely used Apache standard.
 For further information you may look at http://javaeeconfig.blogspot.com .
 
 == Rationale ==
 Configuration is one of the most cross-cutting concerns, which still
 lacks of a standard.
 Java EE is currently (EE7) in most areas strictly only configurable during
 build time of the deployed artifacts. Especially dynamic provisioning
 of resources or runtime configuration
 is not supported and in many cases impossible to add without tweaking
 the underlying application server.
 On the other hand running two separate configuration solutions for
 Java EE and Java SE as well make no or
 little sense. So it would be important we have a unified configuration
 model at hand, that is flexible enough, so
 
 * it can be used in Java SE, EE and ME
 * it can support contextual behaviour (like in Java EE and
 multi-tenancy/SaaS scenarios)
 * it provides a uniform API, regardless, if its used in SE or EE scenarios
 * it supports existing APIs, e.g. `System.getProperties,
 java.util.preferences` in SE and `CDI, JNDI` in Java EE
 * it supports service location pattern like access as well as
 ''injection'' of configured values.
 * it is simple in use and easily extensible.
 * it support integration with existing configuration solutions
 

Re: Incubator PMC/Board report for Nov 2014 ([ppmc])

[Alan D. Cabrera]

 On Oct 29, 2014, at 9:21 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 
 On Oct 29, 2014, at 9:08 AM, Andy Seaborne a...@apache.org wrote:
 
 On 27/10/14 14:15, 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, 19 November 2014, 10:30 am 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, Nov 5th).
 
 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.
 
 Thanks,
 
 The Apache Incubator PMC
 
 Taverna wasn't in the incubator template so I added a section for it to make 
 sure it didn't get lost.  No shepherd assignment.
 
 Have I failed to find some place that needs updating so the template 
 includes Taverna?  Or was it just timing, because we only started late in 
 October?
 
 I think that it’s because you started after I ran the tools.  I’ll update the 
 shepherd assignments.

Updated.

Roman, I’ve assigned you the task of shepherding Taverna this month.  :)


Regards,
Alan


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

Re: [VOTE] Release Apache Flink 0.7.0-incubating

[Alan D. Cabrera]

This doesn’t seem to exist.  Does that matter?


Regards,
Alan

On Oct 22, 2014, at 12:29 AM, Robert Metzger rmetz...@apache.org wrote:

 The staging repository for this release can be found at:
 https://repository.apache.org/content/repositories/orgapacheflink-1016
 -

Re: [VOTE] Release Apache Flink 0.7.0-incubating

[Alan D. Cabrera]

I ran rat and found that there are a number of Markdown, HTML, Scala archetype 
files that don’t seem to have the proper license header.


Regards,
Alan


On Oct 22, 2014, at 12:29 AM, Robert Metzger rmetz...@apache.org wrote:

 Hi all,
 
 This is our second try to release Flink 0.7.0-incubating. The last time we
 found a critical issue while the vote was running, so I had to cancel the
 vote here.
 The 0.7.0-incubating release will be the second major-version release of
 Flink in the incubator.
 
 
 The vote thread can be found here:
 *https://mail-archives.apache.org/mod_mbox/incubator-flink-dev/201410.mbox/%3CCAGr9p8DqXzM1_SM32zw-nMzZ%2B7%2B1f8XNhyhQzFOxwFFRxp%3DYpw%40mail.gmail.com%3E
 https://mail-archives.apache.org/mod_mbox/incubator-flink-dev/201410.mbox/%3CCAGr9p8DqXzM1_SM32zw-nMzZ%2B7%2B1f8XNhyhQzFOxwFFRxp%3DYpw%40mail.gmail.com%3E*
 
 The vote passed with +6 binding votes from the PPMC.
 
 -
 The commit to be voted on is in the branch release-0.7.0-rc2 (commit
 cf4c6e7077fa4c3e3d96758b2f563ec17148a786):
 *http://git-wip-us.apache.org/repos/asf/incubator-flink/commit/cf4c6e70
 http://git-wip-us.apache.org/repos/asf/incubator-flink/commit/cf4c6e70*
 
 The release artifacts to be voted on can be found at:
 *http://people.apache.org/~rmetzger/flink-0.7.0-incubating-rc2/
 http://people.apache.org/~rmetzger/flink-0.7.0-incubating-rc2/*
 
 Release artifacts are signed with the following key:
 https://people.apache.org/keys/committer/rmetzger.asc
 
 The staging repository for this release can be found at:
 https://repository.apache.org/content/repositories/orgapacheflink-1016
 -
 
 Please vote to approve this release.
 
 The vote is open for 72 hours or until the necessary number of votes is
 reached (+3).
 [ ] +1 Release this package as Apache Flink 0.7.0-incubating
 [ ] -1 Do not release this package because ...
 
 
 Thanks!


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

Re: [VOTE] Accept Taverna into the Apache Incubator

[Alan D. Cabrera]

+1 - binding

I assume that you mean Taverna instead of Lens.


Regards,
Alan

On Oct 16, 2014, at 8:54 AM, Andy Seaborne a...@apache.org wrote:

 Following the discussion earlier in the thread:
 
 https://www.mail-archive.com/general@incubator.apache.org/msg45241.html
 
 I would like to call a Vote for accepting Taverna as a new incubator project.
 
 The proposal is available at:
 
 https://wiki.apache.org/incubator/TavernaProposal
 
 Vote is open until at least Sunday, 19th October 2014, 23:59:00 UTC
 
 [ ] +1 accept Lens in the Incubator
 [ ] ±0
 [ ] -1 because...
 
 Only Votes from Incubator PMC members are binding, but everyone is welcome to 
 contribute to the process.
 
   Andy
 
 -
 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 Lens into the Apache Incubator (earlier called Grill)

[Alan D. Cabrera]

+1 - binding


Regards,
Alan

On Oct 6, 2014, at 4:51 AM, Sharad Agarwal sha...@apache.org wrote:

 Following the discussion earlier in the thread
 https://www.mail-archive.com/general@incubator.apache.org/msg45208.html
 I would like to call a Vote for accepting Lens as a new incubator project.
 
 The proposal is available at:
 https://wiki.apache.org/incubator/LensProposal
 
 Vote is open till Oct 09, 2014 4 PM PST.
 
 [ ] +1 accept Lens in the Incubator
 [ ] +/-0
 [ ] -1 because...
 
 Only Votes from Incubator PMC members are binding, but all are welcome to
 express their thoughts.
 I am +1 (non-binding).
 
 Thanks
 Sharad


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

Re: October reporting

[Alan D. Cabrera]

I'm happy to do it again.

Regards,
Alan

On Oct 4, 2014, at 2:15 PM, Roman Shaposhnik r...@apache.org wrote:

 Hi!
 
 I am just wondering if this month I'll be as lucky
 as the previous few and could rely on excellent
 work of report manager volunteers to fill out the
 October report.
 
 As usual, the most tricky bit is chasing all the poddling
 releases.
 
 Thanks,
 Roman.
 
 -
 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

76 character widths for board reports?

[Alan D. Cabrera]

Is this really necessary?

Speaking as one who actually coded on punched cards on an octal based computer, 
I feel indignant that you young whippersnappers don't appreciate the hard won 
freedoms us older coders have brought to the younger generations.


Regards,
Alan


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

Re: September report

[Alan D. Cabrera]

Busy night last night.  Hoping to do it this morning.


Regards,
Alan

On Sep 7, 2014, at 10:33 PM, Marvin Humphrey mar...@rectangular.com wrote:

 On Sun, Sep 7, 2014 at 9:57 PM, Roman Shaposhnik r...@apache.org wrote:
 
 Also, if there's anybody planning on creating
 a summary -- please let me know. Otherwise
 I'll do by the end of the day tomorrow.
 
 If this month's Report Manager needs support, I'm happy to pitch in.
 If we have to fall back to the PMC Chair handling the report, I'm also
 happy to pitch in.
 
 I'll check in tomorrow to see where things are at.
 
 Marvin Humphrey
 
 -
 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: September report

[Alan D. Cabrera]

Filled in a fair bit.  I can’t get back to fill in the rest of the bits until 
later this afternoon.


Regards,
Alan

On Sep 8, 2014, at 5:45 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 Busy night last night.  Hoping to do it this morning.
 
 
 Regards,
 Alan
 
 On Sep 7, 2014, at 10:33 PM, Marvin Humphrey mar...@rectangular.com wrote:
 
 On Sun, Sep 7, 2014 at 9:57 PM, Roman Shaposhnik r...@apache.org wrote:
 
 Also, if there's anybody planning on creating
 a summary -- please let me know. Otherwise
 I'll do by the end of the day tomorrow.
 
 If this month's Report Manager needs support, I'm happy to pitch in.
 If we have to fall back to the PMC Chair handling the report, I'm also
 happy to pitch in.
 
 I'll check in tomorrow to see where things are at.
 
 Marvin Humphrey
 
 -
 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: Tooling friendly incubator report

[Alan D. Cabrera]

I already am aware of Whimsy.  :)

My main goal is to put into place building blocks, for automated tooling, 
around bits such as reporting, mailing list management, etc.  These can be used 
my Whimsy as well as other tooling bits and my site.

As for my site, I like Python and wish to goof around with panopticon.  I, 
frankly, don’t see that harm in that since I am taking great pains to make sure 
that Whimsy is not excluded from the building blocks that I wish to put into 
place.  Nor am I requiring that Whimsy uses panopticon to take advantage of the 
work.


Regards,
Alan

On Sep 4, 2014, at 1:19 AM, Upayavira u...@odoko.co.uk wrote:

 Alan,
 
 I really really encourage you to take a look at Whimsy. It is both a
 front end, and also has libraries for integrating with other things at
 the ASF, such as subversion, etc. It'd be great if we were able to use
 the same tooling for incubator as we are for board reports, etc.
 
 Just a thought,
 
 Upayavira
 
 On Wed, Sep 3, 2014, at 10:33 PM, Alan D. Cabrera wrote:
 
 On Sep 3, 2014, at 2:11 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 
 On Wed, Sep 3, 2014 at 1:05 PM, Marvin Humphrey mar...@rectangular.com
 wrote:
 
 So how about creating the web form but having it generate text which can be
 inserted into the wiki template?  That would allow us to tune the web
 interface without committing to the new format.
 
 
 +1
 
 A simple interface to copy/paste the entire podling report or by section
 and also for mentors to sign off would be a bit of an improvement over the
 current system.
 
 I don't see much attraction to manually editing YAML or JSON.
 
 
 +1 too
 
 You may recall earlier in this thread I mentioned that I'm writing some
 tooling for editing and report generating in:
 
 https://svn.apache.org/repos/asf/labs/panopticon
 
 This is by no means the only way we can modify this file.  The idea is to
 be tool agnostic and let a hundred flowers bloom”.
 
 The whole point in getting this information into YAML is to make the data
 accessible and freely available to what ever tooling is out there.
 
 
 Regards,
 Alan
 
 
 -
 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: Tooling friendly incubator report

[Alan D. Cabrera]

On Sep 2, 2014, at 5:49 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Sat, Aug 30, 2014 at 8:54 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 On Aug 24, 2014, at 2:16 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 On Sun, Aug 24, 2014 at 1:54 PM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 but its just my opinion, and if incubator is used to work differently, I
 will not be the one to propose big changes.
 
 This is pretty much how it works now.  As I mentioned above, I am merely 
 proposing
 that we use a more structured YAML file instead of a wiki page.
 
 On that note: I *really* would like to start using YAMLized version
 for our Sep report.
 
 I think that we'll stick w/ the wiki for September's report.  We need to 
 work out things like where to put the YAML file.
 
 Can I make a suggestion, please?
 
 Would it be too much to ask to have YAML report *in addition*
 with the regular wiki?

Keeping the YAML file in sync with the free form wiki would be very difficult.  

IMO, having both would be confusing.

 We should be absolutely clear that it is auxiliary, but I think
 it will be a useful way for poddlings to familiarize themselves
 with the structure of the YAML file and ease the transition
 later on.

Working with a YAML file will not be too difficult for podlings; this is a 
technical community.

 Where should we put the YAML file.  It needs to be in a place where all 
 committers have R/W access.  I was thinking:
 
 https://svn.apache.org/repos/asf/incubator/public/trunk/content/data/reports
 
 This looks like as good place as any. Besides, changing that location
 is one svn mv away ;-)

Do podling committers have R/W access?


Regards,
Alan

Re: Tooling friendly incubator report

[Alan D. Cabrera]

On Sep 3, 2014, at 2:11 PM, Ted Dunning ted.dunn...@gmail.com wrote:

 On Wed, Sep 3, 2014 at 1:05 PM, Marvin Humphrey mar...@rectangular.com
 wrote:
 
 So how about creating the web form but having it generate text which can be
 inserted into the wiki template?  That would allow us to tune the web
 interface without committing to the new format.
 
 
 +1
 
 A simple interface to copy/paste the entire podling report or by section
 and also for mentors to sign off would be a bit of an improvement over the
 current system.
 
 I don't see much attraction to manually editing YAML or JSON.


+1 too

You may recall earlier in this thread I mentioned that I'm writing some tooling 
for editing and report generating in:

https://svn.apache.org/repos/asf/labs/panopticon

This is by no means the only way we can modify this file.  The idea is to be 
tool agnostic and let a hundred flowers bloom”.

The whole point in getting this information into YAML is to make the data 
accessible and freely available to what ever tooling is out there.


Regards,
Alan

September 2014 Incubator report timeline

[Alan D. Cabrera]

September 2014 Incubator report timeline:

   http://wiki.apache.org/incubator/September2014

   Wed September 03 -- Podling reports due by end of day
   Sun September 07 -- Shepherd reviews due by end of day
   Sun September 07 -- Summary due by end of day
   Tue September 09 -- Mentor signoff due by end of day
   Wed September 10 -- Report submitted to Board
   Wed September 17 -- Board meeting

Re: Tooling friendly incubator report

[Alan D. Cabrera]

On Aug 24, 2014, at 2:16 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Sun, Aug 24, 2014 at 1:54 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 but its just my opinion, and if incubator is used to work differently, I
 will not be the one to propose big changes.
 
 This is pretty much how it works now.  As I mentioned above, I am merely 
 proposing
 that we use a more structured YAML file instead of a wiki page.
 
 On that note: I *really* would like to start using YAMLized version
 for our Sep report.

I think that we'll stick w/ the wiki for September's report.  We need to work 
out things like where to put the YAML file.

Where should we put the YAML file.  It needs to be in a place where all 
committers have R/W access.  I was thinking:

https://svn.apache.org/repos/asf/incubator/public/trunk/content/data/reports

Then the data can be automatically available via 

http://incubator.apache.org/data/reports


Regards,
Alan


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

Re: Tooling friendly incubator report

[Alan D. Cabrera]

On Aug 24, 2014, at 2:35 PM, Marvin Humphrey mar...@rectangular.com wrote:

 On Sun, Aug 24, 2014 at 12:47 PM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 Here's a first sketch of a YAML based incubator report
 
 I suggest that those who wish to refactor how the Incubator report is
 done first take a turn as Report Manager -- familiarizing themselves
 with the existing toolset, and collaborating with the existing
 volunteers.

How do I get started?


Regards,
Alan


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

Re: Tooling friendly incubator report

[Alan D. Cabrera]

There can be.  That’s why I’m espousing a tool free solution.


Regards,
Alan

On Aug 24, 2014, at 6:43 PM, Brett Porter br...@apache.org wrote:

 There seems to be some overlap with what whimsy does (though also additional 
 incubator specifics). I wonder if there's an opportunity for reuse there?
 
 - Brett
 
 On 25 Aug 2014, at 5:47 am, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 Here's a first sketch of a YAML based incubator report
 
 https://wiki.apache.org/incubator/ReportFormat
 
 I'm writing some tooling for editing and report generating in:
 
 https://svn.apache.org/repos/asf/labs/panopticon
 
 This is by no means the only way we can modify this file.  The idea is to be 
 tool agnostic and let a hundred flowers bloom.
 
 
 Regards,
 Alan
 
 
 
 -
 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: Mentors heartbeat

[Alan D. Cabrera]

On Aug 24, 2014, at 9:06 AM, Benson Margulies bimargul...@gmail.com wrote:

 I am a programmer and like formats like JSON, but  it is true that the
 world does not only consist of programmers, so I suggest we make 2 webpages:
 - one page that create/modify the report and update svn with the JSON file
 - one page where mentors can sign the report
 
 json === yaml, and anyone could edit yaml.

YAML works for me.  If we store these reports in a known protected location in 
svn then people could write what ever tooling they wished to updated.

 I am not so sure if its worth while with the board report.

What's good for the goose is good for the gander.  Having the board report in 
machine readable formats provides the same advantages as that afforded 
incubator reports.


Regards,
Alan

Re: Mentors heartbeat

[Alan D. Cabrera]

On Aug 24, 2014, at 10:51 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 I am not so sure if its worth while with the board report.
 
 What's good for the goose is good for the gander.  Having the board report in 
 machine readable formats provides the same advantages as that afforded 
 incubator reports.

If these machine readable reports work out, I see no reason why they would not, 
then I predict an explosion of tool driven processes, e.g. release voting, 
podling acceptance and graduation votes, etc.


Regards,
Alan

Tooling friendly incubator report

[Alan D. Cabrera]

Here's a first sketch of a YAML based incubator report

https://wiki.apache.org/incubator/ReportFormat

I'm writing some tooling for editing and report generating in:

https://svn.apache.org/repos/asf/labs/panopticon

This is by no means the only way we can modify this file.  The idea is to be 
tool agnostic and let a hundred flowers bloom.


Regards,
Alan

Re: Tooling friendly incubator report

[Alan D. Cabrera]

On Aug 24, 2014, at 12:54 PM, jan i j...@apache.org wrote:

 On 24 August 2014 21:47, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 Here's a first sketch of a YAML based incubator report
 
 https://wiki.apache.org/incubator/ReportFormat
 
 looks good, but 2 questions arise after a brief look:
 
 you use the expression shepherds, thats a new expression to me (I thought
 we in TAC was the only the used it).

What's TAC?

Shepherds are supposed to review the reports.

 I thought you would start with the single incubator project reports,
 because the board report can to a large extent be generated from those ?

There's shared collected data about the Incubator itself.  We could break out 
the podlings' reports into separate files but that would lead to an explosion 
of files in the report directory.


Regards,
Alan


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

How many podlings are being incubated?

[Alan D. Cabrera]

Lookse like we need to update podling.xml.  The August report states 31.  My 
tooling states 33:

Argus
Aurora
BatchEE
Blur
Brooklyn
Celix
DataFu
DeviceMap
Drill
Droids
Falcon
Fleece
Flink
Hadoop Development Tools
Kalumet
log4cxx2
MetaModel
MRQL
NPanday
ODF Toolkit
Optiq
Parquet
REEF
Ripple
Samza
Sentry
Sirona
Slider
Storm
Streams
Twill
Usergrid
Wave




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

Re: Tooling friendly incubator report

[Alan D. Cabrera]

On Aug 24, 2014, at 1:26 PM, jan i j...@apache.org wrote:

 On 24 August 2014 22:00, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 
 On Aug 24, 2014, at 12:54 PM, jan i j...@apache.org wrote:
 
 On 24 August 2014 21:47, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 Here's a first sketch of a YAML based incubator report
 
 https://wiki.apache.org/incubator/ReportFormat
 
 looks good, but 2 questions arise after a brief look:
 
 you use the expression shepherds, thats a new expression to me (I
 thought
 we in TAC was the only the used it).
 
 What's TAC?
 
 Travel Assistance, another internal project.
 
 
 
 Shepherds are supposed to review the reports.
 
 Sometimes its good to be new in a project, and able to ask the of course
 questions.
 
 http://incubator.apache.org/incubation/Roles_and_Responsibilities.html
 
 Does not have a thing called shepherd. Seems like a good idea though.

This is a role that's been in place for a while now.  I, personally, am loath 
to document it since I am adamantly against having this role in the first 
place.  (please, don't respond to my opinion on this thread)

 I thought you would start with the single incubator project reports,
 because the board report can to a large extent be generated from those ?
 
 There's shared collected data about the Incubator itself.  We could break
 out the podlings' reports into separate files but that would lead to an
 explosion of files in the report directory.
 
 
 Then let me see if I misunderstood the sequence. I thought every incubator
 project submit its own report internally to incubator, and that is then
 combined into the board report.

Currently, a single wiki page gets generated, emails get sent out notifying the 
podlings that a report is due, and podlings fill in the wiki page.  Instead of 
scraping a wiki page I am proposing a more structured YAML file to replace the 
wiki page.

 I would really prefer that every incubator project had its own file (or
 directory if you prefer), it has 2 advantages:
 1) the file only contain information relevant for that project.
 2) it is much easier for IPMC to determine, which mentors have acted on a
 specific project report.

These are tooling issues.  All things being equal, one file per month is better 
than N files per month.

 the board report should then be assembled via a tool, and IPMC (the chair)
 can add the verbal missing parts.

Yep.

 but its just my opinion, and if incubator is used to work differently, I
 will not be the one to propose big changes.

This is pretty much how it works now.  As I mentioned above, I am merely 
proposing that we use a more structured YAML file instead of a wiki page.


Regards,
Alan

Re: Tooling friendly incubator report

[Alan D. Cabrera]

On Aug 24, 2014, at 2:35 PM, Marvin Humphrey mar...@rectangular.com wrote:

 On Sun, Aug 24, 2014 at 12:47 PM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 Here's a first sketch of a YAML based incubator report
 
 I suggest that those who wish to refactor how the Incubator report is
 done first take a turn as Report Manager -- familiarizing themselves
 with the existing toolset, and collaborating with the existing
 volunteers.

Sounds good.  I volunteer to be September's Report Manager.


Regards,
Alan


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

Re: Tooling friendly incubator report

[Alan D. Cabrera]

On Aug 24, 2014, at 2:16 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Sun, Aug 24, 2014 at 1:54 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 but its just my opinion, and if incubator is used to work differently, I
 will not be the one to propose big changes.
 
 This is pretty much how it works now.  As I mentioned above, I am merely 
 proposing
 that we use a more structured YAML file instead of a wiki page.
 
 On that note: I *really* would like to start using YAMLized version
 for our Sep report.
 
 Any objections to that?

SGTM.


Regards,
Alan


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

Re: Mentors heartbeat

[Alan D. Cabrera]

This is pretty cool but I think it underscores the need to get off of free form 
files that need to be scraped.

I think that maybe for future reports we can have a JSON file in svn that 
people can update.  We could then have our report automatically generated from 
the JSON file for the board report; which, btw, I think should also be a JSON 
file.

wdyt?


Regards,
Alan


On Aug 23, 2014, at 3:23 PM, Mattmann, Chris A (3980) 
chris.a.mattm...@jpl.nasa.gov wrote:

 Sorry  https://github.com/chrismattmann/apachestuff
 
 Sent from my iPhone
 
 On Aug 23, 2014, at 3:22 PM, Mattmann, Chris A (3980) 
 chris.a.mattm...@jpl.nasa.gov wrote:
 
 Check my apachestuff GitHub repo 
 https://guthub.com/chrismattmann/apachestuff
 
 Sent from my iPhone
 
 On Aug 23, 2014, at 3:16 PM, Roman Shaposhnik r...@apache.org wrote:
 
 Hi!
 
 in my never ending quest to help boost the
 graduation rate I've come across a few cases
 where I had to reach out to project mentors.
 Typically the initial list would be around 3
 individuals, but the reply would only come
 from a single one.
 
 I believe we owe it to the projects to monitor
 whether there mentors are MIA and take
 corrective actions. There's not too many
 promises that we IPMC makes to the podlings,
 but promising a reasonable amount of
 mentor attention is definitely one of them.
 
 I'm open to suggestions of how we can start
 tracking MIA mentors and what actions would
 help to remedy the situation.
 
 Thanks,
 Roman.
 
 -
 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
 


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

Re: [VOTE] Graduate Apache Storm to a TLP

[Alan D. Cabrera]

+1 binding


Regards,
Alan

On Aug 18, 2014, at 2:02 PM, P. Taylor Goetz ptgo...@apache.org wrote:

 Apache Storm has been incubating since September 2014. Since then we have 
 added 3 additional committers (with another 2 approved and pending account 
 creation), and performed two releases. The Storm community recently voted to 
 graduate[1] with 11 +1 votes. Of the 11 votes, 2 were from IPMC members:
 
- Arvind Prabhakar
- Suresh Srinivas
 
 I would now like to ask the IPMC to vote for the graduation of Apache Storm 
 to a top-level project.
 
 Please vote to indicate if Apache Storm is ready to graduate. The proposed 
 board resolution is included below.
 
 [ ] +1 Graduate Apache Storm as a TLP
 [ ] +0 No opinion
 [ ] -1 Do not graduate Apache Storm as a TLP because…
 
 This vote will be open for at least 72 hours.
 
 - Taylor
 
 [1] 
 http://mail-archives.apache.org/mod_mbox/incubator-storm-dev/201408.mbox/%3c6ea90e5b-792f-4ec2-b5fc-086caf642...@apache.org%3e
 
 
 
 === Board Resolution ===
 
X. Establish the Apache Storm 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, for distribution at no charge to 
   the public, related to distributed, fault-tolerant, 
   and high-performance realtime computation.
 
   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Storm Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further
 
   RESOLVED, that the Apache Storm Project be and hereby is
   responsible for the creation and maintenance of software
   related to distributed, fault-tolerant, and high-
   performance realtime computation; and be it further
 
   RESOLVED, that the office of Vice President, Apache Storm 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 Storm Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Storm 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 Storm Project:
 
 * Derek Dagit  (da...@apache.org)
 * Devaraj Das  (d...@apache.org)
 * Ted Dunning  (tdunn...@apache.org)
 * Robert Evans (bo...@apache.org)
 * Andy Feng(af...@apache.org)
 * P. Taylor Goetz  (ptgo...@apache.org)
 * Jason Jackson(jjack...@apache.org)
 * Flip Kromer  (mrf...@apache.org)
 * David Lao(d...@apache.org)
 * Nathan Marz  (nathanm...@apache.org)
 * Michael G. Noll  (mig...@apache.org)
* Arvind Prabhakar (arv...@apache.org)
 * James Xu (xumingm...@apache.org)
 
   NOW, THEREFORE, BE IT FURTHER RESOLVED, that P. Taylor Goetz
   be appointed to the office of Vice President, Apache Storm, 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 Storm 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 Storm Project; and be it further
 
   RESOLVED, that the Apache Storm Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator Storm podling; and be it further
 
   RESOLVED, that all responsibilities pertaining to the Apache
   Incubator Storm podling encumbered upon the Apache Incubator
   Project are hereafter discharged.


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

Re: [VOTE] Accept REEF into the Apache Incubator

[Alan D. Cabrera]

+1 binding


Regards,
Alan

On Aug 8, 2014, at 10:40 PM, Byung-Gon Chun bgc...@gmail.com wrote:

 Let's keep this vote open for three business days, closing the voting on
 August 11, 11:59PM (PDT).
 
 [] +1 Accept REEF into the Incubator
 [] 0 Don't care
 [] -1 Don't accept REEF because...