Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

The JMSAppender is an optional module. I think you will get the distinction. It 
doesn’t break the world to remove it, unlike changing the class hierarchy of 
Appender or removing a method on an extension interface used by same, I think 
the distinction is clear. We might find agreement in the response to concern 
about removal as “this is a maintenance version, you will need to upgrade”. The 
key is to take a practical approach to what the users are asking for now not a 
perhaps cleaner but absolutist position that strands and frustrates them. What 
we (users) are doing in the wild is simply taking the last log4j 1 release, 
removing JMSAppender.class from the JAR, and publishing them to our Nexus or 
whatever with a modified version. This is what regulators and compliance 
officers will care about. It is being done as a stopgap and I can’t say if it 
would be acceptable or not as a final solution. My guess is not, for what it’s 
worth. A release by the foundation would. Users do not need all theoretical CVE 
worthy issues addressed at at once, just the one. Just like many have avoided 
the concurrency issues listed earlier and don’t need up front solutions for 
those either. Just a new release without JMSAppender. 

> On Jan 8, 2022, at 6:34 PM, Matt Sicker  wrote:
> 
> 
>>> On Jan 8, 2022, at 19:39, Andrew Purtell  wrote:
>>> 
>>> Are you using the JMS appender? Are you using the socket receiver? If the
>> answer is no to those questions, you don’t have security concerns besides
>> the more glaring fact that you’re depending on end of life software that
>> has been marked as such for going on 7 years now.
>> 
>> I know you keep returning to the end of life designation in these
>> discussions, but do not acknowledge that the users of this EOL version were
>> deliberately stranded by incompatible API and configuration file formats.
>> There is a reason we are stuck on Log4J 1. I wish you could just hear this,
>> acknowledge it, and service the concerns of users in this regard without
>> the dictatorial attitude by continuing to release version 1 with security
>> fixes applied. That's all I think interested parties here want.
> 
> Which security fixes? Part of the EOL status has meant that anytime someone 
> has tried reporting a new security vulnerability in log4j1, we’ve informed 
> them that the version is EOL. No new CVEs published. Being EOL, less security 
> review is being done other than thorough audits of old software. This would 
> be like opening Pandora’s Box, and that’s one of the reasons why software is 
> sometimes effectively abandoned before being declared end of life.
> 
>> My employer, for example, will be forced to accommodate government
>> compliance officers' demands for a CVE-free version of Log4J to be included
>> in our products. If Log4J 1 were to satisfy that requirement, this
>> necessitates at least a release of 1 without the JMSAppender or with the
>> JNDI issues therein addressed some other way. (I would advocate removal.)
> 
> So you couldn’t upgrade to version 2 due to incompatibility (which still has 
> no concrete examples; did you know that we’ve improved compatibility several 
> times since version 2.0?), yet right out of the gate you want to break 
> compatibility in version 1 by just nuking a feature.
> 
>> Since I volunteered on this thread to maintain a resurrected Log4J 1 --
>> whatever form that would take can be debated, it's not material for this
>> point -- this would be the maintenance philosophy I would adopt or
>> advocate, for what it is worth:
>> 
>>  - Start with latest/last Log4J 1 release.
>>  - Security vulnerabilities addressed. JMSAppender to be immediately
>>  removed.
> 
> To be more constructive, I’d suggest following the compatibility-oriented 
> philosophy of guarding this class with a feature flag to opt in. Being such 
> an old library used so extensively, there are bound to be a non-trivial 
> number of legitimate users of this appender.
> 
>>  - Pay down the build system tech debt - migrate to Maven 3.
> 
> That would be expected; I wouldn’t want anyone to have to dig up ancient VMs 
> just to build and release the project!
> 
>>  - No API changes.
> 
> This makes sense of course, but I should note that one of the historical 
> reasons why both Logback and Log4j2 exist is because Log4j1 doesn’t have a 
> clear delineation between its API and implementation, and some problems 
> cannot be fixed without breaking the effective API.
> 
>>  - No new appenders.
>>  - Additional security fixes as required. Typical 'maintenance mode'
>>  stuff.
> 
> Given the limited changes desired (which mostly sound fine otherwise), I

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

The discussion continues here because the Logging PMC is intransigent and
non-responsive to the concerns already well established by parties on this
thread. I don't see how this can be resolved without you "giving in".
Perhaps that is the problem, but I don't want to be an armchair
psychiatrist, I just want a logging library without known security bugs
that remains compatible with existing code and configuration formats and
does not force me to transitively upgrade/rebuild/modify the world.

On Sat, Jan 8, 2022 at 5:00 PM Ralph Goers 
wrote:

>
>
> > On Jan 8, 2022, at 4:34 PM, Andrew Purtell  wrote:
> >
> > The Logging PMC is the hostile party here as far as I can tell, operating
> > in defiance of the community of users that have made the points I have
> just
> > written here abundantly clear for years.
>
> The Logging PMC is the owner of Log4j 1.x. We declared it EOL in 2015. Not
> one single complaint was received nor were any proposals made to the PMC
> until over 6 years later. This is not the sign of a hostile PMC but one
> that has
> moved on from unmaintainable software. Heck, even Ceki abandoned it years
> before its last release to concentrate on its replacement.
>
> The PMC held a discussion on the dev mailing list. Out of non-PMC members
> there were very few responses. One person was in favor of reviving the
> project
> even to the point of fixing bugs and continuing development beyond just
> fixing
> CVEs. Leo Simmons did offer to help. Here is what he said during the
> discussion:
>
> I think I made clear what I am interested in through several emails
> and in code.
> I've also pointed out what I wouldn't do (like step up as a maintainer
> on a.
> permanent basis, or incubate something).
>
> I think all the relevant arguments on how to proceed with 1.x have been
> made (a few times…).
> I don't have anything new to add.
> I'll accept the vote outcome.
>
> So we had two people expressing interest, one with no hope of ever being
> offered
> commit rights due to his behavior on our lists and in reviewing the other
> projects
> he participates on.
>
> So we were left with the choice of us allowing Leo to do that work and us
> having
> to spend time reviewing the PRs and applying them. Frankly, none of us
> were
> interested enough in this to spend that kind of time, especially since we
> know at
> least two usable drop-in replacements for Log4j 1.2 that fix the CVEs
> already exist.
>
> I seriously think the outcome would have been different had Ceki offered
> to help
> while the discussion was going on. Instead, he decided to offer to help
> after the
> PMC posted its announcement of the vote results and the reasons why we
> voted
> that way.
>
> Since the Logging Services PMC is responsible for Log4j1 I fail to see why
> a
> discussion is even continuing on this list. The Logging Services PMC has
> made
> clear that it is not going to sponsor a podling for this and the PMC still
> retains
> ownership of the code.
>
> Ralph
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

> Are you using the JMS appender? Are you using the socket receiver? If the
answer is no to those questions, you don’t have security concerns besides
the more glaring fact that you’re depending on end of life software that
has been marked as such for going on 7 years now.

I know you keep returning to the end of life designation in these
discussions, but do not acknowledge that the users of this EOL version were
deliberately stranded by incompatible API and configuration file formats.
There is a reason we are stuck on Log4J 1. I wish you could just hear this,
acknowledge it, and service the concerns of users in this regard without
the dictatorial attitude by continuing to release version 1 with security
fixes applied. That's all I think interested parties here want.

My employer, for example, will be forced to accommodate government
compliance officers' demands for a CVE-free version of Log4J to be included
in our products. If Log4J 1 were to satisfy that requirement, this
necessitates at least a release of 1 without the JMSAppender or with the
JNDI issues therein addressed some other way. (I would advocate removal.)

Since I volunteered on this thread to maintain a resurrected Log4J 1 --
whatever form that would take can be debated, it's not material for this
point -- this would be the maintenance philosophy I would adopt or
advocate, for what it is worth:

   - Start with latest/last Log4J 1 release.
   - Security vulnerabilities addressed. JMSAppender to be immediately
   removed.
   - Pay down the build system tech debt - migrate to Maven 3.
   - No API changes.
   - No new appenders.
   - Additional security fixes as required. Typical 'maintenance mode'
   stuff.

I have lurked in some discussion here and elsewhere and I really don't see
that much daylight between the Logging PMCs position on 1 and what users
like myself want of it. I hear concerns about resurrecting 1 that seem
focused on some theoretical future development of 1 that I don't think
anyone is actually interested in doing. If I can be said to be
representative of a Log4J 1 user that would like to stay on 1, the vision
is "just fix security bugs, please, we will upgrade or migrate to something
else someday, don't change API or configuration file formats, thanks".
There exists the possibility that some day a theoretical required security
fix cannot be accomplished without a breaking change. We can cross that
bridge when and if we come to it. It may never happen. Or, it might, and
then 1 has truly reached the end of the road.

On Sat, Jan 8, 2022 at 4:17 PM Matt Sicker  wrote:

> Answers below:
>
> > On Jan 8, 2022, at 17:34, Andrew Purtell  wrote:
> >
> > Log4J 1 has known concurrency issues but many projects live with them or
> > work around them. For example, several "Big Data" Apache projects have
> been
> > fine with it, themselves internally highly concurrent and performance
> > sensitive. Log4J 1 might not be a Platonic ideal, but certainly good
> > enough, as evidenced by the popularity of those projects, operational in
> > numerous high scale and/or performance sensitive environments.
>
> It’s also a fairly common source of application performance problems that
> leads to reduction in logs being stored and the added difficulty of
> debugging problems with less context. Here are just some of the Bugzilla
> issues you’ve been conveniently ignoring for years:
>
> 50213   Category callAppenders synchronization causes
> java.lang.Thread.State: BLOCKED
> 46878   Deadlock in 1.2.15 caused by AsyncAppender and
> ThrowableInformation classes
> 41214   Deadlock with RollingFileAppender
> 44700   Log4J locks rolled log files (files can’t be deleted)
> 49481   Log4j stops writing to file, and then causes server to lockup
> 50323   Vulnerability in NTEventLogAppender
> 50463   AsyncAppender causing deadlock when dispatcher thread dies
> 50858   Classloader leak when using Log4j in a webapp container such as
> Tomcat, WebLogic
> 52141   [STUCK] ExecuteThread...Blocked trying to get lock:
> org/apache/log4j/Logger@0xc501e0a8[fat lock]
> 54009   Thread is getting Blocked
> 54325   Concurrency issues in AppenderAttachableImpl
>
> > In a perfect world Log4J 2 would have been API compatible and
> configuration
> > format compatible with 1, such that everyone could have migrated years
> ago,
>
> Can you point out any specific incompatibilities? Particularly in the
> current version.
>
> > but the Logging PMC/devs decided otherwise. Whether or not we assess that
> > as desirable, we arrive at the present, with hundreds, perhaps thousands,
> > of open source and internal projects stuck on Log4J 1 due to API or
> > operational compatibility concerns that would carry downstream to their
> > users. No matter what

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

t; >> On 2022/01/08 19:51:07 Matt Sicker wrote:
> >> It would be nice if you filed any issues with Log4j2 about problems
> with migration. It would have been nice to hear about these issues back
> when v1 stopped development, but this is the next best time to do so. The
> Log4j team are actively working to fill in any remaining gaps on backward
> compatibility; making new releases of EOL software with numerous
> implementation errors inherent to its architecture seems like going
> backwards.
> >>
> >> —
> >> Matt Sicker
> >>
> >>>> On Jan 8, 2022, at 13:45, Rohit Yadav  wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I agree and extend support for Andrew's remarks. Apache CloudStack too
> uses log4j 1.x and our use case is simply a logging library that 1.x just
> satisfies. The effort to migrate to 2.x is not quick, at least in our
> initial investigation and a migration may likely require huge effort in
> testing.
> >>>
> >>> Assuming this quick upgrade path doesn't exist, and I already read
> struggles by other projects trying to migrate to 2.x - maintaining 1.x and
> doing a 1.2.x release makes more sense than investing weeks in migration
> and testing to 2.x, while maintaining the same artifact IDs. I'm up for
> volunteering and supporting 1.x maintenance.
> >>>
> >>> Regards,
> >>> Rohit Yadav
> >>> PMC, Apache CloudStack
> >>>
> >>> On 2021/12/21 21:54:34 Andrew Purtell wrote:
> >>>>> as for the v1 :: COBOL analogy, that’s not a bad comparison.
> Basically,
> >>>> users who haven’t bothered to upgrade in 10 years will have to end up
> >>>> paying astronomical costs for consultants who can still work on
> ancient
> >>>> software effectively to help modify their systems.
> >>>>
> >>>> I have to take some exception to this. If the log4j 2.x configuration
> files
> >>>> were compatible _enough_ with 1.x then taking this position would be
> >>>> understandable. However, because they are not compatible in the way
> that
> >>>> users require -- and the backwards compatibility is still marked as
> >>>> 'experimental', even -- it is not great to blame users "who haven't
> >>>> bothered to upgrade in 10 years". Turning this around, why is
> backwards
> >>>> compatibility still experimental after 10 years? I am involved with
> several
> >>>> Apache projects where we would love to upgrade from log4j 1 to log4j
> 2, and
> >>>> have been talking about it for _years_. However, we have not been
> able to
> >>>> easily do so because we actually care about operational cross-version
> >>>> compatibility for our users. On some of these projects we are still
> stuck
> >>>> on log4j 1.
> >>>>
> >>>> I also support continuing releasing for log4j 1.x, and would
> volunteer some
> >>>> of my time to assist in the effort.
> >>>>
> >>>>
> >>>> On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker 
> wrote:
> >>>>
> >>>>> Nobody in the Logging PMC is blocking a release here. What we don’t
> want
> >>>>> is to falsely advertise that v1 is still under development. We
> already have
> >>>>> a huge increase in mailing list, PR, and other traffic ever since
> >>>>> Log4Shell, and if we resurrect v1, then it’ll quickly become
> impossible to
> >>>>> keep up with all the activity given the size of the PMC. If any
> non-trivial
> >>>>> work is to be done in v1, we’d prefer to see more than one person
> working
> >>>>> on that, especially if we want to add more PMC members to oversee v1
> in the
> >>>>> first place.
> >>>>>
> >>>>> And as for the v1 :: COBOL analogy, that’s not a bad comparison.
> >>>>> Basically, users who haven’t bothered to upgrade in 10 years will
> have to
> >>>>> end up paying astronomical costs for consultants who can still work
> on
> >>>>> ancient software effectively to help modify their systems. Was Maven
> even
> >>>>> widely used back when v1 was popular? Or were people still using a
> mix of
> >>>>> make or Ant?
> >>>>> --
> >>>>> Matt Sicker
> >>>>>
> >>>>>> On Dec 2

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
users who haven’t bothered to upgrade in 10 years will have to end up
paying astronomical costs for consultants who can still work on ancient
software effectively to help modify their systems.

I have to take some exception to this. If the log4j 2.x configuration files
were compatible _enough_ with 1.x then taking this position would be
understandable. However, because they are not compatible in the way that
users require -- and the backwards compatibility is still marked as
'experimental', even -- it is not great to blame users "who haven't
bothered to upgrade in 10 years". Turning this around, why is backwards
compatibility still experimental after 10 years? I am involved with several
Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
have been talking about it for _years_. However, we have not been able to
easily do so because we actually care about operational cross-version
compatibility for our users. On some of these projects we are still stuck
on log4j 1.

I also support continuing releasing for log4j 1.x, and would volunteer some
of my time to assist in the effort.


On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:

> Nobody in the Logging PMC is blocking a release here. What we don’t want
> is to falsely advertise that v1 is still under development. We already have
> a huge increase in mailing list, PR, and other traffic ever since
> Log4Shell, and if we resurrect v1, then it’ll quickly become impossible to
> keep up with all the activity given the size of the PMC. If any non-trivial
> work is to be done in v1, we’d prefer to see more than one person working
> on that, especially if we want to add more PMC members to oversee v1 in the
> first place.
>
> And as for the v1 :: COBOL analogy, that’s not a bad comparison.
> Basically, users who haven’t bothered to upgrade in 10 years will have to
> end up paying astronomical costs for consultants who can still work on
> ancient software effectively to help modify their systems. Was Maven even
> widely used back when v1 was popular? Or were people still using a mix of
> make or Ant?
> --
> Matt Sicker
>
> > On Dec 21, 2021, at 07:13, Romain Manni-Bucau 
> wrote:
> >
> > Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
> > écrit :
> >
> >> Vladimir,
> >> I totally support this proposal.
> >>
> >> Which are actually the steps we need to cut a release of log4j 1.x ?
> >> - establish an Apache project ?
> >>
> >
> > 1. Send a patch to apply on
> > http://svn.apache.org/repos/asf/logging/log4j/trunk
> >
> >
> >> - do the fix
> >>
> >
> > 2. Get it applied
> >
> >
> >> - cut a release
> >>
> >> Can this be done inside another Apache Project who "adopts" the log4j
> >> sources if the Logging Project doesn't want to do it ?
> >>
> >
> > The PMC of log4j2 is logging project so it should be done there, if not
> the
> > project can be forked inside Apache but should change of package until we
> > get the perms to reuse the same one which means likely as much work as
> just
> > getting it done at logging project so hope it is not needed ;).
> >
> >
> >>
> >> Enrico
> >>
> >>
> >> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> >> sitnikov.vladi...@gmail.com> ha scritto:
> >>
>  Just wondering, is it even fulfilling the criteria of incubation?
> >>>
> >>> I believe, the world does not need "active development in log4j 1.x"
> >>> nowadays.
> >>> What everybody needs from log4j 1.x is to fix security issues, fix
> >>> outstanding issues (if any),
> >>> keep the project buildable (e.g. avoid using outdated build systems),
> >> etc.
> >>>
>  it doesn't seem that sustainability is proven.
> >>>
> >>> The problem is log4j 1.x is like COBOL of logging. There are apps that
> >> are
> >>> just stuck with log4j 1.x.
> >>> The proof of sustainability is that lots of existing apps will never
> >>> upgrade to 2.x because 2.x is incompatible.
> >>> If the compatibility layer of 2.x would be improved to handle 99.999%
> of
> >>> apps,
> >>> then we could indeed move 1.x to the attic.
> >>>
> >>> The Incubator Cookbook says:
>  The ASF provides software for the public good,
> >>>
> >>> As I described, log4j 2.x is not a direct replacement for log4j 1.x,
> and
> >>> there are **lots** of applications
> >>> that can't easily be upgraded to 2.x due to testing, configuration, and
> >>> implementation issues.
> >>>
> >>> The current Logging PMC is focused on log4j 2.x only, and they have no
> >>> desire to release 1.x
> >>>
>  active development but focus only on CVE fixes
> >>>
> >>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
> >> and
> >>> keep the project buildable and testable.
> >>> However, it might be the case, that certain fixes or features would
> >> appear.
> >>>
> >>> The sad story is that the industry is using 1.x A LOT, and what Logging
> >> PMC
> >>> did was
> >>> they ignored the community, and they just stopped 

Re: [DISCUSS] Omid and Tephra - Graduation (or Retirement?)

[Andrew Purtell]

Ok my mistake about Solr. I thought it was a TLP. 

As to the second half of what I said still this doesn’t look like a failure to 
gain a community and stable management. Omid and Tephra code is now under 
Phoenix. The Phoenix TLP has a community and stable management. Just like 
Lucene has a community and stable management.


> On Nov 21, 2019, at 5:16 PM, Dave Fisher  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Nov 21, 2019, at 2:10 PM, Andrew Purtell  wrote:
>> 
>> Those aren’t comparable though, right?
>> 
>> Solr was a sub project that graduated to a TLP.
> 
> Solr is a sub project of Lucene.
>> 
>> Omid and Tephra are projects that instead of becoming TLP’s “graduated” into 
>> the existing Phoenix TLP. 
>> 
>> Not the same thing. 
> 
> Exactly.
>> 
>> And also I don’t believe this result is unsuccessful. Neither Omid or Tephra 
>> code bases are read only or discarded. Omid and Tephra past or future 
>> contributors still have a code base and community to work with. Past Omid 
>> and Tephra committers can become Phoenix committers. Phoenix is a stable 
>> TLP. This looks like a success. 
>> 
>> 
>>>> On Nov 21, 2019, at 4:55 PM, Dave Fisher  wrote:
>>> 
>>> Hi Justin,
>>> 
>>>>> On Nov 21, 2019, at 1:48 PM, Justin Mclean  
>>>>> wrote:
>>>> 
>>>> HI,
>>>> 
>>>>> I’m going to change podlings.xml to reflect these as “graduated”. If 
>>>>> after discussion we have consensus to change these to “retired” then the 
>>>>> change is easy.
>>>> 
>>>> To officially graduate that would need a board proposal would it not?
>>> 
>>> To graduate as a TLP yes. To graduate as a subproject of an existing TLP 
>>> no. [1]
>>> 
>>> So there are two kinds of graduation as a subproject: successful like Solr, 
>>> DistributedLog, … and unsuccessful like Omid and Tephra. Certainly the 
>>> “success” here is hard to measure. Your analysis in the future should 
>>> consider the resolution tag which has 'https://incubator.apache.org/guides/graduation.html#whether_to_graduate_to_subproject_or_to_top_level_project
>>> 
>>>> 
>>>> 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
>>> 
>> 
>> -
>> 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: [DISCUSS] Omid and Tephra - Graduation (or Retirement?)

[Andrew Purtell]

Those aren’t comparable though, right?

Solr was a sub project that graduated to a TLP.

 Omid and Tephra are projects that instead of becoming TLP’s “graduated” into 
the existing Phoenix TLP. 

Not the same thing. 

And also I don’t believe this result is unsuccessful. Neither Omid or Tephra 
code bases are read only or discarded. Omid and Tephra past or future 
contributors still have a code base and community to work with. Past Omid and 
Tephra committers can become Phoenix committers. Phoenix is a stable TLP. This 
looks like a success. 


> On Nov 21, 2019, at 4:55 PM, Dave Fisher  wrote:
> 
> Hi Justin,
> 
>> On Nov 21, 2019, at 1:48 PM, Justin Mclean  wrote:
>> 
>> HI,
>> 
>>> I’m going to change podlings.xml to reflect these as “graduated”. If after 
>>> discussion we have consensus to change these to “retired” then the change 
>>> is easy.
>> 
>> To officially graduate that would need a board proposal would it not?
> 
> To graduate as a TLP yes. To graduate as a subproject of an existing TLP no. 
> [1]
> 
> So there are two kinds of graduation as a subproject: successful like Solr, 
> DistributedLog, … and unsuccessful like Omid and Tephra. Certainly the 
> “success” here is hard to measure. Your analysis in the future should 
> consider the resolution tag which has 'https://incubator.apache.org/guides/graduation.html#whether_to_graduate_to_subproject_or_to_top_level_project
> 
>> 
>> 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
> 

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

Re: Omid and Tephra

[Andrew Purtell]

+1 this would be a good outcome. Both Tephra and OMID are good
technologies, with respective pros and cons, and Phoenix can make good use
of both of them, should they choose to accept ownership of the code.

On Wed, Oct 23, 2019 at 11:26 AM Alan Gates  wrote:

> Justin and mentors of Omid and Tephra,
>
> As Justin noted in his emails to these podlings this month both are very
> low activity, struggling to even file their reports, and appear to be
> candidates for retirement.
>
> The situation here is somewhat special because Phoenix uses one or both of
> these technologies (they are both transaction managers on top of HBase), so
> they may have an interest in their continued survival.  Tephra briefly
> discussed this last June[1], though nothing came of it.  My conclusion is
> there is not enough momentum left for these podlings to vote themselves
> into Phoenix without an external push.
>
> So before we push them into retirement I believe we should involve the
> Phoenix PMC and see if they want to adopt either or both of these, with the
> knowledge that they will likely be getting minimal contributions from
> current members of those projects going forward.  If others are ok with
> this I can contact the Phoenix PMC and see if they wish to take any action
> on this.
>
> Alan.
>
> 1.
>
> https://lists.apache.org/thread.html/87ace080ef8a967b238781979a8d9a0cb9607ac4a195d5937756ec66@%3Cdev.tephra.apache.org%3E
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [VOTE] Retire Gearpump podling

[Andrew Purtell]

+1


> On Sep 16, 2018, at 2:31 AM, Manu Zhang  wrote:
> 
> Hi mentors,
> 
> The Gearpump podling has voted to retire from incubation. Here are the
> relevant discussion and vote threads from the dev list. The vote passed
> unanimously with 6 +1s.
> 
> DISCUSS:
> https://lists.apache.org/thread.html/77946cfff4557cf10c13c2d35fc165223583e58c2f7705319acabcf4@%3Cdev.gearpump.apache.org%3E
> VOTE:
> https://lists.apache.org/thread.html/03fc0421bb425f79d623863335bc2b81e4b6c77a169f508aadce7785@%3Cdev.gearpump.apache.org%3E
> 
> Please vote to ratify this request for retirement. It will be open for at
> least 72 hours.
> 
> Thanks,
> Manu Zhang

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

Re: [VOTE] Accept Zipkin into the Apache Incubator

[Andrew Purtell]

+1 binding

> On Aug 26, 2018, at 8:26 PM, Adrian Cole  wrote:
> 
> +1 Accept Zipkin (non binding)
>> On Mon, Aug 27, 2018 at 10:14 AM Mick Semb Wever  wrote:
>> 
>> After a brief discussion¹ I would like to call a VOTE to accept Zipkin into 
>> the Apache Incubator.
>> The full proposal is available on the wiki² and is pasted below in text form 
>> as well.
>> 
>> This vote will run at least 72 hours. Please VOTE as follows:
>> 
>> [ ] +1 Accept Zipkin into the Apache Incubator
>> [ ] +0 No opinion
>> [ ] -1 Do not accept Zipkin into the Apache Incubator because…
>> 
>> regards,
>> Mick
>> 
>> [1] 
>> https://lists.apache.org/thread.html/54798a5059db1d5716ed9910a15c92945509a25ec3b7ccb6b1215c53@%3Cgeneral.incubator.apache.org%3E
>> [2] https://wiki.apache.org/incubator/ZipkinProposal
>> 
>> 
>> 
>> = Abstract =
>> Zipkin is a distributed tracing system. It helps gather timing data needed 
>> to troubleshoot latency problems in microservice architectures. It manages 
>> both the collection and lookup of this data. Zipkin’s design is based on the 
>> Google Dapper paper.
>> 
>> = Proposal =
>> Zipkin provides a defined data model and payload type for distributed trace 
>> data collection. It also provides an UI and http api for querying the data. 
>> Its server implements this api and includes abstractions for storage and 
>> transport of trace payloads. The combination of these parts avoid lock-in to 
>> a specific tracing backend. For example, Zipkin includes integration with 
>> different open source storage mechanisms like Apache Cassandra and 
>> Elasticsearch. It also includes bridges to convert collected data and 
>> forward it to service offerings such as Amazon X-Ray and Google Stackdriver. 
>> Ecosystem offering extend this portability further.
>> 
>> While primarily focused on the system, Zipkin also includes tracing 
>> libraries which applications use to report timing information. Zipkin's core 
>> organization includes tracer libraries written in Java, Javascript, Go, PHP 
>> and Ruby. These libraries use the formats mentioned above to report data, as 
>> well "B3" which is a header format needed to send trace identifiers along 
>> with production requests. Many Zipkin libraries can also send data directly 
>> to other services such as Amazon X-Ray and Google Stackdriver, skipping any 
>> Zipkin infrastructure. There are also more Zipkin tracing libraries outside 
>> the core organization than inside it. This is due to the "OpenZipkin" 
>> culture of promoting ecosystem work.
>> 
>> = Background =
>> Zipkin began in 2012 at Twitter during a time they were investigating 
>> performance problems underlying the "fail whale" seen by users. The name 
>> Zipkin is from the Turkish word for harpoon: the harpoon that will kill the 
>> failures! Incidentally, Zipkin was not the first tracing system, it had 
>> roots in a former system at Twitter named BigBrotherBird. It is due to 
>> BigBrotherBird that the de-facto tracing headers we still use today include 
>> the prefix "X-B3".
>> 
>> In 2015, a community of users noticed the project was not healthy in so far 
>> as it hadn't progressed and often didn't accept pull requests, and the 
>> Cassandra backend was stuck on an unmaintained library. For example, the 
>> Apache Incubator H-Trace project started in some ways as a reaction to the 
>> inability to customize the code. The root cause of this was Twitter moving 
>> to internal storage (Manhattan) and also the project not being managed as a 
>> product. By mid 2015, the community regrouped as OpenZipkin and the codebase 
>> moved from Twitter to an org also named OpenZipkin. This led to fast 
>> progress on concerns including initially a server rewrite and Docker based 
>> deployment.
>> 
>> In 2018, the second version of the data model completed, and along the way, 
>> many new libraries became standard, including javascript, golang and PHP. 
>> The community is dramatically larger than 2015, and Zipkin remains the most 
>> popular tracing system despite heavy competition.
>> 
>> = Rationale =
>> Zipkin is a de-facto distributed tracing system, which is more important as 
>> architectures become more fine grained due to popularity of microservice or 
>> even serverless architectures. Applications transition to use more complex 
>> communication including asynchronous code and service mesh, increasing the 
>> need for tools that visualize the behavior of requests as they map across an 
>> architecture.
>> 
>> Zipkin's server is focused only on distributed tracing. It is meant to be 
>> used alongside existing logging and metrics systems. Generally, the 
>> community optimizes brown field concerns such as interop over breaking 
>> changes such as experimental features. The combination of code and community 
>> make Zipkin a safe and easier choice for various sites to introduce or grow 
>> their observability practice.
>> 
>> = Initial Goals =
>> The initial goals are to mature OpenZipkin's community 

Re: [PROPOSAL] Zipkin for Apache Incubator

[Andrew Purtell]

+1

After the retirement of the HTrace podling to the attic we are facing a
fragmentation or removal of distributed tracing capabilities from a set of
related projects (Hadoop, HBase, and Phoenix) that could really use it.
When considering a replacement I think if the replacement was also a
project under the Apache umbrella this would increase confidence, and I
think we can expect a better result with an incubation of Zipkin than we
had with HTrace. Sadly, HTrace didn't get off the ground because it failed
to develop a sustainable community, yet distributed tracing is so important
we took a risk on adopting a early stage podling with an uncertain future.
Zipkin is a better bet, given its maturity as software, significant
adoption to date, and existing community. A slam dunk, IMHO.




On Fri, Aug 17, 2018 at 2:30 AM Adrian Cole  wrote:

> I would like to propose Zipkin as an Apache Incubator project.
>
> The text of the proposal can be found below as well as on the Incubator
> wiki:
>
> https://wiki.apache.org/incubator/ZipkinProposal
>
> I believe we should have 3 mentors.. currently we have 2 (plus Wu
> Sheng and I who are familiar but not mentor-grade :P). If another
> person can volunteer to mentor us, would be sweet.
>
> -Adrian
>
> = Abstract =
> Zipkin is a distributed tracing system. It helps gather timing data
> needed to troubleshoot latency problems in microservice architectures.
> It manages both the collection and lookup of this data. Zipkin’s
> design is based on the Google Dapper paper.
>
> = Proposal =
> Zipkin provides a defined data model and payload type for distributed
> trace data collection. It also provides an UI and http api for
> querying the data. Its server implements this api and includes
> abstractions for storage and transport of trace payloads. The
> combination of these parts avoid lock-in to a specific tracing
> backend. For example, Zipkin includes integration with different open
> source storage mechanisms like Apache Cassandra and Elasticsearch. It
> also includes bridges to convert collected data and forward it to
> service offerings such as Amazon X-Ray and Google Stackdriver.
> Ecosystem offering extend this portability further.
>
> While primarily focused on the system, Zipkin also includes tracing
> libraries which applications use to report timing information.
> Zipkin's core organization includes tracer libraries written in Java,
> Javascript, Go, PHP and Ruby. These libraries use the formats
> mentioned above to report data, as well "B3" which is a header format
> needed to send trace identifiers along with production requests. Many
> Zipkin libraries can also send data directly to other services such as
> Amazon X-Ray and Google Stackdriver, skipping any Zipkin
> infrastructure. There are also more Zipkin tracing libraries outside
> the core organization than inside it. This is due to the "OpenZipkin"
> culture of promoting ecosystem work.
>
> = Background =
> Zipkin began in 2012 at Twitter during a time they were investigating
> performance problems underlying the "fail whale" seen by users. The
> name Zipkin is from the Turkish word for harpoon: the harpoon that
> will kill the failures! Incidentally, Zipkin was not the first tracing
> system, it had roots in a former system at Twitter named
> BigBrotherBird. It is due to BigBrotherBird that the de-facto tracing
> headers we still use today include the prefix "X-B3".
>
> In 2015, a community of users noticed the project was not healthy in
> so far as it hadn't progressed and often didn't accept pull requests,
> and the Cassandra backend was stuck on an unmaintained library. For
> example, the Apache Incubator H-Trace project started in some ways as
> a reaction to the inability to customize the code. The root cause of
> this was Twitter moving to internal storage (Manhattan) and also the
> project not being managed as a product. By mid 2015, the community
> regrouped as OpenZipkin and the codebase moved from Twitter to an org
> also named OpenZipkin. This led to fast progress on concerns including
> initially a server rewrite and Docker based deployment.
>
> In 2018, the second version of the data model completed, and along the
> way, many new libraries became standard, including javascript, golang
> and PHP. The community is dramatically larger than 2015, and Zipkin
> remains the most popular tracing system despite heavy competition.
>
> = Rationale =
> Zipkin is a de-facto distributed tracing system, which is more
> important as architectures become more fine grained due to popularity
> of microservice or even serverless architectures. Applications
> transition to use more complex communication including asynchronous
> code and service mesh, increasing the need for tools that visualize
> the behavior of requests as they map across an architecture.
>
> Zipkin's server is focused only on distributed tracing. It is meant to
> be used alongside existing logging and metrics systems. Generally, the
> community op

Re: [VOTE] Accept Druid into the Apache Incubator

[Andrew Purtell]

+1 (binding)


On Thu, Feb 22, 2018 at 11:03 AM, Julian Hyde  wrote:

> Hi all,
>
> After some discussion on the Druid proposal[1], I'd like to
> start a vote on accepting Druid into the Apache Incubator,
> per the ASF policy[2] and voting rules[3].
>
> A vote for accepting a new Apache Incubator podling is a
> majority vote for which only Incubator PMC member votes are
> binding. Votes from other people are also welcome as an
> indication of people's enthusiasm (or lack thereof).
>
> Please do not use this VOTE thread for discussions.  If
> needed, start a new thread instead.
>
> This vote will run for at least 72 hours. Please VOTE as
> follows:
>  [ ] +1 Accept Druid into the Apache Incubator
>  [ ] +0 Abstain
>  [ ] -1 Do not accept Druid into the Apache Incubator
> because ...
>
> The proposal is listed below, but you can also access it on
> the wiki[4].
>
> Julian
>
> [1] https://lists.apache.org/thread.html/b95f90a30b6e8587e9b108f368b07c
> 1b3e23e25ca592448d9c9f81e2@%3Cgeneral.incubator.apache.org%3E
>
> [2] https://incubator.apache.org/policy/incubation.html#
> approval_of_proposal_by_sponsor
>
> [3] http://www.apache.org/foundation/voting.html
>
> [4] https://wiki.apache.org/incubator/DruidProposal
>
>
>
>
>
> = Druid Proposal =
>
> == Abstract ==
>
> Druid is a high-performance, column-oriented, distributed
> data store.
>
> == Proposal ==
>
> Druid is an open source data store designed for real-time
> exploratory analytics on large data sets. Druid's key
> features are a column-oriented storage layout, a distributed
> shared-nothing architecture, and ability to generate and
> leverage indexing and caching structures. Druid is typically
> deployed in clusters of tens to hundreds of nodes, and has
> the ability to load data from Apache Kafka and Apache
> Hadoop, among other data sources. Druid offers two query
> languages: a SQL dialect (powered by Apache Calcite) and a
> JSON-over-HTTP API.
>
> Druid was originally developed to power a slice-and-dice
> analytical UI built on top of large event streams. The
> original use case for Druid targeted ingest rates of
> millions of records/sec, retention of over a year of data,
> and query latencies of sub-second to a few seconds. Many
> people can benefit from such capability, and many already
> have (see http://druid.io/druid-powered.html). In addition,
> new use cases have emerged since Druid's original
> development, such as OLAP acceleration of data warehouse
> tables and more highly concurrent applications operating
> with relatively narrower queries.
>
> == Background ==
>
> Druid is a data store designed for fast analytics. It would
> typically be used in lieu of more general purpose query
> systems like Hadoop MapReduce or Spark when query latency is
> of the utmost importance. Druid is often used as a data
> store for powering GUI analytical applications.
>
> The buzzwordy description of Druid is a high-performance,
> column-oriented, distributed data store. What we mean by
> this is:
>
> * "high performance": Druid aims to provide low query
>   latency and high ingest rates possible.
> * "column-oriented": Druid stores data in a column-oriented
>   format, like most other systems designed for analytics. It
>   can also store indexes along with the columns.
> * "distributed": Druid is deployed in clusters, typically of
>   tens to hundreds of nodes.
> * "data store": Druid loads your data and stores a copy of
>   it on the cluster's local disks (and may cache it in
>   memory). It doesn't query your data from some other
>   storage system.
>
> == Rationale ==
>
> Druid is a mature, active project with a large number of
> production installations, dozens of contributors to each
> release, and multiple vendors offering professional
> support. Given Druid's strong community, its close
> integration with many other Apache projects (such as Kafka,
> Hadoop, and Calcite), and its pre-existing Apache-inspired
> governance structure, we feel that Apache is the best home
> for the project on a long-term basis.
>
> == Current Status ==
>
> === Meritocracy ===
>
> Since Druid was first open sourced the original developers
> have solicited contributions from others, including through
> our blog, the project mailing lists, and through accepting
> GitHub pull requests. We have an Apache-inspired governance
> structure with a PMC and committers, and our committer ranks
> include a good number of people from outside the original
> development team.
>
> === Community ===
>
> The Druid core developers have sought to nurture a community
> throughout the life of the project. We use GitHub as the
> focal point for bug reports and code contributions, and the
> mailing lists for most other discussion. To try to make
> people feel welcome, we've also spelled this out on a
> "CONTRIBUTE" link from the project page:
> http://druid.io/community/. Today we have an active
> contributor base (a typical release has ~40 contributors)
> and mailing list.
>
> === Core D

Re: [VOTE] Graduate the Apache PredictionIO podling from Incubator to a TLP

[Andrew Purtell]

Forwarding my +1 (binding) from the PPMC vote

I think the issues with the website are not fatal to the vote and I am
confident will be addressed before it closes. I think it is also fine to
wait for them to be addressed before proceeding.

On Wed, Oct 4, 2017 at 9:55 PM, Donald Szeto  wrote:

> Hi all,
>
> The PredictionIO community started an initial discussion on graduation
> [1], evaluated the maturity model [2], and had a consensus that the podling
> is good to graduate. The community proceeded to draft a
> resolution, discussed it [3], and voted on it [4]. The vote passed with 9
> +1 votes (8 binding) and no -1 votes.
>
> The discussion proceeded to the general incubator list, and had gained
> support [5]. I would now like to call for a recommendation vote to present
> the ASF Board with the resolution to graduate from incubation and establish
> Apache PredictionIO as a top-level project.
>
> Apache PredictionIO entered incubation in May 2016. Since then the podling
> has made 3 releases and added 8 PPMC members. For each release, source
> artifacts have been voted on and made available to the public on the Apache
> distribution network. Based on the maturity model evaluation [2], we
> believe that the project is ready to graduate from the Incubator.
>
> Please vote on whether to graduate PredictionIO from the Incubator and
> recommend the graduation resolution below to the ASF Board.
>
> [  ] +1 Graduate Apache PredictionIO podling from the Incubator
> [  ] +0 Don't care
> [  ] -1 Don't graduate Apache PredictionIO podling from the Incubator
> because...
>
> This vote will be open for at least 72 hours. Thanks to all mentors and
> Apache PredictionIO project members and community for their support and
> contribution.
>
> The full text of the resolution from [5] is below. The resolution will be
> submitted to the Board of Directors for their consideration upon approval
> by the Apache Incubator PMC members.
>
> Best Regards,
> Donald
>
> --
>
> Establish the Apache PredictionIO 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 a machine learning server built on top of state-of-the-art
> open source stack, that enables developers to manage and deploy
> production-ready predictive services for various kinds of machine
> learning tasks.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache PredictionIO Project", be and hereby
> is established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache PredictionIO Project be and hereby is
> responsible for the creation and maintenance of software related to a
> machine learning server built on top of state-of-the-art open source
> stack, that enables developers to manage and deploy production-ready
> predictive services for various kinds of machine learning tasks; and be
> it further
>
> RESOLVED, that the office of "Vice President, Apache PredictionIO" 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
> PredictionIO Project, and to have primary responsibility for management
> of the projects within the scope of responsibility of the Apache
> PredictionIO 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 PredictionIO
> Project:
>
>  * Alex Merritt 
>  * Andrew Kyle Purtell 
>  * Chan Lee 
>  * Donald Szeto 
>  * Felipe Oliveira 
>  * James Taylor 
>  * Justin Yip 
>  * Kenneth Chan 
>  * Lars Hofhansl 
>  * Lee Moon Soo 
>  * Luciano Resende 
>  * Marcin Ziemiński 
>  * Marco Vivero 
>  * Mars Hall 
>  * Matthew Tovbin 
>  * Naoki Takezoe 
>  * Pat Ferrel 
>  * Paul Li 
>  * Shinsuke Sugaya 
>  * Simon Chan 
>  * Takahiro Hagino 
>  * Takako Shimamoto 
>  * Tamas Jambor 
>  * Tom Chan 
>  * Vitaly Gordon 
>  * Xiangrui Meng 
>  * Xusen Yin 
>  * Yevgeny Khodorkovsky 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Donald Szeto be appointed
> to the office of Vice President, Apache PredictionIO, 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 PredictionIO PMC be and hereby is
> tasked with the creation of a set of bylaws intend

Re: [DISCUSS] Proposed resolution to graduate the PredictionIO podling

[Andrew Purtell]

Thank you Shane!


On Tue, Oct 3, 2017 at 4:51 PM, Donald Szeto  wrote:

> Awesome. Thanks for your clarification Shane!
>
> On Tue, Oct 3, 2017 at 4:44 PM Shane Curcuru  wrote:
>
> > Andrew Purtell wrote on 10/3/17 5:59 PM:
> > > I think we can proceed to a vote as soon as Shane confirms we are good
> on
> > > the PredictionIO trademark transfer. Should we ping him?
> >
> > The trademark assignment is signed, so you're all set to vote for
> > graduation recommendation!
> >
> > Note that the ownership of the trademark in the USPTO's system will take
> > a while to file the paperwork to show the change of ownership (sometimes
> > a while...) but that doesn't matter for graduation.
> >
> > --
> >
> > - Shane
> >   https://www.apache.org/foundation/marks/resources
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] Proposed resolution to graduate the PredictionIO podling

[Andrew Purtell]

I think we can proceed to a vote as soon as Shane confirms we are good on
the PredictionIO trademark transfer. Should we ping him?


On Mon, Oct 2, 2017 at 3:52 PM, Donald Szeto  wrote:

> Thanks everyone for input! Should we wait for more comments, or is this a
> good time to move to a recommendation vote?
>
> Regards,
> Donald
>
> On Fri, Sep 29, 2017 at 2:02 PM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>
> > Hi Andrew,
> >
> > On Fri, Sep 29, 2017 at 6:30 PM, Andrew Purtell
> >  wrote:
> > > ...I think they are ready to graduate...
> >
> > Thank you very much for your comments, with this I'm +1 for graduation.
> >
> > The resolution looks good to me.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] Proposed resolution to graduate the PredictionIO podling

[Andrew Purtell]

I am mentor and champion.

I've made some comment on the incubator reports to the board about readiness, 
in the past few reports. PredictionIO has gotten the hang of making releases, 
is reliably following ASF policies and practice (I lurk on all the lists), has 
grown their PPMC, and on their own initiative raised the prospect of 
graduation, self-assessing they are ready, which is a signal of readiness in 
its own right in my opinion. They've done this despite a lack of engagement of 
their mentors.

I think they are ready to graduate. 

If you would like me to expand on any of this please ask. 


> On Sep 29, 2017, at 5:59 AM, John D. Ament  wrote:
> 
> On Fri, Sep 29, 2017 at 4:35 AM Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> 
>> Hi,
>> 
>>> On Fri, Sep 29, 2017 at 7:50 AM, Donald Szeto  wrote:
>>> ...Please provide your feedback on this proposed graduation resolution
>> by the
>>> PredictionIO community below...
>> 
>> Maybe I missed something but looking at the links below, that you
>> provided before, I see very few comments from your mentors about
>> PredictionIO's readiness for graduation.
>> 
>> 
> I wouldn't conflate lack of mentor engagement with a project's readiness to
> graduate, though I do agree with just hearing from them.
> 
> 
>> Could we have a stronger statement from your mentors about that? Or
>> links to that if I missed it.
>> 
>> Also, has there been an assessment of the project's maturity as per
>> [0] ? It is not a strong requirement but often a great way to find
>> things that might have been overlooked during incubation.
>> 
> 
> I see [3], but to reiterate completing the maturity assessment is not a
> requirement for the incubator to recommend them for graduation.
> 
> [3]:
> https://lists.apache.org/thread.html/94f22dd6e81063af020a206f59ac7137c7e52f2d2664639093ce17e2@%3Cdev.predictionio.apache.org%3E
> 
> 
>> 
>> -Bertrand
>> 
>> [0]
>> https://community.apache.org/apache-way/apache-project-maturity-model.html
>> 
>> 
>> [1] https://lists.apache.org/thread.html/
>> 2b4ef7c394584988cf0c99920824afaa60ee4c648d5c0069b1bf55c0@%
>> 3Cdev.predictionio.apache.org%3E
>> 
>> [2] https://lists.apache.org/thread.html/
>> 1b06e510773ee1d315728e0ce25f220c9cf7d9e8ad601ec9dba4fe1d@%
>> 3Cdev.predictionio.apache.org%3E
>> 
>> -
>> 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 Apache PredictionIO 0.12.0 (incubating) RC3

[Andrew Purtell]

+1 (binding)


On Wed, Sep 20, 2017 at 3:58 PM, Chan Lee  wrote:

> Hi all,
>
> The PredictionIO community has voted that 0.12.0-incubating-rc3 to be good
> for a source and binary release. This thread is to facilitate a voting for
> the
> IPMC before a final official source and binary release.
>
> Vote result on dev@:
> https://lists.apache.org/thread.html/b1857fe1accd911fa59ec7fbc30192
> a5700853aca4c51f05e7eb4bcc@%3Cdev.predictionio.apache.org%3E
>
> The original vote thread on dev@:
> https://lists.apache.org/thread.html/0cdca8bfc28f7e0bf9c17d0642c5e6
> 75905324cfb16e81bb09101b01@%3Cdev.predictionio.apache.org%3E
>
> The release candidate Git commit is:
> 018ea8e34261f0929ad6d4c669fe80d7520bae16
>
> The release candidate Git tag is:
> v0.12.0-incubating-rc3
>
> The source and binary release candidate artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.12.0-
> incubating-rc3/
>
> Test results of RC3 can be found here:
> https://travis-ci.org/apache/incubator-predictionio/builds/276558626
>
> Build instructions of previous versions can be used on this RC:
> https://predictionio.incubator.apache.org/install/install-sourcecode/
>
> Maven artifacts are built from the release candidate artifacts above, and
> are provided as convenience for testing with PredictionIO engine templates.
> The Maven artifacts are provided at the Maven staging repo here:
> https://repository.apache.org/content/repositories/
> orgapachepredictionio-1021/
>
> All JIRAs completed for this release are tagged with 'FixVersion =
> 0.12.0-incubating'. You can view them here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa
> ?version=12340591&projectId=12320420
>
> The artifacts have been signed with Key : 4719A8F4
>
> Please vote accordingly:
>
> [ ] +1, accept RC as the official 0.11.0 release
> [ ] 0, neutral because...
> [ ] -1, do not accept RC as the official 0.11.0 release because...
>
> The vote will be open for 72 hours and close at 4pm PDT 9/23/2017.
>
> Regards,
> Chan
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [VOTE] Apache Gearpump (incubating) 0.8.4-RC1

[Andrew Purtell]

+1

On Mon, Jun 26, 2017 at 10:47 PM, Karol Brejna 
wrote:

> IPMC Community,
>
> The PPMC vote to release Apache Gearpump (incubating) 0.8.4-RC1 has passed.
> We would like to now submit this release candidate to the IPMC.
>
> The PPMC vote thread is here:
> https://lists.apache.org/thread.html/d04e30eec251c8f33f319e98d24a5c
> d2d3cc62455276d49719057c3f@%3Cdev.gearpump.apache.org%3E
>
> The source and binary tarballs, including signatures, digests, etc.
> can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/gearpump/0.
> 8.4-incubating/RC1/
>
> Release artifacts are signed with the key with fingerprint:
> 3F12 81A2 DB58 0842 5ABA  6962 D8A8 4FBC 0A83 B291
>
> The KEYS file is available here:
> https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS
>
> The tag to be voted upon is:
> https://git-wip-us.apache.org/repos/asf?p=incubator-
> gearpump.git;a=shortlog;h=refs/tags/0.8.4-RC1
>
> The release hash is:
> https://git-wip-us.apache.org/repos/asf?p=incubator-
> gearpump.git;a=commit;h=71132b256b8edbd734839386d8de2731813bd290
>
> For information about the contents of this release see:
> https://issues.apache.org/jira/projects/GEARPUMP/versions/12340225
> Most changes are driven by Apache Beam integration.
>
>
> This vote will be open for at least 72 hours (Thursday, June 29, 2017
> at 11:00 PM PDT).
>
>
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, run the
> binary artifacts in the binary release and test.
> Please vote:
>
> [ ] +1 Release this package as gearpump-0.8.4
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because...
>
> Thanks,
> Karol
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [VOTE] Livy to enter Apache Incubator

[Andrew Purtell]

+1 (binding)

> On May 31, 2017, at 6:03 AM, Sean Busbey  wrote:
> 
> Hi folks!
> 
> I'm calling a vote to accept "Livy" into the Apache Incubator.
> 
> The full proposal is available below, and is also available in the wiki:
> 
> https://wiki.apache.org/incubator/LivyProposal
> 
> For additional context, please see the discussion thread:
> 
> https://s.apache.org/incubator-livy-proposal-thread
> 
> Please cast your vote:
> 
> [ ] +1, bring Livy into Incubator
> [ ] -1, do not bring Livy into Incubator, because...
> 
> The vote will open at least for 72 hours and only votes from the Incubator
> PMC are binding.
> 
> I start with my vote:
> +1
> 
> 
> 
> = Abstract =
> 
> Livy is web service that exposes a REST interface for managing long running
> Apache Spark contexts in your cluster. With Livy, new applications can be
> built on top of Apache Spark that require fine grained interaction with many
> Spark contexts.  
> 
> = Proposal =
> 
> Livy is an open-source REST service for Apache Spark. Livy enables
> applications to submit Spark applications and retrieve results without a
> co-location requirement on the Spark cluster. 
> 
> We propose to contribute the Livy codebase and associated artifacts (e.g.
> documentation, web-site context etc) to the Apache Software Foundation.
> 
> = Background =
> 
> Apache Spark is a fast and general purpose distributed compute engine, with
> a versatile API. It enables processing of large quantities of static data
> distributed over a cluster of machines, as well as processing of continuous
> streams of data. It is the preferred distributed data processing engine for
> data engineering, stream processing and data science workloads. Each Spark
> application uses a construct called the SparkContext, which is the
> application’s connection or entry point to the Spark engine. Each Spark
> application will have its own SparkContext.
> 
> Livy enables clients to interact with one or more Spark sessions through the
> Livy Server, which acts as a proxy layer. Livy Clients have fine grained
> control over the lifecycle of the Spark sessions, as well as the ability to
> submit jobs and retrieve results, all over HTTP. Clients have two modes of
> interaction: RPC Client API, available in Java and Python, which allows
> results to be retrieved as Java or Python objects. The serialization and
> deserialization of the results is handled by the Livy framework. HTTP based
> API that allows submission of code snippets, and retrieval of the results in
> different formats.
> 
> Multi-tenant resource allocation and security: Livy enables multiple
> independent Spark sessions to be managed simultaneously. Multiple clients
> can also interact simultaneously with the same Spark session and share the
> resources of that Spark session. Livy can also enforce secure, authenticated
> communication between the clients and their respective Spark sessions.
> 
> More information on Livy can be found at the existing open source website:
> http://livy.io/
> 
> = Rationale =
> 
> Users want to use Spark’s powerful processing engine and API as the data
> processing backend for interactive applications. However, the job submission
> and application interaction mechanisms built into Apache Spark are
> insufficient and cumbersome for multi-user interactive applications.
> 
> The primary mechanism for applications to submit Spark jobs is via
> spark-submit
> (http://spark.apache.org/docs/latest/submitting-applications.html), which is
> available as a command line tool as well as a programmatic API. However,
> spark-submit has the following limitations that make it difficult to build
> interactive applications: It is slow: each invocation of spark-submit
> involves a setup phase where cluster resources are acquired, new processes
> are forked, etc. This setup phase runs for many seconds, or even minutes,
> and hence is too slow for interactive applications. It is cumbersome and
> lacks flexibility: application code and dependencies have to be pre-compiled
> and submitted as jars, and can not be submitted interactively.
> 
> Apache Spark comes with an ODBC/JDBC server, which can be used to submit SQL
> queries to Spark. However, this solution is limited to SQL and does not
> allow the client to leverage the rest of the Spark API, such as RDDs, MLlib
> and Streaming.
> 
> A third way of using Spark is via its command-line shell, which allows the
> interactive submission of snippets of Spark code. However, the shell entails
> running Spark code on the client machine and hence is not a viable mechanism
> for remote clients to submit Spark jobs.
> 
> Livy solves the limitations of the above three mechanisms, and provides the
> full Spark API as a multi-tenant service to remote clients. 
> 
> Since the open source release of Livy in late 2015, we have seen tremendous
> interest among a diverse set of application developers and ISVs that want to
> build applications with Apache Spark. To make Livy a robust and fl

Re: [VOTE] Release Apache PredictionIO 0.11.0 (incubating) RC2

[Andrew Purtell]

No, you are free to make this release provided there is an issue tracking the 
RAT check failures and a promise to fix them for the next release.  

> On Apr 23, 2017, at 8:50 AM, Pat Ferrel  wrote:
> 
> Many thanks! 
> 
> I for one was not aware we could change an RC without a podling vote, which 
> seems better in any case. These issues will be fixed asap in master and the 
> live site.
> 
> 
> On Apr 22, 2017, at 6:28 PM, Andrew Purtell  wrote:
> 
> I was just trying to get something moving. Glad to see it. 
> 
> +1 (binding)
> 
>> On Apr 22, 2017, at 6:24 PM, Luciano Resende  wrote:
>> 
>> Sure, I am ok having this become blocker if its still an issue on the next
>> release.
>> 
>> Here is my +1 the .
>> 
>>> On Sat, Apr 22, 2017 at 4:49 PM John D. Ament  wrote:
>>> 
>>> In general, the preference is to report the non-blocking issue, and confirm
>>> the podling has it entered into their bug tracker.  Then they accept
>>> the +1.  We don't generally wait for a code change to be made, but would
>>> block the next release if these issues are not addressed.  I personally
>>> want to understand why we're requiring the podling to fix it now before
>>> approving the release.  This looks like PredictionIO's first release, so we
>>> wouldn't have seen this already.
>>> 
>>> The contents of the release generally look good.  IN addition to the notes
>>> from Luciano, your NOTICE file should be updated to reflect 2016-2017 ASF.
>>> I would recommend renaming these files to just NOTICE and LICENSE and drop
>>> the .txt, to better comply with the licensing.
>>> 
>>> Here's my +1, not waiting for anything to be fixed.
>>> 
>>> John
>>> 
>>> On Sat, Apr 22, 2017 at 7:43 PM Andrew Purtell 
>>> wrote:
>>> 
>>>> I will too, and then you will have two binding votes in the affirmative.
>>>> 
>>>>> On Apr 22, 2017, at 12:34 PM, Luciano Resende 
>>>> wrote:
>>>>> 
>>>>>> On Sat, Apr 22, 2017 at 12:14 PM, Pat Ferrel 
>>>> wrote:
>>>>>> 
>>>>>> But is it worth doing yet another podling RC and release vote?
>>>>>> 
>>>>> 
>>>>>> If it is, please vote -1, at least we won’t be left waiting and we
>>> thank
>>>>>> you for being the one who took a look either way.
>>>>>> 
>>>>>> We are just trying to move, out if possible or iterate if not. These
>>>>>> issues have not changed from the current release and so do not
>>> indicate
>>>>>> regression and they have Jira’s for the next release.
>>>>>> 
>>>>>> 
>>>>> Not necessary, once this is fixed in master I would vote ok for the
>>>> current
>>>>> RC
>>>>> 
>>>>> --
>>>>> Luciano Resende
>>>>> 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
>>>> 
>>>> 
>>> 
>> -- 
>> Sent from my Mobile device
> 
> -
> 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 Apache PredictionIO 0.11.0 (incubating) RC2

[Andrew Purtell]

I was just trying to get something moving. Glad to see it. 

+1 (binding)

> On Apr 22, 2017, at 6:24 PM, Luciano Resende  wrote:
> 
> Sure, I am ok having this become blocker if its still an issue on the next
> release.
> 
> Here is my +1 the .
> 
>> On Sat, Apr 22, 2017 at 4:49 PM John D. Ament  wrote:
>> 
>> In general, the preference is to report the non-blocking issue, and confirm
>> the podling has it entered into their bug tracker.  Then they accept
>> the +1.  We don't generally wait for a code change to be made, but would
>> block the next release if these issues are not addressed.  I personally
>> want to understand why we're requiring the podling to fix it now before
>> approving the release.  This looks like PredictionIO's first release, so we
>> wouldn't have seen this already.
>> 
>> The contents of the release generally look good.  IN addition to the notes
>> from Luciano, your NOTICE file should be updated to reflect 2016-2017 ASF.
>> I would recommend renaming these files to just NOTICE and LICENSE and drop
>> the .txt, to better comply with the licensing.
>> 
>> Here's my +1, not waiting for anything to be fixed.
>> 
>> John
>> 
>> On Sat, Apr 22, 2017 at 7:43 PM Andrew Purtell 
>> wrote:
>> 
>>> I will too, and then you will have two binding votes in the affirmative.
>>> 
>>>> On Apr 22, 2017, at 12:34 PM, Luciano Resende 
>>> wrote:
>>>> 
>>>>> On Sat, Apr 22, 2017 at 12:14 PM, Pat Ferrel 
>>> wrote:
>>>>> 
>>>>> But is it worth doing yet another podling RC and release vote?
>>>>> 
>>>> 
>>>>> If it is, please vote -1, at least we won’t be left waiting and we
>> thank
>>>>> you for being the one who took a look either way.
>>>>> 
>>>>> We are just trying to move, out if possible or iterate if not. These
>>>>> issues have not changed from the current release and so do not
>> indicate
>>>>> regression and they have Jira’s for the next release.
>>>>> 
>>>>> 
>>>> Not necessary, once this is fixed in master I would vote ok for the
>>> current
>>>> RC
>>>> 
>>>> --
>>>> Luciano Resende
>>>> 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
>>> 
>>> 
>> 
> -- 
> Sent from my Mobile device

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

Re: [VOTE] Release Apache PredictionIO 0.11.0 (incubating) RC2

[Andrew Purtell]

I will too, and then you will have two binding votes in the affirmative. 

> On Apr 22, 2017, at 12:34 PM, Luciano Resende  wrote:
> 
>> On Sat, Apr 22, 2017 at 12:14 PM, Pat Ferrel  wrote:
>> 
>> But is it worth doing yet another podling RC and release vote?
>> 
> 
>> If it is, please vote -1, at least we won’t be left waiting and we thank
>> you for being the one who took a look either way.
>> 
>> We are just trying to move, out if possible or iterate if not. These
>> issues have not changed from the current release and so do not indicate
>> regression and they have Jira’s for the next release.
>> 
>> 
> Not necessary, once this is fixed in master I would vote ok for the current
> RC
> 
> -- 
> Luciano Resende
> 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

Re: [VOTE] Release of Apache Tephra-0.11.0-incubating [rc2]

[Andrew Purtell]

+1

Unpacked source tarball, layout looks ok.
Checked sums and signature: ok
LICENSE and NOTICE: ok
DISCLAIMER: ok
RAT check passes: ok
Built from source: ok (7u80)
Unit tests pass: ok (7u80)


On Fri, Mar 10, 2017 at 5:18 PM, Gokul Gunasekaran  wrote:

> Hi all,
>
> This is a call for a vote on releasing Apache Tephra 0.11.0-incubating,
> release candidate 2. This is the fourth release of Tephra.
>
> Apache Tephra community has voted and approved the release.
>
> Vote thread:
> http://mail-archives.apache.org/mod_mbox/incubator-tephra-
> dev/201703.mbox/%3CCAFgkoWEhJrFB5WdUJBh3qe5v9UqYxPHLRQRJQBKUr7gD%2BHOCEA%
> 40mail.gmail.com%3E
>
> Result thread:
> http://mail-archives.apache.org/mod_mbox/incubator-tephra-
> dev/201703.mbox/%3CCAFgkoWHo6bQ6sN_X64_%3Df5PYV2SLhdswZ%2BbBbpp-
> jHK3smpALw%40mail.gmail.com%3E
>
> The source tarball, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/tephra/0.
> 11.0-incubating-rc2/src
>
> The tag to be voted upon is v0.11.0-incubating:
> https://git-wip-us.apache.org/repos/asf?p=incubator-tephra.
> git;a=shortlog;h=refs/tags/v0.11.0-incubating
>
> The release hash is 6c0ba4da1597394d9d24bfde7f50a8793ac85e67:
> https://git-wip-us.apache.org/repos/asf?p=incubator-tephra.git;a=commit;h=
> 6c0ba4da1597394d9d24bfde7f50a8793ac85e67
>
> The Nexus Staging URL:
> https://repository.apache.org/content/repositories/orgapachetephra-1007/
>
> Release artifacts are signed by:
> http://people.apache.org/keys/committer/gokul
>
> KEYS file available:
> https://dist.apache.org/repos/dist/dev/incubator/tephra/KEYS
>
> For information about the contents of this release, see:
> https://dist.apache.org/repos/dist/dev/incubator/tephra/0.
> 11.0-incubating-rc2/CHANGES.txt
>
> Please vote on releasing this package as Apache Tephra 0.11.0-incubating.
> Note that the vote for rc1 was canceled due to the bug
> https://issues.apache.org/jira/browse/TEPHRA-223. This bug is fixed in
> rc2.
>
> The vote will be open for 72 hours.
>
> [ ] +1 Release this package as Apache Tephra 0.11.0-incubating
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
> Thanks,
> Gokul
>



-- 
Best regards,

   - Andy

If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)

Re: [VOTE] Ratis to enter Apache Incubator

[Andrew Purtell]

+1 (binding)

On Fri, Dec 16, 2016 at 3:41 PM, Jitendra Pandey 
wrote:

> Dear All,
>I would like to call a vote for accepting "Ratis" for incubation in the
> Apache Incubator.
> The full proposal is available below, and is also available at this wiki
> link.
>https://wiki.apache.org/incubator/RatisProposal
> There are two discussion threads for this proposal, because the project
> was renamed from Concur to Ratis based on feedback. Please look for both
> Concur and Ratis in the archives.
>
> Please cast your vote:
>
>   [ ] +1, bring Ratis into Incubator
>   [ ] +0, I don't care either way,
>   [ ] -1, do not bring Ratis into Incubator, because...
>
>  The vote will open at least for 72 hours and only votes from the
> Incubator PMC are binding.
>
> I start with my vote:
> +1 (binding)
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Bring Griffin to Apache Incubator

[Andrew Purtell]

+1 (binding)

> On Dec 1, 2016, at 8:35 AM, Felix Cheung  wrote:
> 
> +1
> 
> On Wed, Nov 30, 2016 at 10:40 PM Henry Saputra 
> wrote:
> 
>> Hi All,
>> 
>> As the champion for Griffin, I would like to start VOTE to bring  the
>> project as Apache incubator podling.
>> 
>> Here is the direct quote from the abstract:
>> 
>> "
>> Griffin is a Data Quality Service platform built on Apache Hadoop and
>> Apache Spark. It provides a framework process for defining data
>> quality model, executing data quality measurement, automating data
>> profiling and validation, as well as a unified data quality
>> visualization across multiple data systems. It tries to address the
>> data quality challenges in big data and streaming context.
>> "
>> 
>> Please cast your vote:
>> 
>> [ ] +1, bring Griffin into Incubator
>> [ ] +0, I don't care either way,
>> [ ] -1, do not bring Griffin into Incubator, because...
>> 
>> This vote will be open at least for 72 hours and only votes from the
>> Incubator PMC are binding.
>> 
>> The VOTE will end 12/5 9am PST to pass through weekend.
>> 
>> 
>> Here is the link to the proposal:
>> 
>> https://wiki.apache.org/incubator/GriffinProposal
>> 
>> I have copied the proposal below for easy access
>> 
>> 
>> Thanks,
>> 
>> - Henry
>> 
>> 
>> 
>> Griffin Proposal
>> 
>> Abstract
>> 
>> Griffin is a Data Quality Service platform built on Apache Hadoop and
>> Apache Spark. It provides a framework process for defining data
>> quality model, executing data quality measurement, automating data
>> profiling and validation, as well as a unified data quality
>> visualization across multiple data systems. It tries to address the
>> data quality challenges in big data and streaming context.
>> 
>> Proposal
>> 
>> Griffin is a open source Data Quality solution for distributed data
>> systems at any scale in both streaming or batch data context. When
>> people use open source products (e.g. Apache Hadoop, Apache Spark,
>> Apache Kafka, Apache Storm), they always need a data quality service
>> to build his/her confidence on data quality processed by those
>> platforms. Griffin creates a unified process to define and construct
>> data quality measurement pipeline across multiple data systems to
>> provide:
>> 
>> Automatic quality validation of the data
>> Data profiling and anomaly detection
>> Data quality lineage from upstream to downstream data systems.
>> Data quality health monitoring visualization
>> Shared infrastructure resource management
>> 
>> Overview of Griffin
>> 
>> Griffin has been deployed in production at eBay serving major data
>> systems, it takes a platform approach to provide generic features to
>> solve common data quality validation pain points. Firstly, user can
>> register the data asset which user wants to do data quality check. The
>> data asset can be batch data in RDBMS (e.g.Teradata), Apache Hadoop
>> system or near real-time streaming data from Apache Kafka, Apache
>> Storm and other real time data platforms. Secondly, user can create
>> data quality model to define the data quality rule and metadata.
>> Thirdly, the model or rule will be executed automatically (by the
>> model engine) to get the sample data quality validation results in a
>> few seconds for streaming data. Finally, user can analyze the data
>> quality results through built-in visualization tool to take actions.
>> 
>> Griffin includes:
>> 
>> Data Quality Model Engine
>> 
>> Griffin is model driven solution, user can choose various data quality
>> dimension to execute his/her data quality validation based on selected
>> target data-set or source data-set ( as the golden reference data). It
>> has a corresponding library supporting it in back-end for the
>> following measurement:
>> 
>> Accuracy - Does data reflect the real-world objects or a verifiable source
>> Completeness - Is all necessary data present
>> Validity - Are all data values within the data domains specified by the
>> business
>> Timeliness - Is the data available at the time needed
>> Anomaly detection - Pre-built algorithm functions for the
>> identification of items, events or observations which do not conform
>> to an expected pattern or other items in a dataset
>> Data Profiling - Apply statistical analysis and assessment of data
>> values within a dataset for consistency, uniqueness and logic.
>> 
>> Data Collection Layer
>> 
>> We support two kinds of data sources, batch data and real time data.
>> 
>> For batch mode, we can collect data source from Apache Hadoop based
>> platform by various data connectors.
>> 
>> For real time mode, we can connect with messaging system like Kafka to
>> near real time analysis.
>> 
>> Data Process and Storage Layer
>> 
>> For batch analysis, our data quality model will compute data quality
>> metrics in our spark cluster based on data source in Apache Hadoop.
>> 
>> For near real time analysis, we consume data from messaging system,
>> then our data quality model will compute our real time data qual

Re: [VOTE] Release Apache PredictionIO 0.10.0 (incubating) RC5

[Andrew Purtell]

+1 binding

- Checked sums and signatures: ok

- Spot checked LICENSE and NOTICE: present, properly formatted

- No binaries in the source release (except source image files)

- Compiled from source following the build instructions (8u102)

- Manually invoked Apache RAT using ./tests/.rat-excludes: 0 unknown
licenses

However, the exclusion list of the RAT check seems overly broad. For
example, the entirety of the documentation source files are excluded.
Piping 'find' through 'wc -l' counts 200 markdown files not covered by the
release audit and not carrying the AL header. These are files that have
been created by the project authors. They should carry the AL header I
believe and markdown supports embedded comments. There are also 59 files
with .txt extension that are excluded and are of unclear disposition. Some
are to be used as templates, are created by the project authors, and seem
important for implementing functionality. This can be addressed in a
subsequent release.


On Tue, Oct 4, 2016 at 10:00 AM, Donald Szeto  wrote:

> Hi all,
>
> The PredictionIO community has voted that 0.10.0-incubating-rc5 to be good
> for a source-only release. This thread is to facilitate a voting for the
> IPMC before a final official source-only release.
>
> Vote result on dev@:
> http://mail-archives.apache.org/mod_mbox/incubator-
> predictionio-dev/201610.mbox/%3CCAD8z1JJgU4Ewgkh9zFCD9iXvUSE
> ERcXn74pjbyReHheYXN4onw%40mail.gmail.com%3E
>
> The original vote thread on dev@:
> http://mail-archives.apache.org/mod_mbox/incubator-
> predictionio-dev/201610.mbox/%3CCAD8z1JJ4jPkmO42dZjB0bcLqCua
> XTWhB1Z%3D5-aAx1iLuYha0iw%40mail.gmail.com%3E
>
> The release candidate Git commit is:
> 5db129aa94bb82674eb9c85c197cd6bb0afaea83
>
> The release candidate Git tag is:
> v0.10.0-incubating-rc5
>
> The source-only release candidate artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.10.0-
> incubating-rc5/
> 
>
> Test results of RC5 can be found here:
> https://travis-ci.org/apache/incubator-predictionio/builds/164221633
>
> Build instructions of previous versions can be used on this RC:
> http://predictionio.incubator.apache.org/install/install-sourcecode/
>
> Unit and integration tests instructions can be found at:
> https://github.com/apache/incubator-predictionio/blob/
> release/0.10.0/tests/README.md
>
> Maven artifacts are built from the release candidate artifacts above, and
> are provided as convenience for testing with PredictionIO engine templates.
> The Maven
> artifacts are provided at the Maven staging repo here:
> https://repository.apache.org/content/repositories/
> orgapachepredictionio-1009/
>
> All JIRAs completed for this release are tagged with 'FixVersion = 0.10.0'.
> You can view them here: https://issues.apache.org/
> jira/secure/ReleaseNote.jspa?projectId=12320420&version=12337844
>
> The artifacts have been signed with Key : 8BF4ABEB
>
> Please vote accordingly:
>
> [ ] +1, accept RC as the official 0.10.0 release
> [ ] 0, neutral because...
> [ ] -1, do not accept RC as the official 0.10.0 release because...
>
> The vote will be open for 72 hours and close at 10am PST 10/7/2016.
>
> Regards,
> Donald
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Apache Gearpump (incubating) 0.8.1-RC5 as 0.8.1 Release

[Andrew Purtell]

I did also mention that 72 hours is a minimum. :-)

> On Aug 1, 2016, at 6:52 AM, Kam Kasravi  wrote:
> 
> Thanks John, we usually do. Andy suggested under certain circumstances (in 
> this case minor LICENSE corrections culled from general@ comments for RC4) 
> there have been past examples where the voted period had been expedited. 
> Earlier RC releases provided 3 day voting periods.
> 
>> On Aug 1, 2016, at 9:33 AM, John D. Ament  wrote:
>> 
>> You should wait at least 3 days (72 hours) for a vote, even on a dev thread.
>> 
>> John
>> 
>>> On Mon, Aug 1, 2016 at 9:26 AM Kam Kasravi  wrote:
>>> 
>>> Hi IPMC Community
>>> 
>>> The PPMC vote to release Apache Gearpump (incubating) 0.8.1-RC5 has passed
>>> successfully.
>>> We would like to now submit this release candidate to the IPMC.
>>> 
>>> The PPMC vote thread is here:
>>> 
>>> https://lists.apache.org/thread.html/efcd821ea9053e6a74d6ad113f4dc38408630d19f47a821d8d234d1c@%3Cdev.gearpump.apache.org%3E
>>> 
>>> The source tarball, including signatures, digests, etc. can be found at:
>>> 
>>> https://dist.apache.org/repos/dist/dev/incubator/gearpump/0.8.1-incubating/RC5/
>>> 
>>> 
>>> The release hash is:
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=commit;h=867f9be55ddf7e50e2a6d5579834c4418818c44c
>>> 
>>> Release artifacts are signed with the following key:
>>> https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS
>>> 
>>> The KEYS file is available here:
>>> https://dist.apache.org/repos/dist/dev/incubator/gearpump
>>> 
>>> For information about the contents of this release see:
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=blob;f=CHANGELOG.md;h=8a24bf48066bff8b46316abd9d28cc62aac71095;hb=867f9be55ddf7e50e2a6d5579834c4418818c44c
>>> 
>>> The vote will be open for 72 hours (Thursday, August 4, 2016 at 09:30 EST)
>>> 
>>> Please download the release candidate and evaluate the necessary items
>>> including checking hashes, signatures, build from source, and test.
>>> 
>>> Please vote:
>>> [ ] +1 Release this package as gearpump-0.8.1
>>> [ ] +0 no opinion
>>> [ ] -1 Do not release this package because because...
>>> 
>>> Thanks,
>>> Kam
> 
> 
> -
> 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 Gearpump (incubating) 0.8.1-RC4 as 0.8.1

[Andrew Purtell]

Jersey is dual licensed CDDL and a transitive dependency from (at least) Hadoop 
and Spark. 


> On Jul 27, 2016, at 7:23 AM, Kam Kasravi  wrote:
> 
> Hi Justin
> 
> These were tagged as GPL
> 
> 
> I'll determine their dependencies linkage - we have no references to 
> com.sun.jersey within our codebase but it looks to be dual licensed?
> 
> Thanks
> Kam
> 
> 
> On Tuesday, July 26, 2016 6:28 PM, Justin Mclean  
> wrote:
> 
> 
> Hi,
> 
> > [Kam] This analyzes jars required to build the binary artifacts - so my 
> > assumption is that it is not relevant to release just the source?
> 
> Apache project cannot have GPL dependancies [1][5][6] (there are however a 
> few exceptions for optional parts[2] and some build tools [3]). I’d first 
> check to see if the software is question is dual licensed. [4]
> 
> > Based on just releasing source there are no CCL related artifacts included 
> > in the .tgz.
> 
> Again see [1] and [6] for problematic licenses.
> 
> Thanks,
> Justin
> 
> 1.http://www.apache.org/legal/resolved.html#prohibited
> 2. http://www.apache.org/legal/resolved.html#optional
> 3. http://www.apache.org/legal/resolved.html#build-tools
> 4. http://www.apache.org/legal/resolved.html#mutually-exclusive
> 5. http://www.apache.org/licenses/GPL-compatibility.html
> 6. http://www.apache.org/legal/resolved.html#category-x
> 
> -
> 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 Gearpump (incubating) 0.8.1-RC4 as 0.8.1

[Andrew Purtell]

I am out until the first week of August. Could one of the Gearpump mentors also 
on the IPMC have a look? 

> On Jul 25, 2016, at 1:14 AM, Manu Zhang  wrote:
> 
> Could any PMC members please take a look at this release candidate ?
> We have already passed the vote deadline but not got a vote yet.
> BTW, can we extend the vote because of the weekends ?
> 
> Thanks,
> Manu Zhang
> 
>> On Thu, Jul 21, 2016 at 12:32 AM Kam Kasravi  wrote:
>> 
>> Hi IPMC Community
>> 
>> The PPMC vote to release Apache Gearpump (incubating) 0.8.1-RC4 has passed
>> successfully.
>> We would like to now submit this release candidate to the IPMC.
>> 
>> The PPMC vote thread is here:
>> 
>> https://lists.apache.org/thread.html/a53ecee5575ec998d757a084ba5c4132691b1a97fd0e6705ab670fbe@%3Cdev.gearpump.apache.org%3E
>> 
>> The source tarball, including signatures, digests, etc. can be found at:
>> 
>> https://dist.apache.org/repos/dist/dev/incubator/gearpump/0.8.1-incubating/RC4/
>> 
>> 
>> The release hash is:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=commit;h=533377fb135807d1f87a8a88c73ab6eb5a6c04c2
>> 
>> Release artifacts are signed with the following key:
>> https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS
>> 
>> The KEYS file is available here:
>> https://dist.apache.org/repos/dist/dev/incubator/gearpump
>> 
>> For information about the contents of this release see:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=blob;f=CHANGELOG.md;h=8a24bf48066bff8b46316abd9d28cc62aac71095;hb=533377fb135807d1f87a8a88c73ab6eb5a6c04c2
>> 
>> The vote will be open for 72 hours (Saturday, July 22, 2016 at 09:30 PST)
>> 
>> Please download the release candidate and evaluate the necessary items
>> including checking hashes, signatures, build from source, and test.
>> 
>> Please vote:
>> [ ] +1 Release this package as gearpump-0.8.1
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because because...
>> 
>> Thanks,
>> Kam
>> 

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

Re: [VOTE] Apache Gearpump (incubating) 0.8.1-RC3

[Andrew Purtell]

Thank you very much John. We will fix.


On Fri, Jul 15, 2016 at 4:50 AM, John D. Ament 
wrote:

> Sorry but -1 due to missing DISCLAIMER in the release.  See [1] for more
> details
>
>
> [1]:
> http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
>
> On Thu, Jul 14, 2016 at 3:39 PM Kam Kasravi  wrote:
>
> > Hi IPMC Community
> >
> > The PPMC vote to release Apache Gearpump (incubating) 0.8.1-RC3 has
> passed.
> > We would like to now submit this release candidate to the IPMC.
> >
> > The PPMC vote thread is here:
> >
> >
> https://lists.apache.org/thread.html/d72a820712f0a1816e2c5d66b7708ee81401d9cb91f36b9ea6230c09@%3Cdev.gearpump.apache.org%3E
> >
> > The source tarball, including signatures, digests, etc. can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/gearpump/0.8.1-incubating/RC3/
> >
> > The release hash
> > is:
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=commit;h=e7fef511d9f25cf2cdedc3ea4eb90d71c1c74c19
> >
> > Release artifacts are signed with the following
> > key:https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS
> >
> > The KEYS file is available
> > here:https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS
> >
> > For information about the contents of this release (including fixes
> > for prior failed release candidates) see:
> >
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=blob;f=CHANGELOG.md;h=143222da2435a1cea5b2f265da6b69f9b9169f8e;hb=e7fef511d9f25cf2cdedc3ea4eb90d71c1c74c19
> >
> > The vote will be open for 72 hours (Sunday, July 17, 2016 at 12:40 PST)
> >
> > Please download the release candidate and evaluate the necessary items
> > including checking hashes, signatures, build from source, and test.  The
> > please vote:
> >
> > [ ] +1 Release this package as gearpump-0.8.1
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because because...
> >
> > Thanks,
> > Kam
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Apache Gearpump (incubating) 0.8.1-RC3

[Andrew Purtell]

Carrying over my +1 from the PPMC vote.

Please someone have a look at the release artifacts. I try, but don't have
the encyclopedic knowledge of policy nor the eye for detail that some of
you other IPMCers do.


On Thu, Jul 14, 2016 at 12:39 PM, Kam Kasravi  wrote:

> Hi IPMC Community
>
> The PPMC vote to release Apache Gearpump (incubating) 0.8.1-RC3 has passed.
> We would like to now submit this release candidate to the IPMC.
>
> The PPMC vote thread is here:
>
> https://lists.apache.org/thread.html/d72a820712f0a1816e2c5d66b7708ee81401d9cb91f36b9ea6230c09@%3Cdev.gearpump.apache.org%3E
>
> The source tarball, including signatures, digests, etc. can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/gearpump/0.8.1-incubating/RC3/
>
> The release hash
> is:
> https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=commit;h=e7fef511d9f25cf2cdedc3ea4eb90d71c1c74c19
>
> Release artifacts are signed with the following
> key:https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS
>
> The KEYS file is available
> here:https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS
>
> For information about the contents of this release (including fixes
> for prior failed release candidates) see:
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=blob;f=CHANGELOG.md;h=143222da2435a1cea5b2f265da6b69f9b9169f8e;hb=e7fef511d9f25cf2cdedc3ea4eb90d71c1c74c19
>
> The vote will be open for 72 hours (Sunday, July 17, 2016 at 12:40 PST)
>
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test.  The
> please vote:
>
> [ ] +1 Release this package as gearpump-0.8.1
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because...
>
> Thanks,
> Kam
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: DISCUSS: Trafodion for TLP

[Andrew Purtell]

Thanks a lot for the clarification, Dave.


On Wed, Jun 8, 2016 at 12:18 PM, Dave Birdsall 
wrote:

> That is close. When entering incubation, all nine of the original Trafodion
> committers were HP employees. Of those, four decamped to Esgyn. Five
> remained at HP or found other affiliations but have largely been inactive.
> More Esgyn committers have been added since.
>
> One non-Esgyn committer, Pierre Smits, has been added since entering
> incubation.
>
> -Original Message-
> From: Andrew Purtell [mailto:apurt...@apache.org]
> Sent: Wednesday, June 8, 2016 12:12 PM
> To: general@incubator.apache.org
> Subject: Re: DISCUSS: Trafodion for TLP
>
> Am I correct in understanding that when entering incubation all Trafodion
> committers were Esgyn employees and after one year the podling has added
> three new committers of different affiliation?
>
> On Wed, Jun 8, 2016 at 12:08 PM, Stack  wrote:
>
> > We'd like to solicit feedback on whether the Trafodiion project is
> > ready to go TLP. I am the project Champion writing on behalf of the
> > project PMC.
> >
> > Our clutch report is nice and healthy [2]. Our up-to-date status page
> > can be found here [1.]. Development is brisk. We've made two releases
> > out of incubator up to this (with another up for vote). We have taken
> > on new committers since we entered incubation about a year ago.
> >
> > The main downside that we see is that we have few users -- going by
> > traffic up on the mailing list -- and that near all committers are
> > from a single company, Esgyn (Three committers are not Esgyn employees).
> >
> > Feedback/opinions appreciated.
> >
> > Yours,
> > St.Ack
> >
> > 1. http://incubator.apache.org/projects/trafodion.html
> > 2. http://incubator.apache.org/clutch.html
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: DISCUSS: Trafodion for TLP

[Andrew Purtell]

Am I correct in understanding that when entering incubation all Trafodion
committers were Esgyn employees and after one year the podling has added
three new committers of different affiliation?

On Wed, Jun 8, 2016 at 12:08 PM, Stack  wrote:

> We'd like to solicit feedback on whether the Trafodiion project is ready to
> go TLP. I am the project Champion writing on behalf of the project PMC.
>
> Our clutch report is nice and healthy [2]. Our up-to-date status page can
> be found here [1.]. Development is brisk. We've made two releases out of
> incubator up to this (with another up for vote). We have taken on new
> committers since we entered incubation about a year ago.
>
> The main downside that we see is that we have few users -- going by traffic
> up on the mailing list -- and that near all committers are from a single
> company, Esgyn (Three committers are not Esgyn employees).
>
> Feedback/opinions appreciated.
>
> Yours,
> St.Ack
>
> 1. http://incubator.apache.org/projects/trafodion.html
> 2. http://incubator.apache.org/clutch.html
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Graduate Apache Twill as Top Level Project

[Andrew Purtell]

+1 (binding)

On Thu, Jun 2, 2016 at 3:06 PM, Henry Saputra 
wrote:

> Hi All,
>
> Following the DISCUSS thread about Apache Twill graduating as TLP, I would
> like to send VOTE request thread.
>
> All the +1 binding votes sent in the DISCUSS will be counted in the final
> tally unless the individual request otherwise.
>
> Here is the link to the VOTE in dev@ list:
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-twill-dev/201605.mbox/%3cCALuGr6ZB1DZVWZJNd+-ib0NXZwyWebSBE0evs0Yp8uthe+=o...@mail.gmail.com%3e
>
>
> Here is link to the VOTE result summary in the dev@list :
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-twill-dev/201605.mbox/%3cCALuGr6aSYs=daVpeeYO0GPKdfu=dkhvyhw12jdj66-dpzsq...@mail.gmail.com%3e
>
>
> The VOTE will run until June 6, 2016 4pm PST
>
> +1 [  ]
> 0 [  ]
> -1 [  ]
>
>
>
> Thanks,
>
> - Henry
> On behalf of Apache Twill PPMC
>
>
> PS:
>
> Here is my vote:
>
> +1 (binding)
>
>
>
>
> ## Resolution to create a TLP from graduating Incubator podling
>
>
> X. Establish the Apache Twill 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 a set of libraries as
> abstraction to develop
>
>distributed applications, with a programming model that is similar
> to
>
>running threads, inside compute cluster such as Apache Hadoop YARN
>
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>
>Committee (PMC), to be known as the "Apache Twill Project",
>
>be and hereby is established pursuant to Bylaws of the
>
>Foundation; and be it further
>
>
>RESOLVED, that the Apache Twill Project be and hereby is
>
>responsible for the creation and maintenance of software
>
>related to providing a set of libraries as abstraction to develop
>
>distributed applications, with a programming model that is similar
> to
>
>running threads, inside compute cluster such as Apache Hadoop YARN
>
>and be it further
>
>
>RESOLVED, that the office of "Vice President, Apache Twill" 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 Twill Project, and to have primary responsibility
>
>for management of the projects within the scope of
>
>responsibility of the Apache Twill 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 Twill Project:
>
>
>  * Terence Yim 
>
>  * Andreas Neumann 
>
>  * Gary Helmling 
>
>  * Albert Shau 
>
>  * Poorna Chandra 
>
>  * Henry Saputra 
>
>
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Terence Yim
>
>be appointed to the office of Vice President, Apache Twill, 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 Twill 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 Twill Project; and be it further
>
>
>RESOLVED, that the Apache Twill Project be and hereby
>
>is tasked with the migration and rationalization of the Apache
>
>Incubator Twill podling; and be it further
>
>
>RESOLVED, that all responsibilities pertaining to the Apache
>
>Incubator Twill podling encumbered upon the Apache Incubator
>
>Project are hereafter discharged.
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [DICSUSS] Graduation of Apache Twill as Top Level Project

[Andrew Purtell]

I'd vote +1. Twill has been doing just fine for a while. 


> On Jun 1, 2016, at 10:24 AM, Henry Saputra  wrote:
> 
> Hi All,
> 
> The Apache Twill PPMCs and the community had discussed and voted to
> graduate to become Apache TLP.
> 
> It is a small but welcoming community, and the mentors and rest of PPMCs
> believe that we have satisfied the learning phase during our incubation
> period.
> 
> The community has made several good releases and added new PPMC during its
> time in incubator [1]
> 
> It also has been used by external project such as Cask Data CDAP [2] and
> Apache Fluo [3]
> 
> The PPMCs also have made some presentations in conferences and meetups to
> be open and inclusive [4] [5]
> 
> 
> Here is the link to the VOTE:
> 
> http://mail-archives.apache.org/mod_mbox/incubator-twill-dev/201605.mbox/%3cCALuGr6ZB1DZVWZJNd+-ib0NXZwyWebSBE0evs0Yp8uthe+=o...@mail.gmail.com%3e
> 
> 
> Here is link to the VOTE result summary:
> 
> http://mail-archives.apache.org/mod_mbox/incubator-twill-dev/201605.mbox/%3cCALuGr6aSYs=daVpeeYO0GPKdfu=dkhvyhw12jdj66-dpzsq...@mail.gmail.com%3e
> 
> Thanks,
> 
> - Henry
> On behalf of Apache Twill PPMC
> 
> 
> [1] http://incubator.apache.org/projects/twill.html
> [2] http://cdap.io
> [3] https://wiki.apache.org/incubator/FluoProposal
> [4]
> http://apacheconnorthamerica2014.sched.org/event/1fhOZ6T/harnessing-the-power-of-yarn-with-apache-twill
> [5]
> http://apachebigdata2016.sched.org/event/6Lzt/building-large-scale-applications-in-apache-hadoop-yarn-with-apache-twill-henry-saputra-terence-yim-apache-software-foundation?iframe=no&w=&sidebar=yes&bg=no
> 
> ## Resolution to create a TLP from graduating Incubator podling
> 
> 
>X. Establish the Apache Twill 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 a set of libraries to provide
> abstraction
> 
>   to develop distributed applications such as with Apache Hadoop YARN.
> 
> 
>   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> 
>   Committee (PMC), to be known as the "Apache Twill Project",
> 
>   be and hereby is established pursuant to Bylaws of the
> 
>   Foundation; and be it further
> 
> 
>   RESOLVED, that the Apache Twill Project be and hereby is
> 
>   responsible for the creation and maintenance of software
> 
>   related to providing a set of libraries to provide abstraction
> to develop
> 
>   distributed applications such as with Apache Hadoop YARN
> 
>   and be it further
> 
> 
>   RESOLVED, that the office of "Vice President, Apache Twill" 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 Twill Project, and to have primary responsibility
> 
>   for management of the projects within the scope of
> 
>   responsibility of the Apache Twill 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 Twill Project:
> 
> 
> * Terence Yim 
> 
> * Andreas Neumann 
> 
> * Gary Helmling 
> 
> * Albert Shau 
> 
> * Poorna Chandra 
> 
> * Henry Saputra 
> 
> 
>   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Terence Yim
> 
>   be appointed to the office of Vice President, Apache Twill, 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 Twill 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 Twill Project; and be it further
> 
> 
>   RESOLVED, that the Apache Twill Project be and hereby
> 
>   is tasked with the migration and rationalization of the Apache
> 
>   Incubator Twill podling; and be it further
> 
> 
>   RESOLVED, that all responsibilities pertaining to the Apache
> 
>   Incubator Twill 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

[RESULT] [VOTE] Accept PredictionIO into the Apache Incubator

[Andrew Purtell]

​The ​
VOTE
​ to

​a
ccept PredictionIO into the Apache Incubator
​ has concluded and passed with 20 binding +1s, 8 non-binding +1s, and no 0
or -1 votes.

​Thanks to all who voted.

Binding +1s

Andrew Purtell
​Luciano Resende
James Taylor
Suneel Marthi
​Chris Nauroth
Roman Shaposhnik
Ted Dunning
Henry Saputra
​Drew Farris​
Jean-Baptiste Onofré
Uma Gangumalla
Sergio Fernández
John D. Ament
Ralph Goers
Seetharam Venkatesh
Hitesh Shah
Jake Farrell
Reynold Xin
Paul Fremantle
Bertrand Delacretaz

Nonbinding +1s

Ashish
Debo Dutta
Felix Cheung
Priyank Ashok Rastogi
Moon Soo Lee
Alexander Bezzubov
Tsuyoshi Ozawa
Sandeep Deshmukh

​No binding or nonbinding 0s

No binding or nonbinding -1s
​

--

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Accept Pony Mail into the Apache Incubator

[Andrew Purtell]

+1 (binding)


On Mon, May 23, 2016 at 10:56 PM, Daniel Gruno  wrote:

> Since it seems the discussion has died down, I am now calling a vote on
> accepting Pony Mail into the Incubator. Sorry in advance for potato.
>
> This vote will run for the usual 72 hours.
>
> ### PROPOSAL BELOW ###
>
> Abstract
>
> Pony Mail is a mail-archiving, archive viewing, and interaction service,
> that can be integrated with many email platforms.
>
> Proposal
>
> Background
>
> Pony Mail began as a response to two things; the lack of diversity in
> mailing list archives that are less bureaucratic all-or-nothing and more
> fluid way to interact with mailing lists than what is typically offered,
> and the lack of a performant system that solves this issue. Modern users
> of software want to jump right into a discussion they see, but cannot
> normally do so in a mailing list driven environment because of the rules
> generally surrounding said environment. Pony Mail, along with a select
> handful of newer archive systems, provides an interface that allows
> people to just hop into a thread, and take part. Without the need to
> subscribe, download the mbox archive, load it into your MTA, and respond.
>
> As Rich writes in a very short essay:
>
> You see a thread in which someone is WRONG ON THE INTERNET! You need to
> correct them. How do you do this today? You kinda don't. If you really
> wanted, you could download mbox files (and who the hell knows where they
> are?) and then try to get them into your mail client (which never works)
> and then reply to it. Which will break threading, because you did
> something wrong. Then you tear out your hair. PONY MAIL TO THE RESCUE!!!
> (sound of hoof beats)
>
> Rationale
>
> One of the oft-heard complaints about Apache's development model is that
> mailing lists are an old person's tool, and web-based communication -
> forums - are the way to go in the 21st Century. Providing a
> full-featured forum-like interface to mailing lists is one goal,while
> keeping all of the enormous benefits that mailing lists already provide.
> Asecond goal is to provide the ability to "jump in" to a mailing list
> conversation - even one that was a while back, without the convolutions
> that a mailing list requires. That is, to join this conversation the old
> way, one would have had to subscribe to the mailing list, download an
> mbox, and import it into ones mail client, in order that I be able to
> reply to this message with correct threading. With Pony Mail, one has to
> do none of those things, but can simply reply using the Web UI. To us,
> this is a HUGE benefit for building community. The requirement to jump
> through hoops to join a mailing list conversation drives away a lot of
> people (at least, anecdotally, it does) and if we can remove that
> barrier I think we'll have an easier time of drawing a new generation
> into our projects.
>
> Initial Goals
>
> The initial goals of transitioning to the ASF is to expand and grow both
> the Pony codebase and community, and ensure the project's continued
> growth and stability through forming a diverse and reliable community,
> in which the various facets of developers and contributors help keep the
> project up to date with latest developments and technical as well as
> social needs.
>
> Current Status
>
> Meritocracy:
>
> The bulk of the code has been written by Daniel Gruno to date, but has
> had oversight from other committers, and mentors.
>
> All members of the Pony project and wider community have a deep
> understanding and appreciation for the ASF meritocracy ideals, and are
> almost solely current ASF Members.
>
> Community:
> The community is currently heavily focused within the ASF, and
> more specifically the Infrastructure group. This is to be expected given
> the nature of how the code came into existence in the first place. It
> should be noted that we have started reaching out to other groups who we
> know are using mailing list systems and therefore also rely on mailing
> list archive interfaces.
>
> Core Developers:
>
> Almost all core developers are ASF members, and are already intimately
> familiar with the Apache Way.
>
> Alignment:
>
> Pony will be very in line with ASF practices and processes as many of
> the founding members are long term ASF members and committers.
>
> Known Risks
>
> Orphaned products:
>
> We are not aware of any issues with orphaned products related to this
> project.
>
> Pony Mail relies on a set of CSS3 templates as well as some very stable
> programming languages. We have no reason to believe these would
> be orphaned or, should they become orphaned, that it would impact the
> development of the project.
>
> Inexperience with Open Source:
> Most of the current committers are already ASF members and
> committers, we do not believe there to be any concerns around OSS
> inexperience.
>
> Homogenous Developers:
> W

[VOTE] Accept PredictionIO into the Apache Incubator

[Andrew Purtell]

. Salesforce is
committed to utilize and advance the PredictionIO code base and support
its user community.

Inexperience with Open Source

PredictionIO has existed as a healthy open source project for almost two
years and is the most starred Scala project on GitHub. All of the proposed
committers have contributed to ASF and Linux Foundation open source
projects. Several current committers on Apache projects and Apache Members
are involved in this proposal and intend to provide mentorship.

Homogeneous Developers

The initial list of committers includes developers from several
institutions, including Salesforce, ActionML, Channel4, USC as well as
unaffiliated developers.

Reliance on Salaried Developers

Like most open source projects, PredictionIO receives substantial support
from salaried developers. PredictionIO development is partially supported
by Salesforce.com, but there are many contributors from various other
companies, and an active mailing list composed of hundreds of users. We
will continue our efforts to ensure stewardship of the project to be
independent of salaried developers by meritocratically promoting those
contributors to committers.

Relationships with Other Apache Product

PredictionIO relies heavily on top level Apache projects such as Apache
Spark, HBase and Hadoop. However it brings a distinguished functionality,
rather than just an abstraction - Machine Learning in a plug-and-play
fashion.

Compared to Apache Mahout, which focuses on the development of a wide
variety of algorithms, PredictionIO offers a platform to manage the whole
machine learning workflow, including data collection, data preparation,
modeling, deployment and management of predictive services in production
environments.

An Excessive Fascination with the Apache Brand

PredictionIO is already a widely known open source project. This proposal
is not for the purpose of generating publicity. Rather, the primary
benefits to joining Apache are those outlined in the Rationale section.

Documentation

PredictionIO boasts rich and live documentation, included in the code repo
(docs/manual directory), is built with Middleman, and publicly hosted at
https://docs.prediction.io

Initial Source and Intellectual Property Submission Plan

Currently, the PredictionIO codebase is distributed under the Apache 2.0
License and hosted on GitHub: https://github.com/PredictionIO/PredictionIO

External Dependencies

PredictionIO has the following external dependencies:
 * Apache Hadoop 2.4.0 (optional, required only if YARN and HDFS are needed)
 * Apache Spark 1.3.0 for Hadoop 2.4
 * Java SE Development Kit 8
 * and one of the following sets:
   * PostgreSQL 9.1
 or
   * MySQL 5.1
 or
   * Apache HBase 0.98.6
   * Elasticsearch 1.4.0

Upon acceptance to the incubator, we would begin a thorough analysis of
all transitive dependencies to verify this information and introduce
license checking into the build and release process by integrating with
Apache RAT.

Cryptography

PredictionIO does not include cryptographic code. We utilize standard
JCE and JSSE APIs provided by the Java Runtime Environment.

Required Resources

We request that following resources be created for the project to use

Mailing lists

  predictionio-priv...@incubator.apache.org (with moderated subscriptions)
  predictionio-dev
  predictionio-user
  predictionio-commits

  We will migrate the existing PredictionIO mailing lists.

Git repository

  The PredictionIO team would like to use Git for source control, due to our
  current use of GitHub.

  git://git.apache.org/incubator-predictionio

Documentation

  https://predictionio.incubator.apache.org/docs/

JIRA instance

  PredictionIO currently uses the GitHub issue tracking system associated
  with its repository: https://github.com/PredictionIO/PredictionIO/issues.
  We will migrate to Apache JIRA.

  JIRA PREDICTIONIO
  https://issues.apache.org/jira/browse/PREDICTIONIO

Other Resources

  TravisCI for builds and test running.

  PredictionIO's documentation, included in the code repo (docs/manual
  directory), is built with Middleman and publicly hosted at
  https://docs.prediction.io

  A blog to drive adoption and excitement at https://blog.prediction.io

Initial Committers

  Pat Ferrell
  Tamas Jambor
  Justin Yip
  Xusen Yin
  Lee Moon Soo
  Donald Szeto
  Kenneth Chan
  Tom Chan
  Simon Chan
  Marco Vivero
  Matthew Tovbin
  Yevgeny Khodorkovsky
  Felipe Oliveira
  Vitaly Gordon
  Alex Merritt

Affiliations

  Pat Ferrell - ActionML
  Tamas Jambor - Channel4
  Justin Yip - independent
  Xusen Yin - USC
  Lee Moon Soo - NFLabs
  Donald Szeto - Salesforce
  Kenneth Chan - Salesforce
  Tom Chan - Salesforce
  Simon Chan - Salesforce
  Marco Vivero - Salesforce
  Matthew Tovbin - Salesforce
  Yevgeny Khodorkovsky - Salesforce
  Felipe Oliveira - Salesforce
  Vitaly Gordon - Salesforce
  Alex Merritt - ActionML

Sponsors

Champion

  Andrew Purtell 

Nominated Mentors

  Andrew Purtell 
  James Taylor 
  Lars Hof

Re: [VOTE] Release of Apache Tephra-0.8.0-incubating [rc1]

[Andrew Purtell]

This test failure looks like it could be a failure to set up the minicluster. 
If so, that can be a networking problem on Macs unless using a very recent 
version of the JDK, or any number of reasons really (minicluster is as complex 
as it sounds). Anyway, perhaps posting the complete test output from surefire 
to the project JIRA is in order? 


> On May 21, 2016, at 8:08 AM, James Taylor  wrote:
> 
> Thanks for the testing, John. It builds on my MacBook Pro:
> 
>OS X Version 10.11.4
>java version 1.7.0_80
> 
> What's your system look like?
> 
> On Sat, May 21, 2016 at 6:53 AM, John D. Ament 
> wrote:
> 
>> Hi,
>> 
>> I'm +0 for right now unless there's a way to make the code build and test
>> on a mac and I'm not sure what it is.  Ran mvn clean install from the root
>> and this is the eventual output:
>> 
>> Tests in error:
>> 
>>  TransactionAwareHTableTest.setupBeforeClass:164 » IO Shutting down
>> 
>>  TransactionAwareHTableTest.shutdownAfterClass:174 NullPointer
>> 
>> 
>> Tests run: 15, Failures: 0, Errors: 2, Skipped: 0
>> 
>> 
>>> On Fri, May 20, 2016 at 6:47 PM Poorna Chandra  wrote:
>>> 
>>> Hi all,
>>> 
>>> This is a call for a vote on releasing Apache Tephra 0.8.0-incubating,
>>> release candidate 1. This
>>> is the first release of Tephra.
>>> 
>>> Apache Tephra community has voted and approved the release.
>>> 
>>> Vote thread:
>> http://mail-archives.apache.org/mod_mbox/incubator-tephra-dev/201605.mbox/%3CCAC9o21R1x-m1%2BbaV3oK39RmPbf2pToBQrSGkfzBmWz%3Dp8Ez5JQ%40mail.gmail.com%3E
>>> 
>>> Result thread:
>> http://mail-archives.apache.org/mod_mbox/incubator-tephra-dev/201605.mbox/%3CCAC9o21TR5Ur4nu%2BxOoXB74vHSvRujtj1C6%2BsA2N75YQf4DXd8w%40mail.gmail.com%3E
>>> 
>>> The source tarball, including signatures, digests, etc. can be found at:
>> https://dist.apache.org/repos/dist/dev/incubator/tephra/0.8.0-incubating-rc1/src
>>> 
>>> The tag to be voted upon is v0.8.0-incubating:
>> https://git-wip-us.apache.org/repos/asf?p=incubator-tephra.git;a=shortlog;h=refs/tags/v0.8.0-incubating
>>> 
>>> The release hash is 0db528e3603393221472b89fa9bb30312cfd5470:
>> https://git-wip-us.apache.org/repos/asf?p=incubator-tephra.git;a=commit;h=0db528e3603393221472b89fa9bb30312cfd5470
>>> 
>>> The Nexus Staging URL:
>>> https://repository.apache.org/content/repositories/orgapachetephra-1001
>>> 
>>> Release artifacts are signed with the following key:
>>> http://pgp.mit.edu/pks/lookup?op=get&search=0x8EC4A2C60990A464
>>> 
>>> KEYS file available:
>>> https://dist.apache.org/repos/dist/dev/incubator/tephra/KEYS
>>> 
>>> For information about the contents of this release, see:
>> https://dist.apache.org/repos/dist/dev/incubator/tephra/0.8.0-incubating-rc1/CHANGES.txt
>>> 
>>> Please vote on releasing this package as Apache Tephra 0.8.0-incubating
>>> 
>>> The vote will be open for 72 hours.
>>> 
>>> [ ] +1 Release this package as Apache Tephra 0.8.0-incubating
>>> [ ] +0 no opinion
>>> [ ] -1 Do not release this package because ...
>>> 
>>> Thanks,
>>> Poorna.
>> 

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

Re: [DISCUSS] PredictionIO incubation proposal

[Andrew Purtell]

​​The proposal excludes the Template Gallery from inclusion in the initial
software grant and sets it up as an issue for the podling to tackle during
incubation.

"The PredictionIO community also maintains a​ ​Template Gallery, a place to
publish and download (free or proprietary) engine templates for different
types of machine learning applications, and is a complemental part of the
project. At this point we exclude the Template Gallery from the proposal,
as it has a separate set of contributors and we’re not familiar with an
Apache approved mechanism to maintain such a gallery.​"

I agree with the proposers that tracking down a large set of contributors
to get their ok for a consolidated grant would be onerous.



On Fri, May 20, 2016 at 9:14 AM, Pat Ferrel  wrote:

> +1 for the current committer list, but please, anyone interested get
> familiar, we will need more help soon!
>
> Also I’d like to bring up the template gallery again. Plugins may be
> problematic in other projects but pio does nothing of interest *without* a
> template. There are some examples in the core repo but...
>
> Questions:
> 1) can the gallery be transferred? This is just a listing of templates
> that may be maintained by external people and is the source from which they
> are downloaded by default.
> 2) which templates are proposed for the transfer? Didn’t see that spelled
> out beyond the included examples.
>
> On May 20, 2016, at 8:53 AM, Suneel Marthi  wrote:
>
> The current list is good to go and includes all (both present and former)
> PIO folks.
> I am fine with going for Voting with the present list.
>
> +1
>
> On Fri, May 20, 2016 at 11:47 AM, Andrew Purtell 
> wrote:
>
> > The current list of initial committers was that provided me by the
> > PredictionIO folks so I have every reason to believe they all have a
> stake
> > at entering incubation.
> >
> > It's totally fine with me if we stick to that list. I am just trying to
> > facilitate the fairest process possible.
> >
> >
> > On Friday, May 20, 2016, Roman Shaposhnik  wrote:
> >
> >> On Thu, May 19, 2016 at 9:16 PM, Suneel Marthi  >> > wrote:
> >>> I definitely have concerns about too many folks becoming initial
> >> committers
> >>> and bringing their own corporate agendas to this project.
> >>>
> >>> I suggest that first we vote PIO into incubator then bring in those
> > less
> >>> experienced with the project. We have a good start with people who have
> >>> worked on the project from several orgs. Let us get organized first and
> >>> then bring in new people.
> >>
> >> I think this is a reasonable concern. Andrew, any chance you can look
> > over
> >> the names of initial committers and let us know who has had a stake in
> > the
> >> project before entering the incubation vs. those who are trying to join
> > in
> >> as
> >> part of the ASF Incubation.
> >>
> >> I'm not saying we need to pass judgement one way or the other yet, but
> it
> >> will be a very useful data point to know before voting.
> >>
> >> Thanks,
> >> Roman.
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> 
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >> 
> >>
> >>
> >
> > --
> > Best regards,
> >
> >   - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [DISCUSS] PredictionIO incubation proposal

[Andrew Purtell]

The current list of initial committers was that provided me by the
PredictionIO folks so I have every reason to believe they all have a stake
at entering incubation.

It's totally fine with me if we stick to that list. I am just trying to
facilitate the fairest process possible.


On Friday, May 20, 2016, Roman Shaposhnik  wrote:

> On Thu, May 19, 2016 at 9:16 PM, Suneel Marthi  > wrote:
> > I definitely have concerns about too many folks becoming initial
> committers
> > and bringing their own corporate agendas to this project.
> >
> > I suggest that first we vote PIO into incubator then bring in those less
> > experienced with the project. We have a good start with people who have
> > worked on the project from several orgs. Let us get organized first and
> > then bring in new people.
>
> I think this is a reasonable concern. Andrew, any chance you can look over
> the names of initial committers and let us know who has had a stake in the
> project before entering the incubation vs. those who are trying to join in
> as
> part of the ASF Incubation.
>
> I'm not saying we need to pass judgement one way or the other yet, but it
> will be a very useful data point to know before voting.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>
>

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [DISCUSS] PredictionIO incubation proposal

[Andrew Purtell]

Hi Nick,

Unless there are any concerns or objections, I will add you and Mr.
Dusenberry to the proposal as initial committers tomorrow.

Everyone,

As it seems that discussion has died down I plan to start a VOTE thread on
this coming Monday.

Thank you for the comment and attention thus far.


On Tue, May 17, 2016 at 12:58 PM, Nick Pentreath 
wrote:

> Hi there
>
> I'm glad to see the proposal to incubate PredictionIO. In my previous life
> as a startup co-founder, I kept a close eye on the project, and it would be
> fantastic to see it become an Apache incubating project!
>
> The folks working on Apache Spark and Apache SystemML (incubating) here at
> IBM are excited about the possibilities for integrating PredictionIO and
> SystemML (Mike Dusenberry is a committer on that project), as well
> as further improving Spark integration (I'm a PMC member on that project).
>
> Mike and I, together with Luciano (who is a mentor on this proposal) would
> like to volunteer our services as initial committers, if that is agreeable.
>
> Kind regards
> Nick
> mln...@apache.org
>
>
>
> >
> > -- Forwarded message --
> > From: Andrew Purtell 
> > To: "general@incubator.apache.org" 
> > Cc:
> > Date: Fri, 13 May 2016 13:41:38 -0700
> > Subject: [DISCUSS] PredictionIO incubation proposal
> > Greetings,
> >
> > It is my pleasure to
> > ​ ​
> > propose the PredictionIO project for incubation at the Apache Software
> > Foundation.
> > ​ ​
> > PredictionIO is a
> > ​ popular​
> > open
> > ​ ​
> > source Machine Learning Server built on top of a state-of-the-art open
> > source stack, including several Apache technologies, that
> > ​ ​
> > enables developers to manage and deploy production-ready predictive
> > services for various kinds of machine learning tasks
> > ​, with more than 400 production deployments around the world and a
> growing
> > contributor community. ​
> >
> >
> > The text of the proposal is included below and is also available at
> > https://wiki.apache.org/incubator/PredictionIO
> >
> > Best regards,
> > Andrew Purtell
> >
> >
> > = PredictionIO Proposal =
> >
> > === Abstract ===
> > PredictionIO is an open source Machine Learning Server built on top of
> > state-of-the-art open source stack, that enables developers to manage and
> > deploy production-ready predictive services for various kinds of machine
> > learning tasks.
> >
> > === Proposal ===
> > The PredictionIO platform consists of the following components:
> >
> >  * PredictionIO framework - provides the machine learning stack for
> >  building, evaluating and deploying engines with machine learning
> >  algorithms. It uses Apache Spark for processing.
> >
> >  * Event Server - the machine learning analytics layer for unifying
> events
> >  from multiple platforms. It can use Apache HBase or any JDBC backends
> >  as its data store.
> >
> > The PredictionIO community also maintains a
> > ​ ​
> > Template Gallery, a place to
> > publish and download (free or proprietary) engine templates for different
> > types of machine learning applications, and is a complemental part of the
> > project. At this point we exclude the Template Gallery from the proposal,
> > as it has a separate set of contributors and we’re not familiar with an
> > Apache approved mechanism to maintain such a gallery.
> >
> > You can find the Template Gallery at https://templates.prediction.io/
> >
> > === Background ===
> > PredictionIO was started with a mission to democratize and bring machine
> > learning to the masses.
> >
> > Machine learning has traditionally been a luxury for big companies like
> > Google, Facebook, and Netflix. There are ML libraries and tools lying
> > around the internet but the effort of putting them all together as a
> > production-ready infrastructure is a very resource-intensive task that is
> > remotely reachable by individuals or small businesses.
> >
> > PredictionIO is a production-ready, full stack machine learning system
> that
> > allows organizations of any scale to quickly deploy machine learning
> > capabilities. It comes with official and community-contributed machine
> > learning engine templates that are easy to customize.
> >
> > === Rationale ===
> > As usage and number of contributors to PredictionIO has grown bigger and
> > more diverse, we have sought for an independent framework for the project
> > to keep thriving. We believe the A

Re: [DISCUSS] PredictionIO incubation proposal

[Andrew Purtell]

The process for transferring the rights to the name PredictionIO has
started at Salesforce. I'm optimistic but can't guarantee an outcome as I
am not empowered to make such a decision wearing any hat. I think we can
proceed with the proposal using the PredictionIO mark conditionally as the
desired podling name. Completing the transfer or finding another mark would
be the earliest activity the podling would undertake working through their
PODLINGNAMESEARCH ticket. Does that sound reasonable?


On Sun, May 15, 2016 at 6:29 PM, John D. Ament 
wrote:

> I just want to confirm, Salesforce plans to transfer the rights to the name
> "PredictionIO" to the ASF? Or is the podling expected to take a new name?
>
> John
>
> On Fri, May 13, 2016 at 4:42 PM Andrew Purtell 
> wrote:
>
> > Greetings,
> >
> > It is my pleasure to
> > ​ ​
> > propose the PredictionIO project for incubation at the Apache Software
> > Foundation.
> > ​ ​
> > PredictionIO is a
> > ​ popular​
> > open
> > ​ ​
> > source Machine Learning Server built on top of a state-of-the-art open
> > source stack, including several Apache technologies, that
> > ​ ​
> > enables developers to manage and deploy production-ready predictive
> > services for various kinds of machine learning tasks
> > ​, with more than 400 production deployments around the world and a
> growing
> > contributor community. ​
> >
> >
> > The text of the proposal is included below and is also available at
> > https://wiki.apache.org/incubator/PredictionIO
> >
> > Best regards,
> > Andrew Purtell
> >
> >
> > = PredictionIO Proposal =
> >
> > === Abstract ===
> > PredictionIO is an open source Machine Learning Server built on top of
> > state-of-the-art open source stack, that enables developers to manage and
> > deploy production-ready predictive services for various kinds of machine
> > learning tasks.
> >
> > === Proposal ===
> > The PredictionIO platform consists of the following components:
> >
> >  * PredictionIO framework - provides the machine learning stack for
> >  building, evaluating and deploying engines with machine learning
> >  algorithms. It uses Apache Spark for processing.
> >
> >  * Event Server - the machine learning analytics layer for unifying
> events
> >  from multiple platforms. It can use Apache HBase or any JDBC backends
> >  as its data store.
> >
> > The PredictionIO community also maintains a
> > ​ ​
> > Template Gallery, a place to
> > publish and download (free or proprietary) engine templates for different
> > types of machine learning applications, and is a complemental part of the
> > project. At this point we exclude the Template Gallery from the proposal,
> > as it has a separate set of contributors and we’re not familiar with an
> > Apache approved mechanism to maintain such a gallery.
> >
> > You can find the Template Gallery at https://templates.prediction.io/
> >
> > === Background ===
> > PredictionIO was started with a mission to democratize and bring machine
> > learning to the masses.
> >
> > Machine learning has traditionally been a luxury for big companies like
> > Google, Facebook, and Netflix. There are ML libraries and tools lying
> > around the internet but the effort of putting them all together as a
> > production-ready infrastructure is a very resource-intensive task that is
> > remotely reachable by individuals or small businesses.
> >
> > PredictionIO is a production-ready, full stack machine learning system
> that
> > allows organizations of any scale to quickly deploy machine learning
> > capabilities. It comes with official and community-contributed machine
> > learning engine templates that are easy to customize.
> >
> > === Rationale ===
> > As usage and number of contributors to PredictionIO has grown bigger and
> > more diverse, we have sought for an independent framework for the project
> > to keep thriving. We believe the Apache foundation is a great fit.
> Joining
> > Apache would ensure that tried and true processes and procedures are in
> > place for the growing number of organizations interested in contributing
> > to PredictionIO. PredictionIO is also a good fit for the Apache
> foundation.
> > PredictionIO was built on top of several Apache projects (HBase, Spark,
> > Hadoop). We are familiar with the Apache process and believe that the
> > democratic and meritocratic nature of the foundation aligns with the
> > project goals.
> >
> > === Initial Goals ===
&

Re: [DISCUSS] PredictionIO incubation proposal

[Andrew Purtell]

I am just waiting on an accept from Alex to be in the initial committers
list and will then update the proposal on the wiki.


On Mon, May 16, 2016 at 12:07 PM, Simon Chan  wrote:

> Yes, it includes everyone who previously contributed code from PredictionIO
> before the acquisition and still want to be involved in the project.
>
> We may have missed "Alex Merritt", going to add him to the list soon.
>
> Simon
>
>
> On Mon, May 16, 2016 at 11:58 AM, Suneel Marthi 
> wrote:
>
> > I do have a question about the proposed list of committers.
> >
> > Does the list also include all of those folks who were with PredictionIO
> > (and had contributed to the project) and then chose to leave when PIO was
> > acquired by Salesforce?
> >
> >
> >
> >
> > On Mon, May 16, 2016 at 1:13 PM, Jean-Baptiste Onofré 
> > wrote:
> >
> > > By the way, we have some discussion about integrating Zeppelin with
> Beam
> > ;)
> > >
> > > Regards
> > > JB
> > >
> > > On 05/15/2016 02:32 AM, Roman Shaposhnik wrote:
> > >
> > >> Super excited to see this proposal! This will finally allow us to have
> > >> an ASF managed
> > >> backend for next generation data-driven apps that I see emerging quite
> > >> rapidly.
> > >>
> > >> The proposal looks great to me (although I'd recommend calling Scala
> > >> as an implementation
> > >> language more prominently since it may attract additional developers
> > >> with affinity to it).
> > >>
> > >> I do have two questions about technology:
> > >> 1. do you think it would be possible to leverage Apache Beam
> > >> (incubating)
> > >> for abstracting away dependency on execution frameworks? My
> > >> understanding
> > >> is that PredictionIO currently only run on Spark.
> > >> 2. is there a potential integration with Apache Zeppelin possible?
> > >>
> > >> Thanks,
> > >> Roman.
> > >>
> > >> On Fri, May 13, 2016 at 1:41 PM, Andrew Purtell 
> > >> wrote:
> > >>
> > >>> Greetings,
> > >>>
> > >>> It is my pleasure to
> > >>>
> > >>> propose the PredictionIO project for incubation at the Apache
> Software
> > >>> Foundation.
> > >>>
> > >>> PredictionIO is a
> > >>> popular
> > >>> open
> > >>>
> > >>> source Machine Learning Server built on top of a state-of-the-art
> open
> > >>> source stack, including several Apache technologies, that
> > >>>
> > >>> enables developers to manage and deploy production-ready predictive
> > >>> services for various kinds of machine learning tasks
> > >>> , with more than 400 production deployments around the world and a
> > >>> growing
> > >>> contributor community.
> > >>>
> > >>>
> > >>> The text of the proposal is included below and is also available at
> > >>> https://wiki.apache.org/incubator/PredictionIO
> > >>>
> > >>> Best regards,
> > >>> Andrew Purtell
> > >>>
> > >>>
> > >>> = PredictionIO Proposal =
> > >>>
> > >>> === Abstract ===
> > >>> PredictionIO is an open source Machine Learning Server built on top
> of
> > >>> state-of-the-art open source stack, that enables developers to manage
> > and
> > >>> deploy production-ready predictive services for various kinds of
> > machine
> > >>> learning tasks.
> > >>>
> > >>> === Proposal ===
> > >>> The PredictionIO platform consists of the following components:
> > >>>
> > >>>   * PredictionIO framework - provides the machine learning stack for
> > >>>   building, evaluating and deploying engines with machine learning
> > >>>   algorithms. It uses Apache Spark for processing.
> > >>>
> > >>>   * Event Server - the machine learning analytics layer for unifying
> > >>> events
> > >>>   from multiple platforms. It can use Apache HBase or any JDBC
> backends
> > >>>   as its data store.
> > >>>
> > >>> The PredictionIO community also maintains a
> > >>>

Re: [DISCUSS] PredictionIO incubation proposal

[Andrew Purtell]

Yikes, apologies for the formatting. It looked fine in Gmail when I sent it 
alas. 

I must let the proposers respond to the technical questions but I think I can 
make the general observation that would-be contributors proposing and 
performing work on new and better Apache ecosystem integrations would be 
excellent for the health of the new podling and the ecosystem at large. 


> On May 14, 2016, at 5:32 PM, Roman Shaposhnik  wrote:
> 
> Super excited to see this proposal! This will finally allow us to have
> an ASF managed
> backend for next generation data-driven apps that I see emerging quite 
> rapidly.
> 
> The proposal looks great to me (although I'd recommend calling Scala
> as an implementation
> language more prominently since it may attract additional developers
> with affinity to it).
> 
> I do have two questions about technology:
>   1. do you think it would be possible to leverage Apache Beam (incubating)
>   for abstracting away dependency on execution frameworks? My 
> understanding
>   is that PredictionIO currently only run on Spark.
>   2. is there a potential integration with Apache Zeppelin possible?
> 
> Thanks,
> Roman.
> 
>> On Fri, May 13, 2016 at 1:41 PM, Andrew Purtell  wrote:
>> Greetings,
>> 
>> It is my pleasure to
>> 
>> propose the PredictionIO project for incubation at the Apache Software
>> Foundation.
>> 
>> PredictionIO is a
>> popular
>> open
>> 
>> source Machine Learning Server built on top of a state-of-the-art open
>> source stack, including several Apache technologies, that
>> 
>> enables developers to manage and deploy production-ready predictive
>> services for various kinds of machine learning tasks
>> , with more than 400 production deployments around the world and a growing
>> contributor community.
>> 
>> 
>> The text of the proposal is included below and is also available at
>> https://wiki.apache.org/incubator/PredictionIO
>> 
>> Best regards,
>> Andrew Purtell
>> 
>> 
>> = PredictionIO Proposal =
>> 
>> === Abstract ===
>> PredictionIO is an open source Machine Learning Server built on top of
>> state-of-the-art open source stack, that enables developers to manage and
>> deploy production-ready predictive services for various kinds of machine
>> learning tasks.
>> 
>> === Proposal ===
>> The PredictionIO platform consists of the following components:
>> 
>> * PredictionIO framework - provides the machine learning stack for
>> building, evaluating and deploying engines with machine learning
>> algorithms. It uses Apache Spark for processing.
>> 
>> * Event Server - the machine learning analytics layer for unifying events
>> from multiple platforms. It can use Apache HBase or any JDBC backends
>> as its data store.
>> 
>> The PredictionIO community also maintains a
>> 
>> Template Gallery, a place to
>> publish and download (free or proprietary) engine templates for different
>> types of machine learning applications, and is a complemental part of the
>> project. At this point we exclude the Template Gallery from the proposal,
>> as it has a separate set of contributors and we’re not familiar with an
>> Apache approved mechanism to maintain such a gallery.
>> 
>> You can find the Template Gallery at https://templates.prediction.io/
>> 
>> === Background ===
>> PredictionIO was started with a mission to democratize and bring machine
>> learning to the masses.
>> 
>> Machine learning has traditionally been a luxury for big companies like
>> Google, Facebook, and Netflix. There are ML libraries and tools lying
>> around the internet but the effort of putting them all together as a
>> production-ready infrastructure is a very resource-intensive task that is
>> remotely reachable by individuals or small businesses.
>> 
>> PredictionIO is a production-ready, full stack machine learning system that
>> allows organizations of any scale to quickly deploy machine learning
>> capabilities. It comes with official and community-contributed machine
>> learning engine templates that are easy to customize.
>> 
>> === Rationale ===
>> As usage and number of contributors to PredictionIO has grown bigger and
>> more diverse, we have sought for an independent framework for the project
>> to keep thriving. We believe the Apache foundation is a great fit. Joining
>> Apache would ensure that tried and true processes and procedures are in
>> place for the growing number of organizations interested in contributing
>> to PredictionI

[DISCUSS] PredictionIO incubation proposal

[Andrew Purtell]

Greetings,

It is my pleasure to
​ ​
propose the PredictionIO project for incubation at the Apache Software
Foundation.
​ ​
PredictionIO is a
​ popular​
open
​ ​
source Machine Learning Server built on top of a state-of-the-art open
source stack, including several Apache technologies, that
​ ​
enables developers to manage and deploy production-ready predictive
services for various kinds of machine learning tasks
​, with more than 400 production deployments around the world and a growing
contributor community. ​


The text of the proposal is included below and is also available at
https://wiki.apache.org/incubator/PredictionIO

Best regards,
Andrew Purtell


= PredictionIO Proposal =

=== Abstract ===
PredictionIO is an open source Machine Learning Server built on top of
state-of-the-art open source stack, that enables developers to manage and
deploy production-ready predictive services for various kinds of machine
learning tasks.

=== Proposal ===
The PredictionIO platform consists of the following components:

 * PredictionIO framework - provides the machine learning stack for
 building, evaluating and deploying engines with machine learning
 algorithms. It uses Apache Spark for processing.

 * Event Server - the machine learning analytics layer for unifying events
 from multiple platforms. It can use Apache HBase or any JDBC backends
 as its data store.

The PredictionIO community also maintains a
​ ​
Template Gallery, a place to
publish and download (free or proprietary) engine templates for different
types of machine learning applications, and is a complemental part of the
project. At this point we exclude the Template Gallery from the proposal,
as it has a separate set of contributors and we’re not familiar with an
Apache approved mechanism to maintain such a gallery.

You can find the Template Gallery at https://templates.prediction.io/

=== Background ===
PredictionIO was started with a mission to democratize and bring machine
learning to the masses.

Machine learning has traditionally been a luxury for big companies like
Google, Facebook, and Netflix. There are ML libraries and tools lying
around the internet but the effort of putting them all together as a
production-ready infrastructure is a very resource-intensive task that is
remotely reachable by individuals or small businesses.

PredictionIO is a production-ready, full stack machine learning system that
allows organizations of any scale to quickly deploy machine learning
capabilities. It comes with official and community-contributed machine
learning engine templates that are easy to customize.

=== Rationale ===
As usage and number of contributors to PredictionIO has grown bigger and
more diverse, we have sought for an independent framework for the project
to keep thriving. We believe the Apache foundation is a great fit. Joining
Apache would ensure that tried and true processes and procedures are in
place for the growing number of organizations interested in contributing
to PredictionIO. PredictionIO is also a good fit for the Apache foundation.
PredictionIO was built on top of several Apache projects (HBase, Spark,
Hadoop). We are familiar with the Apache process and believe that the
democratic and meritocratic nature of the foundation aligns with the
project goals.

=== Initial Goals ===
The initial milestones will be to move the existing codebase to Apache and
integrate with the Apache development process. Once this is accomplished,
we plan for incremental development and releases that follow the Apache
guidelines, as well as growing our developer and user communities.

=== Current Status ===
PredictionIO has undergone nine minor releases and many patches.
PredictionIO is being used in production by Salesforce.com as well as many
other organizations and apps. The PredictionIO codebase is currently
hosted at GitHub, which will form the basis of the Apache git repository.

 Meritocracy 
We plan to invest in supporting a meritocracy. We will discuss the
requirements in an open forum. We intend to invite additional developers
to participate. We will encourage and monitor community participation so
that privileges can be extended to those that contribute.

 Community 
Acceptance into the Apache foundation would bolster the already strong
user and developer community around PredictionIO. That community includes
many contributors from various other companies, and an active mailing list
composed of hundreds of users.

 Core Developers 
The core developers of our project are listed in our contributors and
initial PPMC below. Though many are employed at Salesforce.com, there are
also engineers from ActionML, and independent developers.

=== Alignment ===
The ASF is the natural choice to host the PredictionIO project as its goal
is democratizing Machine Learning by making it more easily accessible to
every user/developer. PredictionIO is built on top of several top level
Apache projects as outlined above.

=== Known Risks

Re: [VOTE] Accept Gossip into the Apache Incubator

[Andrew Purtell]

+1 (binding)

> On Apr 25, 2016, at 11:14 AM, P. Taylor Goetz  wrote:
> 
> Following the discussion thread [1], I would like to call a VOTE to accept 
> Gossip into the Apache Incubator.
> 
> The Gossip proposal can be found here [2] and is also listed below.
> 
> [ ] +1 Accept Gossip into the Apache Incubator
> [ ] +0 Abstain.
> [ ] -1 Do not accept Gossip into the Apache Incubator because…
> 
> This vote will be open for at least 72 hours.
> 
> Obviously I am +1 (binding).
> 
> -Taylor
> 
> [1] https://s.apache.org/gossip-discuss
> [2] https://wiki.apache.org/incubator/GossipProposal
> 
> 
> = Abstract =
> 
> Apache Gossip will be an implementation of the Gossip Protocol based on code 
> available here: https://github.com/edwardcapriolo/gossip/ which is already 
> licenced using the glorious Apache V2 License.
> 
> = Proposal =
> 
> Apache Gossip aims to provide a gossip based consensus protocol written in 
> Java for peer-to-peer communication to the Apache Incubator 
> (http://incubator.apache.org/). This implementation will effectively scale 
> from one to one-thousand node clusters. In addition to the code 
> implementation, the project should produce specifications of the wire 
> protocol, features, and expected behavior of the system such that compatible 
> implementations can communicate.
> 
> = Background =
> 
> The gossip protocol has been implemented to varying levels of rigor by a 
> number of entities. In particular, Apache Cassandra uses an implementation of 
> gossip to locate peers and transmit up/down state. Apache Spark leverages 
> tooling in Akka which provides peer-to-peer node discovery capabilities.
> 
>  * 
> http://highscalability.com/blog/2011/11/14/using-gossip-protocols-for-failure-detection-monitoring-mess.html
> 
>  * https://en.wikipedia.org/wiki/Gossip_protocol
> 
> = Rationale =
> 
> With distributed computing becoming extremely widespread, and the growth of 
> the buzz-factor of ‘the-internet-of-things’ it is increasingly important that 
> networks of IP addressable devices can form a peer-to-peer network. 
> Applications of peer-to-peer networks include generating crypto currency, 
> managing hardware such as solar power micro-grids, and more traditional roles 
> like grid/High Performance Computing and distributed storage systems. 
> Different implementations of gossip based consensus protocols have been 
> implemented in numerous languages or as part of more complex software stacks. 
> The Apache Software Foundation should lead the effort of producing a purpose 
> built tool that can be used by downstream projects to form peer-to-peer 
> networks.
> 
> = Initial Goals =
> 
>  * Migration of current code https://github.com/edwardcapriolo/gossip and 
> existing community to the Apache Software Foundation infrastructure
>  * Secure communications
>   * Transport security using a pre-shared key
>   * Public Key Infrastructure
>  * Introduce a cluster name to wire protocol to avoid misconfigurations
>  * Effectively operate when systems have multiple network interfaces by 
> controlling IP binding settings
>  * Effectively operate when systems have Network Address Translations devices 
> between them using a broadcast IP settings
>  * Develop advanced integration testing from cluster sizes of 1-1000 nodes
>   * Test convergence times
>   * Demonstrate the tradeoffs of different settings in regard to 
> bandwidth/cpu/convergence time/accuracy
>  * Gossip data other than cluster state such as application/user data
>  * Provide detailed specifications such that others can implement the 
> protocol in other programming languages
>  * Explore HTTP transport as an alternative to UDP
> 
> = Current Status =
> 
> The current code has been around for some time. Previously it was a Google 
> code project. Since the fork in January 2015 there have been 55 commits and 4 
> releases.
> 
> == Meritocracy ==
> 
> We believe in meritocracy. All suggestions are taken seriously. We enjoy 
> helping new people become part of process. For other projects available on 
> our Github, once a user shows enough activity we grant them collaborator 
> status.
> 
> == Community ==
> 
> In a relatively short amount of time, with a small amount of promotion on 
> twitter and through blogging, we have 50+ followers on Github and several 
> forks of the project. With the Apache brand we should be able to attract 
> more. Once we have entered the incubator we believe it will be easier to 
> attempt to unify with other similar implementations.
> 
> == Core Developers ==
> 
> The code was forked on Jan 9th 2015, since then there have been 4 releases 
> and 55 commits. Since that period, the majority of the work was undertaken by 
> Edward Capriolo. Several people are interested in the features of this 
> proposal and have indicated they will volunteer their time.
> 
> == Alignment ==
> 
> Apache is the perfect organization to take on the Gossip project. Besides 
> benefiting a number of pr

Re: Final draft of the Incubator Board Report - April 2016

[Andrew Purtell]

tion.
> > > >
> > > > How has the community developed since the last report?
> > > >
> > > >   While activity on the mailinglist has been pretty low, we've had a
> > > great
> > > >   meet-up in Amsterdam where a nice mix of existing MifosX community
> > > members
> > > >   and a group of new interested people was present. This has boosted
> > > >   interest in Fineract.
> > > >
> > > >   We have a high level of interest from new contributors throughout
> > > Africa -
> > > >   we are working to properly engage them and guide them to the
> correct
> > > >   collaboration channels in our Fineract community.
> > > >
> > > > How has the project developed since the last report?
> > > >
> > > >   Individual members of the leading partner organizations building
> > > solutions
> > > >   using the Fineract platform have begun to effectively use the
> > Fineract
> > > >   issue tracker to communicate and track the requirements and
> > > enhancements
> > > >   they're building and contributing to Fineract. These individuals
> are
> > > >   setting a good example that other individuals from our partner
> > > community
> > > >   should follow.
> > > >
> > > > Date of last release:
> > > >
> > > >   N/A
> > > >
> > > > When were the last committers or PMC members elected?
> > > >
> > > >   N/A
> > > >
> > > > Signed-off-by:
> > > >
> > > >   [ ](fineract) Ross Gardler
> > > >   [ ](fineract) Greg Stein
> > > >   [X](fineract) Roman Shaposhnik
> > >
> > > This report provides excellent insight into the challenges and
> > > opportunities
> > > before the Fineract community.  Thank you for a good read, and good
> luck!
> > >
> > > > 
> > > > FreeMarker
> > >
> > > > How has the project developed since the last report?
> > > >
> > > >   FreeMarker had two public releases: A Release Candidate (so that
> > users
> > > can
> > > >   test it), and one final release. Apart from the new features and
> > > fixes, we
> > > >   have adjusted the source code and build process to follow Apache
> best
> > > >   practices more closely, and to be more appealing for contributors
> > > >   (switching to Java 5, fixing formatting where it didn't fit the
> > modern
> > > >   Java conventions).
> > >
> > > Those sound like good ideas!  There really are a lot of ways to make a
> > > project
> > > easier to contribute to, but they can be hard to see when you're in the
> > > thick
> > > of it.
> > >
> > > > 
> > > > Gearpump
> > > >
> > > > Gearpump is a reactive real-time streaming engine based on the
> > > micro-service
> > > > Actor model.
> > > >
> > > > Gearpump has been incubating since 2016-03-08.
> > > >
> > > > Three most important issues to address in the move towards
> graduation:
> > > >
> > > >   1. Make initial Apache branded release
> > > >   2. Initial community process definition and practice enforcement by
> > > >  following Apache policies
> > > >   3. Build the first Apache branded informative website to make
> > Gearpump
> > > >  contributor and end-user friendly.
> > > >
> > > > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> > > > aware of?
> > > >
> > > >   The rights holder of the Gearpump copyright filed a CCLA including
> a
> > > >   Schedule B granting the Gearpump codebase to the Foundation. We are
> > > >   awaiting assistance from Infrastructure on INFRA-11435 to perform
> the
> > > >   import.
> > > >
> > > > How has the community developed since the last report?
> > > >
> > > >   All of the initial committers/PPMC have set up with Apache accounts
> > and
> > > >   Apache JIRA accounts.
> > > >
> > > >   Discussion among developers has started on
> > > >   d...@gearpump.incubator.apache.org
> > > >
> > > > How has the project developed since the last report?
> > > >
>

Re: [VOTE] Accept Omid into the Apache Incubator

[Andrew Purtell]

+1 (binding)

On Wed, Mar 23, 2016 at 3:31 PM, Daniel Dai  wrote:

> Following the discussion earlier, I'm calling a vote to accept Omid as
> a new Incubator project.
>
> [ ] +1 Accept Omid into the Incubator
> [ ] +0 Indifferent to the acceptance of Omid
> [ ] -1 Do not accept Omid because ...
>
> The vote will be open for the next 72 hours.
>
> https://wiki.apache.org/incubator/OmidProposal
>
> Thanks,
> Daniel
>
> = Omid Proposal =
>
> === Abstract ===
> Omid is a flexible, reliable, high performant and scalable ACID
> transactional framework that allows client applications to execute
> transactions on top of MVCC key/value-based NoSQL datastores
> (currently Apache HBase) providing Snapshot Isolation guarantees on
> the accessed data.
>
> === Proposal ===
> Omid is a flexible open-source transactional framework that provides
> ACID transactions with Snapshot Isolation guarantees on top of NoSQL
> datastores. In particular, the current codebase brings the concept of
> transactions to the popular Apache HBase datastore. Omid offers great
> performance, it is highly available, and scalable. Omid's current
> version is able to scale to thousands of clients triggering concurrent
> transactions on application data stored in HBase. Omid can scale
> beyond 100K transactions per second on mid-range hardware while
> incurring in a minimal impact on the speed of data access in the
> datastore. We’re currently experimenting with a prototype version that
> can improve the performance up to ~380K TPS.
>
> Omid has been publicly available as an open-source project in Github
> under Apache License Version 2.0 since 2011 [1]. During these years,
> it has generated certain interest in the open source community,
> especially since the public presentation of the first version in
> Hadoop Summit 2013 [2]. Currently the Github project has 241 Stars and
> 93 forks. Yahoo Inc. submits this proposal to the Apache Software
> Foundation with the aim to transfer the Omid project -including its
> source code and documentation- to Apache in order to start the build
> of a stable open source community around it.
>
> [1] https://github.com/yahoo/omid
> [2] Omid presentation at Hadoop Summit 2013:
>
> https://www.youtube.com/watch?v=Rhdmo9pVGgU&index=68&list=PLSAiKuajRe2luyqLU464Nxz4aQe7EPBus
>
> === Background ===
> An Omid prototype was first released as an open-source project back in
> 2011. Inspired by Google Percolator [1], it offered a lock-free
> approach to transactions in NoSQL datastores (See [2]). However,
> during these years, the design of Omid has evolved significantly.
> Whilst the current open-sourced version maintains many aspects of the
> original implementation, it is the result of a major redesign of the
> first prototype released in 2011.
>
> Omid has now a more decentralized design that does not sacrifice the
> consistency and performance of the original version. The current
> design also enables Omid to scale to thousands of clients executing
> transactions concurrently on application data stored in HBase.
> Internally, Omid still utilizes a lock-free approach to support
> multiple concurrent clients. Its design also relies on a centralized
> conflict detection component, the TSO, which now resolves in an
> efficient manner writeset collisions among concurrent transactions
> without having to piggyback commit information to the clients. Another
> important benefit of Omid is that it doesn't require any modification
> of the underlying key-value datastore, HBase in this case. Moreover,
> the recently added high availability algorithm allows to eliminate the
> single point of failure represented by the TSO in those system
> deployments requiring a higher degree of dependability. Last but not
> least, the provided user API is very simple, mimicking transaction
> managers in the relational world: begin, commit, rollback.
>
> Omid is used internally at Yahoo. Sieve, Yahoo’s web-scale content
> management platform powering some of next-generation search and
> personalization products is using Omid as a transaction manager in its
> processing pipeline. Sieve essentially acts as a huge processing hub
> between content feeds and serving systems. It provides an environment
> for highly customizable, real-time, streamed information processing,
> with typical discovery-to-service latencies of just a few seconds. In
> terms of scale and availability, Omid’s new design was largely driven
> by Sieve’s requirements.
>
> At Yahoo, we are also making an effort to disseminate the current
> status of the project through blog entries (See [3], [4] and [5]) and
> submissions to technical and academic conferences such as ATC 2016,
> Hadoop Summit 2016, HBaseConf 2016. Last but not least, Omid also
> appeared in a TechCrunch article in the last quarter of 2015 (See [6])
>
> [1] D. Peng and F. Dabek, Large-scale Incremental Processing Using
> Distributed Transactions and Notifications. USENIX Symposium on
> Operating Systems Design and 

Re: [DISCUSS] [PROPOSAL] Omid for Apache Incubator

[Andrew Purtell]

Apache Phoenix just released version 4.7.0 with big news: transactions support, 
using Tephra. There's some interest in a successful Tephra incubation beyond 
the podling already. That said, that new code in Phoenix can be made pluggable 
to support more than one transaction oracle. Omid might be able to provide 
workable integration to stand in for Tephra. Collaboration between or even a 
joining of the two communities could be good but even if not as a potential 
downstream consumer it's good to have options! (provided the number of 
alternatives is bounded with reason of course). I think it would be good to see 
Omid get in. I think an Omid podling would find interested collaborators in the 
Phoenix and HBase communities right away. 


> On Mar 19, 2016, at 12:20 PM, Henry Saputra  wrote:
> 
> Thanks for the great explanation, Flavio.
> 
> As many have mentioned before, it is definitely ok to have similar projects
> in ASF. We have prior acts before and I didn't expect incubator to reject
> good projects coming in.
> 
> My intention was to avoid split of resources where both projects have
> very similar goal and approach. But maybe both projects have different
> subtle differences that worthy to be done as independent effort.
> 
> Just being devil advocate a bit to see if potential to collaborate.
> 
> - Henry
> 
>> On Saturday, March 19, 2016, Flavio Junqueira  wrote:
>> 
>> I understand the concern, so let me try to offer some facts and see if we
>> can make progress from there.
>> 
>> Omid has been around for some time now, and its initial design appeared in
>> a couple of research papers that I actually co-authored. The architecture
>> is based on the idea of having a centralized transaction status oracle that
>> shares transaction status data with clients for scalability. The current
>> Omid project evolved out of that initial work and it is a much improved
>> version over that first iteration, with the improvements focusing on
>> scalability. It currently runs in production at scale at Yahoo! and there
>> is interest from other companies according to the proposal. There is a
>> series of blog posts about the experience in the project proposal.
>> 
>> Tephra has a very similar architecture. The description here says that it
>> has a transaction server, which sounds like the TSO in the original Omid
>> papers. I haven't spent enough time understanding the precise protocol they
>> use, but I must say that the protocol is very important for correctness and
>> scalability. Having two protocols with different properties could justify
>> the presence of two projects, but they both promise snapshot isolation so I
>> suspect they will be doing very similar things.
>> 
>> Overall, as I see it, it would be very unfair to reject the Omid proposal
>> on the basis that Tephra was incubated a couple of weeks ago. I'd much
>> rather see how the two communities evolve and have the mentors of the
>> projects fostering collaboration and possibly a merge of the two projects
>> before graduation. Why not think of a general transaction status oracle
>> with different protocol implementations assuming it makes sense? I wouldn't
>> like to see any of the two blocked upfront on the basis that they are in
>> the same space, though. We could postpone this decision until graduation
>> when we'll have more knowledge about the projects and the growth of the two
>> communities.
>> 
>> -Flavio
>> 
 On 18 Mar 2016, at 23:19, Henry Saputra >> > wrote:
>>> 
>>> I know Apache incubator does not play favorite but it is getting awkward
>>> that TWO transaction engine for HBase coming to incubator at the same
>> time.
>>> 
>>> As most people know, the other one is Tephra, that just coming to
>> incubator
>>> few weeks ago.
>>> 
>>> As member of IPMC, I would like to see Omid provide some more details
>>> comparisons about the difference that the project bring,  in term of
>>> approach and possible integrations with other ASF projects.
>>> 
>>> If possible, I would prefer to see Omid team work together with Tephra to
>>> work on working together to make one solid transaction engine for HBase
>> and
>>> later NoSQL databases.
>>> 
>>> 
>>> - Henry
>>> 
 On Thu, Mar 17, 2016 at 1:17 PM, Daniel Dai >> > wrote:
>>> 
 Hi,
 
 I would like to propose Omid as an Apache Incubator project:
 
 https://wiki.apache.org/incubator/OmidProposal
 
 I've posted posted the text of the proposal below:
 
 Thanks,
 Daniel
 
 = Omid Proposal =
 
 === Abstract ===
 
 Omid is a flexible, reliable, high performant and scalable ACID
 transactional framework that allows client applications to execute
 transactions on top of MVCC key/value-based NoSQL datastores
 (currently Apache HBase) providing Snapshot Isolation guarantees on
 the accessed data.
 
 
 === Proposal ===
 
 Omid is a flexible open-source transactional framework that provides
 ACID transac

[RESULT] [VOTE] Accept Gearpump into the Apache Incubator

[Andrew Purtell]

Greetings,

Thanks to all who voted! The vote has passed with the following tally:

+1 Binding (11 total)

Andrew Purtell
James Taylor
Reynold Xin
Jarek Jarcec Checo
Alan Cabrera
Jakob Homan
P. Taylor Goetz
Todd Lipcon
Ted Dunning
Jean-Baptiste Onofré
Flavio Junqueira

+1 Non-binding (8 total)

JiangAlan
Kai Zheng
Uma Gangumalla
Henri Yandell
Tsuyoshi Ozawa
Ramkrishna S. Vasudevan
Felix Cheung
Hao Chen

No 0 or -1 votes.

The champion and mentors will work to get the project bootstrapped shortly.


Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Accept Gearpump into the Apache Incubator

[Andrew Purtell]

Hi Henri,

I am tallying the vote and need to mark you as non binding because I don't
see you on the incubator PMC in SVN or via the phonebook (
http://people.apache.org/phonebook.html) yet.


On Wed, Mar 2, 2016 at 11:33 AM, Henri Yandell  wrote:

> +1 (should be binding by vote end :) ).
>
> On Tue, Mar 1, 2016 at 4:53 PM, Andrew Purtell 
> wrote:
>
> > Greetings,
> >
> > The discussion of the Gearpump proposal has concluded. Please vote to
> > accept Gearpump into the Apache Incubator. I will leave this vote open
> for
> > at least the next 72 hours and will aim to close it Monday the 7th of
> > March, 2016 at midnight PT. Gearpump is a flexible, efficient, and
> scalable
> > micro-service based real-time big data streaming engine. The text of the
> > proposal is included below and is also available at
> > https://wiki.apache.org/incubator/GearpumpProposal
> >
> > [ ] +1 Accept Gearpump as an Apache Incubator podling.
> > [ ] +0 Abstain.
> > [ ] -1 Don’t accept Gearpump as an Apache Incubator podling because ...
> >
> > Note that while votes from Incubator PMC members are binding, all are
> most
> > definitely welcome to vote!
> >
> > I am +1 (binding).
> >
> > Best regards,
> >
> >- Andy
> >
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Accept Tephra into the Apache Incubator

[Andrew Purtell]

+1 (binding)

> On Mar 3, 2016, at 5:29 PM, Poorna Chandra  wrote:
> 
> Hi All,
> 
> Tephra proposal was sent out for discussion last week. The proposal is
> available at https://wiki.apache.org/incubator/TephraProposal
> 
> Please vote to accept Tephra into the Apache Incubator. The vote will be
> open for the next 72 hours.
> 
> [ ] +1 Accept Tephra as an Apache Incubator podling.
> [ ] +0 Abstain.
> [ ] -1 Don’t accept Tephra as an Apache Incubator podling because ...
> 
> Thanks,
> Poorna.
> 
> --
> 
> = Abstract =
> 
> Tephra is a system for providing globally consistent transactions on
> top of Apache HBase and other storage engines.
> 
> = Proposal =
> 
> Tephra is a transaction engine for distributed data stores like Apache HBase.
> It provides ACID semantics for concurrent data operations that span over 
> region
> boundaries in HBase using Optimistic Concurrency Control.
> 
> = Background =
> 
> HBase provides strong consistency with row- or region-level ACID
> operations. However, it sacrifices cross-region and cross-table
> consistency in favor of scalability. This trade-off requires application
> developers to handle  the complexity of ensuring consistency when their
> modifications span region boundaries. By providing support for global
> transactions that span regions, tables, or multiple RPCs,
> Tephra simplifies application development on top of HBase, without a
> significant impact on performance or scalability for many workloads.
> 
> Tephra leverages HBase’s native data versioning to provide multi-versioned
> concurrency control (MVCC) for transactional reads and writes.
> With MVCC capability, each transaction sees its own consistent “snapshot” of
> data, providing snapshot isolation of concurrent transactions.
> MVCC along with conflict detection and handling enables Optimistic Concurrency
> Control.
> 
> Tephra consists of three main components:
> * Transaction Server – maintains global view of transaction state, assigns
>   new transaction IDs and performs conflict detection;
> * Transaction Client – coordinates start, commit, and rollback of
> transactions; and
> * Transaction Processor Coprocessor – applies filtering to the data read 
> (based
>   on a given transaction’s state) and cleans up any data from old
>   (no longer visible) transactions.
> 
> Although Tephra only supports HBase now, it can be extended to support
> transactions on any store that has multi-versioning and rollback
> support. The transactions
> can span over multiple stores and storage paradigms.
> 
> = Rationale =
> 
> Tephra has simple abstractions which can be used by an application to
> add transaction support over HBase. By abstracting away transaction
> handling using Tephra, the application is freed of
> transaction logic, and the application developer can focus on the use case.
> Also, Tephra can be extended to support transactions on data sources other
> than HBase.
> 
> By making Tephra an Apache open source project, we believe that there will
> be wider adoption and more opportunities for Tephra to be integrated
> into other Apache projects.
> 
> = Current Status =
> 
> Tephra was built at Cask Data Inc. initially as part of
> open-source framework Cask Data Application Platform (CDAP)
> [[http://cdap.io/]].
> It was later converted into an independent open source project with
> Apache 2.0 License [[https://github.com/caskdata/tephra]].
> 
> Tephra is used in CDAP as the transaction engine. As part of CDAP, Tephra
> has been deployed at multiple companies.
> 
> Apache Phoenix is using Tephra as transaction engine in the next release.
> 
> == Meritocracy ==
> 
> Our intent with this incubator proposal is to start building a diverse
> developer community around Tephra following the Apache meritocracy model.
> Since Tephra was initially developed in early 2013, we have had fast
> adoption and contributions within Cask Data. We are looking forward to
> new contributors. We wish to build a community based on Apache's
> meritocracy principles, working with those who contribute significantly to
> the project and welcoming them to be committers both during the incubation
> process and beyond.
> 
> == Community ==
> 
> Core developers of Tephra are at Cask Data. Recently the developer community
> has expanded to include folks from Apache Phoenix. We hope to extend our
> contributor base significantly and we will invite all who are interested
> in working on distributed transaction engine.
> 
> == Core Developers ==
> 
> A few engineers from Cask Data and outside have developed Tephra:
> Andreas Neumann, Terence Yim, Gary Helmling, Andrew Purtell and
> Poorna Ch

Re: [DISCUSS] Gearpump incubation proposal

[Andrew Purtell]

Hi Taylor,

I don't think it is too late to chime in even though I started a vote.
Sorry we passed each other.


On Tue, Mar 1, 2016 at 5:07 PM, P. Taylor Goetz  wrote:

> Two ships passing in the night. ;)
>
> My apologies for being late to comment.
>
> -Taylor
>
> > On Mar 1, 2016, at 7:41 PM, Andrew Purtell  wrote:
> >
> > It looks like discussion has wrapped up here so I will proceed shortly
> with
> > a VOTE thread.
> >
> >
> > On Fri, Feb 26, 2016 at 11:37 AM, Sean Zhong  wrote:
> >
> >> On Sat, Feb 27, 2016 at 12:56 AM, Sean Zhong 
> wrote:
> >>
> >>> sting this.
> >>>
> >>>
> >> If you want a direct look and feel of what it does, please see demo
> >> http://demo.gearpump.io (user: guest, password: guest)
> >>
> >> ;)
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> >   - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

[VOTE] Accept Gearpump into the Apache Incubator

[Andrew Purtell]

 Documentation 
https://gearpump.incubator.apache.org/docs/

 JIRA instance 
JIRA Gearpump (GEARPUMP)
https://issues.apache.org/jira/browse/gearpump

=== Initial Committers ===
* Xiang Zhong 

* Tianlun Zhang 

* Qian Xu 

* Huafeng Wang 

* Kam Kasravi 

* Weihua Jiang 

* Tomasz Targonski 

* Karol Brejna 

* Gang Wang 

* Mark Chmarny 

* Xinglang Wang 

* Lan Wang 

* Jianzhong Chen 

* Xuefu Zhang 

* Rui Li 

=== Affiliations ===
* Xiang Zhong –  Intel

* Tianlun Zhang –  Intel

* Qian Xu –  Intel

* Huafeng Wang –  Intel

* Kam Kasravi –  Intel

* Weihua Jiang –  Intel

* Tomasz Targonski – Intel

* Karol Brejna – Intel

* Mark Chmarny – Intel

* Gang Wang – Intel

* Mark Chmarny  – Intel

* Xinglang Wang  – Ebay

* Lan Wang – Huawei

* Jianzhong Chen – Cloudera

* Xuefu Zhang – Cloudera

* Rui Li  – Intel

=== Sponsors ===

 Champion 
Andrew Purtell 

 Nominated Mentors 
* Andrew Purtell 

* Jarek Jarcec Cecho 

* Todd Lipcon 

* Xuefu Zhang 

* Reynold Xin 

 Sponsoring Entity 
Apache Incubator PMC​

​

Re: [DISCUSS] Gearpump incubation proposal

[Andrew Purtell]

It looks like discussion has wrapped up here so I will proceed shortly with
a VOTE thread.


On Fri, Feb 26, 2016 at 11:37 AM, Sean Zhong  wrote:

> On Sat, Feb 27, 2016 at 12:56 AM, Sean Zhong  wrote:
>
> > sting this.
> >
> >
> If you want a direct look and feel of what it does, please see demo
> http://demo.gearpump.io (user: guest, password: guest)
>
> ;)
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Accept Mnemonic into the Apache Incubator

[Andrew Purtell]

) Local checkpoints
> b) Memory management for caching
> c) Persistent memory datasets input
> d) Non-Volatile RDD operations
> The best use case for Apache Spark™ computing is that the input data
> is stored in form of Mnemonic native storage to avoid caching its row
> data for iterative processing. Moreover, Spark applications can
> leverage Mnemonic to perform data transforming in persistent or
> non-persistent memory without SerDes.
> 
> For Apache™ Hadoop®, we are integrating HDFS Caching with Mnemonic
> instead of mmap. This will take advantage of persistent memory related
> features. We also plan to evaluate to integrate in Namenode Editlog,
> FSImage persistent data into Mnemonic persistent memory area.
> 
> For Apache HBase™, we are using Mnemonic for BucketCache and
> evaluating performance improvements.
> 
> We expect Mnemonic will be further developed and integrated into many
> Apache BigData projects and so on, to enhance memory management
> solutions for much improved performance and reliability.
> 
>  An Excessive Fascination with the Apache Brand 
> While we expect Apache brand helps to attract more contributors, our
> interests in starting this project is based on the factors mentioned
> in the Rationale section.
> 
> We would like Mnemonic to become an Apache project to further foster a
> healthy community of contributors and consumers in BigData technology
> R&D areas. Since Mnemonic can directly benefit many Apache projects
> and solves major performance problems, we expect the Apache Software
> Foundation to increase interaction with the larger community as well.
> 
> === Documentation ===
> The documentation is currently available at Intel and will be posted
> under: https://mnemonic.incubator.apache.org/docs
> 
> === Initial Source ===
> Initial source code is temporary hosted Github for general viewing:
> https://github.com/NonVolatileComputing/Mnemonic.git
> It will be moved to Apache http://git.apache.org/ after podling.
> 
> The initial Source is written in Java code (88%) and mixed with JNI C
> code (11%) and shell script (1%) for underlying native allocation
> libraries.
> 
> === Source and Intellectual Property Submission Plan ===
> As soon as Mnemonic is approved to join the Incubator, the source code
> will be transitioned via the Software Grant Agreement onto ASF
> infrastructure and in turn made available under the Apache License,
> version 2.0.
> 
> === External Dependencies ===
> The required external dependencies are all Apache licenses or other
> compatible Licenses
> Note: The runtime dependent licenses of Mnemonic are all declared as
> Apache 2.0, the GNU licensed components are used for Mnemonic build
> and deployment. The Mnemonic JNI libraries are built using the GNU
> tools.
> 
> maven and its plugins (http://maven.apache.org/ ) [Apache 2.0]
> JDK8 or OpenJDK 8 (http://java.com/) [Oracle or Openjdk JDK License]
> Nvml (http://pmem.io ) [optional] [Open Source]
> PMalloc (https://github.com/bigdata-memory/pmalloc ) [optional] [Apache 2.0]
> 
> Build and test dependencies:
> org.testng.testng v6.8.17  (http://testng.org) [Apache 2.0]
> org.flowcomputing.commons.commons-resgc v0.8.7 [Apache 2.0]
> org.flowcomputing.commons.commons-primitives v.0.6.0 [Apache 2.0]
> com.squareup.javapoet v1.3.1-SNAPSHOT [Apache 2.0]
> JDK8 or OpenJDK 8 (http://java.com/) [Oracle or Openjdk JDK License]
> 
> === Cryptography ===
> Project Mnemonic does not use cryptography itself, however, Hadoop
> projects use standard APIs and tools for SSH and SSL communication
> where necessary.
> 
> === Required Resources ===
> We request that following resources be created for the project to use
> 
>  Mailing lists 
> priv...@mnemonic.incubator.apache.org (moderated subscriptions)
> comm...@mnemonic.incubator.apache.org
> d...@mnemonic.incubator.apache.org
> 
>  Git repository 
> https://github.com/apache/incubator-mnemonic
> 
>  Documentation 
> https://mnemonic.incubator.apache.org/docs/
> 
>  JIRA instance 
> https://issues.apache.org/jira/browse/mnemonic
> 
> === Initial Committers ===
> * Gang (Gary) Wang (gang1 dot wang at intel dot com)
> 
> * Yanping Wang (yanping dot wang at intel dot com)
> 
> * Uma Maheswara Rao G (umamahesh at apache dot org)
> 
> * Kai Zheng (drankye at apache dot org)
> 
> * Rakesh Radhakrishnan Potty  (rakeshr at apache dot org)
> 
> * Sean Zhong  (seanzhong at apache dot org)
> 
> * Henry Saputra  (hsaputra at apache dot org)
> 
> * Hao Cheng (hao dot cheng at intel dot com)
> 
> === Additional Interested Contributors ===
> * Debo Dutta (dedutta at cisco dot com)
> 
> * Liang Chen (chenliang613 at Huawei dot com)
> 
> === Affiliations ===
> * Gang (Gary) Wang, Intel
> 
> * Yanping Wang, Intel
> 
> * Uma Maheswara Rao G, Intel
> 
> * Kai Zheng, Intel
> 
> * Rakesh Radhakrishnan Potty, Intel
> 
> * Sean Zhong, Intel
> 
> * Henry Saputra, Independent
> 
> * Hao Cheng, Intel
> 
> === Sponsors ===
>  Champion 
> Patrick Hunt
> 
>  Nominated Mentors 
> * Patrick Hunt  - Apache IPMC member
> 
> * Andrew Purtell  - Apache IPMC member
> 
> * James Taylor  - Apache IPMC member
> 
> * Henry Saputra  - Apache IPMC member
> 
>  Sponsoring Entity 
> Apache Incubator PMC
> 
> -
> 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

[DISCUSS] Gearpump incubation proposal

[Andrew Purtell]

 

* Tomasz Targonski 

* Karol Brejna 

* Gang Wang 

* Mark Chmarny 

* Xinglang Wang 

* Lan Wang 

* Jianzhong Chen 

* Xuefu Zhang 

* Rui Li 

=== Affiliations ===
* Xiang Zhong –  Intel

* Tianlun Zhang –  Intel

* Qian Xu –  Intel

* Huafeng Wang –  Intel

* Kam Kasravi –  Intel

* Weihua Jiang –  Intel

* Tomasz Targonski – Intel

* Karol Brejna – Intel

* Mark Chmarny – Intel

* Gang Wang – Intel

* Mark Chmarny  – Intel

* Xinglang Wang  – Ebay

* Lan Wang – Huawei

* Jianzhong Chen – Cloudera

* Xuefu Zhang – Cloudera

* Rui Li  – Intel

=== Sponsors ===

 Champion 
Andrew Purtell 

 Nominated Mentors 
* Andrew Purtell 

* Jarek Jarcec Cecho 

* Todd Lipcon 

* Xuefu Zhang 

* Reynold Xin 

 Sponsoring Entity 
Apache Incubator PMC

Re: interested in joining the IPMC

[Andrew Purtell]

We have had several people write in to general@ over the past few months with 
this type of request. In at least one case a request triggered a vote on the 
private list. We should update the incubator site with guidance on what is the 
best way to approach the IPMC if this isn't ideal. 


> On Dec 12, 2015, at 11:33 AM, Marvin Humphrey  wrote:
> 
>> On Sat, Dec 12, 2015 at 11:04 AM, James Taylor  
>> wrote:
>> Hello,
>> I'm the PMC Chair for Apache Phoenix and a PMC member of Apache Calcite,
>> both top level project and both of which I went through the incubation
>> process. Recently several projects interested in going through incubation
>> approached me to be a mentor, hence my interest in joining - so that I can
>> help guide them through this process. I understand that the process for non
>> ASF members is to initiate a vote on the private list. I'd appreciate it if
>> that could start at your earliest convenience.
>> 
>> Please let me know if I need to perform any further action before a vote is
>> started.
> 
> Hi James, thanks for your interest. For what it's worth, there's no
> reason you couldn't help out a podling without being a Mentor.  And
> the process for non-ASF-Members joining the Incubator PMC is actually
> the same as for any other Apache PMC -- someone earns merit and then
> is invited to join.
> 
> Regardless of what happens in this specific case, if people are going
> to initiate direct requests like this, I wish they would use the
> private list.  Every once in a while somebody who has not earned merit
> makes a request to join a PMC; it is awkward to rebuff such requests
> discreetly when the request is public.  Apache private lists are not
> supposed to be used a lot, but personnel discussions are one of the
> main reasons we have them.
> 
> 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: RTC vs CTR (was: Concerning Sentry...)

[Andrew Purtell]

And I challenge you to comb over all HBase mailing lists and JIRAs and find any 
instance where we were not the model of a meritocratic and consensus driven 
community, or any instance where a committer has ever been aggrieved by our 
practices, and especially where I as chair have tried to exert control. It's 
harder to impugn people's motives if there's at least a minimal evidentiary 
bar. 


> On Nov 25, 2015, at 12:39 PM, Greg Stein  wrote:
> 
> Boo hoo. Todd said it wasn't about control, and then a few days later said
> he was forcing people into doing reviews. So yeah: in his case, it *is*
> about control.
> 
> Over the 17 years I've been around Apache, every single time I've seen
> somebody attempt to justify something like RTC, it always goes back to
> control. Always.
> 
> -g
> 
> 
> On Wed, Nov 25, 2015 at 2:35 PM, Andrew Purtell 
> wrote:
> 
>> I have to completely disagree and find your assertion vaguely offensive.
>> 
>>> On Nov 25, 2015, at 12:32 PM, Greg Stein  wrote:
>>> 
>>> On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell 
>>> wrote:
>>>> ...
>>>> 
>>>> and inherited the RTC ethic from our parent community. I did recently
>> test
>>>> the state of consensus on RTC vs CTR there and it still holds. I think
>> this
>>>> model makes sense for HBase, which is a mature (read: complex) code base
>>>> that implements a distributed database. For sure we want multiple sets
>> of
>>> 
>>> I call bullshit. "complex" my ass. I've said it before: all software is
>>> complex, and yours is no more complex than another. That is NOT a
>> rationale
>>> for installing RTC. It is an excuse for maintaining undue control.
>>> 
>>> -g
>> 
>> -
>> 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: RTC vs CTR (was: Concerning Sentry...)

[Andrew Purtell]

I have to completely disagree and find your assertion vaguely offensive. 

> On Nov 25, 2015, at 12:32 PM, Greg Stein  wrote:
> 
> On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell 
> wrote:
>> ...
>> 
>> and inherited the RTC ethic from our parent community. I did recently test
>> the state of consensus on RTC vs CTR there and it still holds. I think this
>> model makes sense for HBase, which is a mature (read: complex) code base
>> that implements a distributed database. For sure we want multiple sets of
>> 
> 
> I call bullshit. "complex" my ass. I've said it before: all software is
> complex, and yours is no more complex than another. That is NOT a rationale
> for installing RTC. It is an excuse for maintaining undue control.
> 
> -g

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

Re: RTC vs CTR (was: Concerning Sentry...)

[Andrew Purtell]

Most of the Hadoop ecosystem uses RTC. I can't speak to other projects but
on the one I chair there's no conspiracy to exclude anyone.

I chair Bigtop. We recently tested a switch to CTR. It went very well and
so we just wrapped up a vote to make it the permanent state of affairs. I
think this is the best option for Bigtop, which has a small but active
group of committers each working in loosely coupled ways on different parts
of the tree. I also chair HBase. We were spun out of Hadoop direct to TLP
and inherited the RTC ethic from our parent community. I did recently test
the state of consensus on RTC vs CTR there and it still holds. I think this
model makes sense for HBase, which is a mature (read: complex) code base
that implements a distributed database. For sure we want multiple sets of
eyes on changes there. They can have unexpected consequences. Almost above
all, we want to do due diligence on not introducing bugs that lose user
data.

So, to each their own? Please.




On Sun, Nov 22, 2015 at 2:05 PM, Ralph Goers 
wrote:

> Yes, it would be good to take a survey.  Interestingly, I wasn’t aware
> that ANY Apache projects used RTC until I became involved with a project in
> the Hadoop ecosystem, which seems to align with Tood’s statement since all
> the projects he is listed as being involved in are part of that.  In fact,
> when I was mentoring the project I am familiar with I asked during
> incubation why they wanted to use RTC and was told that it was because that
> is the way all Hadoop related projects worked. Since most of the committers
> were paid to work on the project by their employer I also got the feeling
> that it aligned with that.
>
> Ralph
>
> > On Nov 22, 2015, at 1:18 PM, Konstantin Boudnik  wrote:
> >
> > On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
> >> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <
> elecha...@gmail.com>
> >> wrote:
> >>>
> >
>  Except that there seems to be great disagreement among the Members as
> to
>  whether RTC is somehow anti-Apache-Way.
> 
>  If you want to try to create an ASF-wide resolution that RTC doesn't
> >>> follow
>  the Apache Way, and get the board/membership to vote on it, go ahead,
> but
>  it confuses podlings who are new to the ASF when people espouse
> personal
>  opinions as if they are ASF rules.
> >>>
> >>> That is not the point.
> >>>
> >>>
> >>> The question is not to decide if C-T-R is The Apache Way over R-T-C.
> The
> >>> question is wether a project entering incubation with a selected R-T-C
> >>> mode is likely to exit incubation for the simple reason it will be very
> >>> hard for this project to grow its community due to this choice. It's
> >>> like starting a 100m race with a 20kb backpack on your shoulder...
> >>>
> >>
> >> If you have any statistics that show this to be the case, I'd be very
> >> interested. RTC is the norm in basically every Apache project I've been
> a
> >> part of, many of which have thriving communities and are generally
> regarded
> >> as successful software projects.
> >
> > Do you have any statistics on that, Todd? Would be very interesting to
> see,
> > indeed.
> >
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Accept Kudu into the Apache Incubator

[Andrew Purtell]

+1 (binding)

Good luck!


On Tue, Nov 24, 2015 at 11:32 AM, Todd Lipcon  wrote:

> Hi all,
>
> Discussion on the [DISCUSS] thread seems to have wound down, so I'd like to
> call a VOTE on acceptance of Kudu into the ASF Incubator. The proposal is
> pasted below and also available on the wiki at:
> https://wiki.apache.org/incubator/KuduProposal
>
> The proposal is unchanged since the original version, except for the
> addition of Carl Steinbach as a Mentor.
>
> Please cast your votes:
>
> [] +1, accept Kudu into the Incubator
> [] +/-0, positive/negative non-counted expression of feelings
> [] -1, do not accept Kudu into the incubator (please state reasoning)
>
> Given the US holiday this week, I imagine many folks are traveling or
> otherwise offline. So, let's run the vote for a full week rather than the
> traditional 72 hours. Unless the IPMC objects to the extended voting
> period, the vote will close on Tues, Dec 1st at noon PST.
>
> Thanks
> -Todd
> -
>
> = Kudu Proposal =
>
> == Abstract ==
>
> Kudu is a distributed columnar storage engine built for the Apache Hadoop
> ecosystem.
>
> == Proposal ==
>
> Kudu is an open source storage engine for structured data which supports
> low-latency random access together with efficient analytical access
> patterns. Kudu distributes data using horizontal partitioning and
> replicates each partition using Raft consensus, providing low
> mean-time-to-recovery and low tail latencies. Kudu is designed within the
> context of the Apache Hadoop ecosystem and supports many integrations with
> other data analytics projects both inside and outside of the Apache
> Software Foundation.
>
>
>
> We propose to incubate Kudu as a project of the Apache Software Foundation.
>
> == Background ==
>
> In recent years, explosive growth in the amount of data being generated and
> captured by enterprises has resulted in the rapid adoption of open source
> technology which is able to store massive data sets at scale and at low
> cost. In particular, the Apache Hadoop ecosystem has become a focal point
> for such “big data” workloads, because many traditional open source
> database systems have lagged in offering a scalable alternative.
>
>
>
> Structured storage in the Hadoop ecosystem has typically been achieved in
> two ways: for static data sets, data is typically stored on Apache HDFS
> using binary data formats such as Apache Avro or Apache Parquet. However,
> neither HDFS nor these formats has any provision for updating individual
> records, or for efficient random access. Mutable data sets are typically
> stored in semi-structured stores such as Apache HBase or Apache Cassandra.
> These systems allow for low-latency record-level reads and writes, but lag
> far behind the static file formats in terms of sequential read throughput
> for applications such as SQL-based analytics or machine learning.
>
>
>
> Kudu is a new storage system designed and implemented from the ground up to
> fill this gap between high-throughput sequential-access storage systems
> such as HDFS and low-latency random-access systems such as HBase or
> Cassandra. While these existing systems continue to hold advantages in some
> situations, Kudu offers a “happy medium” alternative that can dramatically
> simplify the architecture of many common workloads. In particular, Kudu
> offers a simple API for row-level inserts, updates, and deletes, while
> providing table scans at throughputs similar to Parquet, a commonly-used
> columnar format for static data.
>
>
>
> More information on Kudu can be found at the existing open source project
> website: http://getkudu.io and in particular in the Kudu white-paper PDF:
> http://getkudu.io/kudu.pdf from which the above was excerpted.
>
> == Rationale ==
>
> As described above, Kudu fills an important gap in the open source storage
> ecosystem. After our initial open source project release in September 2015,
> we have seen a great amount of interest across a diverse set of users and
> companies. We believe that, as a storage system, it is critical to build an
> equally diverse set of contributors in the development community. Our
> experiences as committers and PMC members on other Apache projects have
> taught us the value of diverse communities in ensuring both longevity and
> high quality for such foundational systems.
>
> == Initial Goals ==
>
>  * Move the existing codebase, website, documentation, and mailing lists to
> Apache-hosted infrastructure
>  * Work with the infrastructure team to implement and approve our code
> review, build, and testing workflows in the context of the ASF
>  * Incremental development and releases per Apache guidelines
>
> == Current Status ==
>
>  Releases 
>
> Kudu has undergone one public release, tagged here
> https://github.com/cloudera/kudu/tree/kudu0.5.0-release
>
> This initial release was not performed in the typical ASF fashion -- no
> source tarball was released, but rather only convenience binaries made
> availabl

Re: [VOTE] Accept S2Graph into Apache Incubation

[Andrew Purtell]

m/#!forum/s2graph
>
> == Initial Source ==
>
> The S2Graph codebase is currently hosted on Github:
> https://github.com/kakao/s2graph.
>
> === Source and Intellectual Property Submission Plan ===
>
> Currently, the S2Graph codebase is distributed under the Apache 2.0
> License.
>
> == External Dependencies ==
>
> Beyond relying on Apache HBase, S2Graph has the following external
> dependencies:
>  * Asynchbase (BSD)
>  * Play Framework (Apache 2.0 license)
>  * Scala (http://www.scala-lang.org/license.html)
>  * Spark (Apache 2.0 license)
>  * Kafka (Apache 2.0 license)
>
> == Required Resources ==
>
> === Mailing list ===
>
> We will migrate our mailing lists to the following:
>  * us...@s2graph.incubator.apache.org
>  * d...@s2graph.incubator.apache.org
>  * priv...@s2graph.incubator.apache.org
>  * comm...@s2graph.incubator.apache.org
>
> === Source control ===
>
> The S2Graph team would like to use Git for source code control, due to
> our current use of Git. We request a writeable Git repo for S2Graph,
> and mirroring to be set up to Github through INFRA.
>
> === Issue Tracking ===
>
> S2Graph currently uses the github issue tracking system associated
> with its github repo (https://github.com/kakao/s2graph/issues). We
> will migrate to the Apache JIRA
> (http://issues.apache.org/jira/browse/S2Graph).
>
> === Other Resources ===
>
>  * Jenkins/Hudson for builds and test running.
>  * Wiki for documentation purposes.
>  * Blog to improve project dissemination.
>
> == Initial Committers ==
>
>  * Doyung Yoon 
>  * Daewon Jeong 
>  * Jaesang Kim 
>  * Hwansung Yu 
>  * Min-Seok Kim 
>  * Chul Kang 
>  * Luke Han 
>  * Alexander Bezzubov 
>
> == Affiliations ==
>
>  * Doyung Yoon, Kakao
>  * Daewon Jeong, Kakao
>  * Jaesang Kim, Kakao
>  * Hwansung Yu, Kakao
>  * Min-Seok Kim, Kakao
>  * Chul Kang, Kakao,
>  * Luke Han, Ebay Inc.
>  * Alexander Bezzubov, NFLabs
>
> == Sponsors ==
>
> === Champion ===
> Hyunsik Choi
>
> === Nominated Mentors ===
>  * Andrew Purtell - Apache Member, Salesforce
>  * Sergio Fernández - Apache Member, Redlink
>  * Hyunsik Choi - Apache Member, Gruter Inc.
>  * Seetharam Venkatesh - IPMC, Hortonworks Inc.
>
> === Sponsoring Entity ===
>
>  * The Apache Incubator
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: RTC vs CTR (was: Concerning Sentry...)

[Andrew Purtell]

> After writing the above, I started to feel it was familiar and remember a 
> very similar discussion on hbase-dev last year:
http://mail-archives.apache.org/mod_mbox/hbase-dev/201508.mbox/%3CCA+RK=_dz+_rzumfwvya0tkvxtk4saeie6pwpgs2mxvsbq8h...@mail.gmail.com%3E
 - I'd recommend people go check that one out to see the various viewpoints.

That was a great discussion covering all manner of ideas, crazy or otherwise. 
Key is we brought the discussion out to a public forum and had a no drama 
floating of views and options with an aim to build consensus. 

That consensus on HBase was that RTC is preferred over the alternative, pretty 
much for the code quality reasons Todd discusses below. Any other project could 
come to a different consensus. I don't think we need to or should prescribe RTC 
or CTR up front. Each community should have this discussion and come to a 
rational consensus of what choice they should make for their particular needs. 


> On Nov 16, 2015, at 9:53 AM, Todd Lipcon  wrote:
> 
> [editing subject since the discussion has veered away from Sentry]
> 
> On Mon, Nov 16, 2015 at 7:56 AM, Ralph Goers 
> wrote:
> 
>> And I have to disagree with you Joe. To me, a mandatory RTC policy says
>> “we don’t trust anybody”. Sure, it doesn’t discriminate, but it is also a
>> PITA. One project I mentored uses RTC along with ReviewBoard and mandates
>> that you cannot commit your own work and every commit must be formally
>> reviewed. I have found this process to be so onerous that I have never
>> committed any code to the project, even though I really would like to.  I
>> find the pace of this project to be fairly slow.  But it seems to fit
>> within the corporate culture that most of the committers seem to work in.
>> 
>> OTOH, I am involved in a project that uses CTR but where feature branches
>> are frequently created to allow others to review and improve significant
>> new work before it is integrated. As a consequence, new features are
>> introduced at a much faster pace in this project.
> 
> I've seen this RTC vs CTR discussion come up a number of times over the
> last ~6 years that I've been involved in ASF projects. For every strong
> opinion in favor of CTR (like yours) there is a strong opinion in favor of
> RTC (like mine).
> 
> The quick summary of my viewpoint is:
> 
> 1) You're right, I don't trust anybody to make code changes to a complex
> project with zero oversight. I currently work on a project that I
> originally started, and was the only engineer on for a few months. Even
> when I make changes to code that I wrote 100% of the module, I get others
> to review my work, and you know what? It turns out better for it. Sometimes
> they find bugs. Often they find areas where I didn't comment the code well,
> design it as well as I could have, or missed potential performance
> optimizations.
> 
> Coding's hard. Coding on complex projects is even harder. Some projects
> aren't complex, and maybe on those a CTR policy makes a lot more sense. But
> distributed systems, database storage engines, etc, are pretty hard to get
> right, even for the "experts". I'm always glad to have a second pair of
> eyes before I introduce a bug that takes down critical infrastructure.
> 
> 2) Regardless of trust, code review helps build _shared ownership_ of code.
> In community projects, without code review, it's easy to end up with "pet
> features" or areas of code that only one person understands. When that
> person moves on to new employment or new interests, the project is stuck
> with a bunch of source code that no one understands how to maintain.
> Forcing the original author to get some reviews before committing ensures
> that there is a more likely path to project continuity after they move on
> to new pastures.
> 
> 3) Code reviews are a great way for engineers to learn from others in the
> community. Earlier in my career, I certainly learned a lot from the
> committers on projects like Hadoop and HBase where I "cut my teeth". And
> even as a long-time committer on these systems, I still learn new things
> from reviewing code written by newer members of the community. Review is
> where a lot of the cross-contributor interaction takes place, so it helps
> build a cohesive community.
> 
> Given #2 and #3, I see RTC as an extension of "community over code". Sure,
> it might slow down the introduction of a new feature or fix to have to wait
> to get a review from another community member. But, that's just code.
> Getting more eyes and hands on the code builds the community.
> 
> After writing the above, I started to feel it was familiar and remember a
> very similar discussion on hbase-dev last year:
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201508.mbox/%3CCA+RK=_dz+_rzumfwvya0tkvxtk4saeie6pwpgs2mxvsbq8h...@mail.gmail.com%3E
> - I'd recommend people go check that one out to see the various viewpoints.
> 
> I don't anticipate that the above arguments will convince you, or anyone
> else who believe

Re: Apache Metrics, Not Apache Humans

[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 healthiest version of Hadoop
>

Re: [DISCUSS] S2Graph Incubator Proposal

[Andrew Purtell]

If you are looking for mentors let me volunteer as one.

I think S2Graph has the potential to be a good addition to the Apache
family given its relationships and dependencies with other Apache projects
from the outset.



On Mon, Nov 9, 2015 at 10:54 AM, Hyunsik Choi  wrote:

> This project is looking for mentors. Anyone can help? We are also
> looking forward to any feedback.
>
> Also, I attached the proposal here. I forgot it.
>
> 
>
> = S2Graph Proposal =
>
> == Abstract ==
> S2Graph is a distributed and scalable OLTP graph database built on
> HBase to support fast traversal on extremely large graph.
>
> Here are additional materials to introduce S2Graph.
>  * HBaseCon 2015 - http://www.slideshare.net/HBaseCon/use-cases-session-5
>  * Apache: Big Data 2015 -
> http://schd.ws/hosted_files/apachebigdata2015/06/s2graph_apache_con.pdf
>
> == Proposal ==
> S2Graph is to provide a scalable distributed graph database engine
> over key/value storage such as HBase. S2Graph provide fully
> ashynchronous API to manupulate data as property graph model and fast
> breadth first search query on graph.
>
> == Background ==
> S2Graph initially started as an internal project at Kakao.com to
> efficiently store user relation and user activities as one large graph
> and provide unified query to traverse graph. It was open sourced on
> Github about a 3 months ago in June 2015.
>
> Over time S2Graph, together with HBase as storage tier, has begun to
> be adapted into various applications, such as messaging, social feeds,
> realtime recommendations at Kakao.
>
> Users can benefit from S2Graph`s generalized high level API instead of
> low-level key/value API for graph abstraction, just like Phoenix
> provide SQL layer over HBase.
>
> == Rationale ==
> Graph data(highly interconnected data) is very abundant and important
> these days.
> When users have a multitude of relationships, each with complex
> properties associated with them, graph model is more intuitive and
> efficient than tabular format(RDBMS).
> There are many ASF projects that provide SQL layer, but there is no
> ASF projects that provide scalable graph layer on existing hadoop echo
> system.
> When graph data grows to trillion edge scale, the process of
> traversing takes a long time and costly. However, with the benefit of
> HBase`s scalable architecture, S2Graph can traverse large graph in
> breadth first search manner efficiently.
>
> S2Graph also interoperates with several existing Apache
> projects(HBase, Spark) to provide way to merge real time events and
> batch processed data using property graph data model.
>
> Many developers are running their own domain specific API servers to
> serve their data products, but graph model is general and S2Graph API
> fully support traverse on graph, so it can be used as scalable general
> purpose API serving layer for various domains.
> As long as data can be modeled as graph, then users can avoid tedious
> work for developing customized API servers by using S2Graph.
>
> == Initial Goals ==
> The initial goals will be to move the existing codebase to Apache and
> integrate with the Apache development process. Once this is
> accomplished, we plan for incremental development and releases that
> follow the Apache guidelines.
>
> == Current Status ==
>
> === Meritocracy ===
> S2Graph operated on meritocratic principles from the get go.
> Currently, all the discussions pertaining to S2Graph development are
> public on Github. The current incubation
> proposal includes the major code contributors to S2Graph. Several
> additional people have worked on the S2graph codebase for industry use
> cases and would be interested in becoming committers. We are starting
> with a small committer group and we plan to add additional committers
> following an open merit-based decision process during the incubation
> phase.
>
> === Community ===
> We have already begun building a community but at this time the
> community consists only of S2Graph developers – all Kakao employees –
> and prospective users.
> S2Graph seeks to develop developer and user communities during incubation.
>
> === Core Developers ===
> S2Graph is currently being designed and developed by 2 engineers from
> Kakao. - Doyung Yoon, Deawon Jeong.
>
> === Alignment ===
> Our proposed S2Graph effort aligns closely with Apache HBase. The
> HBase project perimeter is denoted by a simple byte-array based
> Create, Read, Update, Delete and Scan APIs with no current plans to
> extend beyond this bounds.
>
> S2Graph complements this with a higher level API for property graph model.
>
> S2Graph was designed to offer scalable distributed graph database skin
> over HBase from the beginning in order to provide property graph model
> and breadth first search, and continue to focus on providing graph
> model.
>
> == Known Risks ==
> === Orphaned Products ===
> The core developers of S2Graph team plan to work full time on this
> project. There is very little risk of S2Gra

[Result][VOTE] Graduate Apache Kylin from the Apache Incubator

[Andrew Purtell]

Hi Luke,

By my count there was more than one binding -1 raised during the vote and I
don't think all were changed during subsequent discussion.  At a minimum
let's post a corrected RESULT, but I believe by ensuring the raised issues
are satisfactorily resolved and then starting another vote you can achieve
an unanimously positive outcome, if that is desirable (and of course it is
(smile)).


> On Oct 22, 2015, at 8:24 PM, Luke Han >
wrote:
>
> The vote for Apache Kylin to become a top-level project has passed
> with 27 +1 votes and no 0 or -1 votes.
>
> Thank you everyone for taking the time to review and cast your vote.
>
> We will now prepare a resolution for the next Board meeting.
>
> 10 binding:
> * Henry Saputra
> * Andrew Purtell
> * Bertrand Delacretaz
> * Julian Hyde
> * P. Taylor Goetz
> * Ted Dunning
> * Edward J. Yoon
> * Alexander Bezzubov
> * John D. Ament
> * Owen O'Malley
>
> 17 non-binding:
> * Luke Han
> * Shaofeng Shi
> * Jason Zhong
> * Qianhao Zhou
> * Dong Li
> * Droopy Hu
> * Xiaoyong Bai (lostitle)
> * Qi Liu (Goroutine)
> * Yerui Sun
> * Xu Jiang
> * Debashis Saha
> * Yang Li
> * Chad Chun
> * Atri Sharma
> * Hao Chen
> * Eddy Cai
> * Naresh Agarwal
>
> Luke
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org

> For additional commands, e-mail: general-h...@incubator.apache.org



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Graduate Apache Kylin from the Apache Incubator

[Andrew Purtell]

+1 (binding)

On Thu, Oct 15, 2015 at 4:59 PM, Luke Han  wrote:

> The Apache Kylin community and project made significant advances during the
> incubating (from Nov 2014) and
> believes it is ready to graduate as a top-level project.
>
> The Apache Kylin is very active. The PPMC doubled in size (added 6
> committers and 2 mentors) and
>  increased diversity in the past year. Released 3 version in the past 6
> months. There were presentations about Apache Kylin
> at most of the big conferences of the world (including Strata+Hadoop World
> London, Hadoop Summit San Jose,
> ApacheCon EU, Big Data Technology China, Database Technology Conference
> China) and some meetups (Bay Area,
> Beijing and one is coming in this weekend in Shanghai), and many talks
> around the world.
> The dev mailing list is growing very month, about 500+ topics per month
> now.
> The community created 1000+ JIRA tickets, many patches from
> contributors/committers have been merged into code base.
>
> A vote passed unanimously on the dev@ list (27 +1 votes). Please find
> below
> references to the graduation preparation artifacts:
> * discussion on dev list [1]
> * vote thread [2]
> * podling name search [3]
> * incubation status [4]
> * proposed resolution below
>
> We believe Apache Kylin is ready to become a top-level project and if the
> IPMC agree we will move to a formal vote.
> There are a few more items to be updated on the project status page and
> others during the next couple of days.
>
>
> Many thanks to the mentors and the IPMC for the support,
> Luke Han (on behalf of the Apache Kylin PPMC)
>
> [1] http://s.apache.org/KylinDisGraduate
> [2] http://s.apache.org/KylinGraduateVote
> [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
> [4] http://incubator.apache.org/projects/kylin.html
>
>
>
> Apache Kylin top-level project resolution:
> ===
>
>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, relative to distributed and scalable OLAP engine
>
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache Kylin Project",
>be and hereby is established pursuant to Bylaws of the
>Foundation; and be it further
>
>RESOLVED, that the Apache Kylin Project be and hereby is
>responsible for the creation and maintenance of open-source
>software related to distributed and scalable OLAP engine;
>and be it further
>
>RESOLVED, that the office of "Vice President, Kylin" 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 Kylin Project, and to have primary responsibility for
>management of the projects within the scope of responsibility
>of the Apache Kylin 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 Kylin Project:
>
> * Dayue Gao 
> * Jason Zhong 
> * Julian Hyde 
> * Luke Han 
> * Henry Saputra 
> * Hongbin Ma 
> * Hua Huang 
> * Owen O'Malley 
> * P. Taylor Goetz 
> * Qianhao Zhou 
> * Shaofeng Shi 
> * Song Yi 
> * Ted Dunning 
> * Xu Jiang 
> * Yang Li 
> * Yerui Sun < sunyerui at apache dot org>
>
>
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Luke Han
>be appointed to the office of Vice President,Apache Kylin, 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 Kylin Project be and hereby
>is tasked with the creation of a set of bylaws intended to
>encourage open development and increased participation in the
>Kylin Project; and be it further
>
>RESOLVED, that the initial Apache Kylin Project be and hereby
>is tasked with the migration and rationalization of the Apache
>Incubator Kylin podling; and be it further
>
>RESOLVED, that all responsibility pertaining to the Apache
>Incubator Kylin podling encumbered upon the Apache Incubator
>PMC are hereafter discharged.
>
>
> - - - end - - -
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: gene

Re: [DISCUSS] Mentor neutrality policy

[Andrew Purtell]

I would not have been able to mentor Phoenix should it have come along now.
At the time I was not employed by the originator of the project. Later I
chose to join them in part because they contributed the results of their
labor to Apache. My evaluation of how well a podling might be
functioning would not have been in any way different before or after I took
the job.


On Mon, Oct 12, 2015 at 10:13 AM, Ted Dunning  wrote:

> The practical effect on me of this requirement would be that
>
> a) I couldn't have mentored Drill
>
> b) I couldn't have mentored Zookeeper (assuming it were to come along now)
>
> c) I couldn't mentor Kylin (it affects Drill and MapR customers are
> considering using it)
>
> d) I couldn't mentor Calcite (same as Drill)
>
> e) I couldn't mentor Storm (MapR distributes it)
>
> f) I couldn't mentor Flink (I am co-writing a book that highlights it)
>
> g) I couldn't help with Zeppelin (our SE's use it for demos)
>
> h) I couldn't mentor Apex (MapR is a partner of DataTorrent)
>
> In fact, I can't think of any project that I have helped out that would be
> allowable under this policy.
>
> Take Julian Hyde and Taylor Goetz as additional examples.  They wouldn't be
> able to help on any of the projects they have been helping on.
>
> So I *could* mentor Corinthia. Or some of the projects that I had never
> heard of and couldn't care less about.
>
> Well, that doesn't work because I don't care about those projects and I am
> not going to waste my time.  I care about machine learning and big data and
> streaming and query languages. That is what drives my choice of work and
> what drives my choice of open source projects to contribute to. It also
> leads me to advocate for adoption of those projects at work and for driving
> some of the work I do into open source.
>
>
>
> On Sat, Oct 10, 2015 at 7:49 AM, Mattmann, Chris A (3980) <
> chris.a.mattm...@jpl.nasa.gov> wrote:
>
> > So here’s my elaboration.
> >
> > The proposal below would have prevented me from ever helping
> > projects to the ASF and convincing them that it may be a good
> > home for them. I’ve always had financial ties to a project’s
> > Incubation status. In many cases, projects being at the ASF,
> > and my involvement in them has assisted my mission of doing
> > scientific research and helping win proposals and so forth for
> > NASA and other agencies.
> >
> > Further, I’ve many times been at the same institution in which
> > the project has originated from before the ASF.
> >
> > I think I’ve done a good job on the projects I’ve helped to
> > bring here and they have been successful too and have overall
> > benefitted the ASF.
> >
> > This rings to me very similar to Roy’s email circa 2012 I believe
> > in which in the Incubator we tried to force the diversity requirement
> > as a graduation requirement, and Roy succinctly explained that we
> > can’t punish e.g., a podling for having people all from the same
> > institution. That would punish that institution for hiring folks
> > for open source who work on code at the ASF. Diversity is always
> > a strong property of a podling as I feel it makes it more resilient
> > but it’s not a hard requirement. I feel the same thing in this thread.
> >
> > Cheers,
> > Chris
> >
> > ++
> > Chris Mattmann, Ph.D.
> > Chief Architect
> > Instrument Software and Science Data Systems Section (398)
> > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > Office: 168-519, Mailstop: 168-527
> > Email: chris.a.mattm...@nasa.gov
> > WWW:  http://sunset.usc.edu/~mattmann/
> > ++
> > Adjunct Associate Professor, Computer Science Department
> > University of Southern California, Los Angeles, CA 90089 USA
> > ++
> >
> >
> >
> >
> >
> > -Original Message-
> > From: jpluser 
> > Reply-To: "general@incubator.apache.org" 
> > Date: Friday, October 9, 2015 at 5:14 PM
> > To: "general@incubator.apache.org" 
> > Subject: Re: [DISCUSS] Mentor neutrality policy
> >
> > >I do not agree with this proposal I will elaborate more later
> > >
> > >Sent from my iPhone
> > >
> > >> 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 th

Re: [DISCUSS] Graduate Kylin from the Apache Incubator

[Andrew Purtell]

Agreed, it would be good to have this clarification. The vote is likely to
proceed more smoothly.

I'm in favor of graduation. I've been lurking over the past few months and
the podling has been functioning well.


On Fri, Oct 9, 2015 at 3:05 PM, Pierre Smits  wrote:

> Maybe the podling should then elaborate on their choice of having it in the
> request proposal, before it comes to a vote and it is still in.
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Fri, Oct 9, 2015 at 11:47 PM, P. Taylor Goetz 
> wrote:
>
> > Exactly my point. If it's intentional, leave it in, otherwise consider
> > taking it out.
> >
> > As a (very recent) mentor, I see no indication that the Kylin community
> > has plans to deviate.
> >
> > Background: When Storm was incubating I thought that creating bylaws was
> > required, and we did so, for better or worse. In retrospect, I probably
> > would have stuck with the defaults.
> >
> > -Taylor
> >
> > > On Oct 9, 2015, at 5:22 PM, Pierre Smits 
> wrote:
> > >
> > > Maybe the podling has a valid reason behind that choice. So let us not
> > > chuck that out of the window because of other podlings not paying
> > attention
> > > to what they did.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *OFBiz Extensions Marketplace*
> > > http://oem.ofbizci.net/oci-2/
> > >
> > >> On Fri, Oct 9, 2015 at 10:42 PM, P. Taylor Goetz 
> > wrote:
> > >>
> > >> I agree.
> > >>
> > >> It’s also worth discussing whether the “tasked with the creation of a
> > set
> > >> of bylaws” section of the proposal is really needed.
> > >>
> > >> My understanding is that that section is not actually necessary, and
> has
> > >> proliferated among projects largely due to copying/pasting of other
> > >> graduation proposals. I believe it is only necessary if a project
> plans
> > to
> > >> deviate from the ASF standard ASF practices.
> > >>
> > >> Just something to consider.
> > >>
> > >> -Taylor
> > >>
> > >>> On Oct 9, 2015, at 3:53 PM, Julian Hyde  wrote:
> > >>>
> > >>> I am a mentor of Kylin and I believe the project is ready to
> graduate.
> > >>> They have created a vibrant, open community and are conducting
> > >>> business in the Apache Way.
> > >>>
> > >>> One proviso: Let's complete the name search before starting the IPMC
> > >>> vote. It would be foolish to let that particular cart get in front of
> > >>> the horse. I don't think that prevents us from discussing graduation.
> > >>>
> > >>> Julian
> > >>>
> > >>>
> >  On Fri, Oct 9, 2015 at 10:44 AM, Samant, Medha 
> > wrote:
> >  +1
> > 
> > > On 10/9/15, 10:13 AM, "Adunuthula, Seshu" 
> > wrote:
> > >
> > > +1
> > >
> > >> On 10/7/15, 8:32 AM, "John D. Ament" 
> wrote:
> > >>
> > >> I would be happy to see kylin graduate.
> > >>> On Oct 7, 2015 11:28, "Luke Han"  wrote:
> > >>>
> > >>> The Kylin community and project made significant advances during
> > the
> > >>> incubating (from Nov 2014) and
> > >>> believes it is ready to graduate as a top-level project.
> > >>>
> > >>> The Apache Kylin is very active. The PPMC doubled in size (added
> 6
> > >>> committers and 2 mentors) and
> > >>> increased diversity in the past year. Released 3 version in the
> > past
> > >> 6
> > >>> months. There were presentations about Kylin
> > >>> at most of the big conferences of the world (including
> > Strata+Hadoop
> > >>> World
> > >>> London, Hadoop Summit San Jose,
> > >>> ApacheCon EU, Big Data Technology China, Database Technology
> > >> Conference
> > >>> China) and some meetups (Bay Area,
> > >>> Beijing and one is coming in this weekend in Shanghai), and many
> > >> talks
> > >>> around the world.
> > >>> The dev mailing list is growing very month, about 500+ topics per
> > >> month
> > >>> now.
> > >>> The community created 1000+ JIRA tickets, many patches from
> > >>> contributors/committers have been merged into code base.
> > >>>
> > >>> A vote passed unanimously on the dev@ list (27 +1 votes). Please
> > >> find
> > >>> below
> > >>> references to the graduation preparation artifacts:
> > >>> * discussion on dev list [1]
> > >>> * vote thread [2]
> > >>> * podling name search (still in progress) [3]
> > >>> * incubation status [4]
> > >>> * proposed resolution below
> > >>>
> > >>> We believe Apache Kylin is ready to become a top-level project
> and
> > if
> > >>> the
> > >>> IPMC agree we will move to a formal vote.
> > >>> There are a few more items to be updated on the project status
> page
> > >> and
> > >>> others during the next couple of days.
> > >>>
> > >>>
> > >>> Many thanks to the mentors and the IPMC for the support,
> > >>> Luke Han (on behalf of the Apache Kylin PPMC)
> > >>>
> > >>> [1] http://s.apache.org/KylinDisGraduate
> > >>> [2] http://s.apache.org/Kyli

Re: [DISCUSS] Mentor neutrality policy

[Andrew Purtell]

Big +1

If you don't mind a personal anecdote, in fact at work I was recently
pointedly asked how the pay is over at the Foundation. (Smile)


On Saturday, October 10, 2015, Patrick Hunt  wrote:

> 10x to what Chris said, put much better than I could.
>
> We all wear multiple hats, can't tell you the number of times I've worn my
> Apache hat in the office, in some cases to my own detriment there. If I
> weren't associated with the project at Apache that representation would be
> missing. So really it cuts both ways.
>
> Patrick
>
>
> On Sat, Oct 10, 2015 at 7:49 AM, Mattmann, Chris A (3980) <
> chris.a.mattm...@jpl.nasa.gov > wrote:
>
> > So here’s my elaboration.
> >
> > The proposal below would have prevented me from ever helping
> > projects to the ASF and convincing them that it may be a good
> > home for them. I’ve always had financial ties to a project’s
> > Incubation status. In many cases, projects being at the ASF,
> > and my involvement in them has assisted my mission of doing
> > scientific research and helping win proposals and so forth for
> > NASA and other agencies.
> >
> > Further, I’ve many times been at the same institution in which
> > the project has originated from before the ASF.
> >
> > I think I’ve done a good job on the projects I’ve helped to
> > bring here and they have been successful too and have overall
> > benefitted the ASF.
> >
> > This rings to me very similar to Roy’s email circa 2012 I believe
> > in which in the Incubator we tried to force the diversity requirement
> > as a graduation requirement, and Roy succinctly explained that we
> > can’t punish e.g., a podling for having people all from the same
> > institution. That would punish that institution for hiring folks
> > for open source who work on code at the ASF. Diversity is always
> > a strong property of a podling as I feel it makes it more resilient
> > but it’s not a hard requirement. I feel the same thing in this thread.
> >
> > Cheers,
> > Chris
> >
> > ++
> > Chris Mattmann, Ph.D.
> > Chief Architect
> > Instrument Software and Science Data Systems Section (398)
> > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > Office: 168-519, Mailstop: 168-527
> > Email: chris.a.mattm...@nasa.gov 
> > WWW:  http://sunset.usc.edu/~mattmann/
> > ++
> > Adjunct Associate Professor, Computer Science Department
> > University of Southern California, Los Angeles, CA 90089 USA
> > ++
> >
> >
> >
> >
> >
> > -Original Message-
> > From: jpluser >
> > Reply-To: "general@incubator.apache.org " <
> general@incubator.apache.org >
> > Date: Friday, October 9, 2015 at 5:14 PM
> > To: "general@incubator.apache.org " <
> general@incubator.apache.org >
> > Subject: Re: [DISCUSS] Mentor neutrality policy
> >
> > >I do not agree with this proposal I will elaborate more later
> > >
> > >Sent from my iPhone
> > >
> > >> 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...@incub

Re: [DISCUSS] Mentor neutrality policy

[Andrew Purtell]

We should address perceived, and certainly provable, instances of
corruption at the Foundation directly, rather than prescribe policy that
seeks to prevent future instances as if there is a precedent (but there
isn't one here... at least one not spoken aloud, right?).

> A mentor must not be financially tied to the project or its incubation
status.

Aside from deviating greatly from treating mentors and all other persons as
individuals, for verification purposes this would require a level of
intrusive financial reporting that we don't remotely approach today and to
which most members would probably object.

> A mentor must not have a vested interest in incubating, graduating or
dismantling a podling that goes beyond the general Apache mission

None of this is well defined.

> If you are a in the original community behind the project, you cannot
mentor it nor vote for/against it.

​This diminishes the pool of available mentors and in particular those
probably most vested in the success of the podling.​




On Fri, 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
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Graduate Calcite from the Apache Incubator

[Andrew Purtell]

+1 (binding)

Good luck!


On Mon, Sep 14, 2015 at 6:56 PM, Julian Hyde  wrote:

> This is a vote for Calcite to become a top-level project.
>
> Since joining the Incubator in May, 2014, the Calcite
> community has:
> * Produced eight IPMC-approved releases under two release
>   managers;
> * Added five new committers and one new PPMC member;
> * Collaborated successfully with several other Apache
> projects (Drill, Hive, Kylin, Phoenix, Samza);
> * Grown into an active community (typical monthly activity
>   is 100 emails, 30 commits and 20 issues fixed);
> * Conducted a successful community vote to graduate with
>   20 +1 votes, of which 2 were from our mentors, 12 were
>   from committers, and 6 were from IPMC members.
>
> Further information: the discussion on the dev list [1],
> vote thread [2] and result [3]. Also relevant are the
> incubation status page [4] and a thread on this list
> requesting review of whether Calcite met the criteria to
> graduate [5].
>
> Below is our proposed resolution for the Board.
>
> Please vote:
>
> [ ] +1 Graduate Apache Calcite as a top-level project
> [ ] +0
> [ ] -1 Do not graduate Apache Calcite because…
>
> Here is my vote:
> +1 (binding)
>
> Voting will last 72 hours, ending at 19:00 Pacific on
> September 17th.
>
> Julian Hyde, on behalf of Calcite PPMC
>
> [1] http://s.apache.org/ZPC
> [2] http://s.apache.org/rvB
> [3] http://s.apache.org/sv
> [4] http://incubator.apache.org/projects/calcite.html
> [5] http://s.apache.org/itP
>
> - - - snip - - -
>
> 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 parsing and planning queries on data in a
> wide variety of formats.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Calcite
> Project", be and hereby is established pursuant to Bylaws of
> the Foundation; and be it further
>
> RESOLVED, that the Apache Calcite Project be and hereby is
> responsible for the creation and maintenance of software
> related to parsing and planning queries on data in a wide
> variety of formats; and be it further
>
> RESOLVED, that the office of "Vice President, Apache
> Calcite" 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 Calcite Project, and to have
> primary responsibility for management of the projects within
> the scope of responsibility of the Apache Calcite 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 Calcite Project:
>
> * Alan Gates 
> * Aman Sinha 
> * Ashutosh Chauhan 
> * James R. Taylor 
> * Jacques Nadeau 
> * Jesús Camacho Rodríguez 
> * Jinfeng Ni 
> * John Pullokkaran 
> * Julian Hyde 
> * Nick Dimiduk 
> * Steven Noels 
> * Ted Dunning 
> * Vladimir Sitnikov 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Julian Hyde be
> appointed to the office of Vice President, Apache Calcite,
> 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 Apache Calcite Project be and hereby is
> tasked with the migration and rationalization of the Apache
> Incubator Calcite podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Calcite podling encumbered upon the Apache
> Incubator Project are hereafter discharged.
>
> - - - end - - -
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Accept HAWQ into the Apache Incubator

[Andrew Purtell]

+1
Yay, more SQL on Hadoop, party on.

On Mon, Aug 31, 2015 at 11:47 AM, Roman Shaposhnik  wrote:

> Following the discussion earlier:
>http://s.apache.org/Gaf
>
> I would like to call a VOTE for accepting HAWQ
> as a new incubator project.
>
> The proposal is available at:
> https://wiki.apache.org/incubator/HAWQProposal
> and is also included at the bottom of this email.
>
> Vote is open until at least Thu, 3 September 2015, 23:59:00 PST
>
>  [ ] +1 accept HAWQ into the Apache Incubator
>  [ ] ±0
>  [ ] -1 because...
>
> Thanks,
> Roman.
>
> == Abstract ==
>
> HAWQ is an advanced enterprise SQL on Hadoop analytic engine built
> around a robust and high-performance massively-parallel processing
> (MPP) SQL framework evolved from Pivotal Greenplum DatabaseⓇ.
>
> HAWQ runs natively on Apache HadoopⓇ clusters by tightly integrating
> with HDFS and YARN. HAWQ supports multiple Hadoop file formats such as
> Apache Parquet, native HDFS, and Apache Avro. HAWQ is configured and
> managed as a Hadoop service in Apache Ambari. HAWQ is 100% ANSI SQL
> compliant (supporting ANSI SQL-92, SQL-99, and SQL-2003, plus OLAP
> extensions) and supports open database connectivity (ODBC) and Java
> database connectivity (JDBC), as well. Most business intelligence,
> data analysis and data visualization tools work with HAWQ out of the
> box without the need for specialized drivers.
>
> A unique aspect of HAWQ is its integration of statistical and machine
> learning capabilities that can be natively invoked from SQL or (in the
> context of PL/Python, PL/Java or PL/R) in massively parallel modes and
> applied to large data sets across a Hadoop cluster. These capabilities
> are provided through MADlib – an existing open source, parallel
> machine-learning library. Given the close ties between the two
> development communities, the MADlib community has expressed interest
> in joining HAWQ on its journey into the ASF Incubator and will be
> submitting a separate, concurrent proposal.
>
> HAWQ will provide more robust and higher performing options for Hadoop
> environments that demand best-in-class data analytics for business
> critical purposes. HAWQ is implemented in C and C++.
>
> HAWQ has a few runtime dependencies licensed under the Cat X list:
>   * gperf (GPL Version 3)
>   * libgsasl (LGPL Version 2.1)
>   * libuuid-2.26 (LGPL Version 2)
> However, given the runtime (dynamic linking) nature of these
> dependencies it doesn't represent a problem for HAWQ to be considered
> an ASF project.
>
> == Proposal ==
> The goal of this proposal is to bring the core of Pivotal Software,
> Inc.’s (Pivotal) Pivotal HAWQⓇ codebase into the Apache Software
> Foundation (ASF) in order to build a vibrant, diverse and
> self-governed open source community around the technology. Pivotal has
> agreed to transfer the brand name "HAWQ" to Apache Software Foundation
> and will stop using HAWQ to refer to this software if the project gets
> accepted into the ASF Incubator under the name of "Apache HAWQ
> (incubating)". Pivotal will continue to market and sell an analytic
> engine product that includes Apache HAWQ (incubating). While HAWQ is
> our primary choice for a name of the project, in anticipation of any
> potential issues with PODLINGNAMESEARCH we have come up with two
> alternative names: (1) Hornet; or (2) Grove.
>
> Pivotal is submitting this proposal to donate the HAWQ source code and
> associated artifacts (documentation, web site content, wiki, etc.) to
> the Apache Software Foundation Incubator under the Apache License,
> Version 2.0 and is asking Incubator PMC to establish an open source
> community.
>
> == Background ==
> While the ecosystem of open source SQL-on-Hadoop solutions is fairly
> developed by now, HAWQ has several unique features that will set it
> apart from existing ASF and non-ASF projects. HAWQ made its debut in
> 2013 as a closed source product leveraging a decade's worth of product
> development effort invested in Greenplum DatabaseⓇ. Since then HAWQ
> has rapidly gained a solid customer base and became available on
> non-Pivotal distributions of Hadoop.
> In 2015 HAWQ still leverages the rock solid foundation of Greenplum
> Database, while at the same time embracing elasticity and resource
> management native to Hadoop applications. This allows HAWQ to provide
> superior SQL on Hadoop performance, scalability and coverage while
> also providing massively-parallel machine learning capabilities and
> support for native Hadoop file formats. In addition, HAWQ's advanced
> features include support for complex joins, rich and compliant SQL
> dialect and industry-differentiating data federation capabilities.
> Dynamic pipelining and pluggable query optimizer architecture enable
> HAWQ to perform queries on Hadoop with the speed and scalability
> required for enterprise data warehouse (EDW) workloads. HAWQ provides
> strong support for low-latency analytic SQL queries, coupled with
> massively parallel machine learn

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Andrew Purtell]

Who are the village spinsters?


On Mon, Aug 3, 2015 at 1:21 PM, Branko Čibej  wrote:

> On 03.08.2015 21:51, Julian Hyde wrote:
> > In my experience incubating Calcite, the “overhead” was mostly the
> infrastructure and process, not politics. (If you think the incubator is
> political, you haven’t seen politics…) The process is necessary (mostly) to
> ensure clean IP. The infrastructure, less so. So, if we’re talking about
> how to reduce the burden on podlings, those are the areas I would focus on.
> >
> > Roman’s proposed reform places more responsibility on podling PMCs and,
> by implication, the mentors embedded in those PMCs.
>
> At the end of the day, it *is* the mentors' responsibility. The IPMC
> mostly gets involved after the fact.
>
> > I am not sure how well that would work in practice given the ongoing
> problem of absentee mentors. The IPMC epitomizes the “it takes a village to
> raise a child”, in particular with village elders stepping in with
> help/advice from time to time. It would be a shame to lose that.
>
> There's no need to lose that. But it would be a really good idea to lose
> the village spinster who makes the child afraid of the dark and monsters
> under the bed ...
>
> -- Brane
>
>
> >> On Aug 3, 2015, at 12:23 PM, Ross Gardler 
> wrote:
> >>
> >> " This is that proverbial "political overhead" that a lot of folks are
> accusing ASF of and cite as a reason of not going into the foundation.
> Which is grossly unfair at the board level, but unfortunately seems to be
> very true at IPMC level today."
> >>
> >> +1000
> >>
> >> -Original Message-
> >> From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of
> Roman Shaposhnik
> >> Sent: Monday, August 3, 2015 12:13 PM
> >> To: general@incubator.apache.org
> >> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite
> from the Apache Incubator)
> >>
> >> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier  wrote:
> >>> On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
>  I've been waiting for a bout a week for other to chime in, but it
>  seems that nobody has so I'll repeat my question as of a week ago:
>  what would be the effective way to change the status quo around IPMC
>  an make it more board like?
> 
>  Perhaps we can start from making the release policy actually make
>  sense along the lines that Ross has outlined. I guess I can propose a
>  change to the current policies (or to Ross'
>  point just get it back from the wayback machine :-)).
> 
>  But seriously, who else thinks the movement towards empowering PPMCs
>  and making IPMC very much like the board makes sense?
> >>> I think the thread fizzled because there's not a lot of support for
> >>> the idea. At least, on my end, I'm not in favor.
> >> Yup. I believe this to be an unfortunate (at least from my standpoint)
> but and extremely fair observation.
> >>
> >> As far as I'm concerned the issue of R&Rs of IPMC is in a state of a
> stalemate right now. We clearly have a "everything's fine lets just add
> more policy" constituency vs. "IPMC should be small and more board like"
> crowd.
> >>
> >> The good news is that we're all united on making sure that the
> foundation is growing by podlings making progress and graduating to TLPs.
> The bad news is that because of the current mentality I don't see the types
> of unfortunate threads that Ignite just went through going away anytime
> soon.
> >>
> >> This is that proverbial "political overhead" that a lot of folks are
> accusing ASF of and cite as a reason of not going into the foundation.
> Which is grossly unfair at the board level, but unfortunately seems to be
> very true at IPMC level today.
> >>
> >> It is clear to me that the change has very little chance of coming from
> within IPMC.
> >>
> >> 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
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Andrew Purtell]

Can you provide a pointer to a specific example of what you mean?


On Mon, Aug 3, 2015 at 4:06 PM, Arvind Prabhakar  wrote:

> On Mon, Aug 3, 2015 at 1:59 PM, Andrew Purtell 
> wrote:
>
> > >
> > ​
> > In fact, in my opinion it leads to the very unfortunate side effect of
> IPMC
> > ​> ​
> > feeling in need to justify why it exists by micromanaging podlings.
> >
> > I've been through incubation as a mentor on Phoenix, Nifi, and now
> getting
> > up to speed on Trafodion, I have not seen micromanagement of podlings.
> > Could you point out an example? Curious what you mean.
> >
>
> It is worth noting that none of the IPMC members micromanage on purpose, or
> are even aware that their actions are being interpreted as acts of
> micromanagement. From their perspective, it is their responsibility to
> guide the podling, and that is what they are trying to do. It will unfair
> to bring those out as examples of micromanagement.
>
> That said, I have personally been in positions where I have seen IPMC
> members ask - and even demand things at times - that I feel are
> unreasonable requests for the podling. The reason I do not challenge those
> is because I feel that their asks are rooted in good intentions, and that
> the IPMC in its current form encourages such involvement and authority. At
> the same time I also worry about the state of the podling and what this
> does to their way of thinking about Apache and the Incubator.
>
> Regards,
> Arvind Prabhakar
>
>
> >
> >
> > On Mon, Aug 3, 2015 at 11:33 AM, Roman Shaposhnik 
> > wrote:
> >
> > > On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament 
> > > wrote:
> > > > I wonder how much of the silence is a notion of "I don't want to be
> > > > accountable if something goes wrong in this podling."
> > >
> > > Right, but that same concern could be applied to every single TLP
> > > and yet the board seems to do the right thing with that.
> > >
> > > > Having the IPMC safety net means its at least the IPMC's fault if
> > > something
> > > > goes wrong.
> > >
> > > My point all along has been that this is a false sense of security.
> > > ​​
> > > In fact,
> > > in my opinion it leads to the very unfortunate side effect of IPMC
> > > feeling in need to justify why it exists by micromanaging podlings.
> > >
> > > > Personally, I'd be happy if the PPMCs had more self governance.  But
> I
> > > > think there are also some key people on the IPMC that should be able
> to
> > > > lend their skills out to the broader PPMCs in case of need.
> > >
> > > Which would be totally fine and gets us back to the point Daniel and I
> > were
> > > discussing: a release compliance team (horrible name, I know) as part
> of
> > > ASF.
> > >
> > > Thanks,
> > > Roman.
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Andrew Purtell]

>
​
In fact, in my opinion it leads to the very unfortunate side effect of IPMC
​> ​
feeling in need to justify why it exists by micromanaging podlings.

I've been through incubation as a mentor on Phoenix, Nifi, and now getting
up to speed on Trafodion, I have not seen micromanagement of podlings.
Could you point out an example? Curious what you mean.


On Mon, Aug 3, 2015 at 11:33 AM, Roman Shaposhnik 
wrote:

> On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament 
> wrote:
> > I wonder how much of the silence is a notion of "I don't want to be
> > accountable if something goes wrong in this podling."
>
> Right, but that same concern could be applied to every single TLP
> and yet the board seems to do the right thing with that.
>
> > Having the IPMC safety net means its at least the IPMC's fault if
> something
> > goes wrong.
>
> My point all along has been that this is a false sense of security.
> ​​
> In fact,
> in my opinion it leads to the very unfortunate side effect of IPMC
> feeling in need to justify why it exists by micromanaging podlings.
>
> > Personally, I'd be happy if the PPMCs had more self governance.  But I
> > think there are also some key people on the IPMC that should be able to
> > lend their skills out to the broader PPMCs in case of need.
>
> Which would be totally fine and gets us back to the point Daniel and I were
> discussing: a release compliance team (horrible name, I know) as part of
> ASF.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [PROPOSAL]Pistachio

[Andrew Purtell]

Thanks Gavin.

Please let me suggest that novelty is not a requirement for incubation, and
a proposal doesn't need to make claims of novelty to be accepted.

Should the proposal be accepted for incubation, you may find your new
neighbors at Apache can do X where you weren't aware of it. It will be
totally up to the new podling if you want to survey the landscape when
figuring out how to differentiate, but I do recommend it, it may help you
crystallize a community around a real difference and advantage provided by
Pistachio.


On Mon, Jun 22, 2015 at 7:54 PM, Gavin Li  wrote:

> Hi Andrew,
>
> As we described more in
>
> http://yahooeng.tumblr.com/post/116291838351/pistachio-co-locate-the-data-and-compute-for
> ,
> a very common problem we saw in Hadoop use cases is we often need to
> persist the previous result of one map reduce job onto HDFS, then the next
> day we process the new data together with the previous result. Usually the
> most expensive part is the shuffling part where we need to join the
> previous data and the new data together. It's so expensive because HDFS
> doesn't store the data in a partitioned way. So data have to be transferred
> again and again in the shuffling phase. Instead, in Pistachio we do the
> computation right on top of the partitioned storage layer, so that the
> previous result is always stored in a partitioned way, so shuffling can be
> avoided. Expensive IO and roundtrips can thus be avoided so that much
> better performance can be achieved.
>
> The other difference is in Pistachio we can do computation based on
> in-memory storage with data replication. Different from the in-memory
> computation in Spark, the storage can be in-memory here.
>
> Please let me know if I'm not clear enough.
>
> Thanks,
> Gavin Li
>
> On Mon, Jun 22, 2015 at 7:53 PM, Andrew Purtell 
> wrote:
>
> > It was a simple question, and not meant to suggest anything one way or
> > other regarding my opinion of this proposal.
> >
> > On Monday, June 22, 2015, John D. Ament  wrote:
> >
> > > On Mon, Jun 22, 2015 at 10:26 PM Andrew Purtell  > > > wrote:
> > >
> > > > > Pistachio can easily embed computation to the storage layer to
> > achieve
> > > > the
> > > > > best data locality to improve the computation performance
> > significantly
> > > > > which is an innovative model comparing with the normal ways where
> the
> > > > > storage and compute are independent to each other.
> > > >
> > > > Have you heard of something called Hadoop?
> > > >
> > >
> > > Regardless of whether he has or not - what's your point? The ASF has
> > > historically not denied the entry of new projects just because their
> > domain
> > > intersects with another project's.
> > >
> > >
> > > >
> > > >
> > > > On Thu, Jun 18, 2015 at 10:17 AM, Gavin Li  > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I want to propose project Pistachio to enter Apache Incubator.
> > > > >
> > > > > Below please find the proposal.
> > > > >
> > > > > Thanks,
> > > > > Gavin Li
> > > > >
> > > > >
> > > > >
> > > > > = Pistachio =
> > > > >
> > > > > == Abstract ==
> > > > >
> > > > > Pistachio is a fault-tolerant low latency distributed storage
> system
> > > > which
> > > > > enables simple embedding the computation to the storage layer to
> > > achieve
> > > > > best data locality. It evolves from Yahoo’s global user profile
> > storage
> > > > > system.
> > > > >
> > > > > == Proposal ==
> > > > >
> > > > > Pistachio is a distributed key value store system with fault
> > tolerance
> > > > and
> > > > > consistency guarantee. It supports multiple local storage engine
> > > > including
> > > > > in-memory, kyoto cabinet, rocks DB etc. Pistachio is being used as
> > the
> > > > user
> > > > > profile storage for massive scale global ads products in Yahoo
> > storing
> > > > 10+
> > > > > billion user profiles. The performance and reliability has been
> well
> > > > proven
> > > > > on production.
> > > > >
> > > > > Pistachio can easily embed computation to the storage l

Re: [PROPOSAL]Pistachio

[Andrew Purtell]

It was a simple question, and not meant to suggest anything one way or
other regarding my opinion of this proposal.

On Monday, June 22, 2015, John D. Ament  wrote:

> On Mon, Jun 22, 2015 at 10:26 PM Andrew Purtell  > wrote:
>
> > > Pistachio can easily embed computation to the storage layer to achieve
> > the
> > > best data locality to improve the computation performance significantly
> > > which is an innovative model comparing with the normal ways where the
> > > storage and compute are independent to each other.
> >
> > Have you heard of something called Hadoop?
> >
>
> Regardless of whether he has or not - what's your point? The ASF has
> historically not denied the entry of new projects just because their domain
> intersects with another project's.
>
>
> >
> >
> > On Thu, Jun 18, 2015 at 10:17 AM, Gavin Li  > wrote:
> >
> > > Hi,
> > >
> > > I want to propose project Pistachio to enter Apache Incubator.
> > >
> > > Below please find the proposal.
> > >
> > > Thanks,
> > > Gavin Li
> > >
> > >
> > >
> > > = Pistachio =
> > >
> > > == Abstract ==
> > >
> > > Pistachio is a fault-tolerant low latency distributed storage system
> > which
> > > enables simple embedding the computation to the storage layer to
> achieve
> > > best data locality. It evolves from Yahoo’s global user profile storage
> > > system.
> > >
> > > == Proposal ==
> > >
> > > Pistachio is a distributed key value store system with fault tolerance
> > and
> > > consistency guarantee. It supports multiple local storage engine
> > including
> > > in-memory, kyoto cabinet, rocks DB etc. Pistachio is being used as the
> > user
> > > profile storage for massive scale global ads products in Yahoo storing
> > 10+
> > > billion user profiles. The performance and reliability has been well
> > proven
> > > on production.
> > >
> > > Pistachio can easily embed computation to the storage layer to achieve
> > the
> > > best data locality to improve the computation performance significantly
> > > which is an innovative model comparing with the normal ways where the
> > > storage and compute are independent to each other.
> > >
> > > == Background ==
> > >
> > > Pistachio is originally designed and optimized for Yahoo’s large scale
> > > global open RTB(real-time bidding) use cases where latency is
> > critical(the
> > > whole request needs to be finished within 100ms including network round
> > > trips). It stores 10+ billion user profiles in 8 data centers.
> > >
> > > Then because of the great performance and the flexibility of local
> > storage
> > > choices, we evolved it to do distributed compute. Rich call back
> > interfaces
> > > are added to supports easy compute directly on top of the storage
> system
> > > local to the data partition. This model is totally different from the
> > > traditional distributed computation model where the storage and compute
> > are
> > > separated and independent. In the new model we found data locality can
> be
> > > improved significantly and lots of data access round trips can be
> reduced
> > > in computation, and the performance can be improved significantly.
> > >
> > > It was publicly announced in April 2015 and currently being hosted in
> > > Github.
> > >
> > > == Rationale ==
> > >
> > > As a key value store system Pistachio is unique in terms of low latency
> > > access with fault tolerance and consistency guarantee. The reliability,
> > > scalability, fault tolerance and performance has been well proven in
> > global
> > > large scale revenue supporting production system in Yahoo.
> > >
> > > As a distributed computation system, it’s an innovative model where the
> > > compute layer is introduced on top of the storage layer natively and
> > > naturally to optimize the data locality of computation.
> > >
> > > Operating the project in “apache way” greatly aligns with the long-term
> > > vision of this project and can greatly help the development of the
> > > community.
> > >
> > > == Current Status ==
> > >
> > > Pistachio was open-sourced and announced in April 2015 and currently
> > being
> > > hosted in Github, it was mainly being 

Re: [PROPOSAL]Pistachio

[Andrew Purtell]

> Pistachio can easily embed computation to the storage layer to achieve the
> best data locality to improve the computation performance significantly
> which is an innovative model comparing with the normal ways where the
> storage and compute are independent to each other.

Have you heard of something called Hadoop?


On Thu, Jun 18, 2015 at 10:17 AM, Gavin Li  wrote:

> Hi,
>
> I want to propose project Pistachio to enter Apache Incubator.
>
> Below please find the proposal.
>
> Thanks,
> Gavin Li
>
>
>
> = Pistachio =
>
> == Abstract ==
>
> Pistachio is a fault-tolerant low latency distributed storage system which
> enables simple embedding the computation to the storage layer to achieve
> best data locality. It evolves from Yahoo’s global user profile storage
> system.
>
> == Proposal ==
>
> Pistachio is a distributed key value store system with fault tolerance and
> consistency guarantee. It supports multiple local storage engine including
> in-memory, kyoto cabinet, rocks DB etc. Pistachio is being used as the user
> profile storage for massive scale global ads products in Yahoo storing 10+
> billion user profiles. The performance and reliability has been well proven
> on production.
>
> Pistachio can easily embed computation to the storage layer to achieve the
> best data locality to improve the computation performance significantly
> which is an innovative model comparing with the normal ways where the
> storage and compute are independent to each other.
>
> == Background ==
>
> Pistachio is originally designed and optimized for Yahoo’s large scale
> global open RTB(real-time bidding) use cases where latency is critical(the
> whole request needs to be finished within 100ms including network round
> trips). It stores 10+ billion user profiles in 8 data centers.
>
> Then because of the great performance and the flexibility of local storage
> choices, we evolved it to do distributed compute. Rich call back interfaces
> are added to supports easy compute directly on top of the storage system
> local to the data partition. This model is totally different from the
> traditional distributed computation model where the storage and compute are
> separated and independent. In the new model we found data locality can be
> improved significantly and lots of data access round trips can be reduced
> in computation, and the performance can be improved significantly.
>
> It was publicly announced in April 2015 and currently being hosted in
> Github.
>
> == Rationale ==
>
> As a key value store system Pistachio is unique in terms of low latency
> access with fault tolerance and consistency guarantee. The reliability,
> scalability, fault tolerance and performance has been well proven in global
> large scale revenue supporting production system in Yahoo.
>
> As a distributed computation system, it’s an innovative model where the
> compute layer is introduced on top of the storage layer natively and
> naturally to optimize the data locality of computation.
>
> Operating the project in “apache way” greatly aligns with the long-term
> vision of this project and can greatly help the development of the
> community.
>
> == Current Status ==
>
> Pistachio was open-sourced and announced in April 2015 and currently being
> hosted in Github, it was mainly being developed by the team from Yahoo and
> already attracted lots of external developers (20+ watches and forks on
> github).
>
> == Meritocracy ==
>
> We plan to build an environment following the Apache meritocracy
> principles. Many companies including Linkedin, GF securities, Microsoft and
> open source communities like deeplearning4j have already expressed
> interests or accepted the invitations to participate in this project.
>
> == Community ==
>
> Since the announcement of Pistachio we received lots of interests. And the
> concept of embedding computation to storage also got lots of recognitions.
> We also started to work with other communities like deeplearning4j to build
> more application use cases with Pistachio. We believe the community will
> grow fast.
>
> == Core Developers ==
>
> This project is created by Gavin Li. Core developers are currently mainly
> in Yahoo.
>
> == Alignment ==
>
> Pistachio depends on many Apache projects and dependencies including Kafka,
> Helix, Zookeeper, Curator, Apache Commons, etc.
>
> == Known Risks ==
>
> === Orphaned Products ===
>
> The risk of Pistachio being orphaned is small because Yahoo heavily
> invested in this system. It’s the internal storage standard for Yahoo’s
> global ads products and still being expanded. Migration cost from this
> project is very high. We are also working with external communities like
> deeplearning4j and other companies to expand the applications.
>
> === Inexperience with Open Source ===
>
> Core developers are experienced open source contributors in many projects
> including Druid, Spark, Storm, etc. Pistachio committers will be guided by
> the mentors with strong Apache open source pro

Re: [VOTE] Graduate Apache NiFi from the Incubator

[Andrew Purtell]

+1 (binding, podling mentor)


On Tue, Jun 16, 2015 at 9:05 PM, Joe Witt  wrote:

> Hello Apache Incubator
>
> This thread is to call a vote within the Incubator for the graduation
> of Apache NiFi.
>
> Status page:  http://incubator.apache.org/projects/nifi.html
> Incubator graduation discussion: http://s.apache.org/wmy
> NiFi community graduation vote: http://s.apache.org/GT9
>
> The discussion prompted Benson to join the PMC list to provide apache
> member experience and we clarified the scope language with discussion
> in the NiFi community.
>
> From the discussion thread Chris Mattmann offered his binding +1 vote.
>
> Since joining the Incubator in November, 2014 the NiFi community has:
>  * Produced three IPMC approved releases.
>  * Expanded the PPMC with 4 new members.
>  * Grown the community.  Developed increased interoperability with
> other Apache projects.
>  * Conducted a successful community vote to graduate with 22 +1 votes
> (5 IPMC binding).
>
> Please vote
>
> [  ] +1 Graduate Apache NiFi as a TLP
> [  ] +0
> [  ] -1 Do not graduate Apache NiFi as a TLP because…
>
> Voting will last 72 hours ending at 05:00 June 20, 2015 UTC.
>
> Thanks
> Joe
>
> === Board Resolution ===
>
> Establish the Apache NiFi 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 an automated and durable data broker
> between systems providing interactive command and control
> and detailed chain of custody for data.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache NiFi Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache NiFi Project be and hereby is
> responsible for the creation and maintenance of software
> related to an automated and durable data broker
> between systems providing interactive command and control
> and detailed chain of custody for data; and be it further
>
> RESOLVED, that the office of "Vice President, Apache NiFi" 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 NiFi Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache NiFi 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 NiFi Project:
> * Brandon DeVries (devri...@apache.org)
> * Matt Gilman (mcgil...@apache.org)
> * Tony Kurc (tk...@apache.org)
> * Mark Payne (marka...@apache.org)
> * Aldrin Piri (ald...@apache.org)
> * Dan Bress (danbr...@apache.org)
> * Jennifer Barnabee (jbarna...@apache.org)
> * Joseph L. Witt (joew...@apache.org)
> * Jason Carey (jca...@apache.org)
> * Adam Taft (tafts...@apache.org)
> * Benson Margulies (bimargul...@apache.org)
> * Bryan Bende (bbe...@apache.org)
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that
> Joseph L. Witt be appointed to the office of Vice President,
> Apache NiFi, 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 NiFi 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 NiFi Project; and be it further
>
> RESOLVED, that the Apache NiFi Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator NiFi podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator NiFi 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
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [DISCUSSION] Graduate NiFi from the Apache Incubator

[Andrew Purtell]

gt; the public, related to an automated and durable data broker
> > > > > >> between systems providing realtime command and control
> > > > > >> and detailed chain of custody for data.
> > > > > >>
> > > > > >> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > > > > >> Committee (PMC), to be known as the "Apache NiFi Project",
> > > > > >> be and hereby is established pursuant to Bylaws of the
> > > > > >> Foundation; and be it further
> > > > > >>
> > > > > >> RESOLVED, that the Apache NiFi Project be and hereby is
> > > > > >> responsible for the creation and maintenance of software
> > > > > >> related to an automated and durable data broker
> > > > > >> between systems providing realtime command and control
> > > > > >> and detailed chain of custody for data; and be it further
> > > > > >>
> > > > > >> ...
> > > > > >>
> > > > > >>
> > > > > >> Thanks
> > > > > >> Joe
> > > > > >>
> > > > > >> On Sat, Jun 13, 2015 at 10:25 PM, Niclas Hedhman <
> > > nic...@hedhman.org>
> > > > > >> wrote:
> > > > > >> > From the peanut gallery;
> > > > > >> > Doesn't
> > > > > >> > "related to the automated and managed flow of information
> > > > between
> > > > > >> > systems"
> > > > > >> > apply to at least half of all software out there?
> > > > > >> >
> > > > > >> > In other words, the scope is very wide, and could include
> > anything
> > > > > from
> > > > > >> > SNMP to Apache Mesos and much much more. I think the Board
> will
> > be
> > > > > >> happier
> > > > > >> > with a somewhat more narrow definition.
> > > > > >> >
> > > > > >> > Cheers
> > > > > >> > Niclas
> > > > > >> >
> > > > > >> >
> > > > > >> > On Sat, Jun 13, 2015 at 1:04 AM, jan i 
> wrote:
> > > > > >> >
> > > > > >> >> thanks for the responses I will cast a +1 at vote time.
> > > > > >> >>
> > > > > >> >> sorry for asking the questions, but I was insecure.
> > > > > >> >>
> > > > > >> >> rgds
> > > > > >> >> jan i
> > > > > >> >>
> > > > > >> >> On Friday, June 12, 2015, Benson Margulies <
> > > bimargul...@gmail.com>
> > > > > >> wrote:
> > > > > >> >>
> > > > > >> >> > Sean sure makes more sense than me.
> > > > > >> >> >
> > > > > >> >> > On Fri, Jun 12, 2015 at 12:35 PM, Joe Witt <
> > joe.w...@gmail.com
> > > > > >> >> > > wrote:
> > > > > >> >> > > Sean is one of those folks i referred to.  Id be an easy
> +1
> > > > > >> >> > > On Jun 12, 2015 9:24 AM, "Andrew Purtell" <
> > > apurt...@apache.org
> > > > > >> >> > > wrote:
> > > > > >> >> > >
> > > > > >> >> > >> As Sean says he's been engaged with the project while
> > acting
> > > > as
> > > > > >> >> mentor,
> > > > > >> >> > >> IMHO beyond mentor-ly duties. If the NiFi folks will
> have
> > > him
> > > > on
> > > > > >> the
> > > > > >> >> > >> initial PMC and he's willing to join it, this should
> > resolve
> > > > the
> > > > > >> >> stated
> > > > > >> >> > >> concerns.
> > > > > >> >> > >>
> > > > > >> >> > >>
> > > > > >> >> > >> On Friday, 

Re: [RESULT][VOTE] Graduate NiFi from the Apache Incubator

[Andrew Purtell]

As Sean says he's been engaged with the project while acting as mentor,
IMHO beyond mentor-ly duties. If the NiFi folks will have him on the
initial PMC and he's willing to join it, this should resolve the stated
concerns.


On Friday, June 12, 2015, Sean Busbey  wrote:

> On Fri, Jun 12, 2015 at 9:40 AM, Bertrand Delacretaz <
> bdelacre...@apache.org 
> > wrote:
>
> > On Fri, Jun 12, 2015 at 3:53 PM, Sean Busbey  > wrote:
> > > ...I have no reason to believe either my engagement or the PPMC's
> > willingness
> > > to reach out to or listen to what I have to say will change upon
> > > graduation, so I don't think they need a checkbox ASF member on the
> > initial
> > > PMC and I'd prefer they not add one...
> >
> > It's not about ticking a checkbox - it's about an ASF member agreeing
> > to stay with the project to help here and there with things where
> > members can help.
> >
> >
>
> Understood. I can't speak for any other ASF member, but I'm already there,
> engaged, and planning to stay. I don't need a binding PMC vote to do that.
>
> --
> Sean
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Accept Trafodion into Apache Incubator

[Andrew Purtell]

ends it to support ACID
> transactions with HBase co-processors for distributed transaction
> management and recovery. Trafodion envisions future collaborations with the
> Apache HBase project on performance optimizations, such as in the areas of
> mixed workload support, High Availability, etc. It also provides
> transactional support and querying from native HBase tables as well.
>
> Trafodion uses Apache Zookeeper to coordinate and manage the distribution
> of connection services across the cluster for load-balancing and high
> availability reconnection purposes in the event a Trafodion process should
> fail.
>
> Trafodion also envisions working with the Apache Ambari project on enabling
> better Trafodion manageability. While Ambari focuses on system and
> component level performance metrics, Trafodion manageability will focus in
> a complimentary way on database workload monitoring and performance
> analytics with capabilities more geared towards database administrators.
>
> There are alternative open source projects that are providing SQL-on-Hadoop
> capabilities, such as Apache Hive, Apache Drill, and Apache Phoenix. These
> are more focused on reporting and analytics across data structures
> supported on HDFS. In comparison to all of these technologies Trafodion
> provides a very complete implementation of ANSI SQL, one of the most
> sophisticated optimizers for such workloads, a completely parallel data
> flow architecture that does not materialize intermediate results unless
> necessary, full ACID transactional support, ANSI GRANT/REVOKE security, and
> other capabilities that would take decades to build in these products. On
> the other hand currently Trafodion is just focused on HBase and querying
> Hive, whereas Hive and Drill provide access to other data formats in HDFS.
>
> An Excessive Fascination with the Apache Brand
>
> We understand the reputation and value of the Apache brand, and no doubt
> believe that it will help us attract contributors and users. Our primary
> goal is to follow a proven, open source development and community building
> model that will make Trafodion successful and enable better collaboration
> with other Apache projects in the Hadoop ecosystem. We also understand the
> rules and guidelines about the use of the Apache brand and intend to follow
> them.
>
> Documentation
>
> Documentation and technical details on Trafodion can be found at:
> http://www.trafodion.org/
>
> Initial Source
>
> The source is available today in a public github repository:
> https://github.com/trafodion/trafodion.
>
> Source and Intellectual Property Submission Plan
>
> The source code has already been released under the Apache License, Version
> 2. The manuals have been released in Adobe PDF format. As part of the
> submission process, the source for the manuals will be converted from a
> proprietary DocBook XML format to AsciiDoc.
>
> External Dependencies
>
> Two dependencies do not have Apache compatible licenses and will be
> addressed as we enter incubation. One dependency is log4cpp, which is
> licensed under the LGPL. A compatible alternative might be Apache incubator
> project log4cxx. The other dependency is unixodbc, which is used as the
> ODBC driver manager. We will look into how Apache Hive manages being able
> to use this incompatible software and do similar. All other dependencies
> have Apache compatible licenses, including Apache 2.0, MIT/X11, MIT, and
> BSD.
>
> Cryptography
>
> Trafodion does not contain any cryptographic code. It does call
> cryptographic libraries: OpenSSL for C++ code and Java Cryptography
> Extension (JCE) for Java code.
>
> Required Resources
>
> Mailing Lists
>
> priv...@trafodion.incubator.apache.org
> d...@trafodion.incubator.apache.org comm...@trafodion.incubator.apache.org
>
> Git Repository
>
> https://git-wip-us.apache.org/repos/afs/incubator-trafodion.git
>
> Issue Tracking
>
> JIRA: JIRA Trafodion (Trafodion)
>
>
> Initial Committers and Affiliation
>
> Dave Birdsall, Hewlett-Packard Company, Dave.Birdsallhpcom
> Matt Brown, Hewlett-Packard Company, mattbrownhpcom
> Tharak Capirala, Hewlett-Packard Company, Tharak.Capiralahpcom
> Alice Chen, Hewlett-Packard Company, Alice.Chenhpcom
> John DeRoo, Hewlett-Packard Company, John.Deroohpcom
> Roberta Marton, Hewlett-Packard Company, Roberta.Martonhpcom
> Amanda Moran, Hewlett-Packard Company, Amanda.Kay.Moranhpcom
> Suresh Subbiah, Hewlett-Packard Company, Suresh.Subbiahhpcom
> Sandyha Sundaresan, Hewlett-Packard Company,
> Sandhya.Sundaresanhpcom
>
> Sponsors
>
> Champion
>
> Michael Stack, Stackapacheorg
>
> Nominated Mentors
>
> Andrew Purtell apurtellapacheorg
> Devaraj Das, ddasapacheor
> Enis Söztutar, Enisapacheorg
> Lars Hofhansl, larshapacheorg
> Michael Stack, Stackapacheorg
> Roman Shaposhnik, rshaposhnikpivotalio
>
> Sponsoring Entity
>
> Apache Incubator PMC
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Release Apache NiFi 0.1.0-incubating

[Andrew Purtell]

+1

Checked signature and sums of nifi-parent (1.0.0), nifi-nar-maven-plugin
(1.0.1) and nifi (0.1.0) source release zipfiles.
Unpacked all source release zipfiles, layout looks good
README, LICENSE, NOTICE, and DISCLAIMER files are present in each source
zip and look ok
Source builds of nifi-parent, nifi-nar-maven-plugin, and nifi complete
successfully*
RAT checks of nifi-parent, nifi-nar-maven-plugin, and nifi pass
All unit tests pass (tested using Java 7u79)

Kudos to the Nifi developers for providing a thorough checklist of
verification steps for community volunteers to use to help verify the
release: http://s.apache.org/ELZ .

* - Warning, you will jarcrawl the world if you try this, you have been
warned (smile). Also, give Maven plenty of heap and permgen.


On Thu, May 14, 2015 at 2:10 PM, Mark Payne  wrote:

> Hello
>
> The Apache NiFi PPMC has voted to release Apache NiFi 0.1.0-incubating.
> The vote was based on the release candidate and thread described below.
> We now request the IPMC to vote on this release.
>
> Here is the PPMC voting result:
> 1 +1 (IPMC binding)
> 5 +1 (PPMC non-binding)
> 3 +1 (non-binding)
> 0 0
> 0 -1
>
> Here is the PPMC vote thread:
> http://mail-archives.apache.org/mod_mbox/incubator-nifi-dev/201505.mbox/browser
>
> In this release, we factored out a parent maven artifact. This means that
> we also had to do a new
> release of the nifi-nar-maven-plugin, so there are a total of three
> artifacts for this build:
>
> nifi-parent
> nifi-nar-maven-plugin
> nifi
>
>
> ---
> For nifi-parent:
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1049
>
>
> The Git tag is nifi-parent-1.0.0-incubating-rc13
> The Git commit ID is 37732bddcfcb2affcba1f3b4a9e3dd5ebd7b5a30
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=37732bddcfcb2affcba1f3b4a9e3dd5ebd7b5a30
>
>
> Checksums of nifi-parent-1.0.0-incubating-source-release.zip:
> MD5: fc22f90566b44dcc1e8637df2cfe71be
> SHA1: 24ef57c27489e74be3bf5167d13b852be704d96d
>
> ---
> For nifi-nar-maven-plugin:
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1050
>
>
> The Git tag is nifi-nar-maven-plugin-1.0.1-incubating-rc13
> The Git commit ID is 1fc8453b36c1a1d600a911668f10249cf1e52ea7
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=1fc8453b36c1a1d600a911668f10249cf1e52ea7
>
>
> Checksums of nifi-nar-maven-plugin-1.0.1-incubating-source-release.zip:
> MD5: 90c6e9e8f7037df4aa41e6978e6f34ad
> SHA1: 155b9e633a724e76fa9f223fafa8d9f92377fed9
>
> ---
> For nifi:
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1051
>
>
> The Git tag is nifi-0.1.0-incubating-rc13
> The Git commit ID is 65a07b6b634e04f44b5b89bfaf95e0ff35c3c68c
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=65a07b6b634e04f44b5b89bfaf95e0ff35c3c68c
>
>
> Checksums of nifi-0.1.0-incubating-source-release.zip:
> MD5: 805d96637327885f38420ba6b9f39066
> SHA1: dde266518632af33b432dd03d6da931aa27dbabc
>
> ---
> For all artifacts:
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/markap14.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/incubator/nifi/KEYS
>
>
> Should the source release be successful we intend to make convenience
> binaries available.  The
> convenience binary of this source release along with the appropriate
> hashes and signature can be found
> here: https://dist.apache.org/repos/dist/dev/incubator/nifi
>
> 121 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12329276
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test.  The
> please vote:
>
> [ ] +1 Release this package as nifi-0.1.0-incubating
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [DISCUSS] Trafodion Incubation Proposal

[Andrew Purtell]

If you are looking for mentors, I helped on the Phoenix incubation, happy
to do so again for Trafodion.

On Fri, May 8, 2015 at 2:59 PM, Stack  wrote:

> I would like to start up a discussion on Trafodion joining the ASF as an
> incubating project.
>
> Trafodion is a webscale SQL-on-Hadoop solution that enables transactional
> or operational workloads on Hadoop, .
>
> The proposal is available on the wiki here:
> https://wiki.apache.org/incubator/TrafodionProposal#preview
>
> The proposal text is also attached to the end of this email.
>
> Trafodion is a rich, storied SQL engine that has recently been ported to
> run on HBase and Hadoop. I think it would make for a fine addition to the
> Apache family of projects  It would be good to hear what others think.
>
> Thank you in advance for giving the proposal a read.
>
> Yours,
> St.Ack
>
>
> Trafodion Apache Incubator Proposal
>
> Abstract
>
> Trafodion is a webscale SQL-on-Hadoop solution enabling transactional or
> operational workloads on Hadoop.
>
> Proposal
>
> Apache Trafodion builds on the scalability, elasticity, and flexibility of
> Hadoop. Trafodion extends Hadoop to provide guaranteed transactional
> integrity, enabling new kinds of big data applications to run on Hadoop.
> Key
> features of Apache Trafodion include:
>
> * Full-functioned ANSI SQL language support
> * JDBC/ODBC connectivity for Linux/Windows clients
> * Distributed ACID transaction protection across multiple statements,
> tables and rows
> * Performance improvements for OLTP workloads with compile-time and
> run-time optimizations
> * Support for large data sets using a parallel-aware query optimizer
> * ANSI SQL security and data integrity constraints including referential
> integrity
>
> Hewlett-Packard Company submits this proposal to donate its Apache License,
> Version 2.0 open source project known as Trafodion, its source code,
> documentation, and web site content to the Apache Software Foundation in
> order to build an open source community
>
> Background
>
> Trafodion is an open source project sponsored by HP, incubated at HP Labs
> and HP-IT, to develop an enterprise-class SQL-on-Hadoop solution targeting
> big data transactional or operational workloads. HP publically announced
> the open source project and uploaded the source code to GitHub in June
> 2014.
>
> The SQL compiler, optimizer and executor components of Trafodion have a
> rich heritage. Under development since 1993, they were released as
> commercial closed source software in various flavors such as HP NonStop
> SQL/MX and HP Neoview. NonStop SQL/MX was designed for online transaction
> processing on HP’s NonStop (formerly Tandem) fault-tolerant servers and is
> known for its high availability, scalability, and performance. Hundreds of
> companies and thousands of servers are running mission-critical
> applications today on NonStop SQL/MX. In addition, much of these components
> today are running internal to HP as the core of its Enterprise Data
> Warehouse (EDW), managing over a PB of data.
>
> Starting in 2013, the software was modified to run on HBase and a new
> distributed transaction manager was written to run as an HBase
> co-processor.
>
> Unlike most NOSQL and other SQL-on-Hadoop open source projects, Trafodion
> provides comprehensive ANSI SQL language support including full-functioned
> data definition (DDL), data manipulation (DML), transaction control (TCL)
> and database utility support.
>
> Trafodion provides comprehensive and standard SQL data manipulation support
> including SELECT, INSERT, UPDATE, DELETE, and UPSERT/MERGE syntax with
> language options including join variants, unions, where predicates,
> aggregations (group by and having), sort ordering, sampling, correlated and
> nested sub-queries, cursors, and many SQL functions.
>
> Utilities are provided for updating table statistics used by the optimizer
> for costing (i.e. selectivity/cardinality estimates) plan alternatives, for
> displaying the chosen SQL execution plan, plan shaping, backup and
> restoring the database, data loading and unloading, and a command line
> utility for interfacing with the database engine.
>
> Explicit control statements are provided to allow applications to define
> transaction boundaries and to abort transactions when warranted, including
> BEGIN WORK, COMMIT WORK, ROLLBACK WORK and SET TRANSACTION.
>
> Trafodion supports ANSI’s grant/revoke semantics to define user and role
> privileges in terms of managing and accessing the database objects.
>
> Rationale
>
> The name “Trafodion” (the Welsh word for transactions, pronounced
> “Tra-vod-eee-on”) was chosen specifically to emphasize the differentiation
> that Trafodion provides in closing a critical gap in the Hadoop ecosystem.
> Trafodion builds on the scalability, elasticity, and flexibility of Hadoop.
> Trafodion extends Hadoop to provide guaranteed transactional integrity,
> enabling new kinds of big data applications to run on Hadoop.
>
> Current S

Re: Do we need @ASFIncubator ?

[Andrew Purtell]

It certainly wouldn't hurt to have another channel for getting the word
out. I presume @ASFIncubator would announce new proposals, new projects,
project graduations, and releases of incubating software? Anything else
besides that ? (Which is quite a lot already.) This would be more Incubator
coverage than afforded by @TheASF today, which has not to date and probably
won't announce every Incubator related happening.


On Mon, Mar 23, 2015 at 2:05 PM, Roman Shaposhnik  wrote:

> Hi!
>
> while trying to spread the good news that the Groovy
> vote has passed, I've realized that we don't have
> a dedicate Incubator Twitter account.
>
> Question for all: should we leverage @TheASF for
> the incubator-level announcements or should we
> establish our own handle?
>
> WDYGT?
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Accept Groovy into the Apache Incubator

[Andrew Purtell]

+1 (binding)

On Wed, Mar 18, 2015 at 11:55 PM, Roman Shaposhnik  wrote:

> Following the discussion earlier in the thread:
>http://s.apache.org/KWE
>
> I would like to call a VOTE for accepting Groovy
> as a new incubator project.
>
> The proposal is available at:
> https://wiki.apache.org/incubator/GroovyProposal
> and is also included at the bottom of this email.
>
> Vote is open until at least Saturday, 21st March 2015, 23:59:00 PST
>
>  [ ] +1 accept Groovy in the Incubator
>  [ ] ±0
>  [ ] -1 because...
>
> Thanks,
> Roman.
>
> == Abstract ==
> Groovy is an object-oriented programming language for the Java
> platform. It is a language with features similar to those of Python,
> Ruby, Java, Perl, and Smalltalk.
> Groovy, if accepted by Incubator, will be a first major programming
> language developed under the umbrella of Apache Software Foundation.
>
> == Proposal ==
> Groovy is a programming language for the Java platform. It is a
> primarily dynamic language with features similar to those of Python,
> Ruby, Perl, and Smalltalk. It also has optional static type checking
> and static compilation facilities. It can be used as a scripting
> language for the Java Platform or to write complete applications, is
> compiled to Java Virtual Machine (JVM) bytecode, and interoperates
> with other Java code and libraries. Groovy uses a Java-like
> curly-bracket syntax. Most Java code is also syntactically valid
> Groovy, although semantics may be different. Groovy has long been
> developed under an Apache License v2.0 under an open governance
> community management process. However, so far Groovy has been a
> project mostly sponsored by a single company. This proposal aims at
> bringing Groovy community under the umbrella of the Apache Software
> Foundation.
>
> It must be explicitly noted, that a few sister projects such as Groovy
> Eclipse and others (some of them hosted under
> https://github.com/groovy and listed at
> http://groovy-lang.org/ecosystem.html) are not covered by this
> proposal. It is possible that these other projects will be joining ASF
> either independently or as sub-projects of Apache Groovy in the
> future. For now, we are only proposing groovy-core.
>
> == Background ==
> Groovy 1.0 was released on January 2, 2007, and Groovy 2.0 in July,
> 2012. Groovy 2.5 is planned for release in 2015. Groovy 3.0 is planned
> for release in 2016, with support for a new Meta Object Protocol.
> Since version 2, Groovy can also be compiled statically, offering type
> inference and performance very close to that of Java. Groovy 2.4 will
> be the last major release under Pivotal Software's sponsorship, which
> is scheduled to end on March 31, 2015.
>
> == Rationale ==
> Groovy is a pretty mature language. After 12 years of development, it
> has grown from being primarily a dynamic scripting language on the JVM
> to an optionally statically compiled language allowing the same
> performance level as Java applications. With the release of Groovy
> 2.4, the language targets the largest pool of mobile developers with
> native Android support. Groovy has been integrated in a large number
> of applications, including well known open-source projects like
> Jenkins, Gradle, ElasticSearch, Spring and more.
>
> There are multiple alternative languages on the JVM: Scala, Clojure,
> Ceylon, Kotlin, JRuby, Golo and others but Groovy is the only one
> which has proved to be very easy to integrate with Java in both ways:
> Groovy code using Java code, but also Java code using Groovy code.
> Groovy even provides a joint compiler which allows interdependent Java
> and Groovy classes to compile together. Groovy also supports dynamic
> code generation, that is to say classes at runtime, making it a
> perfect fit for scripting. With a very lightweight and malleable
> syntax, it is also easy to build internal Domain Specific Languages
> (DSLs) which integrate smoothly within applications.
>
> Groovy provides a number of unique features, like builders (Java 8 has
> lambdas but still has syntactic overhead and no notion of delegate),
> AST transformations (compile-time metaprogramming) or type checking
> extensions (which allows the developer to bring the compiler to levels
> of type checking and type inference that go far beyond what other
> languages do). Groovy also provides powerful integration options and
> customizations which set it apart from other languages. Groovy is also
> unique in the way it allows the developer to choose between various
> paradigms without compromise: functional vs object-oriented,
> statically compiled vs dynamic, scripting vs applications, etc.
>
> Despite all those advantages, and the fact that Groovy is widely
> adopted (4.5 million downloads in 2014 for Groovy alone), only a few
> Apache projects include Groovy and not a lot of them leverage its full
> power. Some developers tend to choose Scala for example to build DSLs
> without even knowing that the learning curve is much easier with

Re: [VOTE] Release Apache NiFI 0.0.1-incubating

[Andrew Purtell]

+1 (binding)

On Mon, Jan 26, 2015 at 7:33 PM, Joe Witt  wrote:

> Hello
>
> The Apache NiFi (incubating) team is pleased to be calling this vote for
> the source release of Apache
> NiFi 0.0.1-incubating.
>
> With six binding (in the ppmc sense) +1 votes and no dissenting votes the
> PPMC has approved the vote for the release in this thread:
>
> http://s.apache.org/nifi-rc3
>
> We now ask the IPMC to vote for this release.
>
> Since this is our first release as part of the Apache Incubator it will be
> slightly unique because we need to release two components.
>
> The first component is the 'nifi-nar-maven-plugin' which allows us to build
> 'NiFi Archives' which is part of our classloader isolation model.  The
> second is simply 'nifi' which is the full build and application that is
> 'Apache NiFi (incubating)'.
>
> After this first release we expect to be releasing the
> 'nifi-nar-maven-plugin' very rarely.
>
> So we'll break the information sections of this vote into two parts where
> one is for 'nifi-nar-maven-plugin' and the other 'nifi'.
>
> For the 'nifi-nar-maven-plugin'
> --
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1021
>
> The specific repository path in that staging repo is:
>
> orgapachenifi-1021/content/org/apache/nifi/nifi-nar-maven-plugin/1.0.0-incubating/
>
> The sources.zip is called
> 'nifi-nar-maven-plugin-1.0.0-incubating-source-release.zip'
>
> The Git tag is nifi-nar-maven-plugin-1.0.0-incubating-RC3
>
> The Git commit ID is 6e69d99444e22772df300cd777096dc21a7c8e35
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=6e69d99444e22772df300cd777096dc21a7c8e35
>
> Checksums of nar-maven-plugin-1.0.0-incubating-source-release.zip:
> MD5: 2681be25c32a45df07fbac59f768c5d2
> SHA1: 1e6057e07c32a7a0208afdc36e7ce725bd9935e4
>
> 7 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12329307
>
> 
> Note once you have completed the verification of the
> 'nifi-nar-maven-plugin' you will have
> 'nifi-nar-maven-plugin:1.0.0-incubating' in your local repo and thus you
> can move on to the 'nifi' build below which depends on it.
> 
>
> For 'nifi'
> -
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1022
>
> The specific repository path in that staging repo is:
> orgapachenifi-1022/org/apache/nifi/nifi/0.0.1-incubating/
>
> The sources.zip is called 'nifi-0.0.1-incubating-source-release.zip'
>
> The Git tag is 'nifi-0.0.1-incubating-RC3'
>
> The Git commit ID is 3a7625920866deaab1f3973fc4db0847d054a9b5
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=3a7625920866deaab1f3973fc4db0847d054a9b5
>
> Checksums of nifi-0.0.1-incubating-source-release.zip:
> MD5: f421bb67a775b9ef7e29a34c08c538c1
> SHA1: a04a3914d9e5a4455c1b503785a7772ab772816c
>
> 114 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12329078
>
> The following information applies to both the 'nifi-nar-maven-plugin' and
> 'nifi':
>
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/joewitt.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/incubator/nifi/KEYS
>
> This vote will follow 'http://www.apache.org/foundation/voting.html'
> 'Votes
> on Package Releases' guidelines.
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test.  Then
> please vote:
>
> [ ] +1 Release this package as Apache NiFi 0.0.1-incubating
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because...
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Andrew Purtell]

Yes, formal votes for all decisions has been my *universal* experience on
all projects I have participated in at Apache. It's like there are two (or
more) different foundations, culturally. Thanks for the consideration.

On Sun, Jan 25, 2015 at 12:40 PM, Branko Čibej  wrote:

> On 25.01.2015 21:07, Andrew Purtell wrote:
> > I'm not arguing with you Greg (smile), honestly, Subversion sounds like a
> > very laid back place to participate. It's different in Bigtop, HBase,
> > Phoenix, Whirr (of historical note), and Hadoop (secondhand observation),
> > Hive (secondhand observation), ZooKeeper (secondhand observation) and
> > others. Formal votes are called on releases, committerships, PMC
> elevation,
> > branch merges (with even additional hurdles by bylaw), and are most
> > definitely talled.
>
> Sigh ... well, all I can really add here is that the projects you
> mention might benefit from a bit of therapy to cure their control-freak
> reflex.
>
> The reason why communities should reach consensus through public
> discussion is that, when instead you have a formal vote every time
> someone gets an itch, you're likely to end up with some very nasty
> behind-the-scenes vote swapping. Of course I'm not accusing anyone of
> doing that ... though, sadly, I've heard rumours.
>
> Suffice it to say that what you describe is not the ASF Way.
>
> -- Brane
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Andrew Purtell]

I'm not arguing with you Greg (smile), honestly, Subversion sounds like a
very laid back place to participate. It's different in Bigtop, HBase,
Phoenix, Whirr (of historical note), and Hadoop (secondhand observation),
Hive (secondhand observation), ZooKeeper (secondhand observation) and
others. Formal votes are called on releases, committerships, PMC elevation,
branch merges (with even additional hurdles by bylaw), and are most
definitely talled.

On Sun, Jan 25, 2015 at 12:01 PM, Greg Stein  wrote:

> Apache Subversion uses discussion/consensus for all of those. We throw out
> +1 and similar as shorthand for our preference, but we never tally, as it
> isn't a formal vote.
>
> On Sun, Jan 25, 2015 at 1:58 PM, Andrew Purtell 
> wrote:
>
> > In all of the projects I have been PMC or PPMC on, we vote on releases,
> new
> > committers, and elevating committers to PMC.
> >
> >
> > On Sun, Jan 25, 2015 at 11:56 AM, Greg Stein  wrote:
> >
> > > On Sun, Jan 25, 2015 at 1:49 PM, Andrew Purtell 
> > > wrote:
> > >
> > > > > This is *exactly* the way things work in a TLP.
> > > >
> > > > Yes, everyone new to the Foundation on the PPMC has a sense of equal
> > > > ownership in the process. The PPMC makes a decision together as
> equals,
> > > > then the decision is reviewed as a whole. But this is not how things
> > > would
> > > > work in a pTLP, right? Individuals there would effectively cast votes
> > +1
> > > > (binding), or -1 (binding), +1 (non-binding), or -1 (non-binding),
> > etc.,
> > > > depending if they are a Member or not. Maybe in practice the pTLP PMC
> > > > wouldn't write down their votes like that, but somehow the
> distinction
> > > must
> > > > be presented in the tallies to be meaningful.
> > > >
> > >
> > > Nah. First: votes should be rare in the first place. Go for consensus
> > > instead. Apache Subversion has had maybe 3 votes in its 15 year
> history.
> > >
> > > And if you *do* end up voting? People already know who is binding or
> not.
> > > This isn't some star chamber PMC. Everybody knows each other already.
> If
> > > the PMC is voting differently from the others, then you have a problem,
> > > regardless of not/binding.
> > >
> > > Anyways... we'll run the experiment, and see how it works. We may have
> a
> > > candidate already.
> > >
> > > Cheers,
> > > -g
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Andrew Purtell]

Yes, and I briefly confused the two, and fessed up.

On Sun, Jan 25, 2015 at 12:03 PM, Greg Stein  wrote:

> Go to the FIRST POST of this thread (titled: "my pTLP view"!!). THAT is
> what we're talking about. Not the Strawman.
>
> On Sun, Jan 25, 2015 at 1:56 PM, Andrew Purtell 
> wrote:
>
> > Oh, my mistake! (smile) I confused pTLP with the "Strawman" proposal
> there
> > for a minute. In the pTLP proposal, there are no new-to-the-Foundation
> > project members on the pTLP PMC.
> >
> > "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"
> >
> >
> > Newcomers to Apache *might* get committership depending how the
> > only-members-as-PMC decide. They don't get even non-binding
> stakeholdership
> > in decisionmaking on new commiters, releases, and so on.
> >
> >
> > On Sun, Jan 25, 2015 at 11:49 AM, Andrew Purtell 
> > wrote:
> >
> > > > This is *exactly* the way things work in a TLP.
> > >
> > > Yes, everyone new to the Foundation on the PPMC has a sense of equal
> > > ownership in the process. The PPMC makes a decision together as equals,
> > > then the decision is reviewed as a whole. But this is not how things
> > > would work in a pTLP, right? Individuals there would effectively cast
> > > votes +1 (binding), or -1 (binding), +1 (non-binding), or -1
> > > (non-binding), etc., depending if they are a Member or not. Maybe in
> > > practice the pTLP PMC wouldn't write down their votes like that, but
> > > somehow the distinction must be presented in the tallies to be
> > meaningful.
> > >
> > >
> > >
> > > On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej 
> wrote:
> > >
> > >> On 25.01.2015 19:51, Andrew Purtell wrote:
> > >> >> That hardly ever happens (it's most likely when there are problems
> > with
> > >> > ​> ​
> > >> > a podling's first few releases), which is why you get the impression
> > >> > ​> ​
> > >> > that the PPMC can make binding decisions.
> > >> >
> > >> > ​Close. The PPMC membership feels they have made a decision that
> > matters
> > >> > with equal input.
> > >> > Certainly on PPMCs I've been on,
> > >> > ​there is awareness that everything is
> > >> > provisional
> > >> > ​. Still, a
> > >> >  process takes place on PPMC mailing lists leading to a tallied
> > outcome.
> > >> > The input that leads to this output is the consensus or voting of *a
> > >> group
> > >> > of equal peers*.
> > >> > ​ This output is handed to the IPMC in aggregate. ​
> > >> > When casting votes on the PPMC lists there are no +1 (binding) or +1
> > >> > (non-binding) distinctions made. PPMC sends the outcome over to the
> > IPMC
> > >> > feeling some level of ownership having just participated in a
> decision
> > >> > making process as equal
> > >> > ​s​
> > >> > . (Or at least so I think, in some perhaps quaint notion.) Of course
> > in
> > >> > IPMC voting it is different, but the IPMC is where supervision
> > happens,
> > >> or
> > >> > doesn't, as some argue.
> > >>
> > >> This is *exactly* the way things work in a TLP. Any committer can
> > >> propose a release. The PMC must (!) start a (public) vote. Anyone can
> > >> vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
> > >> member or plain committer, should block the release and trigger a
> > >> discussion to find a solution; and in this discussion (which purpose
> is
> > >> to reach consensus on a solution), PMC members have no more voice than
> > >> any other community member.
> > >>
> > >> If the PMC decides to ignore a -1 on a release vote, they'd better
> have
> > >> really good reasons for that, or I'd expect the Board to come down
> like
> > >> a ton of bricks on that PMC.
> > >>
> > >> The situation is slightly different with new committer/PMC member
> > >> nominations and votes, which are private; you have a p

Re: my pTLP view

[Andrew Purtell]

In all of the projects I have been PMC or PPMC on, we vote on releases, new
committers, and elevating committers to PMC.


On Sun, Jan 25, 2015 at 11:56 AM, Greg Stein  wrote:

> On Sun, Jan 25, 2015 at 1:49 PM, Andrew Purtell 
> wrote:
>
> > > This is *exactly* the way things work in a TLP.
> >
> > Yes, everyone new to the Foundation on the PPMC has a sense of equal
> > ownership in the process. The PPMC makes a decision together as equals,
> > then the decision is reviewed as a whole. But this is not how things
> would
> > work in a pTLP, right? Individuals there would effectively cast votes +1
> > (binding), or -1 (binding), +1 (non-binding), or -1 (non-binding), etc.,
> > depending if they are a Member or not. Maybe in practice the pTLP PMC
> > wouldn't write down their votes like that, but somehow the distinction
> must
> > be presented in the tallies to be meaningful.
> >
>
> Nah. First: votes should be rare in the first place. Go for consensus
> instead. Apache Subversion has had maybe 3 votes in its 15 year history.
>
> And if you *do* end up voting? People already know who is binding or not.
> This isn't some star chamber PMC. Everybody knows each other already. If
> the PMC is voting differently from the others, then you have a problem,
> regardless of not/binding.
>
> Anyways... we'll run the experiment, and see how it works. We may have a
> candidate already.
>
> Cheers,
> -g
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Andrew Purtell]

Oh, my mistake! (smile) I confused pTLP with the "Strawman" proposal there
for a minute. In the pTLP proposal, there are no new-to-the-Foundation
project members on the pTLP PMC.

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


Newcomers to Apache *might* get committership depending how the
only-members-as-PMC decide. They don't get even non-binding stakeholdership
in decisionmaking on new commiters, releases, and so on.


On Sun, Jan 25, 2015 at 11:49 AM, Andrew Purtell 
wrote:

> > This is *exactly* the way things work in a TLP.
>
> Yes, everyone new to the Foundation on the PPMC has a sense of equal
> ownership in the process. The PPMC makes a decision together as equals,
> then the decision is reviewed as a whole. But this is not how things
> would work in a pTLP, right? Individuals there would effectively cast
> votes +1 (binding), or -1 (binding), +1 (non-binding), or -1
> (non-binding), etc., depending if they are a Member or not. Maybe in
> practice the pTLP PMC wouldn't write down their votes like that, but
> somehow the distinction must be presented in the tallies to be meaningful.
>
>
>
> On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej  wrote:
>
>> On 25.01.2015 19:51, Andrew Purtell wrote:
>> >> That hardly ever happens (it's most likely when there are problems with
>> > ​> ​
>> > a podling's first few releases), which is why you get the impression
>> > ​> ​
>> > that the PPMC can make binding decisions.
>> >
>> > ​Close. The PPMC membership feels they have made a decision that matters
>> > with equal input.
>> > Certainly on PPMCs I've been on,
>> > ​there is awareness that everything is
>> > provisional
>> > ​. Still, a
>> >  process takes place on PPMC mailing lists leading to a tallied outcome.
>> > The input that leads to this output is the consensus or voting of *a
>> group
>> > of equal peers*.
>> > ​ This output is handed to the IPMC in aggregate. ​
>> > When casting votes on the PPMC lists there are no +1 (binding) or +1
>> > (non-binding) distinctions made. PPMC sends the outcome over to the IPMC
>> > feeling some level of ownership having just participated in a decision
>> > making process as equal
>> > ​s​
>> > . (Or at least so I think, in some perhaps quaint notion.) Of course in
>> > IPMC voting it is different, but the IPMC is where supervision happens,
>> or
>> > doesn't, as some argue.
>>
>> This is *exactly* the way things work in a TLP. Any committer can
>> propose a release. The PMC must (!) start a (public) vote. Anyone can
>> vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
>> member or plain committer, should block the release and trigger a
>> discussion to find a solution; and in this discussion (which purpose is
>> to reach consensus on a solution), PMC members have no more voice than
>> any other community member.
>>
>> If the PMC decides to ignore a -1 on a release vote, they'd better have
>> really good reasons for that, or I'd expect the Board to come down like
>> a ton of bricks on that PMC.
>>
>> The situation is slightly different with new committer/PMC member
>> nominations and votes, which are private; you have a point there.
>>
>> -- Brane
>>
>> > On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej 
>> wrote:
>> >
>> >> On 25.01.2015 19:16, Andrew Purtell wrote:
>> >>> With a PPMC we invite newcomers to make votes we call binding on
>> matters
>> >> of
>> >>> their own project.
>> >> As other people have said, PPMC members (that are not also IPMC
>> members)
>> >> do not have binding votes, neither for releases nor for inviting new
>> >> committers/PPMC members. The "binding" bit lies with the IPMC, which
>> can
>> >> revoke any formal decision made by the PPMC.
>> >>
>> >> That hardly ever happens (it's most likely when there are problems with
>> >> a podling's first few releases), which is why you get the impression
>> >> that the PPMC can make binding decisions. In this respect, there's no
>> >> practical difference between the current IPMC model and the proposed
>> >> pTLP model.
>> >>
>> >> Of co

Re: my pTLP view

[Andrew Purtell]

> This is *exactly* the way things work in a TLP.

Yes, everyone new to the Foundation on the PPMC has a sense of equal
ownership in the process. The PPMC makes a decision together as equals,
then the decision is reviewed as a whole. But this is not how things would
work in a pTLP, right? Individuals there would effectively cast votes +1
(binding), or -1 (binding), +1 (non-binding), or -1 (non-binding), etc.,
depending if they are a Member or not. Maybe in practice the pTLP PMC
wouldn't write down their votes like that, but somehow the distinction must
be presented in the tallies to be meaningful.



On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej  wrote:

> On 25.01.2015 19:51, Andrew Purtell wrote:
> >> That hardly ever happens (it's most likely when there are problems with
> > ​> ​
> > a podling's first few releases), which is why you get the impression
> > ​> ​
> > that the PPMC can make binding decisions.
> >
> > ​Close. The PPMC membership feels they have made a decision that matters
> > with equal input.
> > Certainly on PPMCs I've been on,
> > ​there is awareness that everything is
> > provisional
> > ​. Still, a
> >  process takes place on PPMC mailing lists leading to a tallied outcome.
> > The input that leads to this output is the consensus or voting of *a
> group
> > of equal peers*.
> > ​ This output is handed to the IPMC in aggregate. ​
> > When casting votes on the PPMC lists there are no +1 (binding) or +1
> > (non-binding) distinctions made. PPMC sends the outcome over to the IPMC
> > feeling some level of ownership having just participated in a decision
> > making process as equal
> > ​s​
> > . (Or at least so I think, in some perhaps quaint notion.) Of course in
> > IPMC voting it is different, but the IPMC is where supervision happens,
> or
> > doesn't, as some argue.
>
> This is *exactly* the way things work in a TLP. Any committer can
> propose a release. The PMC must (!) start a (public) vote. Anyone can
> vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
> member or plain committer, should block the release and trigger a
> discussion to find a solution; and in this discussion (which purpose is
> to reach consensus on a solution), PMC members have no more voice than
> any other community member.
>
> If the PMC decides to ignore a -1 on a release vote, they'd better have
> really good reasons for that, or I'd expect the Board to come down like
> a ton of bricks on that PMC.
>
> The situation is slightly different with new committer/PMC member
> nominations and votes, which are private; you have a point there.
>
> -- Brane
>
> > On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej  wrote:
> >
> >> On 25.01.2015 19:16, Andrew Purtell wrote:
> >>> With a PPMC we invite newcomers to make votes we call binding on
> matters
> >> of
> >>> their own project.
> >> As other people have said, PPMC members (that are not also IPMC members)
> >> do not have binding votes, neither for releases nor for inviting new
> >> committers/PPMC members. The "binding" bit lies with the IPMC, which can
> >> revoke any formal decision made by the PPMC.
> >>
> >> That hardly ever happens (it's most likely when there are problems with
> >> a podling's first few releases), which is why you get the impression
> >> that the PPMC can make binding decisions. In this respect, there's no
> >> practical difference between the current IPMC model and the proposed
> >> pTLP model.
> >>
> >> Of course, when it comes to /technical/ decisions, there's no such thing
> >> as a vote, so the term "binding" does not apply. Consensus, of one form
> >> or another, always rules: and the IPMC or mentors can't meddle in this
> >> case.
> >>
> >> -- Brane
> >>
> >>
> >> -
> >> 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
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Andrew Purtell]

> That hardly ever happens (it's most likely when there are problems with
​> ​
a podling's first few releases), which is why you get the impression
​> ​
that the PPMC can make binding decisions.

​Close. The PPMC membership feels they have made a decision that matters
with equal input.
Certainly on PPMCs I've been on,
​there is awareness that everything is
provisional
​. Still, a
 process takes place on PPMC mailing lists leading to a tallied outcome.
The input that leads to this output is the consensus or voting of *a group
of equal peers*.
​ This output is handed to the IPMC in aggregate. ​
When casting votes on the PPMC lists there are no +1 (binding) or +1
(non-binding) distinctions made. PPMC sends the outcome over to the IPMC
feeling some level of ownership having just participated in a decision
making process as equal
​s​
. (Or at least so I think, in some perhaps quaint notion.) Of course in
IPMC voting it is different, but the IPMC is where supervision happens, or
doesn't, as some argue.


On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej  wrote:

> On 25.01.2015 19:16, Andrew Purtell wrote:
> > With a PPMC we invite newcomers to make votes we call binding on matters
> of
> > their own project.
>
> As other people have said, PPMC members (that are not also IPMC members)
> do not have binding votes, neither for releases nor for inviting new
> committers/PPMC members. The "binding" bit lies with the IPMC, which can
> revoke any formal decision made by the PPMC.
>
> That hardly ever happens (it's most likely when there are problems with
> a podling's first few releases), which is why you get the impression
> that the PPMC can make binding decisions. In this respect, there's no
> practical difference between the current IPMC model and the proposed
> pTLP model.
>
> Of course, when it comes to /technical/ decisions, there's no such thing
> as a vote, so the term "binding" does not apply. Consensus, of one form
> or another, always rules: and the IPMC or mentors can't meddle in this
> case.
>
> -- Brane
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Andrew Purtell]

With a PPMC we invite newcomers to make votes we call binding on matters of
their own project. Under the pTLP proposal they will not have this unless
they happen to already be part of the Apache membership. I don't find it a
distinction without a difference. I think it withholds an ownership stake
in the process. All of this may be word games on some level, but words do
matter.



On Fri, Jan 23, 2015 at 11:01 PM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> What makes you think the PPMC today had more influence than the
> contributors to a pushing?
>
> Votes have been mentioned, but votes remain the same. Despite what people
> on this thread are saying PPMC members do not have a binding vote. That
> does not change.
>
> Besides, the whole thing is moot because pTLP is an *option*
>
> Sent from my Windows Phone
> ________
> From: Andrew Purtell<mailto:apurt...@apache.org>
> Sent: ‎1/‎23/‎2015 6:09 PM
> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> Subject: Re: my pTLP view
>
> You are approaching this question with complete trust and faith in the
> Apache process, being an Apache member, but an incoming / foreign community
> will not have this, not universally. Take the emotion out of this, because
> I certainly am not being emotional here, but instead trying to evaluate
> this change from the perspective of an outsider. I assume the objective is
> to be and remain an inviting place for building community and code,
> attracting new blood.
>
> I think everyone can accept an organization has a Board with a final say.
> What I find attractive about the current incubation model is Apache
> welcomes new communities by making them voting stakeholders in their new
> project, they become a PPMC, a podling. Sure, the IPMC provides oversight,
> and the board again, but the PPMC can make binding votes on committers,
> releases, everything that matters - provisionally, of course, which is
> completely acceptable. This all changes if the PMC does not include any
> members of the incoming community. There isn't even a provisional ownership
> stake in the endeavor. When Apache grants the incoming community a
> provisional binding stake in the process, this establishes trust.
>
> I don't agree that the chances ASF PMC members of pTLP will start actively
> overriding votes is slim to none.  I've been around here for a while and
> spent some time in Hadoop land. The process is not infallable. The
> membership is not infallable. To ensure the probability of better outcomes
> no matter what happens during an incubation, the incoming community should
> be treated more like partners in a common endeavor with a full stake in the
> process than what is proposed here.
>
> >
> ​
> The incoming community is disempowered and has no recourse but to go along
> with the outcome of Apache politics or abandon the project.
>
> How is this not true? What can the incoming community make a binding vote
> on, under this proposal?
>
>
> On Fri, Jan 23, 2015 at 5:53 PM, Roman Shaposhnik  wrote:
>
> > On Fri, Jan 23, 2015 at 5:42 PM, Andrew Purtell 
> > wrote:
> > > Those of us in such a new incoming community might get the commit bit
> but
> > > can't vote on adding committers,
> >
> > See my reply to Jan. C == PPMC solves this completely.
> >
> > > or making releases.
> >
> > This is *exactly* what is happening today with every single poddling.
> > Why are you bringing this up as a *new* concern around pTLP?
> >
> > > We don't have a
> > > binding vote on our own committership / fate / ability to manage our
> own
> > > sources.
> >
> > I'll be a stickler here: literally  the only new issue that doesn't
> > exist today is that there won't be a by-law guaranteeing community
> > that they can *override* ASF members vote on new committers. That is it!
> > Everything else stays *exactly* the same. Not a single change
> > to how IPMC *rules* are structured.
> >
> > > This situation is primed for mistrust, conflict, and heartache the
> > > second the members and the incoming community disagree about some
> > > substantial aspect of the project direction. The incoming community is
> > > disempowered and has no recourse but to go along with the outcome of
> > Apache
> > > politics or abandon the project. As a responsible steward of my
> > community,
> > > I would never consider bringing my project to Apache under these
> > > circumstances.
> >
> > Wow! This is a pretty gross overstatement if you ask me. Remember,

Re: my pTLP view

[Andrew Purtell]

You are approaching this question with complete trust and faith in the
Apache process, being an Apache member, but an incoming / foreign community
will not have this, not universally. Take the emotion out of this, because
I certainly am not being emotional here, but instead trying to evaluate
this change from the perspective of an outsider. I assume the objective is
to be and remain an inviting place for building community and code,
attracting new blood.

I think everyone can accept an organization has a Board with a final say.
What I find attractive about the current incubation model is Apache
welcomes new communities by making them voting stakeholders in their new
project, they become a PPMC, a podling. Sure, the IPMC provides oversight,
and the board again, but the PPMC can make binding votes on committers,
releases, everything that matters - provisionally, of course, which is
completely acceptable. This all changes if the PMC does not include any
members of the incoming community. There isn't even a provisional ownership
stake in the endeavor. When Apache grants the incoming community a
provisional binding stake in the process, this establishes trust.

I don't agree that the chances ASF PMC members of pTLP will start actively
overriding votes is slim to none.  I've been around here for a while and
spent some time in Hadoop land. The process is not infallable. The
membership is not infallable. To ensure the probability of better outcomes
no matter what happens during an incubation, the incoming community should
be treated more like partners in a common endeavor with a full stake in the
process than what is proposed here.

>
​
The incoming community is disempowered and has no recourse but to go along
with the outcome of Apache politics or abandon the project.

How is this not true? What can the incoming community make a binding vote
on, under this proposal?


On Fri, Jan 23, 2015 at 5:53 PM, Roman Shaposhnik  wrote:

> On Fri, Jan 23, 2015 at 5:42 PM, Andrew Purtell 
> wrote:
> > Those of us in such a new incoming community might get the commit bit but
> > can't vote on adding committers,
>
> See my reply to Jan. C == PPMC solves this completely.
>
> > or making releases.
>
> This is *exactly* what is happening today with every single poddling.
> Why are you bringing this up as a *new* concern around pTLP?
>
> > We don't have a
> > binding vote on our own committership / fate / ability to manage our own
> > sources.
>
> I'll be a stickler here: literally  the only new issue that doesn't
> exist today is that there won't be a by-law guaranteeing community
> that they can *override* ASF members vote on new committers. That is it!
> Everything else stays *exactly* the same. Not a single change
> to how IPMC *rules* are structured.
>
> > This situation is primed for mistrust, conflict, and heartache the
> > second the members and the incoming community disagree about some
> > substantial aspect of the project direction. The incoming community is
> > disempowered and has no recourse but to go along with the outcome of
> Apache
> > politics or abandon the project. As a responsible steward of my
> community,
> > I would never consider bringing my project to Apache under these
> > circumstances.
>
> Wow! This is a pretty gross overstatement if you ask me. Remember,
> all of the above is predicated on a *single* possibility. Not even a
> guarantee a *possibility*. That ASF PMC members of pTLP will start
> actively overriding  votes on adding new members to the community.
> This is literally *the only* power they will be getting that doesn't
> exist in IPMC today.
>
> The chances of that are slim to none, so I have no choice but to call
> the above a strawman.
>
> > This may also increase the risk a project is coming here due to an
> > excessive fascination with the Apache brand, because otherwise the
> bargain
> > seems poor (in my view).
>
> Like I said -- we won't know until we try. We will try with *willing*
> participants. If they like it and if the board likes it -- we will start
> migrating folks. If not -- we'll stop.
>
> Thanks,
> Roman.
>
> P.S. This is my time to apologize for harsh tone. But really? Really:
> "
> ​​
> The incoming community is disempowered and has no recourse
> but to go along with the outcome of Apache politics or abandon the
> project."
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Andrew Purtell]

I find the direction this discussion has gone personally disappointing, but
I might be missing understanding of some crucial point.

> 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

So should I take my successful project and community to Apache, the first
thing that happens is the foundation creates a Project Management Committee
out of the membership, not the incoming community. This might be fine for
new projects made up of familiar faces, but not where there is new blood.
Those of us in such a new incoming community might get the commit bit but
can't vote on adding committers, or making releases. We don't have a
binding vote on our own committership / fate / ability to manage our own
sources. This situation is primed for mistrust, conflict, and heartache the
second the members and the incoming community disagree about some
substantial aspect of the project direction. The incoming community is
disempowered and has no recourse but to go along with the outcome of Apache
politics or abandon the project. As a responsible steward of my community,
I would never consider bringing my project to Apache under these
circumstances.

This may also increase the risk a project is coming here due to an
excessive fascination with the Apache brand, because otherwise the bargain
seems poor (in my view).


On Fri, Jan 23, 2015 at 5:10 PM, Greg Stein  wrote:

> On Fri, Jan 23, 2015 at 6:18 PM, jan i  wrote:
>
> > On Saturday, January 24, 2015, Ross Gardler (MS OPEN TECH) <
> > ross.gard...@microsoft.com
> > > wrote:
> >
> > > No, the PMC is *not* the driving force. The project community is, even
> > > where the PMC is a subset of the committers. Since it is the set of
> > active
> > > *contributors* that are important, they are the ones doing the work.
> >
> > I totally agree, but pTLC calls for a PMC that can be 0% subset of the
> > community, how can the PMC in this situation reflect the community?
> >
>
> Because the Board chose to put people onto the PMC that understand: *guide*
> the community. Not *rule* the community.
>
> Even better is when the ASF/PMC members are *part* of the community, rather
> than just being present to assist with that guidance.
>
> In the current Incubator model, a "Champion" is chosen. That is usually a
> person who has some self-interest in the project, and becomes *part* of the
> community. So you already have some overlap there.
>
>
> >
> > Remember we talk rules here, and rules should be made so the reflect what
> > we want, and I believe it is important that the community is represented
> in
> > the PMC, not 100% but also not 0%.
> >
>
> No. We DON'T talk about rules here. I said "create a PMC with a couple
> requirements". Then the project does what works best for their community,
> within the overall view of what the ASF believes makes a great project.
>
> Rules exist to provide guidance when consensus does not exist. That is all
> a rule is good for. A project with a strong consensus model doesn't need
> rules.
>
> > > I don't understand your argument about releases. Nothing changes under
> > > under the pTLP proposal with respect to how a release is made. In any
> ASF
> > > project the full community votes for a release if they want to. Only
> the
> > > PMC have binding votes, but they should listen to the community in
> casting
> > > those votes (same is true for podlings where the podling community
> votes on
> > > a release but it needs to be formalized by the IPMC via its mentors).
>
> > I read the rules instead of believing in "should". If a PMC does not like
> a
> > technical direction, they can block it totally within the rules, even if
> > all non-PMC prefers it.
>
> Sure... they *could*. How long do you honestly believe the Board would
> allow that to continue? Seriously.
>
> You propose a situation that just won't ever happen.
>
> > I think my problem is that I agree with both you and Roman, The PMC
> should
> > leave technical matters including releases to the total community. But
> > alone by talking about "binding" and "non-binding" votes creates two
> > levels, and if the PMC does not include the incoming community the
> > disconnect gets bigger.
>
> There *are* two different levels. That is how it works. Always has. Always
> will. Accept that.
>
> But that doesn't mean those with binding votes should (or WOULD!!) ignore
> those without. I don't see that happen. Do you? I would guess not. So it
> isn't something to worry about.
>
> I also specifically said "ASF Members" because I believe *they* know how to
> run a community. Not to use the ASF legal structure against it, but to help
> the community work *within* the structure. As Ross said: to empower the
> community.
>
> > With pTLC I fear that the incoming community will feel empowered,  the
> [ I'm assuming you meant: