Re: Concerning Sentry: A disagreement over the Apache Way and graduation

2015-11-15 Thread Justin Erenkrantz 
On Saturday, November 14, 2015, Rich Bowen  wrote:

> No. I can use whatever criteria I like to justify my vote on a podlings
> graduation, if it's in line with asf philosophy. This document is,  and
> accurately reflects the criteria I use when voting on a graduation. That
> is, the document reflects me, not vice versa, as I said above.
>
> It's very akin to the docs that circulate around member election time. They
> are useful guidelines but nobody is compelled to adhere to any particular
> one of them.
>

The difference is that member elections are majority-based - graduation
votes are essentially subject to veto.

There's a huge difference there.  If you are subjecting all of your votes
to that checklist and will actively block podlings that do not meet your
personal guidelines, you are making everyone else subject to it.  -- justin

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

2015-11-15 Thread Joe Brockmeier 
Top-posting on purpose. 

This thread has veered from discussing specific concerns about Sentry to
a discussion about the Maturity Model. It'd probably be good to fork the
thread and continue the discussion separately in case other folks
specifically interested in the discussion about Sentry are watching this
thread. 

Best, 

jzb

On Sun, Nov 15, 2015, at 01:56 PM, Pierre Smits wrote:
> Justin,
> 
> Why is it so that graduation can be vetoed?
> 
> Best regards,
> 
> Pierre Smits
> 
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
> 
> On Sun, Nov 15, 2015 at 4:13 PM, Justin Erenkrantz
> 
> wrote:
> 
> > On Saturday, November 14, 2015, Rich Bowen  wrote:
> >
> > > No. I can use whatever criteria I like to justify my vote on a podlings
> > > graduation, if it's in line with asf philosophy. This document is,  and
> > > accurately reflects the criteria I use when voting on a graduation. That
> > > is, the document reflects me, not vice versa, as I said above.
> > >
> > > It's very akin to the docs that circulate around member election time.
> > They
> > > are useful guidelines but nobody is compelled to adhere to any particular
> > > one of them.
> > >
> >
> > The difference is that member elections are majority-based - graduation
> > votes are essentially subject to veto.
> >
> > There's a huge difference there.  If you are subjecting all of your votes
> > to that checklist and will actively block podlings that do not meet your
> > personal guidelines, you are making everyone else subject to it.  -- justin
> >


Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

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

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

2015-11-15 Thread Rich Bowen 
On Nov 15, 2015 10:14 AM, "Justin Erenkrantz"  wrote:
>
> On Saturday, November 14, 2015, Rich Bowen  wrote:
>
> > No. I can use whatever criteria I like to justify my vote on a podlings
> > graduation, if it's in line with asf philosophy. This document is,  and
> > accurately reflects the criteria I use when voting on a graduation. That
> > is, the document reflects me, not vice versa, as I said above.
> >
> > It's very akin to the docs that circulate around member election time.
They
> > are useful guidelines but nobody is compelled to adhere to any
particular
> > one of them.
> >
>
> The difference is that member elections are majority-based - graduation
> votes are essentially subject to veto.
>
> There's a huge difference there.  If you are subjecting all of your votes
> to that checklist and will actively block podlings that do not meet your
> personal guidelines, you are making everyone else subject to it.  --
justin

Sure. If these were just my personal guidelines, that would indeed be a
concern.

I'd assert, however, that we already have members voting on their own
personal guidelines, they just haven't written them down for the rest of us
to see.

Re: Apache Metrics, Not Apache Humans

2015-11-15 Thread toki 
On 15/11/2015 18:20, Marko Rodriguez wrote:

>   1. There is no need to have philosophical arguments (not grounded in 
> measurables) about what rules a project should follow (bounded by law). 

"Healthy" is intrinsically subjective, and as such, unmeasurable,
leading to even more debates as to whether or not a project is "healthy".

> Apache becomes a breeding ground for different models of open source (bounded 
> by law), not just "The Apache Way." 

"The Apache Way" was formulated for a reason, and not only because it
more or less works as designed.

Other models of open source have different points of failure, some of
them being the equivalent of sepiku on sight.

> The Apache Way should be about metrics,

The major problem with measuring things, is that the only things that
get done, are those that get measured. This is most clearly seen in the
bankruptcy of ISO-9000 certified organizations, that won awards for
their quality control, and measurement in changes thereof.
(In some fields of endeavour, ISO-9000 certification is the first step
towards an inevitable chapter 7 bankruptcy filing.)

> not about philosophy as different paths lead to the same mountain top

Somebody failed Buddhist Logic 101. (Not all paths lead to the same
mountain top, even if they appear to start at the base of the same
mountain.)

> P.S. The same should hold true for educational degrees. I graduate and now 
> forever I'm an expert in computers? 

That depends upon whether you went to a vocational/trade school, or an
institutional that gave you a real education. (Hint: if you didn't learn
the YiJing,TRIZ, and at least seven languages, alongside the seven arts,
you didn't have an education.)

jonathon



signature.asc
Description: OpenPGP digital signature

Re: Apache Metrics, Not Apache Humans

2015-11-15 Thread Andrew Purtell 
> Because of Apache Infrastructure's centralized server model (email lists,
version control, distributions, homepages, etc.), it  has the ability to
gather metrics such as, for example, the distribution of pushes to the
repository, the branch factor of the mailing list, the centrality of the
project in the Central Maven repository dependency graph, the number of
non-sequisters (dead-end conversations) in the email chain, the length of
discussions in JIRA, etc. etc.

Does anyone have any statistically significant measure that any of those
"measurables" define the health of a community?

> Which metrics are important? Who care -- just make up things to glean
from the wealth of information you already have access to. Watch...

"Who care".

"Just make up things".

WTH. Yeah, I thought not.

> Next, the Apache members subjectively say which projects they think are
"good" (healthy).
> [...]
​> From here, all Apache projects have a computed "healthy" score(s) and
when users go to download, lets say, Lucene, they go: "Cool. This is a
healthy project." (it has a HEALTH.txt file distributed with it, lets say).

​That file should not be named HEALTH.txt, ​it should be called
POPULARITY_CONTEST_WINNERS.txt.

What is wrong with, for the most part, allowing communities to define their
own success? Why do we have to pick "best"?

Why should every project community not picked as "best" by the membership
not then respond with an immediate and hearty "fuck you"?

I'm sorry, but this reads as a collection of frighteningly terrible ideas
that I hope die as quickly as possible.


On Sun, Nov 15, 2015 at 10:20 AM, Marko Rodriguez 
wrote:

> Hi,
>
> I was talking with Daniel Gruno and wrote the following ideas to him. Note
> that these are just ideas and not based on any real momentary issue or
> concern -- though a more general concern about how Apache should evolve.
>
> Apache should NOT use a binary "podling" / "top-level" model. All projects
> should simply have a "health score" and that health score is derived from
> measurables. Because of Apache Infrastructure's centralized server model
> (email lists, version control, distributions, homepages, etc.), it  has the
> ability to gather metrics such as, for example, the distribution of pushes
> to the repository, the branch factor of the mailing list, the centrality of
> the project in the Central Maven repository dependency graph, the number of
> non-sequisters (dead-end conversations) in the email chain, the length of
> discussions in JIRA, etc. etc. Which metrics are important? Who care --
> just make up things to glean from the wealth of information you already
> have access to. Watch...
>
> Next, the Apache members subjectively say which projects they think are
> "good" (healthy). This can even be a global vote including everyone in the
> world and (should be) dynamic over time as projects evolve with time.
> Either way, lets say, the ranking says Apache Hadoop, Apache Solr, Apache
> Commons, etc. are the (collective subjective's) "best" Apache projects.
> Now, there should exist a multi-dimensional projection of the
> aforementioned gleaned statistics what will have Hadoop, Solr, Commons,
> etc. close to one another in metric-space (clustered). Likewise, low
> ranking projects should be close to one another in this space and far from
> Hadoop, Solr, Commons, etc. Find that projection and that is your "healthy
> metric space."
>
> From here, all Apache projects have a computed "healthy" score(s) and when
> users go to download, lets say, Lucene, they go: "Cool. This is a healthy
> project." (it has a HEALTH.txt file distributed with it, lets say). What
> that means is that Lucene, at that release was in the "healthy" cluster of
> the metric space. This model has various benefits:
>
> 1. There is no need to have philosophical arguments (not grounded
> in measurables) about what rules a project should follow (bounded by law).
> - Perhaps a project that is exclusive, but is X is still
> in the "healthy" subspace.
> - Perhaps having bad documentation is a "unhealthy" even
> though Apache doesn't care about documentation.
> - Perhaps too much discussion causes a project to become
> "unhealthy."
> - Perhaps … who knows? … let the statistics do the talking.
> -  Apache becomes a breeding ground for different models
> of open source (bounded by law), not just "The Apache Way."
> - And these models are measurable! Let us study
> the act of open source.
> 2. "Top-level" projects can fall from grace.
> - Currently, all "top-level" projects are "equal." This
> should by dynamic as the mighty do fall.
> - It is possible for what are now "podlings" to be
> "healthy" as they simply are coming into Apache.
> - "The student is the master."
> - Hadoop 1.2.1 might be the

Re: [DISCUSS] S2Graph Incubator Proposal

2015-11-15 Thread Alexander Bezzubov 
Hi Hyunsik,

the proposal looks strong and the project itself very interesting.
Enthusiastic thumbs up, looking forward the incubation.

Please let me know if there is something I can help with - I would be happy
to get envolved and help you guys with issues related to incubation.

--
Alex

On Sat, Nov 14, 2015, 01:27 Marvin Humphrey  wrote:

> On Thu, Nov 12, 2015 at 9:01 PM, Byung-Gon Chun  wrote:
> > The proposal looks interesting. I'd love to help as a mentor but I can't
> > since I'm not an IPMC member.
>
> Hello Byung-Gon,
>
> You can certainly get involved and help out S2Graph with community,
> legal and other issues related to incubation but not the codebase,
> without being a Mentor or on the IPMC.
>
> And if you sustain that activity in the Incubator and around the other
> common areas of the ASF, demonstrating both competence and commitment,
> hopefully the IPMC would eventually recognize your merit and invite
> you aboard. That's how it's supposed to work, anyway.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[VOTE] Retire Corinthia

2015-11-15 Thread Marvin Humphrey 
Greetings,

The Corinthia community has voted to retire:

  http://s.apache.org/odN

This is a vote of the IPMC to confirm the decision to retire the podling.

[ ] +1 to retire Corinthia from the Incubator
[ ] -1 to keep Corinthia in the Incubator

This vote will be held open for at least 72 hours.

Should this vote pass, I have volunteered to assist Corinthia with retirement,
as I am assisting Droids and Kalumet.

Marvin Humphrey

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

Re: Apache Metrics, Not Apache Humans

2015-11-15 Thread Edward J. Yoon 
momentary issue or concern -- though a more general concern about how
Apache should evolve.

I personally think that the complex human emotions is important
evolutionary mechanism. The machine or math can't.

On Monday, 16 November 2015, Marko Rodriguez  wrote:

> Hi,
>
> I was talking with Daniel Gruno and wrote the following ideas to him. Note
> that these are just ideas and not based on any real momentary issue or
> concern -- though a more general concern about how Apache should evolve.
>
> Apache should NOT use a binary "podling" / "top-level" model. All projects
> should simply have a "health score" and that health score is derived from
> measurables. Because of Apache Infrastructure's centralized server model
> (email lists, version control, distributions, homepages, etc.), it  has the
> ability to gather metrics such as, for example, the distribution of pushes
> to the repository, the branch factor of the mailing list, the centrality of
> the project in the Central Maven repository dependency graph, the number of
> non-sequisters (dead-end conversations) in the email chain, the length of
> discussions in JIRA, etc. etc. Which metrics are important? Who care --
> just make up things to glean from the wealth of information you already
> have access to. Watch...
>
> Next, the Apache members subjectively say which projects they think are
> "good" (healthy). This can even be a global vote including everyone in the
> world and (should be) dynamic over time as projects evolve with time.
> Either way, lets say, the ranking says Apache Hadoop, Apache Solr, Apache
> Commons, etc. are the (collective subjective's) "best" Apache projects.
> Now, there should exist a multi-dimensional projection of the
> aforementioned gleaned statistics what will have Hadoop, Solr, Commons,
> etc. close to one another in metric-space (clustered). Likewise, low
> ranking projects should be close to one another in this space and far from
> Hadoop, Solr, Commons, etc. Find that projection and that is your "healthy
> metric space."
>
> From here, all Apache projects have a computed "healthy" score(s) and when
> users go to download, lets say, Lucene, they go: "Cool. This is a healthy
> project." (it has a HEALTH.txt file distributed with it, lets say). What
> that means is that Lucene, at that release was in the "healthy" cluster of
> the metric space. This model has various benefits:
>
> 1. There is no need to have philosophical arguments (not grounded
> in measurables) about what rules a project should follow (bounded by law).
> - Perhaps a project that is exclusive, but is X is still
> in the "healthy" subspace.
> - Perhaps having bad documentation is a "unhealthy" even
> though Apache doesn't care about documentation.
> - Perhaps too much discussion causes a project to become
> "unhealthy."
> - Perhaps … who knows? … let the statistics do the talking.
> -  Apache becomes a breeding ground for different models
> of open source (bounded by law), not just "The Apache Way."
> - And these models are measurable! Let us study
> the act of open source.
> 2. "Top-level" projects can fall from grace.
> - Currently, all "top-level" projects are "equal." This
> should by dynamic as the mighty do fall.
> - It is possible for what are now "podlings" to be
> "healthy" as they simply are coming into Apache.
> - "The student is the master."
> - Hadoop 1.2.1 might be the healthiest version of Hadoop
> (as I tend to believe). "Hadoop" is not a thing eternal.
> 3. Less work for people.
> - No more VOTEing on graduation.
> - No more amorphous aesthetic arguments about "The Apache
> Way."
> - No more long winded contradictory documentation about
> how things should be done (bounded by law).
>
> The Apache Way should be about metrics, not about philosophy as different
> paths lead to the same mountain top <--- See! Is that random Buddhist
> saying that everyone just "believes" even true? :) Get the human out of the
> loop!
>
> Thanks for reading,
> Marko.
>
> http://markorodriguez.com
>
> P.S. The same should hold true for educational degrees. I graduate and now
> forever I'm an expert in computers? Medical doctors too! A 90 year old
> doctor can do surgery on me?!?!… Binary graduation is not "real." Metrics,
> metrics, metrics --- we live in a world where this is possible. For every
> "thing" good comes and goes, up and down…



-- 
Best Regards, Edward J. Yoon

Kalumet retirement steps

2015-11-15 Thread Marvin Humphrey 
(cross-posted to kalumet-dev@incubator and general@incubator)

Greets,

I'm currently going through the retirement steps for Kalumet, and one of the
first items is this:

http://incubator.apache.org/guides/retirement.html#steps-to-retirement

Has the copyright checkbox of the incubator status page been checked off?
If not, try to resolve it. If it cannot be resolved, source code must be
removed from SVN.

The copyright checkbox for Kalumet is marked with a question mark, which I
interpret as "not checked off":

http://incubator.apache.org/projects/kalumet#Copyright

A successful incubating release would have settled the issue, but I did some
research and it seems that while the Kalumet podling attempted an incubating
release of their 0.6 branch, it doesn't look like it was ever officially
completed.

If the copyright status cannot be resolved, I will have to delete `trunk`,
`tags`, and `branches` from
.

Can someone provide a definitive answer on whether it is OK for Kalumet's code
to remain visible in svn?

Marvin Humphrey

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

Re: [VOTE] Retire Corinthia

2015-11-15 Thread Roman Shaposhnik 
On Sun, Nov 15, 2015 at 7:01 PM, Marvin Humphrey  wrote:
> Greetings,
>
> The Corinthia community has voted to retire:
>
>   http://s.apache.org/odN
>
> This is a vote of the IPMC to confirm the decision to retire the podling.
>
> [ ] +1 to retire Corinthia from the Incubator
> [ ] -1 to keep Corinthia in the Incubator

+1 (binding)

Thanks,
Roman.

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

Re: [VOTE] Apache Apex Malhar Release 3.2.0-incubating (RC2)

2015-11-15 Thread Vlad Rozov 

+1 carrying over from Apache Apex (incubating) dev list vote.

Thank you,

Vlad

On 11/14/15 18:40, Pramod Immaneni wrote:

+1

Carrying vote over from dev list.

Thanks

On Sat, Nov 14, 2015 at 1:47 PM, Amol Kekre  wrote:


+1 (non-binding)

I too am carrying over vote from dev. Did my testing too.

Thks
Amol

On Sat, Nov 14, 2015 at 1:42 PM, Justin Mclean 
wrote:


Hi,

+1 (binding)

Carry over vote from dev list, didi all of the usual checks.

Thanks,
Justin

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

2015-11-15 Thread Greg Stein 
+1 (binding)

On Sun, Nov 15, 2015 at 9:01 PM, Marvin Humphrey 
wrote:

> Greetings,
>
> The Corinthia community has voted to retire:
>
>   http://s.apache.org/odN
>
> This is a vote of the IPMC to confirm the decision to retire the podling.
>
> [ ] +1 to retire Corinthia from the Incubator
> [ ] -1 to keep Corinthia in the Incubator
>
> This vote will be held open for at least 72 hours.
>
> Should this vote pass, I have volunteered to assist Corinthia with
> retirement,
> as I am assisting Droids and Kalumet.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Apex Malhar Release 3.2.0-incubating (RC2)

2015-11-15 Thread Gaurav Gupta 
+1

Carrying vote over from dev list.

Thanks
- Gaurav

> On Nov 15, 2015, at 8:19 PM, Vlad Rozov  wrote:
> 
> +1 carrying over from Apache Apex (incubating) dev list vote.
> 
> Thank you,
> 
> Vlad
> 
> On 11/14/15 18:40, Pramod Immaneni wrote:
>> +1
>> 
>> Carrying vote over from dev list.
>> 
>> Thanks
>> 
>> On Sat, Nov 14, 2015 at 1:47 PM, Amol Kekre  wrote:
>> 
>>> +1 (non-binding)
>>> 
>>> I too am carrying over vote from dev. Did my testing too.
>>> 
>>> Thks
>>> Amol
>>> 
>>> On Sat, Nov 14, 2015 at 1:42 PM, Justin Mclean 
>>> wrote:
>>> 
 Hi,
 
 +1 (binding)
 
 Carry over vote from dev list, didi all of the usual checks.
 
 Thanks,
 Justin
 
 -
 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: Apache Metrics, Not Apache Humans

2015-11-15 Thread Sergio Fernández 
Marko, the metrics approach has been discussed in the past, for instance
http://markmail.org/message/ubx3utli3bnltv75 So far my feeling is that the
ASF prefer to deliver of people to build an opinion of projects rather than
based them on pure statistical metrics. But I'd be happy to see something
like that.
Hi,

I was talking with Daniel Gruno and wrote the following ideas to him. Note
that these are just ideas and not based on any real momentary issue or
concern -- though a more general concern about how Apache should evolve.

Apache should NOT use a binary "podling" / "top-level" model. All projects
should simply have a "health score" and that health score is derived from
measurables. Because of Apache Infrastructure's centralized server model
(email lists, version control, distributions, homepages, etc.), it  has the
ability to gather metrics such as, for example, the distribution of pushes
to the repository, the branch factor of the mailing list, the centrality of
the project in the Central Maven repository dependency graph, the number of
non-sequisters (dead-end conversations) in the email chain, the length of
discussions in JIRA, etc. etc. Which metrics are important? Who care --
just make up things to glean from the wealth of information you already
have access to. Watch...

Next, the Apache members subjectively say which projects they think are
"good" (healthy). This can even be a global vote including everyone in the
world and (should be) dynamic over time as projects evolve with time.
Either way, lets say, the ranking says Apache Hadoop, Apache Solr, Apache
Commons, etc. are the (collective subjective's) "best" Apache projects.
Now, there should exist a multi-dimensional projection of the
aforementioned gleaned statistics what will have Hadoop, Solr, Commons,
etc. close to one another in metric-space (clustered). Likewise, low
ranking projects should be close to one another in this space and far from
Hadoop, Solr, Commons, etc. Find that projection and that is your "healthy
metric space."

>From here, all Apache projects have a computed "healthy" score(s) and when
users go to download, lets say, Lucene, they go: "Cool. This is a healthy
project." (it has a HEALTH.txt file distributed with it, lets say). What
that means is that Lucene, at that release was in the "healthy" cluster of
the metric space. This model has various benefits:

1. There is no need to have philosophical arguments (not grounded
in measurables) about what rules a project should follow (bounded by law).
- Perhaps a project that is exclusive, but is X is still in
the "healthy" subspace.
- Perhaps having bad documentation is a "unhealthy" even
though Apache doesn't care about documentation.
- Perhaps too much discussion causes a project to become
"unhealthy."
- Perhaps … who knows? … let the statistics do the talking.
-  Apache becomes a breeding ground for different models of
open source (bounded by law), not just "The Apache Way."
- And these models are measurable! Let us study the
act of open source.
2. "Top-level" projects can fall from grace.
- Currently, all "top-level" projects are "equal." This
should by dynamic as the mighty do fall.
- It is possible for what are now "podlings" to be
"healthy" as they simply are coming into Apache.
- "The student is the master."
- Hadoop 1.2.1 might be the healthiest version of Hadoop
(as I tend to believe). "Hadoop" is not a thing eternal.
3. Less work for people.
- No more VOTEing on graduation.
- No more amorphous aesthetic arguments about "The Apache
Way."
- No more long winded contradictory documentation about how
things should be done (bounded by law).

The Apache Way should be about metrics, not about philosophy as different
paths lead to the same mountain top <--- See! Is that random Buddhist
saying that everyone just "believes" even true? :) Get the human out of the
loop!

Thanks for reading,
Marko.

http://markorodriguez.com

P.S. The same should hold true for educational degrees. I graduate and now
forever I'm an expert in computers? Medical doctors too! A 90 year old
doctor can do surgery on me?!?!… Binary graduation is not "real." Metrics,
metrics, metrics --- we live in a world where this is possible. For every
"thing" good comes and goes, up and down…

Re: [VOTE] Apache Apex Malhar Release 3.2.0-incubating (RC2)

2015-11-15 Thread Hitesh Shah 
+1 (binding). Carried over vote from dev list.

thanks
— Hitesh

On Nov 13, 2015, at 9:30 PM, Thomas Weise  wrote:

> Hi,
> 
> Please vote on the following Apache Apex Malhar 3.2.0-incubating release
> candidate. This is the first release of the Malhar library in ASF and it is
> based on Apex core 3.2.0-incubating. This is a source release.
> 
> The Apache Apex PPMC has voted to release this candidate.
> 
> The community vote passed with 14 binding votes from the PPMC (including 3
> votes from IPMC members).
> 
> PPMC vote call:
> 
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDMWgzncdN7-nxXksE3F2p3xLfCu%2B_nNL-q6p-H_kwASdA%40mail.gmail.com%3E
> 
> PPMC vote result:
> 
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDPnu2vJZyt%3D9JNmt3nG_nHYk%2B3AseE__SN%3DKXmJ5AskeQ%40mail.gmail.com%3E
> 
> List of all issues fixed: http://s.apache.org/2fZ
> 
> Staging directory:
> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2
> Source zip:
> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.zip
> Source tar.gz:
> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.tar.gz
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheapex-1003/
> 
> Git source:
> https://git-wip-us.apache.org/repos/asf?p=incubator-apex-malhar.git;a=commit;h=refs/tags/v3.2.0-incubating-RC2
> (commit:
> ff0b0d080ebd8d00cee47321df90dad9357bbead)
> 
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=vindex=t...@apache.org
> KEYS file:
> https://dist.apache.org/repos/dist/release/incubator/apex/KEYS
> 
> More information at:
> http://apex.incubator.apache.org
> 
> Please try the release and vote; vote will close after 72 hours.
> 
> [ ] +1 approve
> [ ] -1 disapprove (and reason why)
> 
> http://www.apache.org/foundation/voting.html
> 
> Please add (binding) if your vote is binding.
> 
> Thanks,
> Thomas


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

Re: [VOTE] Retire Corinthia

2015-11-15 Thread Henry Saputra 
+1 (binding)

On Sun, Nov 15, 2015 at 7:01 PM, Marvin Humphrey  wrote:
> Greetings,
>
> The Corinthia community has voted to retire:
>
>   http://s.apache.org/odN
>
> This is a vote of the IPMC to confirm the decision to retire the podling.
>
> [ ] +1 to retire Corinthia from the Incubator
> [ ] -1 to keep Corinthia in the Incubator
>
> This vote will be held open for at least 72 hours.
>
> Should this vote pass, I have volunteered to assist Corinthia with retirement,
> as I am assisting Droids and Kalumet.
>
> 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: [VOTE] Retire Corinthia

2015-11-15 Thread Ted Dunning 
+1 (binding)



On Mon, Nov 16, 2015 at 12:36 PM, Roman Shaposhnik 
wrote:

> On Sun, Nov 15, 2015 at 7:01 PM, Marvin Humphrey 
> wrote:
> > Greetings,
> >
> > The Corinthia community has voted to retire:
> >
> >   http://s.apache.org/odN
> >
> > This is a vote of the IPMC to confirm the decision to retire the podling.
> >
> > [ ] +1 to retire Corinthia from the Incubator
> > [ ] -1 to keep Corinthia in the Incubator
>
> +1 (binding)
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Retire Corinthia

2015-11-15 Thread Bertrand Delacretaz 
> [X ] +1 to retire Corinthia from the Incubator

-Bertrand

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

Re: Apache Metrics, Not Apache Humans

2015-11-15 Thread Bertrand Delacretaz 
On Sun, Nov 15, 2015 at 7:20 PM, Marko Rodriguez  wrote:
> ...The Apache Way should be about metrics..
>...Get the human out of the loop!

No.

The ASF is built on the collective wisdom of its members and
community. Having metrics-based projects might be an interesting
experiment, but that's not the ASF.

-Bertrand

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

RE: Concerning Sentry: A disagreement over the Apache Way and graduation

2015-11-15 Thread Dennis E. Hamilton 
I think the Maturity Model, relied on as some guidelines for assessing a 
project, needs to be applied for that purpose in terms of identifying the 
striving-fors.  Is there evidence that particular areas are being strived for.  
Is there evidence of an anti-pattern.  How do these net out in the considered 
judgment of the person making that assessment, what facts are indicators, 
warning-signs, etc.  

It is my understanding that this is not a pure pass/fail thing.  A graduation 
could be accompanied by a charge to develop/diminish/whatever in the activities 
of the newly-established PMC and having that accounted for.

Isn't this an always "on balance" determination, where in some cases, 
demonstration of remedy is required before graduation and other times not?  
(With some items being show-stoppers, I suppose, such as careless handling of 
IP clearance.)

 - Dennis



> -Original Message-
> From: justin.erenkra...@gmail.com [mailto:justin.erenkra...@gmail.com]
> On Behalf Of Justin Erenkrantz
> Sent: Sunday, November 15, 2015 07:14
> To: general@incubator.apache.org
> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> graduation
> 
> On Saturday, November 14, 2015, Rich Bowen  wrote:
> 
> > No. I can use whatever criteria I like to justify my vote on a
> podlings
> > graduation, if it's in line with asf philosophy. This document is,
> and
> > accurately reflects the criteria I use when voting on a graduation.
> That
> > is, the document reflects me, not vice versa, as I said above.
> >
> > It's very akin to the docs that circulate around member election time.
> They
> > are useful guidelines but nobody is compelled to adhere to any
> particular
> > one of them.
> >
> 
> The difference is that member elections are majority-based - graduation
> votes are essentially subject to veto.
> 
> There's a huge difference there.  If you are subjecting all of your
> votes
> to that checklist and will actively block podlings that do not meet your
> personal guidelines, you are making everyone else subject to it.  --
> justin


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

RE: Concerning Sentry: A disagreement over the Apache Way and graduation

2015-11-15 Thread Ross Gardler 
Dennis makes a good point.

Some to ago it became common to think of the diversity objective to become a 
minimum number of contributors from different orgs rather than an acceptance of 
new contributors views.

Now we require a behavior pattern likely to lead to diversity.

One is quantative (bad, as it does nit take everything into account) one is 
subjective (good, but open to abuse).

To have the good we merely need to trust the people involved. Providing 
guidelines is good. Having those guidelines become rules is bad.

Sent from my Windows Phone

From: Dennis E. Hamilton
Sent: ‎11/‎15/‎2015 10:28 AM
To: general@incubator.apache.org
Subject: RE: Concerning Sentry: A disagreement over the Apache Way and 
graduation

I think the Maturity Model, relied on as some guidelines for assessing a 
project, needs to be applied for that purpose in terms of identifying the 
striving-fors.  Is there evidence that particular areas are being strived for.  
Is there evidence of an anti-pattern.  How do these net out in the considered 
judgment of the person making that assessment, what facts are indicators, 
warning-signs, etc.

It is my understanding that this is not a pure pass/fail thing.  A graduation 
could be accompanied by a charge to develop/diminish/whatever in the activities 
of the newly-established PMC and having that accounted for.

Isn't this an always "on balance" determination, where in some cases, 
demonstration of remedy is required before graduation and other times not?  
(With some items being show-stoppers, I suppose, such as careless handling of 
IP clearance.)

 - Dennis



> -Original Message-
> From: justin.erenkra...@gmail.com [mailto:justin.erenkra...@gmail.com]
> On Behalf Of Justin Erenkrantz
> Sent: Sunday, November 15, 2015 07:14
> To: general@incubator.apache.org
> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> graduation
>
> On Saturday, November 14, 2015, Rich Bowen  wrote:
>
> > No. I can use whatever criteria I like to justify my vote on a
> podlings
> > graduation, if it's in line with asf philosophy. This document is,
> and
> > accurately reflects the criteria I use when voting on a graduation.
> That
> > is, the document reflects me, not vice versa, as I said above.
> >
> > It's very akin to the docs that circulate around member election time.
> They
> > are useful guidelines but nobody is compelled to adhere to any
> particular
> > one of them.
> >
>
> The difference is that member elections are majority-based - graduation
> votes are essentially subject to veto.
>
> There's a huge difference there.  If you are subjecting all of your
> votes
> to that checklist and will actively block podlings that do not meet your
> personal guidelines, you are making everyone else subject to it.  --
> justin


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

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

2015-11-15 Thread Pierre Smits 
Justin,

Why is it so that graduation can be vetoed?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Sun, Nov 15, 2015 at 4:13 PM, Justin Erenkrantz 
wrote:

> On Saturday, November 14, 2015, Rich Bowen  wrote:
>
> > No. I can use whatever criteria I like to justify my vote on a podlings
> > graduation, if it's in line with asf philosophy. This document is,  and
> > accurately reflects the criteria I use when voting on a graduation. That
> > is, the document reflects me, not vice versa, as I said above.
> >
> > It's very akin to the docs that circulate around member election time.
> They
> > are useful guidelines but nobody is compelled to adhere to any particular
> > one of them.
> >
>
> The difference is that member elections are majority-based - graduation
> votes are essentially subject to veto.
>
> There's a huge difference there.  If you are subjecting all of your votes
> to that checklist and will actively block podlings that do not meet your
> personal guidelines, you are making everyone else subject to it.  -- justin
>

Apache Metrics, Not Apache Humans

2015-11-15 Thread Marko Rodriguez 
Hi,

I was talking with Daniel Gruno and wrote the following ideas to him. Note that 
these are just ideas and not based on any real momentary issue or concern -- 
though a more general concern about how Apache should evolve.

Apache should NOT use a binary "podling" / "top-level" model. All projects 
should simply have a "health score" and that health score is derived from 
measurables. Because of Apache Infrastructure's centralized server model (email 
lists, version control, distributions, homepages, etc.), it  has the ability to 
gather metrics such as, for example, the distribution of pushes to the 
repository, the branch factor of the mailing list, the centrality of the 
project in the Central Maven repository dependency graph, the number of 
non-sequisters (dead-end conversations) in the email chain, the length of 
discussions in JIRA, etc. etc. Which metrics are important? Who care -- just 
make up things to glean from the wealth of information you already have access 
to. Watch...

Next, the Apache members subjectively say which projects they think are "good" 
(healthy). This can even be a global vote including everyone in the world and 
(should be) dynamic over time as projects evolve with time. Either way, lets 
say, the ranking says Apache Hadoop, Apache Solr, Apache Commons, etc. are the 
(collective subjective's) "best" Apache projects. Now, there should exist a 
multi-dimensional projection of the aforementioned gleaned statistics what will 
have Hadoop, Solr, Commons, etc. close to one another in metric-space 
(clustered). Likewise, low ranking projects should be close to one another in 
this space and far from Hadoop, Solr, Commons, etc. Find that projection and 
that is your "healthy metric space."

From here, all Apache projects have a computed "healthy" score(s) and when 
users go to download, lets say, Lucene, they go: "Cool. This is a healthy 
project." (it has a HEALTH.txt file distributed with it, lets say). What that 
means is that Lucene, at that release was in the "healthy" cluster of the 
metric space. This model has various benefits:

1. There is no need to have philosophical arguments (not grounded in 
measurables) about what rules a project should follow (bounded by law). 
- Perhaps a project that is exclusive, but is X is still in the 
"healthy" subspace.
- Perhaps having bad documentation is a "unhealthy" even though 
Apache doesn't care about documentation.
- Perhaps too much discussion causes a project to become 
"unhealthy."
- Perhaps … who knows? … let the statistics do the talking.
-  Apache becomes a breeding ground for different models of 
open source (bounded by law), not just "The Apache Way." 
- And these models are measurable! Let us study the act 
of open source.
2. "Top-level" projects can fall from grace. 
- Currently, all "top-level" projects are "equal." This should 
by dynamic as the mighty do fall.
- It is possible for what are now "podlings" to be "healthy" as 
they simply are coming into Apache.
- "The student is the master."
- Hadoop 1.2.1 might be the healthiest version of Hadoop (as I 
tend to believe). "Hadoop" is not a thing eternal.
3. Less work for people.
- No more VOTEing on graduation.
- No more amorphous aesthetic arguments about "The Apache Way."
- No more long winded contradictory documentation about how 
things should be done (bounded by law). 

The Apache Way should be about metrics, not about philosophy as different paths 
lead to the same mountain top <--- See! Is that random Buddhist saying that 
everyone just "believes" even true? :) Get the human out of the loop!

Thanks for reading,
Marko.

http://markorodriguez.com

P.S. The same should hold true for educational degrees. I graduate and now 
forever I'm an expert in computers? Medical doctors too! A 90 year old doctor 
can do surgery on me?!?!… Binary graduation is not "real." Metrics, metrics, 
metrics --- we live in a world where this is possible. For every "thing" good 
comes and goes, up and down…