Re: possible interest in forming a community fork of akka

[Ralph Goers]

+1 to everything Greg says, although I wouldn’t consider it to be a hostile 
fork 
just as I don’t consider the fork of Hudson to Jenkins to be a hostile fork. In 
my 
book it isn’t a hostile fork when the major contributors simply switch to the 
new 
repository and infrastructure. i.e - if the community largely is staying intact 
how 
can it possibly be a fork? You can certainly say the code forked (that happens 
all the time at GitHub and no one really cares) but what is more important to 
me is the community.

Ralph

> On Sep 27, 2022, at 4:23 PM, Greg Stein  wrote:
> 
> On Tue, Sep 27, 2022 at 4:55 AM PJ Fanning  wrote:
>> ...
> 
>> In some cases, the critical fix might be submitted to the fork first
>> and it may be easier for the Lightbend team to cherry pick those cases
>> than it is for the fork team to do the opposite.
>> 
> 
> Should an ALv2 fork arise *anywhere*[1], then I believe
> Lightbend's community will vaporize. That community will follow the OSS
> fork, and Lightbend will be relegated to picking up those ALv2-licensed
> patches into their proprietary version. There will simply be no reason for
> a community to hang around and contribute their work to the newly-licensed
> and proprietary version of Akka.
> 
> Cheers,
> -g
> 
> [1] whether at the ASF, or at an external hosting site. Note that,
> historically, the ASF has been mostly against forks where the owner(s)
> disagree with creating that fork (aka "a hostile fork").


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

Re: possible interest in forming a community fork of akka

[Ralph Goers]

Before going too far with this I would be interested to know:
1. Who the initial committers/PMC members would be.
2. How much familiarity the proposed people already have with the code base.
3. How diverse the community is from an employment point of view.

In other words, I would be concerned if this is pushed by just 3 or 4 people, 
none of which have ever spent much time in the code, and who all work for 
the same employer.

Ralph

> On Sep 26, 2022, at 11:11 AM, PJ Fanning  wrote:
> 
> Hi everyone,
> 
> Apologies if this is not the right mailing list. If it is not, please
> let me know and I'll switch the thread to the right list.
> 
> Lighbend [1], the company that maintains the popular open source
> framework, Akka [2], recently announced they are moving Akka to a
> non-OSS commercial license [3].
> 
> There is interest in the OSS community in forking Akka under a new
> name and maintaining it as an ASF project [4].
> 
> It is early days yet but there is some discussion online [5].
> 
> Reading the incubator cookbook, a new podling would need to have
> champions and mentors from within the Incubator PMC [6].
> 
> I would like to put my name forward for such a role, as an existing
> ASF member [7].
> 
> If anyone else in the Incubator PMC would like to get involved, that
> would be great.
> 
> Regards,
> PJ
> 
> [1] https://www.lightbend.com/
> [2] https://akka.io/
> [3] https://www.lightbend.com/akka/license-faq
> [4] https://github.com/mdedetrich/akka-apache-project
> [5] https://github.com/mdedetrich/akka-apache-project/discussions/9
> [6] 
> https://incubator.apache.org/cookbook/#does_our_project_fit_the_apache_incubator
> [7] https://whimsy.apache.org/roster/committer/fanningpj
> 
> -
> 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: Looking for a champion: resurrect log4j 1.x

[Ralph Goers]

Justin, 

See https://lists.apache.org/thread/fz19gsjnlh84nxgxj0jyy2rzrol1dx9b 
 and 
https://twitter.com/qos_ch/status/1479938932213223424 
.

However, it is worth noting that https://github.com/albfernandez/log4j/ 
 has had a release in Maven Central for 
2 years and published 2 releases in the last month.

Ralph

> On Jan 9, 2022, at 12:35 AM, Justin Mclean  wrote:
> 
> Hi,
> 
> The incubation list for for conversations about new project proposals, 
> releases and graduations and similar things. I think this thread has got off 
> topic and you should probably carry on the conversation back on the logging 
> project lists.
> 
> Building a community around EOLed software, even if it is used would be 
> difficult. However, there is nothing stopping people who are interested 
> forking log4j 1.x and working on it elsewhere. Has that option been 
> considered?
> 
> Kind Regards,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

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

[Ralph Goers]

> 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

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

[Ralph Goers]

> On Dec 22, 2021, at 12:35 AM, Vladimir Sitnikov  
> wrote:
> 
> 
> I already asked Logging PMC to enable Git and GitHub for 1.x, and they
> rejected it:
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2

My recollection was me saying if I had the code in a git repo getting it into a 
GitHub repo would be easy. 
But I wasn’t going to do the work. But it appears the code is in Gitbox. If so, 
getting it into an updatable 
GitHub repo should be easy - except the name you probably want to use is the 
one used by Gitbox.

We’ve also asked what your plans would be for all the issues that are in 
Bugzilla. It seems you would rather 
use Jira or GitHub issues. I don’t blame you there. But will you just ignore 
all those old problems? 
I don’t recall getting an answer. But maybe you did. I was busy.

Ralph


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

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

[Ralph Goers]

> On Dec 21, 2021, at 10:24 PM, Vladimir Sitnikov  
> wrote:
> 
> Matt>Nobody in the Logging PMC is blocking a release here.
> 
> Matt, thanks for the reply, however, it is false :(
> I see you are positive, however, many more replies were quite negative.
> 
> Ralph Goers says: "We’ve stated several times that we don’t think
> resurrecting Log4j 1.x permanently is a good idea."
> https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt
> 
> Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should
> ONLY be for CVEs,"
> https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7
> 
> They both are on Logging PMC, and they both have negative opinions on
> making progress with v1.
> I do not really understand what "ONLY be for CVEs" means (e.g. does it
> allow upgrading from Maven2 to Maven3?),
> but I do not want to get accidentally blocked by "oh, this change is not
> allowed because it is not a CVE fix".

Of course we have opinions. But me saying I don’t think it is a good idea 
doesn’t mean 
“No, it isn’t going to happen”.  I’ve said I think lots of things are bad ideas 
and then 
changed my mind. But the emphasis here should really be on getting consensus 
from 
those who are trying to do work on Log4j 1.x. Do they just want a 1.2.18 
release or a 
continuing sub-project. I know you are very vocal about wanting a continuing 
sub-project 
but I’ve not really heard anybody else say they are in it for the long haul.

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

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

[Ralph Goers]

> On Dec 21, 2021, at 9:22 PM, 张铎(Duo Zhang)  wrote:
> 
> But in my experience, first, the log4j12 bridge is not perfect. For
> example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge
> dependency if I want to run UTs based on hadoop mini cluster, and then I
> need to manually copy some code from log4j1 in order to make it work, this
> is an example
> 
> https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java
> 
> I know in the bridge you will create log4j2 appender instead when reading
> the configuration file of log4j1, but since the appenders in log4j1 lack of
> some abilities, it is common that lots of projects will implement their own
> appender, I think we should take care of these usages and make them migrate
> smoothly.

I do not know if you are aware but the experimental support we added a few 
releases ago should 
be able to use Log4j 1 Appenders in Log4j2. It is experimental simply because 
we have no idea what wild 
and crazy things uses are relying on in Log4j 1 since nothing was private. We 
need user feedback.

> 
> And then, while fully migrating to log4j2, there is another annoying
> problem, the
> 
> log4j.rootLogger=INFO,console
> 
> grammar is gone! It is used among almost all the projects I've seen, and we
> just drop the support for it!

Again, support for Log4j 1 configuration files is part of the experimental 
support. We finally received 
our first bug report on it so someone is using it.

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

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

[Ralph Goers]

I’m sorry, I was just directed to this thread. I don’t read my incubator emails 
every day since I am not mentoring any podlings at the moment.

There seems to be some disconnect with the facts. From my viewpoint they are:

An email came in asking if it would be possible to put out a new 1.2.18 release 
to address the outstanding CVEs. Our response was that we 
were totally focused on 2.x, don’t have a lot of experience building 1.x but 
would be happy to help release that if it met the PMCs expectations.

A pull request then arrived - I believe https://github.com/apache/log4j/pull/16 
- that was objected to by one of our PMC members as it deletes 
a bunch of classes rather than fixing them in a manner similar to what we did 
for Log4j 2.

I noticed that there seemed to be a disconnect between some of the posters. 
Some just wanted to get 1.2.18 published as originally proposed 
while others seemed to want it to continue on. As there currently is no Log4j 1 
community I asked which option they were after and suggested 
that if they wanted to develop a community that the incubator is where that 
happens with Logging Services as the sponsor. If a community 
develops it would be expected that graduation would be as a subproject of the 
Logging Services Project. That seemed to make some 
unhappy as any PMC member could veto commits in the Log4j 1 work.

As far as I am concerned we never really got an answer to
1) Is this a one and done?
2) Is there are real community to support Log4j 1? 
3) There are major flaws in Log4j 1.x’s architecture which is why SLF4J/Logback 
and Log4j 2 came to be. Will an attempt be made to address 
those without breaking compatibility?
4) Does this community care about compatibility? Simply removing classes is not 
user friendly.

To top it off this discussion was going on while the whole Logging Services PMC 
was overwhelmed with security emails, users asking for help, 
and the PMC trying to get patch releases out. It was a poor choice of timing to 
try to have this discussion during that frenzy.

In short, we don’t object to either a 1.2.18 release or reactivating Log4j 1. 
What we don’t want is a release of Log4j 1 along with a misconception 
that it is being supported again when it is not. We don’t want releases of 
Log4j 1 that do more harm than good.

Sorry for the long post.

Ralph


> On Dec 20, 2021, at 12:26 AM, Vladimir Sitnikov  
> wrote:
> 
> Hi,
> 
> I want to resurrect log4j 1.x to fix well-known security issues.
> I'm looking for the champion and committers.
> 
> log4j 1.x is a wildly used logging library, so releasing a secured version
> would silence CVE warnings
> all over the world, and it would enable users to focus on more relevant
> tasks than "upgrading from log4j1 to log4j2".
> 
> I do not expect active log4j1 development, however, I would strongly focus
> on fixing the security issues.
> 
> Unfortunately, there are lots of applications that can't easily upgrade to
> log4j2, and they are exposed to security issues.
> I did try my best cooperating with the current logging PMC, and it looks
> like they
> are not interested in fixing 1.x (see [1], [2], [3], [4])
> 
> I'm a member of PMC on Apache JMeter and Apache Calcite projects, so
> I am familiar with the way Apache projects are governed.
> 
> [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> [2]: https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> [3]: https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
> [4]: https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
> 
> Vladimir


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

Re: JPMS Projects?

[Ralph Goers]

JPMS is flat out a PITA. I’ve tried to get Log4j to fully support it and am 
continuing to work on that. Our current 2.x releases tolerate it primarily by 
declaring their names in the Manifest but that really isn’t full support.  

If I were starting out on a brand new project JPMS might be a lot easier but 
migrating already existing stuff with lots of dependencies is extremely hard. 
To be honest, this isn’t completely the fault of JPMS. The fact that Oracle 
removed classes in Java 9 and forced you to switch in that release played havoc 
with the Log4j build. Trying to get a single deliverable support both Java 8 
and 9+ created a mess. If Oracle had had at least 1 release where both were 
supported it would have made things a LOT easier.

Ralph

> On Mar 18, 2021, at 7:34 AM, Romain Manni-Bucau  wrote:
> 
> Hi,
> 
> If it helps, JPMS has still a lot of blockers IMHO, as soon as you quit
> unamed module land you break most frameworks out there.
> If your lib is a standalone functional set of utilities it can not be
> bothering but if you use any reflection or meta programming I would
> recommend to stick to unamed module by default until you are required to go
> with jpms.
> Only feature JPMS has, as of today, is being able to build jvm images and
> graalvm kind of killed this features by making it irrelevant (I skip the
> licensing issues it can create ;)).
> 
> My 2 cts,
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le jeu. 18 mars 2021 à 15:25, Serge Huber  a écrit :
> 
>> I was also going to mention OSGi. It enforces better lifecycle management
>> than JPMS. If you can do it with OSGi you can certainly use it with JPMS
>> 
>> Regards,
>>  Serge...
>> 
>> On Thu, Mar 18, 2021 at 3:19 PM Matt Sicker  wrote:
>> 
>>> Perhaps the various OSGi-related projects here might be similar to what
>>> you’re looking for since those have enforced modularity for a long time.
>>> That module system is more advanced than JPMS, but the concepts are
>> fairly
>>> similar.
>>> 
>>> We’ve also been looking into this for log4j 3.0, but that’s not out yet.
>>> 
>>> On Thu, Mar 18, 2021 at 01:06 Daniel Widdis  wrote:
>>> 
 After considering this email I wrote, I regret sending it and want to
 apologize if I have overstepped any bounds.
 
 I am not a member of the IPMC or associated in any formal way with
>> Apache
 and am certainly not in any position to make any judgments regarding
>> code
 quality or your wise choice to begin your search with such projects.
 
 I'll back out of this conversation now and let others answer or
>> redirect
 you to other resources.
 
 Dan
 
 
 On 3/17/21, 10:21 PM, "Daniel Widdis"  wrote:
 
Thanks for your clarifications.
 
Regarding "Apache" = "Quality", I'd be careful.  Apache asserts
>> [1] a
 maxim of "Community over code".  While certainly a broad community
 inevitably leads to better code, and Apache is a good starting point,
>>> given
 the specificity of your request I might start there but not exclude
>> other
 established projects (not random code) which follow many of the same
 principles.
 
I do hope those on this list are aware of some projects they can
 recommend to you!
 
As for the technical specifications, I'd also recommend you'd
>>> separate
 those out as well.  Some of your concerns seem to deal with native code
 access which seems a separate issue than modular design of code.  I
>> have
 also been looking around for good Panama/FMA examples and haven't seen
 anything non-trivial yet.  But even those can be done with/without the
>>> Java
 Module System (JPMS).
 
Looking forward to any other replies with interest.
 
Dan
 
[1] - https://www.apache.org/theapacheway/
 
On 3/17/21, 10:08 PM, "leerho"  wrote:
 
Daniel,
Thank you for your reply.
 
 
> Can you clarify what you mean by an "Apache Java project"?
 
 
I would prefer to examine a project that has a formal release
 process and
an active community. So a TLP or incubating project would be
 great.  In
this case I was equating "Apache" = "Quality"  :)
 
I'm not so interested in random code on the Internet that just
 happens to
be Apache licensed :)
 
Is there a particular use case you are interested in?
 
 
I am seriously looking at *redesigning* our JDK8 Library using
 Java Modules
leveraging JDK16+/Panama/FMA and completely replacing the need
>>> for

Re: [DICUSS] Retire Samoa

[Ralph Goers]

I don’t really see anything to discuss.

Ralph

> On Feb 10, 2021, at 7:22 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> My message to the Samoa asking them to consider retirement got no response  
> [1] so I this think it time to discuss their retirement. Are there any 
> objections to returning the project?
> 
> Thanks,
> Justin
> 
> 1. 
> https://lists.apache.org/thread.html/rb513f7ba5cc5dd1ba9adbf9fe8dbbb52db40066f04a9fed9fd2f7293%40%3Cdev.samoa.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: Podling releases and release policy

[Ralph Goers]

Ask yourself this question - “What is the point of the Incubator”?

One of the goals is to teach projects how to create a release that complies 
with ASF policy. But we would be stupid to expect that on the first Incubator 
release as we expect projects to come in with already working source code and 
their own build & release methodology. Placing the disclaimer on the project’s 
site and labeling the release as incubating is done so that downstream users 
are aware the release may be be up to ASF standards.

If we required that podling releases adhered to ASF release policy there would 
be no need for the disclaimer. At the same time, we would probably have a lot 
of projects leave the incubator because it would take them so long to get their 
first release out.

Ralph

> On Jun 2, 2019, at 3:06 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> That is demonstrably not true, as (historically) the Incubator has made
>> releases with GPL'd code in them (eg. Hibernate).
> 
> I assume you mean a dependancy on? I can think of 2 occasions this has 
> occurred, both times permission of VP legal was required.
> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 



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

Re: board report duplication

[Ralph Goers]

I should also add that it seems odd to me that the report field is just a 
string and not and not a container of other fields since reports generally have 
structure to them.

Ralph

> On Apr 15, 2019, at 9:25 PM, Ralph Goers  wrote:
> 
> 
> 
>> On Apr 13, 2019, at 4:27 PM, Sam Ruby  wrote:
>> 
>> On Sat, Apr 13, 2019 at 5:54 PM Ted Dunning  wrote:
>>> 
>>> Moving to a data format that makes a stronger distinction between content
>>> and envelope might be nice. JSON would work if content is actually quoted
>>> (don't bet on it). A directory would probably be better because the content
>>> of a file can't break the meta-data in the directory. Something like a real
>>> database would be even better.
>> 
>> This month's agenda in JSON format:
>> 
>> https://whimsy.apache.org/board/agenda/2019-04-17.json
>> 
>> Ideally the incubator report would not be a single blob (entry 47 this
>> month), but would be a structure.
> 
> After reviewing the json wouldn’t it make sense for the incubator report to 
> just be an array of reports, just like all the other projects? Or maybe that 
> is what you meant by “structure”/
> 
> Ralph
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
> <mailto:general-unsubscr...@incubator.apache.org>
> For additional commands, e-mail: general-h...@incubator.apache.org 
> <mailto:general-h...@incubator.apache.org>

Re: board report duplication

[Ralph Goers]

> On Apr 13, 2019, at 4:27 PM, Sam Ruby  wrote:
> 
> On Sat, Apr 13, 2019 at 5:54 PM Ted Dunning  wrote:
>> 
>> Moving to a data format that makes a stronger distinction between content
>> and envelope might be nice. JSON would work if content is actually quoted
>> (don't bet on it). A directory would probably be better because the content
>> of a file can't break the meta-data in the directory. Something like a real
>> database would be even better.
> 
> This month's agenda in JSON format:
> 
> https://whimsy.apache.org/board/agenda/2019-04-17.json
> 
> Ideally the incubator report would not be a single blob (entry 47 this
> month), but would be a structure.

After reviewing the json wouldn’t it make sense for the incubator report to 
just be an array of reports, just like all the other projects? Or maybe that is 
what you meant by “structure”/

Ralph

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

Re: Challenges using Gitbox

[Ralph Goers]

> On Apr 16, 2018, at 4:22 PM, toki <toki.kant...@gmail.com> wrote:
> 
> On 04/16/2018 07:37 PM, Ralph Goers wrote:
>> IMO, it is inappropriate to add project managers to a project as a committer 
>> just because they are employed by a company that has committers who are paid 
>> to work on the project.
> 
> There are some companies who have a person whose sole duty is manage the
> employees that work on a specific open source project.
> 
> As such, open source projects have two options:
> * grant the employee position the access needed to manage the project,
> so that everybody can see what is going on;
> * deny the employ position the needed access, and be surprised by what
> the company contributes. In most instances, the surprises are things
> that were neither anticipated, nor considered needed by the non-employee
> contributors;

The implication with the way this is all being stated is that the project 
manager is making the decisions about everything and everyone is marching to 
his orders. That is just not how the ASF is supposed to operate.  It is the 
PMC’s job, as a group of collaborators, to make these decisions. That said, 
there is no reason the PMC can’t allow project managers (or anyone else) to 
make proposals regarding a roadmap using Confluence, so long as they are 
discussed and approved by the PMC. The project manager is then free to create 
Jira issues that align with the roadmap. However, what if a committer who 
doesn’t work for the same company as the project manager wants to implement one 
of the roadmap features and/or has different ideas about how it should be done? 
It is up to the PMC as a whole to resolve that, not any one individual.

What you are missing above is the third option. Grant them access to Jira and 
Confluence. Then have them discuss what they are doing on the mailing list. The 
basic difference here is that the individual is not “running” the project but 
is instead contributing to it. If,  after the merit is earned, the PMC decides 
to grant commit rights and/or make them a PMC member, then great. That is how 
it is supposed to work.

The point of all this is, the ASF isn’t trying to get in the way of anyone 
doing their job. Instead, it is trying to put each individual on an equal 
footing with everyone else. Sometimes this may get in the way of a company’s 
goals, but if they wanted to keep total control of the project then they 
shouldn’t have contributed it to the ASF.

>> 
> 
> Do you really want to see a build of, say, Apache OpenOffice, with
> complete L10N (Help documentation, UI, grammar checking, spell checking
> for both ancient, medieval, and modern forms of the official
> language(s), and writing system(s), etc.) for say, Crimea, North Korea,
> or Syria, with no prior notice, much less discussion. I have a pretty
> good idea of what ASF-Legal will say about that specific scenario.
> 
> Sure the company can just fork the project. It has happened before, and
> it will happen again. But setting up conditions where forking is the
> only option for a community based project is, IMNSHO, non-viable.
> 
>> such people can earn merit by becoming involved with the community and
> helping out where they can.
> 
> In theory, that sounds good, but as a practical matter, how many people
> that have ever been on the ASF board of directors neither know/knew, nor
> use(d) any programming languages in getting there? IOW, they got there
> exclusively on their ability to write documentation, do community
> relations, or utilize other non-coding skills?

It has happened many times. When I was a committer on Apache Cocoon we voted 
Arje Cahn as a committer for his contributions to the project which had nothing 
to do with coding. He was voted in as an ASF member for pretty much the same 
reason.

Ralph



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

Re: Challenges using Gitbox

[Ralph Goers]

> On Apr 16, 2018, at 10:46 AM, Maxime Beauchemin  
> wrote:
> 
> About PMs, or other "non-coding contributors", it's pretty common to have
> them at sponsoring organizations. For example both Airbnb and Lyft both
> have a dedicated PM for Apache Superset. While they don't write code, they
> contribute to the project and many other ways (prioritization / planning /
> road-mapping, shaping product design, communication, training,
> documentation, bug reports, issue triaging,  organizing events, ...). It
> sounds like the solution is to make them committers to provide them with
> the level of control they need on Github.

I have a problem with the way this is phrased. Companies do not do the 
prioritization, planning, road-mapping, shaping product-design, etc of ASF 
projects. The committers and PMC members do that. IMO, it is inappropriate to 
add project managers to a project as a committer just because they are employed 
by a company that has committers who are paid to work on the project. They can 
use their own Jira repo for that kind of stuff. Furthermore, merit should be 
earned, not just handed out to anyone who needs it to do the job their employer 
requires.

That said, such people can earn merit by becoming involved with the community 
and helping out where they can.

Ralph



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

Re: Challenges using Gitbox

[Ralph Goers]

> On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin  
> wrote:
> 
> Hi general@incubator!
> 
> This is an email discussing the challenges we are facing while using Github
> / Gitbox for our ASF project and wanted to start a thread to discuss
> solutions and ways we can mitigate.
> 
> We're very grateful for Gitbox, but here are the challenges we're facing
> with it:
> 
> 1. Our PMs are not committers, so they can't do simple things as labeling
> issues, closing issues and assigning issues to people. We need either for
> them to have write access to Github, or for them to get some sort of
> special committer status so they can get write access. Is voting PMs as
> committers the solution here?


I’m just wondering what a project manager is in the context of an Apache 
project? Why would anyone be assigning issues to people? This is a volunteer 
organization.  If this is being done as part of an employer then it should not 
be handled at the ASF.

Ralph

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

Re: [VOTE] Retire the HTrace Podling

[Ralph Goers]

+1 (binding)

Ralph

> On Apr 11, 2018, at 4:40 PM, lewis john mcgibbney  wrote:
> 
> Hi Folks,
> Please excuse the error on my part, which essentially missed this important
> stage of VOTE'ing on general@ for official retirement of the HTrace Podling.
> However, we are here now. The VOTE will be open for a minimum of 72 hours.
> The previous community VOTE [0] took place on the HTrace dev@ list with a
> lot of participation. I closed this off today with the RESULT [1].
> I would like to explicitly note that a subsequent parallel thread was
> initiated [2] which essentially suggested HTrace staying alive as a
> Subproject. Unfortunately this thread petered out... my inclination is that
> this outcome is that for HTrace to become a Subproject, essentially work
> would need to be done by some people... which brings us back to the initial
> reason for drafting the retirement email thread in the first place e.g.
> no-one has the time to work on HTrace any more.
> Please DISCUSS or VOTE as below
> 
> [ ] +1 retire the HTrace podling
> [ ] -1 NOT NOT retire the HTrace podling (please provide justification)
> 
> Thanks,
> Lewis
> P.S. Here is my +1
> 
> 
> [0] VOTE: https://s.apache.org/2sGB
> [1] RESULT: https://s.apache.org/e22i
> [2] https://s.apache.org/MlLn
> 
> -- 
> http://home.apache.org/~lewismc/
> http://people.apache.org/keys/committer/lewismc



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

Re: [VOTE] Accept SkyWalking into the Apache Incubator

[Ralph Goers]

+1 (binding)

Ralph

> On Dec 4, 2017, at 4:17 AM, mck  wrote:
> 
> 
> After some discussion on the SkyWalking proposal, I'd like to raise the
> vote on accepting SkyWalking into into the Apache Incubator.  
> 
> https://lists.apache.org/thread.html/b4e7205e77fe382b4cd096fb6da28b70053e0722b3dd7ae8ac389f8a@%3Cgeneral.incubator.apache.org%3E
> 
> 
> 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 peoples
> 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 SkyWalking
>[] +0 Abstain
>[] -1 Do not accept Skywalking, because ...
> 
> 
> The proposal below is also on the wiki:
> https://wiki.apache.org/incubator/SkyWalkingProposal
> 
> 
> = Abstract =
> Skywalking is an APM (application performance monitor), especially for
> microservice, Cloud Native and container-based architecture systems.
> Also known as a distributed tracing system. It provides an automatic way
> to instrument applications: no need to change any of the source code of
> the target application; and an collector with an very high efficiency
> streaming module.
> 
> = Proposal =
> The goal of this proposal is to bring the existing
> [[https://github.com/OpenSkywalking/skywalking|Skywalking]] codebase and
> existing developers and community into the Apache Software Foundation
> (ASF) in order to build a global, diverse and self-governed open source
> community in APM field. 
> 
> This project started in Open Source on GitHub about more than 2 years
> ago. Beginning with a small SDK and collector. So far the
> [[https://github.com/OpenSkywalking/Organization|OpenSkywalking]]
> governs the project through the PMC and Committer Team. 
> 
> OpenSkywalking is submitting this proposal to donate the Skywalking
> sources code and  associated artifacts (documentation, web site content,
> wiki, etc.) to the Apache Software Foundation Incubator under the Apache
> License, Version 2.0. These artifacts are currently available on GitHub
> at https://github.com/OpenSkywalking and include:
> * Skywalking: The java sniffer(agent) for collecting data, and
> collector for analysing and persistence.
> * Skywalking-UI: The web UI for skywalking APM
> 
> ''Voted on submitting the proposal to the Incubator.
> [[https://github.com/OpenSkywalking/Organization/issues/11|Check
> here]]''
> 
> = Background =
> Mircro-service, Cloud Native and container-based architecture system are
> becoming more and more popular, so the traditional monitoring, like
> application loggings, can provide less information because of the
> distributed isolates the relations. Based on the
> [[https://research.google.com/pubs/pub36356.html|Google Dapper paper]],
> many tracing systems born. The OpenSkywalking organisation was created
> with  Skywalking made based on tracing, but not just tracing, it adds
> additional value by reducing the sniffer (agent) cost, analysis and
> visualization. 
> 
> In 2015, Skywalking project started, when service-oriented architecture
> became popular. At first, skywalking provided a very simple SDK, and
> collected data into a HBASE cluster. After we opened on the GitHub, the
> community gives the feedbacks about how difficult to maintain a HBase
> cluster, even harder than the applications under monitored. So, in 2.x
> 2016, skywalking provided a self-designed storage, and update the SDK to
> a javaagent with supporting auto-instrumentation. Then since 2017, more
> and more contributors joined, we set up the PMC team and committer team.
> Skywalking evolved to an APM, and more and more features provided since
> then.
> 
> = Rationale =
> Skywalking includes these primary parts:
> 1. Provide an anto-instrument sniffer, which is based on Javaagent and
> collects events and traces happened inside JVM, with little CPU/Memory
> cost.
> 1. An extendable `tracing data protocol suit` with gRPC and HTTP
> implementations, is compatible for other language agent or SDK. 
> 1. Provide Collector, which accepts the `tracing data protocol suit`,
> and does the analysis and aggregation inside for detecting the
> relationships among applications and services, generating the metrics,
> and altering.
> 1. Provided our own UI, which visualizes the topological graph of
> related applications and services, trace stack, metrics and alerting.
> 
> Also, Skywalking team is passionate about community cooperations.
> Skywalking is a supported tracer and member of
> [[OpenTracing|http://opentracing.io]]. Also we take part in the
> [[https://github.com/TraceContext/tracecontext-spec|TraceContext
> Specs]], which is about `tracing context propagation format`. The
> founder of the project, Sheng Wu, is the member of these organizations, 
> 
> There is a strong 

[ANNOUNCEMENT] Apache Log4j 2.10.0 released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.10.0 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

This release contains new features, bugfixes and minor enhancements. Some of 
the new features include support for the Java 9 module system, support for the 
new SLF4j 1.8 binding mechanism, simplification of the Log4j property naming 
scheme, and native support of Jetty's logger. Log4j API is now a fully 
compliant Java 9 module while the other Log4j jars are Java 9 named automatic 
modules. 

This release supports both SLF4J 1.7.x and SLF4J 1.8.x. Because SLF4J 1.7.x 
requires implementations to include classes in the org.slf4j.impl package 
log4j-sl4j-impl cannot be used as a Java 9 module. Support for SLF4J 1.7.x will 
be removed in a future release.

As of Log4j 2.9.0, the Log4j API was modified to use java.util.ServiceLoader to 
locate Log4j implementations, although the former binding mechanism is still 
supported. The Log4j API jar is now a multi-release jar to provide 
implementations of Java 9 specific classes. Multi-release jars are not 
supported by the OSGi specification so OSGi modules will not be able to take 
advantage of these implementations but will not lose functionality as they will 
fall back to the implementations used in Java 7 and 8. More details on the new 
features and fixes are itemized below. Note that some tools are not compatible 
with multi-release jars and may fail trying to process class files in the 
META-INF/versions/9 folder. Those errors should be reported to the tool vendor.

During testing of the release it was found that one unit test fails when run on 
Windows. When building from source either use “mvn clean install -DskipTests” 
on Windows or run the build on a different operating system. The unit test 
failure is a problem in the test, not in Log4j. As always, pre-built 
distributions can be downloaded from http://www.apache.org/dist/logging/log4j/ 
or the binaries jars may be obtained from the Maven central repository.

Note that subsequent to the 2.9.0 release, for security reasons, 
SerializedLayout is deprecated and no longer used as default in the Socket and 
JMS appenders. SerializedLayout can still be used as before, but has to be 
specified explicitly. To retain old behaviour, you have to change configuration 
like:


  


into:


  

  


We do, however, discourage the use of SerializedLayout and recommend JsonLayout 
as a replacement:


  

  


Note that subsequent to the 2.9.0 release, for security reasons, Log4j does not 
process DTD in XML files. If you used DTD for including snippets, you have to 
use XInclude or Composite Configuration instead.

The Log4j 2.10.0 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.10.0

Changes in this version include:

New Features

• LOG4J2-2120: Properly escape newlines and other control characters in 
JSON. Thanks to Carter Douglas Kozak.
• LOG4J2-2109: Add property to disable message pattern converter 
lookups. Thanks to Carter Douglas Kozak.
• LOG4J2-2112: MapMessage should use deep toString for values. Thanks 
to Carter Douglas Kozak.
• LOG4J2-2103: XML encoding for PatternLayout.
• LOG4J2-2114: Provide a native Log4j 2 implementation of Eclipse 
Jetty's org.eclipse.jetty.util.log.Logger.
• LOG4J2-1203: Allow filtering of line breaks in layout pattern. Thanks 
to Robert Turner.
• LOG4J2-2098: Add a noop AppenderSkeleton for applications still using 
Log4j 1.x.
• LOG4J2-2062: Add possibility of sending the key of a message to Kafka 
using KafkaAppender. Thanks to Jorge Sanchez.
• LOG4J2-2056: Modularize Log4j-api and make most other log4j jars 
automatic modules.
• LOG4J2-1431: Simplify log4j system property naming scheme.
• LOG4J2-1809: Add global configuration environment SPI.
• LOG4J2-1694: Add fields with fixed values to JSON/XML/YAML layouts. 
Thanks to Michal Dvořák.
• LOG4J2-2054: Provide ways to configure SSL that avoid plain-text 
passwords in the log4j configuration. The configuration may now specify a 
system environment variable that holds the password, or the path to a file that 
holds the password.
• LOG4J2-2071: Add 
org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString().
 Thanks to Carter Kozak.

Fixed Bugs

• LOG4J2-2107: MapMessage supports both 

Re: Affiliation vs. individual

[Ralph Goers]

I have participated in a project since it was in the incubator. More than 90% 
of the committers & PMC members work for the same company. I don’t have a 
problem with that from the perspective of how the project is run. The issue I 
see is that there are only a few significant contributors and they tend to 
disappear after a year or so and be replaced by a new, suddenly active 
committer. It is obvious the person who disappeared and the new person coming 
in were being employed to maintain the project. To me, It speaks volumes that 
they don’t keep committing after the new maintainer comes along.

I’m not saying that this creates any problems from a decision making point of 
view, but it sure seems like the commitment level to the project of the 
individuals who participate isn’t very high. 

Ralph 


> On Nov 4, 2017, at 11:06 AM, Gunnar Tapper  wrote:
> 
> Hi,
> 
> I've discussed this with a few individuals but would like to raise the
> discussion with a larger group.
> 
> Situation
> 
> As contributors to the ASF, we represents ourselves as individuals. Some of
> us contribute to projects as part of our employment, some of us donate our
> time privately.
> 
> Discussion
> 
> You the individual is asked to share your employer when going through
> processes such as graduation. I get the reason: to ensure diversity in the
> project.
> 
> However, some of us are donating our private time and may therefore want to
> represent ourselves as a private donor rather than involve our employeer in
> the discussion.
> 
> [Disclosure: I work for a company that is unlikely to have an issue with my
> involvement with ASF projects outside what my company cares for.]
> 
> Proposal
> 
> Anyone that chooses to do so can use "private donation" instead of the
> employer when representing affiliation.
> 
> Thoughts?
> 
> -- 
> Thanks,
> 
> Gunnar
> *If you think you can you can, if you think you can't you're right.*



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

Re: [VOTE] Retire Sirona

[Ralph Goers]

+1 to retire.

Ralph

> On Jun 26, 2017, at 9:50 AM, John D. Ament  wrote:
> 
> All,
> 
> This is a call to vote the Sirona podling.
> 
> A vote was called for on the dev list for Sirona [1], of which one mentor
> commented and that's all.
> 
> Sirona at this point is behind 6 months on reports, has shown little
> activity since joining the incubator.  Its not clear there are 3 PPMCs
> available for a vote if need be.  Based on the prior discussions ([2] &
> [3]) and these items, I'd like to call for a vote and unilateral decision
> by the IPMC to retire Sirona.
> 
> [ ] +1 to retire Sirona
> [ ] -1 don't retire Sirona because...
> 
> Here is my +1.
> 
> John
> 
> [1]:
> https://lists.apache.org/thread.html/673daa1452150ed5ef0df4aa77f587dbac6e5a4a63670c6bf4809b17@%3Cdev.sirona.apache.org%3E
> [2]:
> https://lists.apache.org/thread.html/0a70d486680f0339bfcb4baae23c2540095fda90ca83eb414104a6fd@%3Cgeneral.incubator.apache.org%3E
> [3]:
> https://lists.apache.org/thread.html/438298290de9a3573b5e315b12e77191b27f8d91b50cf9f97e90cba8@%3Cgeneral.incubator.apache.org%3E



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

Re: [RESULT][VOTE] Return Log4cxx to the Logging Services project

[Ralph Goers]

I don’t really know the answer to that.

Ralph

> On Apr 10, 2017, at 3:35 AM, Thorsten Schöning <tschoen...@am-soft.de> wrote:
> 
> Guten Tag Ralph Goers,
> am Montag, 10. April 2017 um 01:12 schrieben Sie:
> 
>> Yes, please go ahead.
> 
> What happens to the former GIT mirror on GitHub? Should it be
> deactivated/deleted?
> 
> 2 of the 3 PRs there have already been applied in the past and I asked
> the author of the most current third one to provided another PR
> against the new repo.
> 
> https://github.com/apache/log4cxx
> 
> Mit freundlichen Grüßen,
> 
> Thorsten Schöning
> 
> -- 
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
> 
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
> 
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> 
> 
> -
> 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: [RESULT][VOTE] Return Log4cxx to the Logging Services project

[Ralph Goers]

Yes, please go ahead.

Ralph

> On Apr 9, 2017, at 3:06 PM, John D. Ament <johndam...@apache.org> wrote:
> 
> Ralph,
> 
> It looks like most everything is done.  If you don't get to it, I'll update 
> the podlings.xml and content/projects/log4cxx2.xml file to reflect graduation 
> status.
> 
> John
> 
> On Fri, Apr 7, 2017 at 1:10 AM Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> Thanks for the info Greg!
> 
> Ralph
> 
> > On Apr 6, 2017, at 9:14 PM, Greg Stein <gst...@gmail.com 
> > <mailto:gst...@gmail.com>> wrote:
> >
> > On Thu, Apr 6, 2017 at 4:04 AM, Thorsten Schöning <tschoen...@am-soft.de 
> > <mailto:tschoen...@am-soft.de> <mailto:tschoen...@am-soft.de 
> > <mailto:tschoen...@am-soft.de>>> wrote:
> > >...
> > > and I am not quite sure what the process is to move
> > > from svn to git without losing history.  I guess I will just create
> > > a Jira issue for infra and find out.
> >
> > From my understanding, a logging PMC needs to create the GIT repo:
> >
> > Yeup.
> >
> > >...
> > Additionally, the current SVN repo needs to be imported into a local
> > GIT repo and that import can than be pushed to the newly created at
> > Apache. Not sure where the SVN repo goes afterwards...
> >
> > The svn repo sticks around, and we just switch it to read-only (file an 
> > INFRA ticket when ready for that).
> >
> > In some former Mail, Matt thankfully offered to do the repo creation
> > and GIT import, but at least the import is something I could have a
> > look at myself as well. Shouldn't make any difference who pushes the
> > history in the end.
> >
> > Yes. The Logging community can run svn2git and tweak its operation until 
> > you have everything you want in the resulting (local) git repository. Once 
> > it all looks good, then push all of that history into the newly-created 
> > git-wip repository. (you may want to have INFRA disable commit emails 
> > during that push)
> >
> > Cheers,
> > Greg Stein
> > Infrastructure Administrator, ASF
> >
> 

Re: [RESULT][VOTE] Return Log4cxx to the Logging Services project

[Ralph Goers]

Thanks for the info Greg!

Ralph

> On Apr 6, 2017, at 9:14 PM, Greg Stein  wrote:
> 
> On Thu, Apr 6, 2017 at 4:04 AM, Thorsten Schöning  > wrote:
> >...
> > and I am not quite sure what the process is to move
> > from svn to git without losing history.  I guess I will just create
> > a Jira issue for infra and find out.
> 
> From my understanding, a logging PMC needs to create the GIT repo:
> 
> Yeup.
> 
> >... 
> Additionally, the current SVN repo needs to be imported into a local
> GIT repo and that import can than be pushed to the newly created at
> Apache. Not sure where the SVN repo goes afterwards...
> 
> The svn repo sticks around, and we just switch it to read-only (file an INFRA 
> ticket when ready for that).
>  
> In some former Mail, Matt thankfully offered to do the repo creation
> and GIT import, but at least the import is something I could have a
> look at myself as well. Shouldn't make any difference who pushes the
> history in the end.
> 
> Yes. The Logging community can run svn2git and tweak its operation until you 
> have everything you want in the resulting (local) git repository. Once it all 
> looks good, then push all of that history into the newly-created git-wip 
> repository. (you may want to have INFRA disable commit emails during that 
> push)
> 
> Cheers,
> Greg Stein
> Infrastructure Administrator, ASF
> 

Re: [RESULT][VOTE] Return Log4cxx to the Logging Services project

[Ralph Goers]

I figured out how to see the issue - 
https://issues.apache.org/jira/browse/INFRA-13651 
<https://issues.apache.org/jira/browse/INFRA-13651>.  It seems it is in a 
status of waiting for user but the reporter has no way to kick it back to 
infra. It has been sitting there for over a week.

Ralph


> On Apr 5, 2017, at 10:10 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> No. To be honest, I’m not 100% sure if the community wants to move to git or 
> not and I am not quite sure what the process is to move from svn to git 
> without losing history.  I guess I will just create a Jira issue for infra 
> and find out.
> 
> Also we have an outstanding infra request to combine all the logging dev 
> lists but I don’t seem to have permission to view the status of it.
> 
> Ralph
> 
>> On Apr 5, 2017, at 8:19 PM, John D. Ament <johndam...@apache.org 
>> <mailto:johndam...@apache.org>> wrote:
>> 
>> Ralph,
>> 
>> Have you completed the process?  I see log4cxx is still listed as active in 
>> the incubator records.
>> 
>> John
>> 
>> On Thu, Mar 16, 2017 at 10:45 PM Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> This vote has been open for more than 5 days. It received 5 +1 votes and no 
>> other votes. So we will begin the process of moving the project back to 
>> Logging Services.
>> 
>> Ralph
>> 
>> > On Mar 11, 2017, at 10:31 AM, Ralph Goers <ralph.go...@dslextreme.com 
>> > <mailto:ralph.go...@dslextreme.com>> wrote:
>> >
>> > Log4cxx was originally a sub-project of the Logging Services. In 2013 
>> > several users became frustrated that they were submitting patches but 
>> > there were no committers who could apply them. The Logging Services PMC 
>> > was not comfortable making them committers as that would have given them 
>> > commit rights to all the Logging Services projects, which at that time 
>> > were all hosted in Subversion. As a consequence Log4cxx became an 
>> > incubator project in hopes those who had expressed interest would start 
>> > actively contributing to the project. After 3 1/2 years this has not had 
>> > the hoped for result, although it does have more activity than it did 
>> > prior to entering the incubator.
>> >
>> > The Logging Services PMC believes there is no longer a point to having 
>> > Log4cxx remain in the incubator. The one active committer on Log4cxx has 
>> > been voted in as a Logging Services committer and the PMC has voted [1] to 
>> > move the project back to Logging Services. This is a vote for the 
>> > incubator to affirm that move.
>> >
>> > [] +1 Move the project back to Logging Services
>> > [] +0 I don’t care where the project resides
>> > [] -1 The project should remain in the incubator because …
>> >
>> >
>> > [1] 
>> > https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser
>> >  
>> > <https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser>
>> >  
>> > <https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser
>> >  
>> > <https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser>>
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
>> <mailto:general-unsubscr...@incubator.apache.org>
>> For additional commands, e-mail: general-h...@incubator.apache.org 
>> <mailto:general-h...@incubator.apache.org>
>> 
> 

Re: [RESULT][VOTE] Return Log4cxx to the Logging Services project

[Ralph Goers]

No. To be honest, I’m not 100% sure if the community wants to move to git or 
not and I am not quite sure what the process is to move from svn to git without 
losing history.  I guess I will just create a Jira issue for infra and find out.

Also we have an outstanding infra request to combine all the logging dev lists 
but I don’t seem to have permission to view the status of it.

Ralph

> On Apr 5, 2017, at 8:19 PM, John D. Ament <johndam...@apache.org> wrote:
> 
> Ralph,
> 
> Have you completed the process?  I see log4cxx is still listed as active in 
> the incubator records.
> 
> John
> 
> On Thu, Mar 16, 2017 at 10:45 PM Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> This vote has been open for more than 5 days. It received 5 +1 votes and no 
> other votes. So we will begin the process of moving the project back to 
> Logging Services.
> 
> Ralph
> 
> > On Mar 11, 2017, at 10:31 AM, Ralph Goers <ralph.go...@dslextreme.com 
> > <mailto:ralph.go...@dslextreme.com>> wrote:
> >
> > Log4cxx was originally a sub-project of the Logging Services. In 2013 
> > several users became frustrated that they were submitting patches but there 
> > were no committers who could apply them. The Logging Services PMC was not 
> > comfortable making them committers as that would have given them commit 
> > rights to all the Logging Services projects, which at that time were all 
> > hosted in Subversion. As a consequence Log4cxx became an incubator project 
> > in hopes those who had expressed interest would start actively contributing 
> > to the project. After 3 1/2 years this has not had the hoped for result, 
> > although it does have more activity than it did prior to entering the 
> > incubator.
> >
> > The Logging Services PMC believes there is no longer a point to having 
> > Log4cxx remain in the incubator. The one active committer on Log4cxx has 
> > been voted in as a Logging Services committer and the PMC has voted [1] to 
> > move the project back to Logging Services. This is a vote for the incubator 
> > to affirm that move.
> >
> > [] +1 Move the project back to Logging Services
> > [] +0 I don’t care where the project resides
> > [] -1 The project should remain in the incubator because …
> >
> >
> > [1] 
> > https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser
> >  
> > <https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser>
> >  
> > <https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser
> >  
> > <https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser>>
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
> <mailto:general-unsubscr...@incubator.apache.org>
> For additional commands, e-mail: general-h...@incubator.apache.org 
> <mailto:general-h...@incubator.apache.org>
> 

[RESULT][VOTE] Return Log4cxx to the Logging Services project

[Ralph Goers]

This vote has been open for more than 5 days. It received 5 +1 votes and no 
other votes. So we will begin the process of moving the project back to Logging 
Services.

Ralph

> On Mar 11, 2017, at 10:31 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> Log4cxx was originally a sub-project of the Logging Services. In 2013 several 
> users became frustrated that they were submitting patches but there were no 
> committers who could apply them. The Logging Services PMC was not comfortable 
> making them committers as that would have given them commit rights to all the 
> Logging Services projects, which at that time were all hosted in Subversion. 
> As a consequence Log4cxx became an incubator project in hopes those who had 
> expressed interest would start actively contributing to the project. After 3 
> 1/2 years this has not had the hoped for result, although it does have more 
> activity than it did prior to entering the incubator.
> 
> The Logging Services PMC believes there is no longer a point to having 
> Log4cxx remain in the incubator. The one active committer on Log4cxx has been 
> voted in as a Logging Services committer and the PMC has voted [1] to move 
> the project back to Logging Services. This is a vote for the incubator to 
> affirm that move. 
> 
> [] +1 Move the project back to Logging Services
> [] +0 I don’t care where the project resides
> [] -1 The project should remain in the incubator because …
> 
> 
> [1] 
> https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser
>  
> <https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser>



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

Re: [VOTE] Return Log4cxx to the Logging Services project

[Ralph Goers]

There was a discussion on the log4cxx list on March 1st and 2nd so Thorsten is 
aware. He also accepted the invite to be a Logging Services committer.

Yes, the vote had to happen on the private list. The Logging PMC is looking at 
ways to correct that.

Here is my +1

Ralph

> On Mar 11, 2017, at 10:44 AM, John D. Ament <johndam...@apache.org> wrote:
> 
> That link doesn't work for me (its a logging PMC only link).  I'm worried
> about the vote happening in private but think I understand why.
> 
> Here's a valid link to the vote thread:
> https://lists.apache.org/thread.html/f1bed2e2964fc8de4004aeff2b14f8f99931db2c5d574704b17e16c9@%3Cprivate.logging.apache.org%3E
> 
> I just want to confirm that its well understood by Thorsten that its being
> moved back, and if so here's my +1.
> 
> John
> 
> On Sat, Mar 11, 2017 at 12:31 PM Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> 
>> Log4cxx was originally a sub-project of the Logging Services. In 2013
>> several users became frustrated that they were submitting patches but there
>> were no committers who could apply them. The Logging Services PMC was not
>> comfortable making them committers as that would have given them commit
>> rights to all the Logging Services projects, which at that time were all
>> hosted in Subversion. As a consequence Log4cxx became an incubator project
>> in hopes those who had expressed interest would start actively contributing
>> to the project. After 3 1/2 years this has not had the hoped for result,
>> although it does have more activity than it did prior to entering the
>> incubator.
>> 
>> The Logging Services PMC believes there is no longer a point to having
>> Log4cxx remain in the incubator. The one active committer on Log4cxx has
>> been voted in as a Logging Services committer and the PMC has voted [1] to
>> move the project back to Logging Services. This is a vote for the incubator
>> to affirm that move.
>> 
>> [] +1 Move the project back to Logging Services
>> [] +0 I don’t care where the project resides
>> [] -1 The project should remain in the incubator because …
>> 
>> 
>> [1]
>> https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser
>> <
>> https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser
>>> 



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

[VOTE] Return Log4cxx to the Logging Services project

[Ralph Goers]

Log4cxx was originally a sub-project of the Logging Services. In 2013 several 
users became frustrated that they were submitting patches but there were no 
committers who could apply them. The Logging Services PMC was not comfortable 
making them committers as that would have given them commit rights to all the 
Logging Services projects, which at that time were all hosted in Subversion. As 
a consequence Log4cxx became an incubator project in hopes those who had 
expressed interest would start actively contributing to the project. After 3 
1/2 years this has not had the hoped for result, although it does have more 
activity than it did prior to entering the incubator.

The Logging Services PMC believes there is no longer a point to having Log4cxx 
remain in the incubator. The one active committer on Log4cxx has been voted in 
as a Logging Services committer and the PMC has voted [1] to move the project 
back to Logging Services. This is a vote for the incubator to affirm that move. 

[] +1 Move the project back to Logging Services
[] +0 I don’t care where the project resides
[] -1 The project should remain in the incubator because …


[1] 
https://mail-search.apache.org/pmc/private-arch/logging-private/201703.mbox/browser
 

Re: Log4jcxx2 status

[Ralph Goers]

OK. Before we hold a vote on general I think we should hold a vote in logging 
service, although I really don’t know what would happen if it didn’t pass. 
Unfortunately, the board isn’t going to be happy since the only sane place to 
have that vote is on the private list. Most of the PMC members don’t subscribe 
to the log4cxx dev list. We will be rectifying that by moving to having just 
one dev list for all sub projects as Commons does.

Ralph

> On Mar 6, 2017, at 3:04 PM, John D. Ament <johndam...@apache.org> wrote:
> 
> Ralph,
> 
> Sounds fair to me.  Based on what we did for CommonsRDF, I'd recommend that
> we hold a vote on the general@incubator list indicating the intent to
> transfer log4cxx from Incubator to Logging.  The steps are pretty close on
> http://incubator.apache.org/guides/graduation.html#subproject
> 
> John
> 
> On Mon, Mar 6, 2017 at 12:19 PM Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> 
>> The attempt to reboot Log4cxx has not had the hoped for results. Under
>> normal circumstances the project would probably be terminated at Apache.
>> However, this project came to the incubator from the Logging Services
>> project in hopes that it would be able to generate more activity since
>> there were people who said they were interested but didn’t have enough
>> activity to warrant making them a Logging committer. At some point in time
>> the intention was to move the project back into Logging Services.
>> 
>> Because of this history the Logging PMC feels the project should just move
>> back into the Logging project. The Logging PMC voted to add the one active
>> committer in Log4cxx to the Logging project so there should be no problem
>> there.  At that point the Logging PMC would manage the project similar to
>> some of the other not-so-active projects it has.
>> 
>> Thoughts?
>> 
>> Ralph
>> 
>> -
>> 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

Log4jcxx2 status

[Ralph Goers]

The attempt to reboot Log4cxx has not had the hoped for results. Under normal 
circumstances the project would probably be terminated at Apache. However, this 
project came to the incubator from the Logging Services project in hopes that 
it would be able to generate more activity since there were people who said 
they were interested but didn’t have enough activity to warrant making them a 
Logging committer. At some point in time the intention was to move the project 
back into Logging Services.

Because of this history the Logging PMC feels the project should just move back 
into the Logging project. The Logging PMC voted to add the one active committer 
in Log4cxx to the Logging project so there should be no problem there.  At that 
point the Logging PMC would manage the project similar to some of the other 
not-so-active projects it has.

Thoughts?

Ralph

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

Re: [ALL] Volunteers for a Math IPMC?

[Ralph Goers]

I thought this had been made clear.  Several months Commons voted to make Math 
a TLP. But shortly after that most of the people involved with Commons Math 
felt that a TLP at the ASF would not work for them, so they forked the project 
and left, effectively voiding the TLP vote since the proposed PMC is no longer 
valid.  There is one person left who was very involved in Commons Math and a 
few other people who have expressed interest in joining the new community.  

So this is a situation where we have an already existing code base where a lot 
of the people left are not familiar with quite a bit of it.  The new group of 
people who are interested are trying to determine how they should move forward. 
There is some talk of breaking Commons Math into smaller components and 
possibly dropping some where there is no one to maintain it.  

Ralph

> On Jun 11, 2016, at 6:21 PM, Niclas Hedhman  wrote:
> 
> If you have a functioning community around Commons Math already, why do you
> feel you need Incubation?
> 
> People on a Math TLP would come out of the Commons PMC and simply submit a
> Board Resolution, and I doubt that there would be any objects. There are no
> legal concerns, no community training, no need for release management
> training, and so on...
> 
> Or are you looking at a situation where the Commons community has no
> interest in Math subproject, and need new blood?
> 
> 
> Cheers
> Niclas
> 
> On Sat, Jun 11, 2016 at 6:25 PM, James Carman 
> wrote:
> 
>> We (the Commons PMC) have not decided yet what to do, but I just wanted to
>> gauge the interest in joining the math IPMC if we choose to go TLP by way
>> of the incubator. The idea would be that math (whatever its name may be),
>> would go through the incubator in order to enrich its community prior to
>> becoming a TLP. Do we have any folks willing to throw their hat in the
>> ring?
>> 
>> p.s. I've cross-posted to the incubator list as there are folks there who
>> are very good at this stuff and could perhaps lend us some advice.
>> 
> 
> 
> 
> -- 
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java



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

Re: [VOTE] Accept PredictionIO into the Apache Incubator

[Ralph Goers]

+1 (binding)

Ralph

> On May 24, 2016, at 3:44 AM, John D. Ament  wrote:
> 
> +1
> 
> On Mon, May 23, 2016 at 6:23 PM Andrew Purtell  wrote:
> 
>> Since discussion on the matter of PredictionIO has died down, I would like
>> to call a VOTE
>> on accepting PredictionIO into the Apache Incubator.
>> 
>> Proposal: https://wiki.apache.org/incubator/PredictionIO
>> 
>> ​[ ] +1 Accept PredictionIO into the Apache Incubator
>> [ ] +0 Abstain
>> [ ] -1 Do not accept PredictionIO into the Apache Incubator, because ...
>> 
>> This vote will be open for at least 72 hours.
>> 
>> My vote is +1 (binding)
>> 
>> --
>> 
>> 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.
>> 
>> 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 

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

[Ralph Goers]

+1 (binding)

Ralph

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

Re: [VOTE] Accept Gossip into the Apache Incubator

[Ralph Goers]

+1 (binding)

Ralph

> 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 

Re: [VOTE] Graduate Sentry

[Ralph Goers]

+1 (binding)

Ralph

> On Feb 24, 2016, at 12:20 PM, Sravya Tirukkovalur  wrote:
> 
> Hi all,
> 
> Following the positive discussion[1] and vote[2] in the Sentry
> community and a discussion[3] on the incubator list to graduate
> Sentry, I am calling a VOTE to graduate the project from the Incubator
> to a TLP. Please vote on the resolution pasted below.
> 
> [ ] +1 Graduate Sentry from the Incubator
> [ ] +0 Don't care
> [ ] -1 Don't graduate Sentry from the Incubator (please specify reason)
> 
> This vote will be open for at least 72 hours.
> 
> References:
> 
> [1] https://s.apache.org/dev_discuss
> [2] https://s.apache.org/dev_vote_result
> [3] https://s.apache.org/general_discuss
> Other:
> https://s.apache.org/general_notify
> https://cwiki.apache.org/confluence/display/SENTRY/Sentry+maturity+assessment
> 
> Resolution to create a TLP from graduating Incubator podling:
> 
> ==
> 
> 
> X. Establish the Apache Sentry 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 Fine grained authorization to data and
> metadata in Hadoop.
> 
>  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>  Committee (PMC), to be known as the "Apache Sentry Project",
>  be and hereby is established pursuant to Bylaws of the
>  Foundation; and be it further
> 
>  RESOLVED, that the Apache Sentry Project be and hereby is
>  responsible for the creation and maintenance of software
>  related to Fine grained authorization to data and metadata in Hadoop;
>  and be it further
> 
>  RESOLVED, that the office of "Vice President, Apache Sentry" 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 Sentry Project, and to have primary responsibility
>  for management of the projects within the scope of
>  responsibility of the Apache Sentry 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 Sentry Project:
> 
>* Ali Rizvi 
> 
>   * Anne Yu 
> 
>   * Arun Suresh 
> 
>   * Brock Noland 
> 
>   * Chaoyu Tang 
> 
>   * Colin Ma 
> 
>   * Daisy Zhou 
> 
>   * Dapeng Sun 
> 
>   * David Nalley 
> 
>   * Erick Tryzelaar 
> 
>   * Gregory Chanan 
> 
>   * Guoquan Shen 
> 
>   * Hadi Nahari 
> 
>   * Hao Hao 
> 
>   * Jarek Jarcec Cecho 
> 
>   * Johnny Zhang 
> 
>   * Karthik Ramachandran 
> 
>   * Mark Grover 
> 
>   * Milo Polte 
> 
>   * Lenni Kuff 
> 
>   * Patrick Daly 
> 
>   * Patrick Hunt 
> 
>   * Prasad Mujumdar 
> 
>   * Raghu Mani 
> 
>   * Sean Mackrory 
> 
>   * Shreepadma Venugopalan 
> 
>   * Sravya Tirukkovalur 
> 
>   * Tuong Truong 
> 
>   * Vamsee Yarlagadda 
> 
>   * Xiaomeng Huang 
> 
>   * Xuefu Zhang 
> 
>  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Sravya Tirukkovalur
>  be appointed to the office of Vice President, Apache Sentry, 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 Sentry 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 Sentry Project; and be it further
> 
>  RESOLVED, that the Apache Sentry Project be and hereby
>  is tasked with the migration and rationalization of the Apache
>  Incubator Sentry podling; and be it further
> 
>  RESOLVED, that all responsibilities pertaining to the Apache
>  Incubator Sentry podling encumbered upon the Apache Incubator
>  Project are hereafter discharged.
> 
> ==
> 
> 
> 

Re: Help for the Log4cxx podling

[Ralph Goers]

I have to point out that all of this is exactly why the project moved to the 
incubator from the logging project.  While all the logging projects are 
obviously related by what they do, the language and implementation differences 
make it difficult for committers to cross over from one project to the other so 
it was hoped going to incubator would signal people interested in the project 
to get involved. 

Having said that, Log4j 1.x has barely had any life for years, was recently 
marked as end-of-life and still has a huge number of users using it  and 
periodically asking for fixes that will never happen. It is still the most used 
logging framework. While Log4j 2 is in much better shape, we too have a hard 
time attracting committers. We get lots of people submitting one time patches 
but very few stick around. 

I don’t know if it is just because working on logging isn’t as sexy as working 
on a NoSQL thingy or what, but all the logging projects have trouble attracting 
new committers, even though they still seem to be quite popular and people 
still seem to expect them to magically have new releases.

Ralph



> On Jan 7, 2016, at 5:31 AM, Greg Stein  wrote:
> 
> On Thu, Jan 7, 2016 at 6:16 AM, John D. Ament  wrote:
> 
>> ...
>> Your lack of mentors is probably the biggest issue on the incubator side.
>> Without mentors, you have no one to steer you through graduation.  Though
>> Marvin raises a good point - you're coming from an existing TLP, not only
>> would incubation be optional if the logging TLP chose to bring you in, but
>> having the backing of logging likely means there are other existing members
>> out there that can help you through incubation.
>> 
> 
> They arrived from an existing TLP, and have been around for a LONG time. I
> don't think Mentors are the problem at all. ... there is simply no
> community. (and Mentors will not and cannot solve that)
> 
> IMO, close it down.
> 
> Cheers,
> -g
> 
> ps. as ALv2 source, of course anybody willing can clone it elsewhere, but
> may need to change the name.



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

Re: Impala commit policy

[Ralph Goers]

Virtually any project you look at is going to have portions that are fairly 
complex and portions that are pretty straightforward.  In my opinion the 
correct approach is to identify the parts of the code that a) seem to be most 
susceptible to bugs, b) are hard to understand well, or c) where simple changes 
can have huge impacts on performance and then use RTC for those areas. In 
addition, you might want to require RTC for significant new feature additions. 
Although I expect every project to have code that falls into these categories 
the ratio of that code will vary from project to project. As an example, I can 
honestly say that with Flume the File Channel should always be RTC. But almost 
everything else could be done more effectively with CTR.

Ralph



> On Dec 3, 2015, at 11:20 AM, Henry Robinson  wrote:
> 
> I'm happy to field technical questions about Impala. You seem to be
> conflating 'complexity' with 'severity of potential bugs' - I see the two
> as separate.
> 
> Under the 'severity' heading, Impala both writes and reads data from a
> variety of data stores. So if there's a bug in Impala's write path, data
> can be lost. But because Impala also returns results to client
> applications, there's a significant risk of business impact if the *wrong*
> results are returned. I know, because I have dealt with situations where
> this has happened, and no-one is very happy about it. Our customers
> typically run business-critical analytic workloads through Impala; if it
> stops working correctly that's usually a big problem.
> 
> As far as 'complexity' goes, I make no comparative claims about Impala's
> complexity vs any other project. But to give some indication of the moving
> parts inside Impala: there's a component which compiles highly optimised
> versions of each query operator at run time, there's a query planner which
> parses and plans a large portion of the SQL standard, there is the added
> complexity of being a 'massively' (with many deployments in the high 100s
> of nodes) distributed system with the added coordination and consistency
> guarantees that brings to it, and there is also the added complexity of
> running highly concurrent workloads in a single process, with all the
> concurrency headaches etc. that can bring. That's not to mention
> implementations of 'standard' SQL operators like joins, sorts and so on
> that are still the subject of active research in academia and industry.
> 
> All this is in the context of Impala's main differentiator, which is that
> it is amongst the very fastest SQL engine for data stored in HDFS and
> friends. That means that small changes can have large unexpected
> consequences, since efficiency is a subtle and capricious thing. It has
> always, therefore, helped us to have more than one set of eyes on every
> change in the past, to ensure that the probability of the introduction of
> subtle performance and functional regressions is reduced. Automated testing
> plays a huge role here as well, but for us it's been most effective in
> concert with code review.
> 
> (There are other reasons I vastly prefer RTC as well, but I'm addressing
> your specific points here so as not to kick off another RTCvsCTR thread :)).
> 
> 
> 
>> 
>> In this case, the RTC seems to stem from the choice of Gerrit, rather than
>> some innate complexity.
>> 
>> 
> 
> Gerrit does not mandate RTC, since you can just push to refs/heads/
> and bypass the review creation step.
> 
> Historically, the Impala team at Cloudera has used at least three different
> review tools (including Review Board, which is used elsewhere at the ASF).
> The choice of review tool stems completely from pragmatism - we really did
> not like Review Board, and briefly used Rietveld before moving to Gerrit
> which we have preferred. At every step, we used RTC.
> 
> Henry
> 
> 
> 
>> I *do* note that possibly committers could choose to commit directly, or
>> choose to use Gerrit when they are unsure. Will the (P)PMC allow those
>> direct commits? Or mandate Gerrit for every commit?
>> 
>> Cheers,
>> -g

Re: [RESULT] [VOTE] Accept Impala into the Apache Incubator

[Ralph Goers]

The only mention of consensus I could find is in the actual development of the 
actual proposal. I’m sure one could argue that that implies that whether 
consensus is achieved is by the vote, but with a group as large as the IPMC it 
would be horrible to allow a single vote to block a podling from entering.

Ralph


> On Dec 1, 2015, at 3:46 PM, Daniel Gruno <humbed...@apache.org> wrote:
> 
> On 12/01/2015 11:37 PM, Henry Robinson wrote:
>> On 1 December 2015 at 14:32, Bertrand Delacretaz <bdelacre...@apache.org>
>> wrote:
>> 
>>> On Tue, Dec 1, 2015 at 10:51 PM, Henry Robinson <he...@apache.org> wrote:
>>>> ...
>>>> Binding -1s (4):
>>>>Greg Stein
>>>>Ralph Goers
>>>>Roman Shaposhnik
>>>>Konstantin Boudnik ...
>>> 
>>> Please indicate how the issues that are behind these -1s have been
>>> addressed.
>>> 
>>> I might have missed something, just had a quick look at the VOTE thread.
>>> 
>> 
>> Do they have to be addressed for the vote to pass? My understanding was
>> that this vote was by majority, and that -1s did not act as vetos.
>> 
> 
> Given as we have no actual incubator policy that states whether
> consensus is required or not - or at least none that I could find -  one
> would assume this falls back to the default "3x+1 and more +1s than -1s"
> here, with consensus being something we strive for, but not a mandatory
> outcome.
> 
> What Bertrand might be trying to ask here is whether the concerns have
> been addressed in the sense that there have been replies and a
> discussion surrounding these topics.
> 
> You don't necessarily need to have everyone agree with you, but you
> should at least have a discussion about your different opinions.
> 
> With regards,
> Daniel.
> 
>> Best,
>> Henry
>> 
>> 
>> 
>>> 
>>> -Bertrand
>>> 
>>> -
>>> 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: RTC vs CTR (was: Concerning Sentry...)

[Ralph Goers]

Sorry Jim. As an attempt to shut down a thread, this wasn't a very good one.  
Not a single poster in this thread has a problem with the word, or the concept 
of, "review". It is the process that is the issue and what the impact of that 
process is upon a community.

Ralph

> On Nov 26, 2015, at 6:50 AM, Jim Jagielski  wrote:
> 
> OK, ok... we are at diminishing returns here with people
> no longer, imo, listening to what others are saying...
> 
> We have, as a foundation, and HAVE HAD RTC and CTR for years
> and decades. There are times when one or the other are Good
> and when they are Bad. Those exact times will, generally,
> vary depending on a lot of factors.
> 
> We use the right process when it is Good.
> 
> We don't use it when it is Bad.
> 
> Just as 'meritocracy' is not a bad word, as much as
> some people wish to re-define it as such, neither is the
> word 'Review'. 
> 
> -
> 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...)

[Ralph Goers]

> On Nov 25, 2015, at 3:22 PM, Todd Lipcon  wrote:
> 
> Isn't it an issue of scalability? With pre-commit code reviews, typically
> the uploader of the code will pick out one or two people to review the code
> who know the area well. Or, if no one is picked by the submitter of the
> patch, the committers will organically end up deciding who is to review the
> code, at which point that reviewer ends up being a sort of shepherd for the
> patch, sticking with the contributor through multiple revs until it's ready
> for commit.
> 
> With post-commit review, do you expect to watch the mailing list and review
> every patch that comes in? In a project like Hadoop, that's not feasible --
> we've had ~35,000 lines of code changed in the last month in 267 patches.
> If everyone tries to review every patch post-commit, you end up with n^2
> work as the community grows.

Maven is a large project with a decent number of committers. People naturally 
pick their areas and review the code in their areas of interest because it is 
important to them. Maven also has a large suite of integration tests for the 
core and a group of people who are interested in that. Each of the Maven 
plugins has a group of people who gravitate towards them. No one really has to 
assign anything.

With Log4j we have one individual who commits a lot but most of his commits are 
to change variable names, fix javadoc bugs, and other general code cleanup 
tasks.  I will look at the commit log message and won’t review those directly 
because I know that is what he is doing. But when he makes a code change with a 
Jira issue tag I will do my best to review that. That won’t be reflected on the 
dev list because I only comment when I find something that needs to be updated.

The major difference I see between the CTR projects and the RTC projects is 
that the RTC projects mandate that everything has to go through the 
review-then-commit process.  CTR projects a) allow portions of the project to 
be RTC or b) allow committers to choose to use RTC for specific commits.  It is 
almost like we are dealing with the difference between the GPL, where the code 
is supposedly free, and non-copyleft licenses where the user is free. Both can 
get the job done but both come with a different set of benefits and costs. Much 
as I don’t care to participate in GPL projects I also don’t care to participate 
in pure RTC projects as both restrict me in ways I very much dislike,

Ralph




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

[Ralph Goers]

1. What makes you think all bugs are caught during code reviews (they aren’t)?
2. What makes you think that code reviews after the commit are any less 
thorough than reviews required before the commit?

If you don’t trust your community to do code reviews after you commit then 
there is a problem in your community. Forcing a code review to occur first 
won’t fix that.

In a CTR world you can choose to do every piece of work on a branch and ask for 
a code review before you commit. That is your choice.  But if you know that the 
code you are committing is good because you have a thorough knowledge of your 
product you shouldn’t be forced to have it reviewed before you can commit it.  
I actually love the line in Kudu where it says that automation insures quality. 
I am a big fan of that. In my experience having lots of tests is the best way 
to insure stuff doesn’t get broken.

So how did you catch the bugs in your code in Flex?  Would you have preferred 
that they stay on a branch for months so they could be reviewed before 
committing?  Despite how great people say git is I have still had lots of 
problems resolving merge conflicts when the code isn’t merged back quickly.  If 
I understand what you are saying you would prefer that Flex use RTC because you 
don’t trust your fellow committers to review your code.  That is a community 
problem that needs to be fixed. Forcing them to review the code first isn’t the 
proper way to fix it.

Ralph

> On Nov 25, 2015, at 2:00 PM, Harbs  wrote:
> 
> If a review is required for non-code changes to the main branch, then I agree.
> 
> I’m sure you agree that reviews on code make for less bugs. We all make 
> mistakes and can overlook things. It seems kind of extreme to assume that 
> this kind of required review is all about control. Since anyone who can 
> commit can review, it’s kind of hard for me to swallow that.
> 
> I assume your logic is that the reviews can come after the commit. Sure. But 
> what if it doesn’t?
> 
> Case in point: I made some pretty major changes to TLF in Flex which 
> constituted a number of months of work. I’m willing to bet that not every 
> commit I did was checked by others. I did a decent job, but there were a few 
> regressive bugs in my code, and I accidentally reverted some code in my 
> commit as well. In a workflow where my code would have to get one or more +1s 
> before I committed it to the main branch, it’s likely that the reverted 
> commit (at the least) would have been caught.
> 
> I would actually welcome knowing someone looked over my code for a sanity 
> check.
> 
> Harbs
> 
> On Nov 25, 2015, at 10:49 PM, Greg Stein  wrote:
> 
>> That is pretty normal operation in both styles of workflow. My concern is
>> with trunk/master. Is a committer trusted enough to make changes directly?
>> 
>> If all meaningful changes (ie. changing APIs and algorithms, not just
>> fixing typos w/o review) are not trusted, and require review/permission,
>> then I'm against that.
>> 
>> It is good practice to put potentially disruptive code onto a branch while
>> it is developed, then merge it when complete. Trusting a committer to ask
>> for review before the merge is great. Requiring it, less so.
>> 
>> But RTC on trunk/master is harmful.
>> 
>> Cheers,
>> -g
>> 
>> On Wed, Nov 25, 2015 at 2:44 PM, Harbs  wrote:
>> 
>>> What about commit to feature/bug brach, review and then commit to main
>>> branch?
>>> 
>>> Is that CTR or RTC in your book?
>>> 
>>> On Nov 25, 2015, at 10:42 PM, Greg Stein  wrote:
>>> 
 I object to Lucene's path, too. A committer's judgement is not trusted
 enough to make a change without upload/review. They need permission first
 (again: to use your term; it works great).
 
 On Wed, Nov 25, 2015 at 2:39 PM, Upayavira  wrote:
 
> Some setups that people call RTC are actually CTR in your nomenclature,
> so we could be talking cross-purposes. That's all I'm trying to avoid.
> E.g. Lucene - everything happens in JIRA first (upload patch, wait for
> review), but once that has happened, you are free to commit away. So
> strictly, it is RTC, but not seemingly in the sense you are objecting
> to.
> 
> Upayavira
> 
> On Wed, Nov 25, 2015, at 08:35 PM, Greg Stein wrote:
>> I think this is a distraction. You said it best the other day: RTC
>> implies
>> the need for "permission" before making a change to the codebase.
>> Committers are not trusted to make a judgement on whether a change
>>> should
>> be made.
>> 
>> CTR trusts committers to use their judgement. RTC distrusts committers,
>> and
>> makes them seek permission [though one of several mechanisms].
>> 
>> -g
>> 
>> On Wed, Nov 25, 2015 at 10:47 AM, Upayavira  wrote:
>> 
>>> Not replying to this mail specifically, but to the thread in

Re: [VOTE] Accept Impala into the Apache Incubator

[Ralph Goers]

-1 (binding)
I’d like to see the project start with CTR and use RTC only for specific cases 
(like where tests must be modified, over X (1000 lines?) of code added, etc.

Ralph


> On Nov 24, 2015, at 2:03 PM, Henry Robinson  wrote:
> 
> Hi -
> 
> The [DISCUSS] thread has been quiet for a few days, so I think there's been
> sufficient opportunity for discussion around our proposal to bring Impala
> to the ASF Incubator.
> 
> I'd like to call a VOTE on that proposal, which is on the wiki at
> https://wiki.apache.org/incubator/ImpalaProposal, and which I've pasted
> below.
> 
> During the discussion period, the proposal has been amended to add Brock
> Noland as a new mentor, to add one missed committer from the list and to
> correct some issues with the dependency list.
> 
> Please cast your votes as follows:
> 
> [] +1, accept Impala into the Incubator
> [] +/-0, non-counted vote to express a disposition
> [] -1, do not accept Impala into the Incubator (please give your reason(s))
> 
> As with the concurrent Kudu vote, I propose leaving the vote open for a
> full seven days (to close at Tuesday, December 1st at noon PST), due to the
> upcoming US holiday.
> 
> Thanks,
> Henry
> 
> 
> 
> = Abstract =
> Impala is a high-performance C++ and Java SQL query engine for data stored
> in Apache Hadoop-based clusters.
> 
> = Proposal =
> 
> We propose to contribute the Impala codebase and associated artifacts (e.g.
> documentation, web-site content etc.) to the Apache Software Foundation
> with the intent of forming a productive, meritocratic and open community
> around Impala’s continued development, according to the ‘Apache Way’.
> 
> Cloudera owns several trademarks regarding Impala, and proposes to transfer
> ownership of those trademarks in full to the ASF.
> 
> = Background =
> Engineers at Cloudera developed Impala and released it as an
> Apache-licensed open-source project in Fall 2012. Impala was written as a
> brand-new, modern C++ SQL engine targeted from the start for data stored in
> Apache Hadoop clusters.
> 
> Impala’s most important benefit to users is high-performance, making it
> extremely appropriate for common enterprise analytic and business
> intelligence workloads. This is achieved by a number of software
> techniques, including: native support for data stored in HDFS and related
> filesystems, just-in-time compilation and optimization of individual query
> plans, high-performance C++ codebase and massively-parallel distributed
> architecture. In benchmarks, Impala is routinely amongst the very highest
> performing SQL query engines.
> 
> = Rationale =
> 
> Despite the exciting innovation in the so-called ‘big-data’ space, SQL
> remains by far the most common interface for interacting with data in both
> traditional warehouses and modern ‘big-data’ clusters. There is clearly a
> need, as evidenced by the eager adoption of Impala and other SQL engines in
> enterprise contexts, for a query engine that offers the familiar SQL
> interface, but that has been specifically designed to operate in massive,
> distributed clusters rather than in traditional, fixed-hardware,
> warehouse-specific deployments. Impala is one such query engine.
> 
> We believe that the ASF is the right venue to foster an open-source
> community around Impala’s development. We expect that Impala will benefit
> from more productive collaboration with related Apache projects, and under
> the auspices of the ASF will attract talented contributors who will push
> Impala’s development forward at pace.
> 
> We believe that the timing is right for Impala’s development to move
> wholesale to the ASF: Impala is well-established, has been Apache-licensed
> open-source for more than three years, and the core project is relatively
> stable. We are excited to see where an ASF-based community can take Impala
> from this strong starting point.
> 
> = Initial Goals =
> Our initial goals are as follows:
> 
> * Establish ASF-compatible engineering practices and workflows
> * Refactor and publish existing internal build scripts and test
> infrastructure, in order to make them usable by any community member.
> * Transfer source code, documentation and associated artifacts to the ASF.
> * Grow the user and developer communities
> 
> = Current Status =
> 
> Impala is developed as an Apache-licensed open-source project. The source
> code is available at http://github.com/cloudera/Impala, and developer
> documentation is at https://github.com/cloudera/Impala/wiki. The majority
> of commits to the project have come from Cloudera-employed developers, but
> we have accepted some contributions from individuals from other
> organizations.
> 
> All code reviews are done via a public instance of the Gerrit review tool
> at http://gerrit.cloudera.org:8080/, and discussed on a public mailing
> list. All patches must be reviewed before they are accepted into the
> codebase, via a voting mechanism that is similar to that used on 

Re: [VOTE] Accept Kudu into the Apache Incubator

[Ralph Goers]

-1 (binding)
I’d like to see the project start with CTR and use RTC only for specific cases 
(like where tests must be modified, over X (1000 lines?) of code added, etc.

I must say I do find the part about achieving quality through automation 
attractive, but following that up with requiring RTC leads me to conclude that 
the project doesn’t really believe that to be true.

Ralph

> On Nov 24, 2015, at 12:32 PM, 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 

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

[Ralph Goers]

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

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

[Ralph Goers]

A combination approach seems like it would be the best to me. Is the process 
you guys use documented?  

As I said, the part that bothers me with the way RTC is done in the project I 
am involved in is that I can’t commit my own stuff.

Ralph


> On Nov 20, 2015, at 6:09 AM, Jim Jagielski  wrote:
> 
> Lets recall that 'review' is not just about trust (or whether
> or not it exists), it's also about this little thing called
> *oversight*. It's to ensure that at least 3 people are
> engaged enough to be able to not only vet the code/patch/whatever,
> but to make sure that should the original patch provider
> drop out of sight, that there are enough people around to
> keep that code up-to-date.
> 
> As Joe sez, this whole discussion seems weird to me. httpd
> (for example) uses RTC, CTR and Lazy Consensus simultaneously
> and works like a dream. And considering that httpd is pretty
> much the "standard" or "basis" for the Apache Way (or, at least
> one of the main ones), any suggestion that one of these methods
> is broken, or whatever, seems wonky.
> 
>> On Nov 17, 2015, at 9:05 AM, Ted Dunning  wrote:
>> 
>> On Tue, Nov 17, 2015 at 10:33 PM, Jim Jagielski  wrote:
>> 
>>> Certainly we need both a
>>> Review and a Commit and one must be done before the other,
>>> right?
>>> 
>> 
>> Well, not necessarily.  We need a commit.  The review is, strictly
>> speaking, optional. That means that the three choices are C, RTC, CTR.  The
>> empty string is plausible, but implies a dead community.
> 
> 
> -
> 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...)

[Ralph Goers]

And there is another problem I have. Maybe it isn’t true of all projects, but 
the one I am involved with says the author can’t commit his own code. So the 
commit logs will not reflect who actually authored the code but who reviewed 
it. 

I could probably tolerate RTC if I had to have the commit somewhere it could be 
reviewed, I had to wait for the review and fix any defects and then could 
commit the code myself (ideally even if no one actually reviewed it). That 
process isn’t really much different than what I do for my larger commits 
anyway. But just submitting something for review and then hoping someone 
reviews it and then hoping someone commits it takes all the joy out of it for 
me.

Ralph

> On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
> 
> 
> Sure, that's a big problem with some RTC workflows. Using gerrit or github
> PRs makes the flow much easier -- for a trivial or small patch, the sort
> that a "drive-by" contributor typically contributes, there probably won't
> be any review comments. So, they just push the patch for review, and they
> can be out of the loop for the rest of it. If the patch requires small
> revisions (eg addressing a typo or something) I think it's fine for the
> reviewer to just make the change themselves and commit on behalf of the
> original author to avoid the issue you've raised. Most RTC workflows permit
> this kind of thing in my experience.



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

[Ralph Goers]

Greg, which of these do you use when the “contributor” is a committer? Remember 
the model here is that the author is never allowed to commit their own code.

Ralph

> On Nov 19, 2015, at 3:10 PM, Greg Stein <gst...@gmail.com> wrote:
> 
> The Apache Subversion project does something similar:
> 
> http://subversion.apache.org/docs/community-guide/conventions.html#crediting
> 
> We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
> On Nov 19, 2015 1:57 PM, "Chris Nauroth" <cnaur...@hortonworks.com> wrote:
> 
>> Some projects use the git Signed-off-by field in the commit log to
>> differentiate the author from the reviewer.
>> 
>> --Chris Nauroth
>> 
>> 
>> 
>> 
>> On 11/19/15, 10:58 AM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote:
>> 
>>> And there is another problem I have. Maybe it isn¹t true of all projects,
>>> but the one I am involved with says the author can¹t commit his own code.
>>> So the commit logs will not reflect who actually authored the code but
>>> who reviewed it.
>>> 
>>> I could probably tolerate RTC if I had to have the commit somewhere it
>>> could be reviewed, I had to wait for the review and fix any defects and
>>> then could commit the code myself (ideally even if no one actually
>>> reviewed it). That process isn¹t really much different than what I do for
>>> my larger commits anyway. But just submitting something for review and
>>> then hoping someone reviews it and then hoping someone commits it takes
>>> all the joy out of it for me.
>>> 
>>> Ralph
>>> 
>>>> On Nov 19, 2015, at 10:10 AM, Todd Lipcon <t...@cloudera.com> wrote:
>>>> 
>>>> 
>>>> Sure, that's a big problem with some RTC workflows. Using gerrit or
>>>> github
>>>> PRs makes the flow much easier -- for a trivial or small patch, the sort
>>>> that a "drive-by" contributor typically contributes, there probably
>>>> won't
>>>> be any review comments. So, they just push the patch for review, and
>>>> they
>>>> can be out of the loop for the rest of it. If the patch requires small
>>>> revisions (eg addressing a typo or something) I think it's fine for the
>>>> reviewer to just make the change themselves and commit on behalf of the
>>>> original author to avoid the issue you've raised. Most RTC workflows
>>>> permit
>>>> this kind of thing in my experience.
>>> 
>>> 
>>> 
>>> -
>>> 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: RTC vs CTR (was: Concerning Sentry...)

[Ralph Goers]

Yes, it was a trick question. But it proves my point. I can’t imagine a world 
where someone would refuse to participate in a project because it was CTR, but 
in my view this variation of RTC definitely limits the number of people wanting 
to join. I am sure this is going to be a controversial statement, but I have 
noticed that the projects that I’ve seen do this often have a fair number of 
committers who are paid to work on the project by their employer and I have to 
admit that I have wondered if these projects do this actually want to limit 
participation.

Ralph

> On Nov 19, 2015, at 6:05 PM, Greg Stein <gst...@gmail.com> wrote:
> 
> Trick question, as I'd never work under that model :-)
> 
> Apache Subversion is CTR, with a very low bar to get commit access to
> portions of the tree or a branch (only PMC members get access to whole
> tree, so we grant full access and PMC membership simultaneously). We don't
> need a fancy label for "contributor who is a committer" because such a
> concept is anathema to the Subversion community's peer respect model.
> 
> On Thu, Nov 19, 2015 at 6:38 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> 
>> Greg, which of these do you use when the “contributor” is a committer?
>> Remember the model here is that the author is never allowed to commit their
>> own code.



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

[Ralph Goers]

None of your statements below are any different between RTC or CTR. The only 
time it makes aa difference is if no one does reviews.  My feeling is that a 
community that insists on RTC believes that code will not be reviewed unless 
committers are forced to do it.

All I can say, is that for me personally I have found the process of having to 
create a patch, submit a code review, wait for the review and participate in 
it, then wait for the commit to be onerous enough that I just don’t bother.  As 
I said, in a CTR community there are many times where branches are created and 
the code is reviewed there before being merged because the authors believe the 
code is significant enough to require it.  The author is then the one who 
merges the branch once the reviews are complete.  To be perfectly honest, this 
pretty much exactly matches the way software is created in the development team 
I work with in the $day$ job too.

Ralph

> On Nov 18, 2015, at 12:22 AM, Todd Lipcon  wrote:
> 
> I gave the logical and valid reasoning in previous posts in this thread:
> 1) no matter how seasoned a committer you are, you might make mistakes
> which are easily caught in code review
> 2) no matter how good you are at coding, your code might not make sense to
> a second pair of eyes, who can ask you to improve comments or docs
> 3) no matter if your code is perfect, the act of another person reading
> your code builds shared ownership over the code, thus alleviating
> bus-factor issues and improving the general feeling of a cohesive community
> developing a single project instead of a loose coalition of people with
> their own fiefdoms.
> 
> I believe this to be generally accepted in the software engineering
> community. I don't know practices at every company, but I know at least
> that most of the well-regarded technology companies I've met with have some
> form of pre-commit review, and certainly many highly adopted open source
> projects as well (especially in infrastructure software).
> 
> Either a high percentage of the world does this for "no logical or valid
> reason" or this is just a matter of opinion, and like I said, we can agree
> to disagree.
> 
> -Todd



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

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

[Ralph Goers]

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.

Ralph

> On Nov 11, 2015, at 11:16 AM, Joe Witt  wrote:
> 
> "Trust is the basis of a healthy community"
> 
> -- For sure.
> 
> "and RTC (via Jira or otherwise) just screams "we don't trust you. we
> must review all commits first.""
> 
> -- I disagree.  RTC has merit independent of concerns of trust.  If
> trust issues are present in a community then any number of challenges
> will exist and all processes will suffer.  Keep in mind RTC applies to
> everyone (PMC, committer, contributor).  So it isn't about trust at
> all.  It is about community.
> 
> Not wanting to sidetrack this thread but also didn't want that comment
> to go without a counter.
> 
> Thanks
> Joe



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

Re: [VOTE] Accept Eagle into Apache Incubation

[Ralph Goers]

+1 (binding)

Ralph

> On Oct 23, 2015, at 7:11 AM, Manoharan, Arun  wrote:
> 
> Hello Everyone,
> 
> Thanks for all the feedback on the Eagle Proposal.
> 
> I would like to call for a [VOTE] on Eagle joining the ASF as an incubation 
> project.
> 
> The vote is open for 72 hours:
> 
> [ ] +1 accept Eagle in the Incubator
> [ ] ±0
> [ ] -1 (please give reason)
> 
> Eagle is a Monitoring solution for Hadoop to instantly identify access to 
> sensitive data, recognize attacks, malicious activities and take actions in 
> real time. Eagle supports a wide variety of policies on HDFS data and Hive. 
> Eagle also provides machine learning models for detecting anomalous user 
> behavior in Hadoop.
> 
> The proposal is available on the wiki here:
> https://wiki.apache.org/incubator/EagleProposal
> 
> The text of the proposal is also available at the end of this email.
> 
> Thanks for your time and help.
> 
> Thanks,
> Arun
> 
> 
> 
> Eagle
> 
> Abstract
> Eagle is an Open Source Monitoring solution for Hadoop to instantly identify 
> access to sensitive data, recognize attacks, malicious activities in hadoop 
> and take actions.
> 
> Proposal
> Eagle audits access to HDFS files, Hive and HBase tables in real time, 
> enforces policies defined on sensitive data access and alerts or blocks 
> user’s access to that sensitive data in real time. Eagle also creates user 
> profiles based on the typical access behaviour for HDFS and Hive and sends 
> alerts when anomalous behaviour is detected. Eagle can also import sensitive 
> data information classified by external classification engines to help define 
> its policies.
> 
> Overview of Eagle
> Eagle has 3 main parts.
> 1.Data collection and storage - Eagle collects data from various hadoop logs 
> in real time using Kafka/Yarn API and uses HDFS and HBase for storage.
> 2.Data processing and policy engine - Eagle allows users to create policies 
> based on various metadata properties on HDFS, Hive and HBase data.
> 3.Eagle services - Eagle services include policy manager, query service and 
> the visualization component. Eagle provides intuitive user interface to 
> administer Eagle and an alert dashboard to respond to real time alerts.
> 
> Data Collection and Storage:
> Eagle provides programming API for extending Eagle to integrate any data 
> source into Eagle policy evaluation framework. For example, Eagle hdfs audit 
> monitoring collects data from Kafka which is populated from namenode log4j 
> appender or from logstash agent. Eagle hive monitoring collects hive query 
> logs from running job through YARN API, which is designed to be scalable and 
> fault-tolerant. Eagle uses HBase as storage for storing metadata and metrics 
> data, and also supports relational database through configuration change.
> 
> Data Processing and Policy Engine:
> Processing Engine: Eagle provides stream processing API which is an 
> abstraction of Apache Storm. It can also be extended to other streaming 
> engines. This abstraction allows developers to assemble data transformation, 
> filtering, external data join etc. without physically bound to a specific 
> streaming platform. Eagle streaming API allows developers to easily integrate 
> business logic with Eagle policy engine and internally Eagle framework 
> compiles business logic execution DAG into program primitives of underlying 
> stream infrastructure e.g. Apache Storm. For example, Eagle HDFS monitoring 
> transforms audit log from Namenode to object and joins sensitivity metadata, 
> security zone metadata which are generated from external programs or 
> configured by user. Eagle hive monitoring filters running jobs to get hive 
> query string and parses query string into object and then joins sensitivity 
> metadata.
> Alerting Framework: Eagle Alert Framework includes stream metadata API, 
> scalable policy engine framework, extensible policy engine framework. Stream 
> metadata API allows developers to declare event schema including what 
> attributes constitute an event, what is the type for each attribute, and how 
> to dynamically resolve attribute value in runtime when user configures 
> policy. Scalable policy engine framework allows policies to be executed on 
> different physical nodes in parallel. It is also used to define your own 
> policy partitioner class. Policy engine framework together with streaming 
> partitioning capability provided by all streaming platforms will make sure 
> policies and events can be evaluated in a fully distributed way. Extensible 
> policy engine framework allows developer to plugin a new policy engine with a 
> few lines of codes. WSO2 Siddhi CEP engine is the policy engine which Eagle 
> supports as first-class citizen.
> Machine Learning module: Eagle provides capabilities to define user activity 
> patterns or user profiles for Hadoop users based on the user behaviour in the 
> platform. These user profiles are modeled using Machine Learning algorithms 

Re: [DISCUSS] Mentor neutrality policy

[Ralph Goers]

Is there something else going on that I am not aware of?  Is someone using 
undue influence where they shouldn’t be? 

On the Legal list dealing with hypothetical situations is continually avoided. 
While a code of conduct for mentors might make sense, penalizing mentors who 
are trying to educate and really help a new project seen heavy handed.

Without a real use case I think this whole discussion is a solution looking for 
a problem and should be tabled.

Ralph


> On Oct 11, 2015, at 6:47 AM, Daniel Gruno  wrote:
> 
> On 10/11/2015 03:44 PM, John D. Ament wrote:
>> On Sun, Oct 11, 2015 at 9:36 AM Daniel Gruno  wrote:
>> 
>>> On 10/11/2015 03:34 PM, Mark Struberg wrote:
 
> Am 11.10.2015 um 14:45 schrieb Pierre Smits :
> 
> Producing good code is a community effort. When it comes down to just
>>> the
> mentors fix that themselves, there is something wrong with the
>>> community of
> the podling.
 
 I never questioned that.
 
 But the proposal sounds that a mentor _must not_ contribute to the
>>> project itself but just mentor it.
 And I personally question if this is efficient and we would get enough
>>> mentors in that case.
>>> 
>>> The proposal was changed to address that concern. see
>>> <56181303.7000...@apache.org>
>>> 
>> 
>> And how does one access this?
>> 
> 
> Sorry, I just posted the Message ID. It can be found on the
> mail-archives or through our Pony Mail PoC site at
> https://pony-poc.apache.org/thread.html/87bfb7d68294f0872f524b5418f5369a388b3128ff00d53b25df07f0@118307@%3Cgeneral.incubator.apache.org%3E
>  
> 
> 
> With regards,
> Daniel.
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
> 
> For additional commands, e-mail: general-h...@incubator.apache.org 
> 

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Ralph Goers]

I am in the same boat as Alex with regard to QT, but Apache Pivot also has a 
similar goal.

Ralph

> On Sep 7, 2015, at 9:43 PM, Alex Harui  wrote:
> 
> Apologies if I’m way off base here as I’m not familiar with Corinthia or
> QT Editor.  If Corinthia were to  develop the web-based editor mentioned
> upthread and make that the preferred/recommended editor for the project,
> does that make the QT Editor optional enough for Apache?
> 
> Apache Flex is a UI Toolkit for web apps as well as
> desktop and mobile apps and the community is working on a version that
> outputs HTML/JS/CSS that can be consumed by Apache Cordova to target
> multiple platforms.
> 
> -Alex
> 
> On 9/7/15, 2:37 AM, "Greg Stein"  wrote:
> 
>> On Sep 7, 2015 4:12 PM, "Jochen Theodorou"  wrote:
>>> ...
>>> I am not sure that approach is realistic. I mean, if you say it must be
>> optional and not required, then there must be an existing alternative. And
>> that alternative must be not LGPL. If there is such a toolkit, then why
>> not
>> go with that right away? The project has to manage its resources well.
>> 
>> Exactly. Without an alternative, then you have a pile of code that doesn't
>> meet any user expectations.
>> 
>> If it can be released as a library, for downstream users to produce an
>> editor, then okay. But an releasing an editor with no UI is kind of a
>> non-starter. :-(
>> 
>> Given the UI landscape, and its licensing, I can see why Corinthia would
>> like to host elsewhere. One day, we'll see some permissive UI
>> libraries
>> 
>> Cheers,
>> -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: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Ralph Goers]

Licensing is always a thorny issue.  

In general, http://www.apache.org/legal/resolved.html#optional 
 says that you can use 
libraries under licenses such as the LGPL for optional dependencies. This is so 
that user’s can use your project in its base mode with no “surprises”.

However, if the library is something that you would expect to be already 
installed on the platform(s) you support that is a different story. See 
http://www.apache.org/legal/resolved.html#platform 
.

If someone can take your work, modify it, and then attach whatever license they 
want to the combined work then whatever you are doing is probably OK. 

Ralph



> On Sep 6, 2015, at 10:43 AM, Peter Kelly  wrote:
> 
>> On 6 Sep 2015, at 11:22 pm, Jochen Theodorou  wrote:
>> 
>> Am 06.09.2015 04:22, schrieb Dave Fisher:
>> [...]
>>> Also Apache needs a release policy for binaries that would allow the best 
>>> UX/UI API for the platform to be used even if it is GPL. If you have 
>>> subscribed to legal-discuss the last few months you know why that 
>>> discussion was impossible. If that can be worked out then at least it would 
>>> help other projects.
>> 
>> can you explain the case a bit? Do you link statically? What is the license?
> 
> We wanted to use Qt, the open source version of which is LGPL. All other 
> suitable candidates we could find were similar; GTK is LGPL, and wxWidgets 
> has a license that is very close to LGPL. We also needed to use WebKit, 
> regardless of the toolkit involved, and that is (mostly I think) LGPL also.
> 
> There was some debate about whether or not it was ok to write an application 
> which used Qt, though we did not propose including any of the actual Qt 
> source code in the release artefacts. It would be used as an external 
> library, dynamically linked, similar to how many programs use glibc.
> 
> An assertion was made in the discussion that if we cannot develop our app 
> without using Qt, it should not be part of the project (I assume this same 
> argument would have been made if we had chosen one of the others above). 
> Given that this app was a major component (though by no means all) of what we 
> planned to do, it seemed that if that argument was valid (and I don’t think 
> it was, but I’m still not sure), we would have to do so outside of ASF.
> 
> There were numerous other factors involved with our design to resign, mostly 
> involving personal disputes among PPMC members which I won’t get into here 
> out of respect for all involved. But the discussion about licensing and 
> implications for the project was one of the factors, and certainly caused a 
> division in the community.
> 
> If it’s not possible to write apps using LGPL libraries as part of apache 
> projects, then this seems to pretty much rule out any cross-platform native 
> desktop apps, unless you write your own toolkit. I realise OpenOffice has 
> it’s own custom toolkit which is still used for historical reasons, but I 
> don’t think that can adapt well to mobile platforms, so other than that that 
> there don’t seem to be any viable choices which could work with the policy.
> 
> —
> Dr Peter M. Kelly
> pmke...@apache.org
> 
> PGP key: http://www.kellypmk.net/pgp-key 
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> 

Re: Wiki access

[Ralph Goers]

The userid is RalphGoers.

Ralph

 On Aug 4, 2015, at 5:41 PM, Marvin Humphrey mar...@rectangular.com wrote:
 
 On Tue, Aug 4, 2015 at 5:30 PM, Ralph Goers ralph.go...@dslextreme.com 
 wrote:
 For some reason I am not able to edit any pages on the incubator wiki.  I 
 could swear I used to be able to do that.  Does someone have karma to fix 
 this?
 
 Like all Apache wikis, the Incubator wiki had to implement
 whitelisting to counter spam.  I don't see anything resembling your
 name on http://wiki.apache.org/incubator/ContributorsGroup.  Let me
 know your Incubator wiki login and I'll add it.
 
 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: apache binary distributions

[Ralph Goers]

 On Aug 5, 2015, at 5:44 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 On Tue, Aug 4, 2015 at 1:08 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 On Tue, Aug 4, 2015 at 2:22 AM, Jochen Theodorou blackd...@gmx.org wrote:
 
 It was also mentioned here, that for example publishing snapshot builds to
 maven central is not allowed. I guess in the release document they are
 basically to be handled as nightly builds and as such not for the general
 public, thus only for the dev-list. It was said, that having the SNAPSHOT
 appendix in the jar name as well as not being able to automatically get
 them via maven without having to add that tag is not enough for the
 end-user to know for, that this is no official release. And that if such
 things are going into the distribution repository, they have to be handled
 as release, including voting and such. For that I guess it does not matter
 if it is the apache repository or something else.
 
 What would happen if a third party would do this? Is the project/apache
 required to do something about this? I mean if you read this:
 http://mail-archives.apache.org/mod_mbox/incubator-general/201506.mbox/%3CD1B01671.4EE90%25rvesse%40dotnetrdf.org%3E
 some even see nightly builds, not communicated beyond the dev-list on
 non-apache servers already as a problem.
 
 Let us put that last part a step up... Let us assume someone takes one of
 the released sources of one of the java projects out there, makes maven
 artifacts out of it and publishes them at maven central. Is that ok? I mean
 that is very near the distributor case, so it should be ok, or not?
 
 
 That is fine.  Just make sure that the published org is NOT org.apache.foo
 
 What do you mean by publishing org in the context of the Maven Central?
 
 Thanks,
 Roman.

Maven Central has rules about what they will and won’t accept.  
1. My understanding is they will only accept artifacts that have a groupId of 
org.apache if they come from the Apache repository manager, except for what 
would have to be unusual circumstances (they might, for example, accept a new 
version of a project that has moved to the attic, but I would expect that they 
would try to confirm that wherever the artifact came from has taken over that 
project).
2. You cannot publish SNAPSHOTs to Maven Central.

See https://maven.apache.org/guides/mini/guide-central-repository-upload.html 
https://maven.apache.org/guides/mini/guide-central-repository-upload.html

Ralph

Wiki access

[Ralph Goers]

For some reason I am not able to edit any pages on the incubator wiki.  I could 
swear I used to be able to do that.  Does someone have karma to fix this?

Ralph

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

Re: [IP CLEARANCE] HornetQ code grant

[Ralph Goers]

Actually, if you look at the CCLA you will see that you can also do a software 
grant with it.

Ralph

 On Jul 4, 2015, at 11:58 PM, Niclas Hedhman nic...@hedhman.org wrote:
 
 AFAIK, a CCLA from RedHat is not the correct agreement. It should have been
 a Software Grant.
 
 CCLA is acknowledgement that staff are allowed to contribute in the future.
 Software Grant is an agreement from the copyright owner that it approves
 that the IP can continue its life at ASF.
 
 Niclas
 On Jul 2, 2015 12:38, Gary Tully gtu...@apache.org wrote:
 
 Hello,
 on behalf of the ActiveMQ project I would like to request a check of the
 IP clearance for the HornetQ code grant:
 
 https://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/hornetq.xml?view=markup
 Easier to read html version:
 http://incubator.apache.org/ip-clearance/hornetq.html
 
 Please vote to approve this grant.
 Lazy consensus applies.
 If no -1 votes are cast within the next 72 hours, the vote passes.
 
 Thank you,
 Gary.
 
 -
 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: Licensing Issue

[Ralph Goers]

While this is all true, there is a key point in the policy that should be 
considered [1]. 

“Will the majority of users want to use my product without adding the optional 
components”?  

So if a Language Module is required and BerkeleyLM is so substandard that no 
one will really use it, then you aren’t really achieving what the policy is 
saying.


Ralph

[1] - http://www.apache.org/legal/resolved.html#optional 
http://www.apache.org/legal/resolved.html#optional
 On Jun 20, 2015, at 8:42 PM, Niclas Hedhman nic...@hedhman.org wrote:
 
 As Ted is hinting, try to make a Joshua specific abstraction of the
 Language Module, and  then provide N implementations. The KenLM
 implementation could be hosted outside ASF, in case Legal doesn't approve
 (can't recall the status of that) of using KenLM's published API, and users
 have to make the separate download of KenLM.
 
 Painful, yes somewhat... But I think you could provide a script that does
 all the work, just make sure that the User is well-informed.
 
 Niclas
 
 On Sun, Jun 21, 2015 at 7:07 AM, Ted Dunning ted.dunn...@gmail.com wrote:
 
 Yes.  That does sound like a blocker as it stands.
 
 Is there any prospect for relicensing?
 
 Is the BerkeleyLM package suitable for pulling into the Joshua project so
 that KenLM becomes an optional dependency?
 
 
 
 On Sat, Jun 20, 2015 at 3:50 PM, Lewis John Mcgibbney 
 lewis.mcgibb...@gmail.com wrote:
 
 Hi Folks,
 I am looking for some advice here.
 We are currently in conversation about potentially transitioning the
 Joshua
 project [0] to the foundation. Our current conversation is ongoing at
 [1].
 From one of the key developers of Joshua, the following question has
 arose;
 There is an issue with an LGPL'd library for handling language models
 (KenLM
 https://github.com/kpu/kenlm). There is an alternative (BerkeleyLM),
 but
 it is not actively maintained any more and is not quite as good as KenLM
 in
 a few key respects. A quick glance at the incubator page suggests that
 this
 dependency would keep the project from becoming a full-fledged one. Can
 you
 comment on this?
 Thanks for any input folks
 Lewis
 
 [0] http://joshua-decoder.org/
 [1] https://github.com/joshua-decoder/joshua/issues/204
 
 --
 *Lewis*
 
 
 
 
 
 -- 
 Niclas Hedhman, Software Developer
 http://zest.apache.org - New Energy for Java

Re: [VOTE] Accept Freemarker into Apache Incubator

[Ralph Goers]

 source developers. Freemarker to date has 
 been developed as an open source project.
 
 Homogeneous Developers
 
 The Freemarker community is not backed up by any corporation and is diverse 
 in terms of geography and backgrounds of developers.
 
 Reliance on Salaried Developers
 
 The Freemarker contributors are volunteers that are not paid for their 
 contributions to the project.
 
 Relationships with Other Apache Products
 
 Freemarker is an independent product but there are some relationships with 
 other Apache products. Freemarker currently uses some Apache products, mostly 
 in its build process (for example Apache Ant, Apache Ivy, Apache Xalan). 
 Freemarker has been integrated into other Apache products such as Apache 
 OFBiz, Apache Struts, Apache Camel, Apache Tiles. Becoming part of the ASF 
 family could strengthen the collaboration with these and other projects. 
 Apache Velocity is similar in purpose to Freemarker and both address similar 
 needs for a template language in text generating applications. However 
 Freemarker and Apache Velocity have a very different philosophy, design and 
 implementation and there is a sufficient user base and history for both 
 projects to justify their independent existence.
 
 An Excessive Fascination with the Apache Brand
 
 While we intend to leverage the Apache ‘branding’ when talking to other 
 projects as testament of our project’s ‘neutrality’, we have no plans for 
 making use of Apache brand in press releases nor posting billboards 
 advertising acceptance of Freemarker into Apache Incubator.
 
 Documentation
 
 A mature project website is available at freemarker.org. In the website a 
 complete manual is available: http://freemarker.org/docs/index.html
 
 Initial Source
 
 Initial source is available on GitHub under the ALv2:
 
• https://github.com/freemarker/freemarker: The template engine itself
• https://github.com/freemarker/site: Generates the freemarker.org Web site
• https://github.com/freemarker/docgen: Transforms an XDocBook subset to 
 HTML; used for the Freemarker Manual. (Also for the Web site in the future.)
 
 Source and Intellectual Property Submission Plan
 
 We know of no legal encumberments in the way of transfer of source to Apache. 
 The copyright holders are the three main contributors in the history of the 
 project, of which one is the current maintainer and main actor in this 
 incubation process. The other two have been contacted to sign the Software 
 License Agreement.
 
 External Dependencies
 
 The dependencies all have Apache compatible licenses.
 
 Required Resources
 
 Mailing lists
 
• priv...@freemarker.incubator.apache.org (moderated subscriptions)
• d...@freemarker.incubator.apache.org
• notificati...@freemarker.incubator.apache.org (commits, CI reports)
 
 Git Repository
 
• https://git-wip-us.apache.org/repos/asf/incubator-freemarker.git: the 
 template engine itself
• https://git-wip-us.apache.org/repos/asf/incubator-freemarker-site.git: 
 generates the freemarker.org Web site
• https://git-wip-us.apache.org/repos/asf/incubator-freemarker-docgen.git: 
 transforms an XDocBook subset to HTML; used for the Freemarker Manual (also 
 for the Web site in the future).
 
 Issue Tracking
 
 JIRA Freemarker (FREEMARKER)
 
 Initial Committers
 
• Dániel Dékány, ddekany at freemail.hu
• Evangelia Dendramis, evangeliad at gmail.com
 
 Affiliations
 
• Independent: Dániel Dékány
• Independent: Evangelia Dendramis
 
 Sponsors
 
 Champion
 
 Jacopo Cappellato
 
 Nominated Mentors
 
• David E. Jones - Apache Member
• Jacopo Cappellato - Apache Member
• Jean-Frederic Clere - Incubator PMC
• Ralph Goers - Incubator PMC
• Sergio Fernández - Incubator PMC
 
 Sponsoring Entity
 
 We would like to propose Apache Incubator to sponsor this project.
 


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

Re: [DISCUSS] Freemarker Incubation proposal

[Ralph Goers]

As soon as it can be done. The question is, why would you want to wait?  The 
point is, you don’t want to get approval for the project and then have everyone 
lose interest because there is no code to work on.

Ralph

 On Jun 3, 2015, at 12:01 AM, Daniel Dekany ddek...@freemail.hu wrote:
 
 So then I suppose my question can be reduced to: After the voting has
 concluded with positive result (for entering incubation), when must we
 migrate the source code to ASF?
 
 -- 
 Thanks,
 Daniel Dekany
 
 
 Wednesday, June 3, 2015, 2:05:57 AM, Ralph Goers wrote:
 
 IMO, once the source code is migrated to the ASF you should not do
 any more releases outside the ASF.  I would attempt to clear up as
 many IP issues as you can before entering but I believe several
 projects have resolved their IP issues while in the incubator.  In
 the worst case some code may need to be rewritten.
 
 Ralph
 
 On Jun 2, 2015, at 4:54 PM, Daniel Dekany ddek...@freemail.hu wrote:
 
 But before that... a question. Let's say the voting has a positive
 result. Can we still do Freemarker releases outside ASF (with the
 current owners and source code repository) after that? For how long?
 My concern is that when we are already in the incubator, we can't
 release from it as far as ASF finds that there are unsettled IP
 issues. Like if someone finds out that an SGL is needed from X who we
 haven't seen in the last 15 years, that can take a while, which is OK,
 but until that I can't do releases (and in general I can't be sure
 what will happen with the work committed). Is it possible to only
 enter incubation when there are no known blockers that would make
 releases impossible? Or how does it work?
 
 -- 
 Thanks,
 Daniel Dekany
 
 
 Thursday, May 28, 2015, 4:11:49 PM, Bertrand Delacretaz wrote:
 
 Hi,
 
 On Thu, May 28, 2015 at 4:07 PM, Jacopo Cappellato
 jacopo.cappell...@gmail.com wrote:
 ...PS: who should start the vote?..
 
 In general that's the role of the podling's champion.
 
 -Bertrand
 
 
 -
 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] Freemarker Incubation proposal

[Ralph Goers]

I would proceed with the plan that the project will succeed in graduating. 

Usually project names stay with the ASF. I am not sure what the policy would be 
for a project that failed to graduate. I would suspect the project could keep 
it after leaving.  However, if the project fails to graduate the likelihood of 
it succeeding anywhere would be minimal.

Ralph

 On Jun 2, 2015, at 4:42 PM, Daniel Dekany ddek...@freemail.hu wrote:
 
 That's certainly won't be a problem in reality, as Jacopo said.
 
 What I'm curious about is if what happens if Freemarker gets into the
 Incubator but then sadly later fails to graduate, so then it has to
 continue outside ASF, probably with the earlier owners. I guess then
 we will have to fork the work done during incubation (or can that be
 given back with some kind of SLG?), which is messy (complicates the
 license permanently, right?), but doable. But we will need to get the
 product name back too! Is that promised formally somewhere, or how
 does that go? Well, let's hope no such thing will happen, but still, I
 should know this.
 
 -- 
 Thanks,
 Daniel Dekany
 
 
 Thursday, May 28, 2015, 11:39:17 AM, Bertrand Delacretaz wrote:
 
 Hi,
 
 On Thursday, May 28, 2015, Jacopo Cappellato jacopo.cappell...@gmail.com
 wrote:
 
 ...Should we move to the next step (that I think is starting a vote)?...
 
 
 I think so, with two comments:
 
 Having just two committers is very small but that can hopefully be solved
 during incubation.
 
 The proposal does not mention how the Freemarker name/trademark donation
 will be handled, if the copyright owners also own the name that won't be a
 problem. And anyway that can be solved during incubation, but if you can
 make sure before entering incubation that the name can be donated that's
 easier.
 
 -Bertrand
 
 
 
 
 -
 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] Freemarker Incubation proposal

[Ralph Goers]

IMO, once the source code is migrated to the ASF you should not do any more 
releases outside the ASF.  I would attempt to clear up as many IP issues as you 
can before entering but I believe several projects have resolved their IP 
issues while in the incubator.  In the worst case some code may need to be 
rewritten.

Ralph

 On Jun 2, 2015, at 4:54 PM, Daniel Dekany ddek...@freemail.hu wrote:
 
 But before that... a question. Let's say the voting has a positive
 result. Can we still do Freemarker releases outside ASF (with the
 current owners and source code repository) after that? For how long?
 My concern is that when we are already in the incubator, we can't
 release from it as far as ASF finds that there are unsettled IP
 issues. Like if someone finds out that an SGL is needed from X who we
 haven't seen in the last 15 years, that can take a while, which is OK,
 but until that I can't do releases (and in general I can't be sure
 what will happen with the work committed). Is it possible to only
 enter incubation when there are no known blockers that would make
 releases impossible? Or how does it work?
 
 -- 
 Thanks,
  Daniel Dekany
 
 
 Thursday, May 28, 2015, 4:11:49 PM, Bertrand Delacretaz wrote:
 
 Hi,
 
 On Thu, May 28, 2015 at 4:07 PM, Jacopo Cappellato
 jacopo.cappell...@gmail.com wrote:
 ...PS: who should start the vote?..
 
 In general that's the role of the podling's champion.
 
 -Bertrand
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 



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

Re: [VOTE] Accept Mysos into the Apache Incubator

[Ralph Goers]

+1

Ralph

 On May 28, 2015, at 9:14 AM, Jake Farrell jfarr...@apache.org wrote:
 
 Based on the earlier discussion in thread [1], I would like to call a VOTE
 to accept Mysos, an Apache Mesos framework for running MySQL instances, as
 a new Apache Incubator project.
 
 The proposal is available on the wiki at [2] and is also attached below
 
 The VOTE is open for at least the next 72 hours:
 
  [ ] +1 Accept Mysos into the Apache Incubator
  [ ] ±0
  [ ] -1 Do not accept Mysos into the Apache Incubator because...
 
 I would like to get the voting started with my own +1
 
 Thank you
 -Jake
 
 [1]: http://s.apache.org/2vm
 [2]: https://wiki.apache.org/incubator/MysosProposal
 
 
 
 Mysos Proposal
 
 Abstract
 
 Mysos is an Apache Mesos framework for running MySQL instances.
 
 Proposal
 
 Mysos runs on Apache Mesos (cluster manager) to dramatically simplify the
 management of MySQL instances. It is designed to offer:
 
 Efficient hardware utilization through multi-tenancy (in
 performance-isolated containers)
 High reliability through preserving the MySQL state during failure and
 automatic backing up to/restoring from HDFS
 An automated self-service option for bringing up new MySQL clusters
 High availability through automatic MySQL master failover
 An elastic solution that allows users to easily scale up and down a MySQL
 cluster by changing the number of slave instances
 Background
 
 Initial development of Mysos was done at Twitter, and its codebase was
 recently open sourced. This proposal is for Mysos to join the Apache
 Incubator.
 
 Rationale
 
 Mysos is built to be used by anyone who desires to run MySQL on Apache
 Mesos, and in the near-future it will take advantage of state primitives
 that are being added to the Mesos core:
 https://issues.apache.org/jira/browse/MESOS-1554
 
 Furthermore, the rapid growth of Mysos community is empowered by open
 source. We believe the Apache Foundation is a great fit as the long-term
 home for Mysos, as it provides an established process for community-driven
 development and decision making by consensus.
 
 Initial Goals
 
 Move the existing codebase to Apache
 Integrate with the Apache development process
 Ensure all dependencies are compliant with Apache License version 2.0
 Strengthen and grow the Mysos community
 Incremental development and releases per Apache guidelines
 Current Status
 
 Mysos was originally born out of a project within Twitter. The original
 committers (Twitter) are working with Mesosphere and Percona to fully open
 source the code and make it ready for incubation at Apache.
 
 The Mysos source is currently hosted at GitHub, which will be used to seed
 the Apache git repository.
 
 Meritocracy
 
 We plan to invest in supporting a meritocracy. We will discuss the
 requirements in an open forum. Several companies have already expressed
 interest in this project, and 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
 
 By bringing Mysos into Apache, we believe that the community will grow even
 bigger.
 
 Core Developers
 
 Mysos was initially developed as a collaboration between Twitter and
 Mesosphere.
 
 Alignment
 
 We believe that having Mysos at Apache will help further the growth of the
 big-data community, as it will encourage cooperation within the greater
 ecosystem of projects spawned by Apache Mesos.
 
 Known Risks
 
 Orphaned Products
 
 Mysos is being used and developed by companies we work for so the companies
 have an interest in its continued vitality.
 
 Given strong interest we've had since open sourcing Mysos, we anticipate
 we'll grow a sustainable community that will expand contributors and keep
 it active as the Mesos core evolves.
 
 Inexperience with Open Source
 
 Most of the committers have experience at Apache, whether it's through
 Apache Mesos, Aurora or other projects. Apache Mesos and Apache Aurora were
 both shepherded through the ASF incubator process and have graduated to
 become successful and diverse open source projects. We also have Jake
 Farrell as an ASF Champion to help us through incubation.
 
 Homogenous Developers
 
 Initial committers come from a number of companies. Our intention is
 increase the diversity of contributing developers and their affiliations,
 and we'll recognize contributions and contributors as the community grows
 at Apache. We encouraged by interest in the project thus far.
 
 Reliance on Salaried Developers
 
 It is expected that Mysos development will occur on both salaried time and
 on volunteer time, after hours. The majority of initial committers are paid
 by their employers to contribute to this project. However, they are all
 passionate about the project, and we are confident that the project will
 continue even if no salaried developers contribute to the project. We are
 committed to recruiting additional committers including 

Re: [DISCUSS] Freemarker Incubation proposal

[Ralph Goers]

While that is certainly a valid option, I would think that would be a topic for 
determine how to exit the incubator.  

Ralph

 On May 22, 2015, at 11:13 AM, Siegfried Goeschl 
 siegfried.goes...@it20one.com wrote:
 
 Hi Daniel,
 
 regarding “lower bar for project sexiness and buzzwordyness” - another 
 options would be using an existing ASF umbrella project, e.g. Apache Commons. 
 There you find a lot “unsexy but heavily used stuff” … ;-)
 
 Cheers,
 
 Siegfried Goeschl
 
 On 22 May 2015, at 19:31, Daniel Dekany ddek...@freemail.hu wrote:
 
 Technically (i.e., in source code), I don't think Velocity and
 Freemarker can share much. It seems that they kind of share fate
 though. Apparently, everyone has something more important to
 contribute to. And that's fine, I say, because what put these template
 engines into the spotlight 15(?) years ago was Web MVC, and legacy
 JSP's deficiencies to server that paradigm. It was a hot topic back
 then. But nowadays, just like in the case of Velocity (apparently),
 finding guys who want to hack this project for free after coding all
 day at the workplace, and instead of being with their families and all
 that, is, well... challenging. And it seems companies don't care to
 invest either by putting paid developers on it. (Certainly the same
 companies wouldn't be too happy if Freemarker is suddenly EOL-ed,
 though.) I guess there's some kind lower bar in project sexiness and
 buzzwordyness under which life just stops when it comes to
 contributions. Those same properties aren't needed for the project
 being heavily used though.
 
 So that's where we stand. But does it mean these projects should die?
 I don't think so. Does it mean that these projects are not for Apache?
 I don't know that, you tell me! Surely I don't want FM to go into
 incubation if failure is the most probable outcome. Can the
 requirements for getting out from incubation successfully be
 quantified? For the kind of project like this?
 
 -- 
 Thanks,
 Daniel Dekany
 
 
 Friday, May 22, 2015, 2:44:03 AM, Ralph Goers wrote:
 
 I used to use Apache Velocity. However, it hasn’t had a release
 since 2010 and the overall project activity has been minimal for
 years. As a consequence of that, and a feature that was missing, I
 recently switched to using Freemarker for some templating work I
 needed to do. The only reason I mention Velocity is I am wondering
 what relationship these two projects should have, if any.  I am also
 concerned that if interest in development of Freemarker is
 decreasing is it going to suffer the same fate?  I guess what I am
 wondering is if there is some way these two communities and/or technologies 
 could combine?
 
 FWIW, I’d be happy to mentor this project. If I had the time I know
 I’d want to commit, but that has been in extremely short supply of late.
 
 Ralph
 
 
 On May 21, 2015, at 4:38 PM, Marvin Humphrey mar...@rectangular.com 
 wrote:
 
 On Thu, May 21, 2015 at 7:11 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 Hi,
 
 On Thu, May 21, 2015 at 3:38 PM, Sergio Fernández wik...@apache.org 
 wrote:
 ...If you'd need any other mentor, I'm happy to help there (I'm 
 Incubator PMC
 and ASF Member)...
 
 Currently I see three mentors and two committers at
 https://wiki.apache.org/incubator/FreemarkerProposal, I'm not involved
 in that podling but it looks to me that additional committers might be
 more useful than more mentors.
 
 4 Mentors is a good number, though!
 
 It's true that there aren't many initial committers, but the proposal
 addresses this issue at length.
 
  https://wiki.apache.org/incubator/FreemarkerProposal#Known_Risks
 
  While it continues to have a large user base, the active developer
  community has become rather small at this point, and we think that the
  Apache Way governance model and being part of the ASF (together with
  other projects that are already using Freemarker) would help to bring new
  life and energy to the project to better support the maintenance and
  improvements of the Freemarker codebase.
 
 I think this is a reasonable plan and definitely worth a shot at 
 incubating.
 The Incubator has a mixed history with podlings that start small, but
 Freemarker has an advantage over many of those because it begins with a 
 large
 user base and wide adoption.
 
 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
 
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Freemarker Incubation proposal

[Ralph Goers]

I used to use Apache Velocity. However, it hasn’t had a release since 2010 and 
the overall project activity has been minimal for years. As a consequence of 
that, and a feature that was missing, I recently switched to using Freemarker 
for some templating work I needed to do. The only reason I mention Velocity is 
I am wondering what relationship these two projects should have, if any.  I am 
also concerned that if interest in development of Freemarker is decreasing is 
it going to suffer the same fate?  I guess what I am wondering is if there is 
some way these two communities and/or technologies could combine?

FWIW, I’d be happy to mentor this project. If I had the time I know I’d want to 
commit, but that has been in extremely short supply of late.

Ralph


 On May 21, 2015, at 4:38 PM, Marvin Humphrey mar...@rectangular.com wrote:
 
 On Thu, May 21, 2015 at 7:11 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 Hi,
 
 On Thu, May 21, 2015 at 3:38 PM, Sergio Fernández wik...@apache.org wrote:
 ...If you'd need any other mentor, I'm happy to help there (I'm Incubator 
 PMC
 and ASF Member)...
 
 Currently I see three mentors and two committers at
 https://wiki.apache.org/incubator/FreemarkerProposal, I'm not involved
 in that podling but it looks to me that additional committers might be
 more useful than more mentors.
 
 4 Mentors is a good number, though!
 
 It's true that there aren't many initial committers, but the proposal
 addresses this issue at length.
 
https://wiki.apache.org/incubator/FreemarkerProposal#Known_Risks
 
While it continues to have a large user base, the active developer
community has become rather small at this point, and we think that the
Apache Way governance model and being part of the ASF (together with
other projects that are already using Freemarker) would help to bring new
life and energy to the project to better support the maintenance and
improvements of the Freemarker codebase.
 
 I think this is a reasonable plan and definitely worth a shot at incubating.
 The Incubator has a mixed history with podlings that start small, but
 Freemarker has an advantage over many of those because it begins with a large
 user base and wide adoption.
 
 Marvin Humphrey
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 



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

Re: [VOTE] Accept Taverna into the Apache Incubator

[Ralph Goers]

+1 (binding)

Ralph

On Oct 16, 2014, at 12:42 PM, Andy Seaborne a...@apache.org wrote:

 On 16/10/14 18:47, sebb wrote:
 Apart from the typo, I thought it was necessary for the VOTE thread to
 contain the full text of the proposal.
 
 This has been the case for (almost) all previous acceptance votes.
 
 The Lens one I copied from didn't :-)
 
 Version static link:
 https://wiki.apache.org/incubator/TavernaProposal?rev=10
 
 and copied below.
 
   Andy
 
 
 I assume the text is required so the mail archives have a full record
 of what was actually voted on.
 
 The Wiki page might subsequently change or be deleted.
 
 
 
 
 Abstract
 
 Taverna is an open source and domain-independent suite of tools used to
 design and execute data-driven workflows.
 
 Proposal
 
 The Taverna suite includes:
 
 * Taverna Workbench, a desktop application written in Java for graphically
  composing, editing and executing workflows composed of distributed Web
  services and local tools
 
 * Taverna Command Line Tool, which allows execution of workflows from a 
 command line
 
 * Taverna Server, which provides a REST and SOAP API for executing workflows
 
 * Taverna Player, a Web interface the Taverna Server written in Ruby
  towards, providing a high-level view of workflow executions and their
  results and allowing further integrations with other Ruby on Rails
  applications
 
 Taverna allows browsing through and combining different service types in
 workflows, allowing them to integrate steps of arbitrary REST and SOAP Web
 services with command line tools (local and via SSH), scripts (Beanshell,
 R, Jython), and finally to visualize the results.
 
 The goal of the Taverna suite is to help researchers to access distributed
 datasets and processing capabilities by the construction of (data)
 pipelines, and also to simplify the execution of these pipelines in various
 environments.
 
 The Taverna suite of products is already successful and in wide use across
 different domains. The software is currently licensed as LGPL 2.1, with
 copyright owned by the University of Manchester. External contributors have
 all signed Apache-like CLAs.
 
 Background
 
 Taverna workflows coordinate inputs and outputs between computational
 processes and Web services. The workflow is designed in a graphical
 interface which shows the workflow as a series of boxes connected with
 arrows representing processes (i.e. executable services) and their data
 connections. Different processes in a workflow can be command line tools,
 REST and WSDL Web services; which are used for combining steps such as data
 acquisition, filtering, cleaning, integrating, analysis and
 visualization. Taverna calls these processes services, as they generally
 are provided by remote (third-party) servers.These kind of computational
 workflows, also known as pipelines or dataflows, focus on the movement of
 data rather than the execution order of the underlying processes. Features
 such as implicit iterations (where an input list of values causes multiple
 process executions) and parallel invocations (independent processes are
 executed as soon as their data is available) are intrinsic to a dataflow
 system, not requiring any particular constructs by the workflow designer.As
 a visual programming environment, workflows aids collaboration and reuse of
 workflows. At the highest level, a workflow represents the conceptual level
 of an analysis, allowing understanding, discussion and communication of the
 overall analysis protocol. More detail can be revealed and modified for
 individual steps. At the individual process level, the workflow defines
 execution specifics such as operations, parameters and command line
 tools.Sharing of the workflow definitions allows re-use and re-purposing of
 the computational analysis. During workflow execution, provenance can be
 collected from every step, allowing deep inspection of intermediate values
 for the purpose of debugging and validation.
 
 Rationale
 
 There is a strong need to lower the barrier of entry to datasets and
 computational resources widely available on the Internet, to increase their
 use by researchers who understand the computational steps needed to produce
 their results, but who are not necessarily expert programmers. Taverna has
 already shown its success and popularity in a wide range of scientific
 disciplines.
 
 Initial Goals
 
Transition mailing lists to Apache (keep existing subscribers, but invite 
 more)
 
Taverna developer workshop (2014-10-30)
 
Fully investigate/resolve incompatibly licensed dependencies
 
Stage git repositories for move at https://github.com/taverna-incubator :
Update headers/metadata to indicate Apache License 2.0
Restructure git repositories (to ~ 10 repos?)
Rename Maven groupIds to org.apache.taverna.*
Rename packages to org.apache.taverna.*
Move staged Github repositories to Apache git
Automated builds in Apache's Jenkins
   

Re: [VOTE] Accept Apache BeanShell in the Incubator

[Ralph Goers]

+1 (binding)

Ralph

On Jun 3, 2013, at 6:02 AM, Mattmann, Chris A (398J) wrote:

 +1 (binding).
 
 Cheers,
 Chris
 
 ++
 Chris Mattmann, Ph.D.
 Senior Computer Scientist
 NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
 Office: 171-266B, Mailstop: 171-246
 Email: chris.a.mattm...@nasa.gov
 WWW:  http://sunset.usc.edu/~mattmann/
 ++
 Adjunct Assistant Professor, Computer Science Department
 University of Southern California, Los Angeles, CA 90089 USA
 ++
 
 
 
 
 
 
 -Original Message-
 From: Simone Tripodi simonetrip...@apache.org
 Reply-To: general@incubator.apache.org general@incubator.apache.org
 Date: Friday, May 24, 2013 12:23 AM
 To: general@incubator.apache.org general@incubator.apache.org
 Subject: [VOTE] Accept Apache BeanShell in the Incubator
 
 Dear ASF members,
 
 We would like to propose BeanShell for the incubator.
 
 The proposal draft is available at:
 https://wiki.apache.org/incubator/BeanShellProposal,
 follows below the proposal
 
 Open is open for at least 72h and closes approximately on May 27th at
 8:20am GMT
 
 [ ] +1 accept BeanShell in the Incubator
 [ ] +/-0
 [ ] -1 because (provide a reason)
 
 Many thanks in advance, all the best!
 -Simo
 
 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/
 
 ~~
 ~
 
 = BeanShell =
 == Abstract ==
 The following proposal is about BeanShell, see JSR-274: The BeanShell
 Scripting Language implementation.
 
 == Proposal ==
 BeanShell is a small, free, embeddable Java source interpreter with
 object scripting language features, written in Java. BeanShell
 dynamically executes standard Java syntax and extends it with common
 scripting conveniences such as loose types, commands, and method
 closures like those in Perl and JavaScript.
 Users can use BeanShell interactively for Java experimentation and
 debugging as well as to extend your applications in new ways.
 Scripting Java lends itself to a wide variety of applications
 including rapid prototyping, user scripting extension, rules engines,
 configuration, testing, dynamic deployment, embedded systems, and even
 Java education.
 BeanShell is small and embeddable, so users can call BeanShell from
 Java applications to execute Java code dynamically at run-time or to
 provide extensibility in applications. Alternatively, users can use
 standalone BeanShell scripts to manipulate Java applications; working
 with Java objects and APIs dynamically. Since BeanShell is written in
 Java and runs in the same VM as application, users can freely pass
 references to live objects into scripts and return them as results.
 
 == Background ==
 BeanShell is a long living project born in the 2000 thanks to Patrick
 Niemeyer initial effort, who is still maintaining the project, with
 the help of Daniel Leuck and contributions voluntarily sent by users.
 
 == Rationale ==
 Currently there are no projects hosted by the ASF focused on providing
 JSR-274 implementation, moving the existing BeanShell project under
 the Apache umbrella would mean the ASF provides the JSR-274 reference
 implementation.
 
 = Current Status =
 == Meritocracy ==
 The historical BeanShell team believes in meritocracy and always acted
 as a community. Mailing list, open issue tracker and other
 communication channels have always been adopted since its first
 release. The adoption in a larger community, such as Apache, is the
 natural evolution for BeanShell. Moreover, the Apache standards will
 enforce the existing BeanShell community practices and will be a
 foundation for future committers involvement.
 
 == Core Developers ==
 In alphabetical order:
 
 * Daniel Leuck dan at ikayzo dot com,
 * Patrick Niemeyer pat at ikayzo dot com
 * Pedro Giffuni pfg at apache dot org
 * Simone Tripodi simonetripodi at apache dot org
 
 == Alignment ==
 Main aim of the project is to develop and maintain a fully flavored
 JSR-274 implementation that can be used by other Apache projects that
 need a Java  Scripting Language.
 
 = Known Risks =
 == Orphaned Products ==
 The increasing number of BeanShell adopters and the raising interest
 for the JSR-274 technology let us believe that there is a minimal risk
 for this work to being abandoned from the community.
 
 Moreover, BeanShell has been already used by the following projects for
 years:
 
 * Apache OpenOffice
 * Apache Maven
 * Apache JMeter
 
 == Inexperience with Open Source ==
 All of the committers have experience working in one or more open
 source projects inside and outside ASF.
 
 == Homogeneous Developers ==
 The list of initial committers are geographically distributed across
 the world with no one company being associated 

Re: [VOTE] Apache Spark for the Incubator

[Ralph Goers]

+1 (binding)

Ralph

On Jun 7, 2013, at 10:34 PM, Mattmann, Chris A (398J) wrote:

 Hi Folks,
 
 OK discussion has died down, time to VOTE to accept Spark into the
 Apache Incubator. I'll let the VOTE run for at least a week.
 
 So far I've heard +1s from the following folks, so no need for them
 to VOTE again unless they want to change their VOTE:
 
 +1
 
 Chris Mattmann*
 Konstantin Boudnik
 Henry Saputra*
 Reynold Xin
 Pei Chen
 Roman Shaposhnik*
 Suresh Marru*
 
 * -indicates IPMC
 
 [ ] +1 Accept Spark into the Apache Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't accept Spark into the Apache Incubator because..
 
 Proposal text is below.
 
 === Abstract ===
 Spark is an open source system for large-scale data analysis on clusters.
 
 === Proposal ===
 Spark is an open source system for fast and flexible large-scale data
 analysis. Spark provides a general purpose runtime that supports
 low-latency execution in several forms. These include interactive
 exploration of very large datasets, near real-time stream processing, and
 ad-hoc SQL analytics (through higher layer extensions). Spark interfaces
 with HDFS, HBase, Cassandra and several other storage storage layers, and
 exposes APIs in Scala, Java and Python.
 Background
 Spark started as U.C. Berkeley research project, designed to efficiently
 run machine learning algorithms on large datasets. Over time, it has
 evolved into a general computing engine as outlined above. Spark¹s
 developer community has also grown to include additional institutions,
 such as universities, research labs, and corporations. Funding has been
 provided by various institutions including the U.S. National Science
 Foundation, DARPA, and a number of industry sponsors. See:
 https://amplab.cs.berkeley.edu/sponsors/ for full details.
 
 === Rationale ===
 As the number of contributors to Spark has grown, we have sought for a
 long-term home for the project, and we believe the Apache foundation would
 be a great fit. Spark is a natural fit for the Apache foundation: Spark
 already interoperates with several existing Apache projects (HDFS, HBase,
 Hive, Cassandra, Avro and Flume to name a few). The Spark team is familiar
 with the Apache process and and subscribes to the Apache mission - the
 team includes multiple Apache committers already. Finally, joining Apache
 will help coordinate the development effort of the growing number of
 organizations which contribute to Spark.
 
 == Initial Goals ==
 The initial goals will most likely be to move the existing codebase to
 Apache and integrate with the Apache development process. Furthermore, we
 plan for incremental development, and releases along with the Apache
 guidelines.
 
 === Current Status ===
 == Meritocracy ==
 The Spark project already operates on meritocratic principles. Today,
 Spark has several developers and has accepted multiple major patches from
 outside of U.C. Berkeley. While this process has remained mostly informal
 (we do not have an official committer list), an implicit organization
 exists in which individuals who contribute major components act as
 maintainers for those modules. If accepted, the Spark project would
 include several of these participants as committers from the onset. We
 will work to identify all committers and PPMC members for the project and
 to operate under the ASF meritocratic principles.
 
 === Community ===
 Acceptance into the Apache foundation would bolster the already strong
 user and developer community around Spark. That community includes dozens
 of contributors from several institutions, a meetup group with several
 hundred members, 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 exist at UC Berkeley, there is a
 representative cross sampling of other organizations including Quantifind,
 Microsoft, Yahoo!, ClearStory Data, Bizo, Intel, Tagged and Webtrends.
 
 
 === Alignment ===
 Our proposed effort aligns with several ongoing BIGDATA and U.S. National
 priority funding interests including the NSF and its Expeditions program,
 and the DARPA XDATA project. Our industry partners and collaborators are
 well aligned with our code base.
 
 There are also a number of related Apache projects and dependencies, that
 will be mentioned in the Relationships with Other Apache products section.
 
 == Known Risks ==
 
 === Orphaned Products ===
 Given the current level of investment in Spark - the risk of the project
 being abandoned is minimal. There are several constituents who are highly
 incentivized to continue development. The U.C. Berkeley AMPLab relies on
 Spark as a platform for a large number of long-term research projects.
 Several companies have build verticalized products which are tightly
 dependent on Spark. Other companies have devoted significant internal
 infrastructure investment in Spark.
 
 === Inexperience with Open Source ===
 Spark has 

Re: [VOTE] Accept Apache BeanShell in the Incubator

[Ralph Goers]

+1 (binding)

Ralph

On May 24, 2013, at 12:23 AM, Simone Tripodi wrote:

 Dear ASF members,
 
 We would like to propose BeanShell for the incubator.
 
 The proposal draft is available at:
 https://wiki.apache.org/incubator/BeanShellProposal,
 follows below the proposal
 
 Open is open for at least 72h and closes approximately on May 27th at 8:20am 
 GMT
 
 [ ] +1 accept BeanShell in the Incubator
 [ ] +/-0
 [ ] -1 because (provide a reason)
 
 Many thanks in advance, all the best!
 -Simo
 
 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/
 
 ~~~
 
 = BeanShell =
 == Abstract ==
 The following proposal is about BeanShell, see JSR-274: The BeanShell
 Scripting Language implementation.
 
 == Proposal ==
 BeanShell is a small, free, embeddable Java source interpreter with
 object scripting language features, written in Java. BeanShell
 dynamically executes standard Java syntax and extends it with common
 scripting conveniences such as loose types, commands, and method
 closures like those in Perl and JavaScript.
 Users can use BeanShell interactively for Java experimentation and
 debugging as well as to extend your applications in new ways.
 Scripting Java lends itself to a wide variety of applications
 including rapid prototyping, user scripting extension, rules engines,
 configuration, testing, dynamic deployment, embedded systems, and even
 Java education.
 BeanShell is small and embeddable, so users can call BeanShell from
 Java applications to execute Java code dynamically at run-time or to
 provide extensibility in applications. Alternatively, users can use
 standalone BeanShell scripts to manipulate Java applications; working
 with Java objects and APIs dynamically. Since BeanShell is written in
 Java and runs in the same VM as application, users can freely pass
 references to live objects into scripts and return them as results.
 
 == Background ==
 BeanShell is a long living project born in the 2000 thanks to Patrick
 Niemeyer initial effort, who is still maintaining the project, with
 the help of Daniel Leuck and contributions voluntarily sent by users.
 
 == Rationale ==
 Currently there are no projects hosted by the ASF focused on providing
 JSR-274 implementation, moving the existing BeanShell project under
 the Apache umbrella would mean the ASF provides the JSR-274 reference
 implementation.
 
 = Current Status =
 == Meritocracy ==
 The historical BeanShell team believes in meritocracy and always acted
 as a community. Mailing list, open issue tracker and other
 communication channels have always been adopted since its first
 release. The adoption in a larger community, such as Apache, is the
 natural evolution for BeanShell. Moreover, the Apache standards will
 enforce the existing BeanShell community practices and will be a
 foundation for future committers involvement.
 
 == Core Developers ==
 In alphabetical order:
 
 * Daniel Leuck dan at ikayzo dot com,
 * Patrick Niemeyer pat at ikayzo dot com
 * Pedro Giffuni pfg at apache dot org
 * Simone Tripodi simonetripodi at apache dot org
 
 == Alignment ==
 Main aim of the project is to develop and maintain a fully flavored
 JSR-274 implementation that can be used by other Apache projects that
 need a Java  Scripting Language.
 
 = Known Risks =
 == Orphaned Products ==
 The increasing number of BeanShell adopters and the raising interest
 for the JSR-274 technology let us believe that there is a minimal risk
 for this work to being abandoned from the community.
 
 Moreover, BeanShell has been already used by the following projects for years:
 
 * Apache OpenOffice
 * Apache Maven
 * Apache JMeter
 
 == Inexperience with Open Source ==
 All of the committers have experience working in one or more open
 source projects inside and outside ASF.
 
 == Homogeneous Developers ==
 The list of initial committers are geographically distributed across
 the world with no one company being associated with a majority of the
 developers.  Many of these initial developers are experienced Apache
 committers already  and all are experienced with working in
 distributed development communities.
 
 == Reliance on Salaried Developers ==
 To the best of our knowledge, none of the initial committers are being
 paid to develop code for this project. BeanShell has already proven
 its capability to attract external developers.
 
 == Relationships with Other Apache Products ==
 A number of existing ASF projects already benefit from BeanShell
 implementation, including Apache OpenOffice, Apache Maven and Apache
 JMeter. It is hoped that members of those projects will be interested
 in contributing to and adopting this implementation.
 
 == An Excessive Fascination with the Apache Brand ==
 Even if the BeanShell community recognizes the power and the
 attractiveness  of the ASF brand, we are 

Re: [VOTE] Accept Marmotta into the incubator

[Ralph Goers]

+1 (binding)

Ralph

On Nov 29, 2012, at 3:28 AM, Andy Seaborne wrote:

 Hi there,
 
 Following the discussion thread, here is the formal vote on the Marmotta 
 proposal:
 
 Please cast your votes on whether to accept the Apache Marmotta proposal:
 
 [ ] +1 Accept Marmotta into the Apache Incubator
 [ ] +0 Indifferent to the acceptance of Marmotta
 [ ] -1 Do not accept the Marmotta proposal because ...
 
 The vote will be open until at least 23:59 Sunday 2nd December UTC
 (which is three full days from midnight tonight)
 
   Andy
 
 http://wiki.apache.org/incubator/MarmottaProposal
 
 ---
 
 == Abstract
 
 Marmotta is a Linked Data platform for industry-strength installations.
 
 == Proposal
 
 The goal of Apache Marmotta is to provide an open implementation of a Linked 
 Data Platform that can be used, extended, and deployed easily by 
 organizations who want to publish Linked Data or build custom applications on 
 Linked Data.
 
 The phrase Linked Data is used here idiosyncratically to refer to a data 
 integration paradigm across the Web. The term was coined by Tim Berners-Lee 
 in 2006, and it is based on four very simple principles which basically 
 describe recommended best practices for exposing, sharing, and connecting 
 pieces of data, information, and knowledge on the Semantic Web using URIs and 
 the RDF technology stack. Therefore Linked Data is about using the Web to 
 connect related data that wasn't previously linked, or using the Web to lower 
 the barriers to linking data currently linked using other methods.
 
 Marmotta will follow the core recommendations of the W3C on RDF, SPARQL and 
 Linked Data publishing, particularly the emerging Linked Data Platform (LDP) 
 recommendation. It will also offer extensions for frequently needed 
 additional functionalities like Linked Data Querying, WebID, WebACL, 
 Reasoning, and Versioning. Marmotta aims to cover both, Linked Open Data, as 
 well as Enterprise Linked Data scenarios, providing facilities to deal with 
 different data sources and requirements (small data/big data, open 
 access/restricted access, etc).
 
 == Background
 
 The Semantic Web isn't just about putting data on the web. It is about making 
 links, so that a person or machine can explore the web of data. Moreover, the 
 Web has quickly evolved to a Read-Write paradigm, and Linked Data 
 technologies too. And Marmotta will address this challenge and offer a common 
 infrastructure for organizations working in this area.
 
 Marmotta comes as a continuation of the work in the Linked Media Framework 
 (aka LMF) project. LMF is an easy-to-setup server application that bundles 
 central Semantic Web technologies to offer some advanced services. The Linked 
 Media Framework consists of LMF Core which provides a Read-Write Linked Data 
 server, plus some modules that complement the server with other added added 
 capabilities, such as, SPARQL 1.1, LDPath, LDCache, Reasoning, Versioning, 
 etc. Besides, LMF also provides a Client Library, currently available in 
 Java, PHP, and Javascript, as a convenient API abstraction around the LMF web 
 services. Currently LMF integrates with other relevant tools (Apache Stanbol, 
 Google Refine or Drupal) to cover a wider range of use cases and needs.
 
 == Rationale
 
 Linked Data technologies are now at a turning point from mostly research 
 projects to industrial applications, and a lot of standardisation is 
 currently in progress. Industrial applications require a reliable and 
 scalable infrastructure that follows and helps defining a standard way of 
 publishing and consuming Linked Data on the Web. The proposers have a strong 
 background in building such applications and have invested considerable 
 effort in the last years to building up an initial version of such a platform 
 (the “Linked Media Framework” or “LMF”). Starting from this solid base, we 
 strongly believe that Apache is the right environment to open the development 
 of this project to a wider scope.
 
 Marmotta has the potential of being a reference implementation and Apache 
 provides a better environment for a collaborative development effort. With 
 its well-established governance model based on meritocracy and handling 
 IP/legal issues, people from different organizations can more easily 
 contribute to the project. This will help unify the efforts of people 
 implementing the Linked Data Platform specification and other Semantic Web 
 standards. In addition, it would considerably help organizations in adopting 
 Linked Data technologies and would provide a solid base for further research 
 activities in the community.
 
 == Initial Goals
 
 * Foster the use of Semantic Web Technologies in industry
 
 * Provide an open source and community-driven implementation of a Linked Data 
 Platform and related Semantic Web standards, LDP 1.0 Draft and SPARQL 1.1 
 mainly
 
 * Move the existing LMF source from the current Google Code page to the 
 

Re: [VOTE] Accept Apache Streams as an Incubator Project

[Ralph Goers]

+1 (binding)

Ralph

On Nov 14, 2012, at 4:37 AM, Franklin, Matthew B. wrote:

 Given the feedback received so far I think the Streams proposal is in good 
 shape so I am calling for a vote to accept Streams into the Incubator.
 
 The proposal is at: http://wiki.apache.org/incubator/StreamsProposal and also 
 copied as text below.
 
 Please vote.
 
 [ ] +1 Accept Streams into the incubator
 [ ] +0 Don't care'
 [ ] -1 Reject for the following reason:
 
 I'll close the vote at Monday morning on November 19th EST. 
 
 - COPY OF PROPOSAL FROM http://wiki.apache.org/incubator/StreamsProposal 
 -
 
 Apache Streams Proposal
 
 == Abstract ==
 
 Apache Streams will be a lightweight server for ActivityStreams. The role
 of Apache Streams is to provide a central point of aggregation, filtering
 and querying for Activities that have been submitted by disparate systems.
 Apache Streams also intends to include a mechanism for intelligent
 filtering and recommendation to reduce the noise to end users.
 
 == Proposal ==
 
 Apache Streams will bring together individuals who are or are looking to
 increase and centralize the production, consumption and federation of
 ActivityStreams throughout enterprise organizations and the Internet as a
 whole.  The target features include:
 
 * Publication of Activities from multiple systems via HTTP
 * Aggregation and syndication of streams
 * Support for security trimming of streams by social graph
 * Noise reduction and intelligent filtering
 * Federation of streams across disparate systems
 * Provide libraries for easy integration in source systems
 
 == Background ==
 
 The ActivityStreams specification standardizes a generic format for
 describing event-based data.  Many social web companies have adopted the
 format and it has been included in the OpenSocial specification as the
 preferred method for delivery of activity data.  During discussions of
 ActivityStreams at OpenSocial events earlier in the year, it became clear
 that multiple organizations are facing similar issues as to the
 publication and filtering of their activities and would benefit from a
 commonly-developed, open-source ActivityStreams server.
 
 == Rationale ==
 
 In deployment, activities are generated from multiple sources.  This is
 particularly true within the enterprise where disparate systems create and
 manage activities in stove pipes.  What is needed is a central point for
 consumption, aggregation and exposure of activities generated within these
 systems.
 
 == Initial Goals ==
 
 The initial goal of the project is to survey donated code and develop a
 common, high-level architecture for an initial release.  The project will
 then work toward that release in a new code base, pulling in pieces of
 donated code as necessary.
 
 == Current Status ==
 
 The MITRE Corporation will donate its prototype code to the project.
 Aside from this, the project is new and will need bootstrap time to
 develop an initial architecture and roadmap.
 
  Meritocracy 
 
 As a new project with many team members who are seasoned Apache veterans,
 Apache Streams is prepared to build the project under the Apache Way.
 
  Community 
 
 The Apache Streams community combines multiple individuals from different
 organizations, many of which have collaborated before in an open
 environment.  Apache Streams is committed to expanding this community and
 adhering to Apache principles of openness and collaboration.
 
 == Known Risks ==
 
 An exercise in self-knowledge. Risks don't mean that a project is
 unacceptable. If they are recognized and noted then they can be addressed
 during incubation.
 
  Inexperience with Open Source 
 
 Most of the initial committers have worked in open source and many are
 familiar with the ASF and the Apache Way; but, not all.  Additionally,
 many of the committers have not worked on a software project together and
 will need time to familiarize themselves with each other.
 
  Speed of Development 
 
 This project is dependent upon contributions made on company time. For
 this approach to succeed, the project must deliver a workable system in a
 timeframe acceptable to those companies. The initial parties have the
 intention of releasing a first version within 6 months after starting the
 Incubator. Failure to do so could prevent the project reaching critical
 mass, and could prevent the project from being in a position to attract
 new developers.
 
  Reliance on Salaried Developers 
 
 At present, the vast majority of contributors will be doing so as a part
 of their day jobs. Therefore, as already alluded to, there is a risk that
 the project won't gain enough traction to be of use to their employers.
 However, given the centrality of these codebases to the participating
 companies, it is clearly in their best interests to transition to an
 openly developed alternative.
 
  Relationships with Other Apache Products 
 
 Many of the initial 

Re: [VOTE] Retire AWF from incubation

[Ralph Goers]

+1 (binding)

Ralph

On Jul 4, 2012, at 2:18 PM, Roger Schildmeijer wrote:

 Hi,
 
 The AWF community has voted to retire the project. 
 Following the retirement guide [1], I now call the Incubator PMC to vote on 
 confirming this decision. (Will be open for 72 hours).
 
   [ ] +1 Retire the AWF project
   [ ] -1 Do not retire the project, because ...
 
 [1] http://incubator.apache.org/guides/retirement.html
 
 WBR 
 Roger
 


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

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

The graduation requirements say 

The project is considered to have a diverse community when it is not highly 
dependent on any single contributor (there are at least 3 legally independent 
committers and there is no single company or entity that is vital to the 
success of the project). Basically this means that when a project mostly 
consists of contributors from one company, this is a sign of not being diverse 
enough..

This doesn't specify a hard number. In fact, Roy responded to this thread 
saying he doesn't believe there even is a diversity requirement  -

There is no diversity requirement for graduating from the incubator. In many 
ways, incubation hinders community growth. The requirement is that the project 
makes decisions as an Apache project, not in private, which is harder to get 
used to doing if a lot of people share the same office.

So I am left a bit confused. If I go by the what the graduation page says 
literally, then all the statistics that have been generated would seem to show 
that Cloudera is vital to the success of the project. Although Arvind is a bit 
of the driving force, I'm sure if something terrible were to happen to him 
Cloudera would insure his energy was replaced. However, if something terrible 
happened to Cloudera I suspect we would have several Apache projects in 
trouble, not just Flume.

While I clearly don't like some of the ways the project has chosen to organize 
itself, all those decisions were done properly and in public. Again, while I 
don't like that little discussion happens on the dev list, it does happen in 
Jira issues and in the review board, all of which is routed to the dev list, so 
again, most, if not all, of the development is done in public.

So my answer to the question is really that I am finding it hard to reconcile 
whether we actually have or should have a diversity requirement. From what I've 
been told privately Flume would certainly not be the first project to graduate 
from the incubator in a similar situation. 

The other thing I find interesting is that I am also the only non-Cloudera 
mentor on the project. I find it a bit odd that while the incubator has the 
requirement for graduation it doesn't have any such requirement for a codling's 
mentors.  That said, IMO every one of the mentors on the project has been doing 
a good job.

One other disclaimer. My employer is a customer of Cloudera specifically for 
paid support for Flume, so I also have a vested interest in seeing both the 
project and Cloudera succeed.  However, with regards to Flume's graduation, I 
haven't even discussed this issue with anyone in by $dayjob.

So again - if the basis we are to use is whether a single company or entity is 
vital to a project then I don't believe Flume is quite there. OTOH I am not 
completely necessary that that is vital for graduation, in which case the 
section in the graduation requirements needs to be changed. So at this point 
the best I can do is say I'm not really sure how to vote.

Ralph





On Jun 5, 2012, at 6:49 AM, Alan Gates wrote:

 
 On Jun 5, 2012, at 2:19 PM, Marvin Humphrey wrote:
 
 On Sat, May 26, 2012 at 11:44 PM, Ralph Goers
 ralph.go...@dslextreme.com wrote:
 Another way of  looking at these same statistics:
 Cloudera - 217
 Other - 16
 
 That means Cloudera is responsible for over 93% of the Jira issues.  It is
 great that Cloudera is doing so much work but those stats hardly prove
 diversity.
 
 I was surprised to see the IPMC Flume graduation VOTE today -- I don't recall
 seeing another situation like it in the last couple years, where the 
 community
 graduation VOTE was contended.
 
 I checked the Flume dev list archives and I don't see a message from Ralph
 indicating that he thinks the latest measures address the concerns that have
 been raised.
 
 
 Agreed.  It's hard to vote for graduation for a podling when one of the 
 mentors feels strongly that the podling is not ready.
 
 Alan.
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

I suppose. But i guess I'd rather vote on whether diversity is a requirement 
for graduation before I voted on the graduation itself. 

Ralph

On Jun 5, 2012, at 9:53 AM, Patrick Hunt wrote:

 Isn't this why we vote. To come to a decision when consensus can't be
 reached and allow people to move on.
 
 Patrick
 
 On Tue, Jun 5, 2012 at 8:22 AM, Ralph Goers ralph.go...@dslextreme.com 
 wrote:
 
 
 
 The graduation requirements say
 
 The project is considered to have a diverse community when it is not highly 
 dependent on any single contributor (there are at least 3 legally 
 independent committers and there is no single company or entity that is 
 vital to the success of the project). Basically this means that when a 
 project mostly consists of contributors from one company, this is a sign of 
 not being diverse enough..
 
 This doesn't specify a hard number. In fact, Roy responded to this thread 
 saying he doesn't believe there even is a diversity requirement  -
 
 There is no diversity requirement for graduating from the incubator. In 
 many ways, incubation hinders community growth. The requirement is that the 
 project makes decisions as an Apache project, not in private, which is 
 harder to get used to doing if a lot of people share the same office.
 
 So I am left a bit confused. If I go by the what the graduation page says 
 literally, then all the statistics that have been generated would seem to 
 show that Cloudera is vital to the success of the project. Although Arvind 
 is a bit of the driving force, I'm sure if something terrible were to happen 
 to him Cloudera would insure his energy was replaced. However, if something 
 terrible happened to Cloudera I suspect we would have several Apache 
 projects in trouble, not just Flume.
 
 While I clearly don't like some of the ways the project has chosen to 
 organize itself, all those decisions were done properly and in public. 
 Again, while I don't like that little discussion happens on the dev list, it 
 does happen in Jira issues and in the review board, all of which is routed 
 to the dev list, so again, most, if not all, of the development is done in 
 public.
 
 So my answer to the question is really that I am finding it hard to 
 reconcile whether we actually have or should have a diversity requirement. 
 From what I've been told privately Flume would certainly not be the first 
 project to graduate from the incubator in a similar situation.
 
 The other thing I find interesting is that I am also the only non-Cloudera 
 mentor on the project. I find it a bit odd that while the incubator has the 
 requirement for graduation it doesn't have any such requirement for a 
 codling's mentors.  That said, IMO every one of the mentors on the project 
 has been doing a good job.
 
 One other disclaimer. My employer is a customer of Cloudera specifically for 
 paid support for Flume, so I also have a vested interest in seeing both the 
 project and Cloudera succeed.  However, with regards to Flume's graduation, 
 I haven't even discussed this issue with anyone in by $dayjob.
 
 So again - if the basis we are to use is whether a single company or entity 
 is vital to a project then I don't believe Flume is quite there. OTOH I am 
 not completely necessary that that is vital for graduation, in which case 
 the section in the graduation requirements needs to be changed. So at this 
 point the best I can do is say I'm not really sure how to vote.
 
 Ralph
 
 
 
 
 
 On Jun 5, 2012, at 6:49 AM, Alan Gates wrote:
 
 
 On Jun 5, 2012, at 2:19 PM, Marvin Humphrey wrote:
 
 On Sat, May 26, 2012 at 11:44 PM, Ralph Goers
 ralph.go...@dslextreme.com wrote:
 Another way of  looking at these same statistics:
 Cloudera - 217
 Other - 16
 
 That means Cloudera is responsible for over 93% of the Jira issues.  It is
 great that Cloudera is doing so much work but those stats hardly prove
 diversity.
 
 I was surprised to see the IPMC Flume graduation VOTE today -- I don't 
 recall
 seeing another situation like it in the last couple years, where the 
 community
 graduation VOTE was contended.
 
 I checked the Flume dev list archives and I don't see a message from Ralph
 indicating that he thinks the latest measures address the concerns that 
 have
 been raised.
 
 
 Agreed.  It's hard to vote for graduation for a podling when one of the 
 mentors feels strongly that the podling is not ready.
 
 Alan.
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


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

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On Jun 5, 2012, at 2:22 PM, Franklin, Matthew B. wrote:

 
 Based on some digging, I think what you are mostly facing is a battle of 
 perception.  As not everyone has read or is privy to  the private list 
 discussions, what they see is that you have a standing -1 vote from a mentor 
 who has expressed concerns on this list and the dev list as to whether or not 
 the diversity requirement has been met.  It looks (and looked to me 
 initially) like an incubator project that is dominated by a single company 
 was trying to push itself through the incubation process at whatever cost and 
 before it was ready; something that most IPMC members would likely resist.  
 If this type of misperception happened at the incubator, what does the 
 foundation and flume community see?  
 
 With the additional background I have read, it seems that the community is 
 much healthier than it appears and is acting on a lot of communication and 
 consensus that was driven on the private list.  IMO, it would have been 
 better to ask Ralph if he was comfortable retracting his -1 prior to pushing 
 the general@ VOTE and if he was not, then participate in the diversity 
 discussion on general@ until some consensus has been reached. 

I posted an email earlier today where I discussed my confusion over the 
diversity requirement.  I'm not comfortable doing anything without getting some 
feedback on whether the diversity requirement, as currently stated on the wiki, 
is correct or whether diversity should simply be measured by how a project 
makes its decisions as Roy suggests.  

Ralph


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

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On Jun 5, 2012, at 4:10 PM, Jukka Zitting wrote:

 Hi,
 
 On Tue, Jun 5, 2012 at 11:45 PM, Ralph Goers ralph.go...@dslextreme.com 
 wrote:
 I posted an email earlier today where I discussed my confusion over the 
 diversity
 requirement.  I'm not comfortable doing anything without getting some 
 feedback
 on whether the diversity requirement, as currently stated on the wiki, is 
 correct or
 whether diversity should simply be measured by how a project makes its
 decisions as Roy suggests.
 
 All the graduation criteria are things that the IPMC has previously
 considered important things to consider when deciding if a community
 has reached maturity as defined in the original Incubator resolution
 [1]. The criteria have evolved over time and will continue to do so.
 
 That said, I think diversity is an important factor of community
 maturity and should definitely be considered when casting a vote on
 the graduation of a project. The traditional metric of at least three
 independent (active) committers is a good guideline, though it has
 often especially with smaller projects been judged subjectively and
 weighed in relation to other aspects of community health.
 
 As for Flume, you and the other mentors are in the best position to
 consider the overall maturity of the project. Is the project ready to
 function as a standalone TLP on it's own according to the Apache Way
 and the ASF policies, or is there still something that the Incubator
 can or should teach the community?
 
 Personally, based on a few closer looks at Flume, it seems to me that
 the community passes that barrier and I'm satisfied with the way
 they've decided to addressed the concerns that were raised. But before
 casting my vote I'd love to hear your opinion on this since you raised
 the issue originally and as a mentor you have much better insight on
 the actual community dynamics within Flume.
 
 [1] 
 http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt

Thanks.  I think your view here aligns with the way I would prefer to evaluate 
projects.  

As to whether I believe Flume is ready to function as a standalone TLP - 
absolutely yes.  As I have said, the only criteria it doesn't meet is the 
statement that no single company or entity is vital to the success of the 
project.  I believe the project is still highly dependent on Cloudera. But I'm 
ready to vote +1 if that is not considered to be an absolute requirement for 
graduation.

Ralph


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

Re: diversity

[Ralph Goers]

Thanks Roy.  Yes, I would like the diversity section modified, although I'm not 
quite sure how I'd reword it. Even if it isn't, your post below can always be 
referenced again to aid anyone else who may be confused.  

Ralph

On Jun 5, 2012, at 5:00 PM, Roy T. Fielding field...@gbiv.com wrote:

 On Jun 5, 2012, at 2:45 PM, Ralph Goers wrote:
 I posted an email earlier today where I discussed my confusion over the 
 diversity requirement.  I'm not comfortable doing anything without getting 
 some feedback on whether the diversity requirement, as currently stated on 
 the wiki, is correct or whether diversity should simply be measured by how a 
 project makes its decisions as Roy suggests.  
 
 There is no diversity requirement at the ASF.  There is a behavior
 requirement for graduation and a behavior requirement for TLPs.
 We must not confuse the two.  If the Incubator says that there is a
 diversity requirement for graduation, ignore it (or at least figure
 out what the docs were supposed to say and then do that).
 I'd urge folks to fix the docs, but I know where that leads ...
 and I have no cycles to spare.
 
 A diversity requirement would mean that a person's employment
 status impacts their ability to participate here.  IOW, it would
 create a perverse incentive for them not to be employed.
 
 Now, I'll explain why ...
 
 Everyone here participates as volunteers, even when they are
 employed by someone else and that employment pays them to contribute
 here.  If we set requirements on diversity, we are telling potential
 employers of our volunteers that they should not hire those
 volunteers who happen to work on the same project.  They should not
 offer them employment.  They should not pay them well.  They
 should not encourage their other employees to contribute here.
 
 I hope that clarifies the situation.
 
 I will not tolerate a perverse incentive that punishes our existing
 volunteers or prevents additional volunteers from joining our projects.
 That is far worse than a project that happens to be dominated by
 one employer's volunteers (assuming they still *behave* as an
 Apache project).
 
 This is not a theoretical issue.  How long ago was it that Day
 hired Jukka --- a spectacularly productive dude who lived in Finland?
 This very issue came up at the time.  Is it safe to hire Jukka when
 he represents most of the diversity of Jackrabbit (at the time,
 still in Incubator)?
 
 Do you have any idea how f*$ing insane it would have been
 if we had decided not to hire Jukka?  If we had backed off because
 of a frigging diversity requirement?  My mind boggles at the loss.
 
 Or what if Day had hired him and then said he can't participate
 in Jackrabbit?  How much damage would that have done to Apache?
 IMO, far more than anything we'd ever gain from enforcing an
 arbitrary quota for PMC composition.
 
 I don't know about the rest of you folks, but I happen to like
 getting paid while still contributing at Apache.  I think it has
 worked out well for both organizations, and for countless others
 downstream.  I wouldn't mind getting paid more.  Hence, we don't
 allow perverse incentives that interfere with our volunteers'
 future prospects for gainful employment.  It would be wrong,
 even if it is well-intentioned.
 
 Roy
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

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

Re: [VOTE] Graduate Flume podling from Apache Incubator

[Ralph Goers]

+1 (binding)

Ralph

On Jun 5, 2012, at 1:17 AM, Arvind Prabhakar arv...@apache.org wrote:

 This is a call for vote to graduate Flume podling from Apache Incubator.
 
 Flume entered the Incubator in June of 2011. Since then it has added nine
 new committers and made two signifiant releases following the ASF policies
 and guidelines. The community of Flume is active, healthy and growing and
 has demonstrated the ability to self-govern using accepted
 Apache practices. Flume community has voted to proceed with graduation [1]
 and the result can be found at [2].
 
 Please cast your votes:
 
 [  ] +1 Graduate Flume podling from Apache Incubator
 [  ] +0 Indifferent to the graduation status of Flume podling
 [  ] -1 Reject graduation of Flume podling from Apache Incubator
 
 This vote will be open for 72 hours. Please find the proposed board
 resolution below.
 
 [1] http://s.apache.org/Ckq
 [2] http://s.apache.org/DBv
 
 Regards,
 Arvind Prabhakar
 
 
X. Establish the Apache Flume Project
 
   WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the
   Foundation's purpose to establish a Project Management
   Committee charged with the creation and maintenance of
   open-source software related to a system for aggregating
   large amounts of log data on Apache Hadoop's HDFS and
   other scalable storage systems for distribution at no
   charge to the public.
 
   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Flume Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further
 
   RESOLVED, that the Apache Flume Project be and hereby is
   responsible for the creation and maintenance of software
   related to  a system for aggregating large amounts of log
   data on Apache Hadoop's HDFS and other scalable storage
   systems; and be it further
 
   RESOLVED, that the office of Vice President, Apache Flume 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 Flume Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Flume 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 Flume Project:
 
 * Aaron Kimball  kimba...@apache.org
 * Andrew Bayer   aba...@apache.org
 * Ahmed Radwan   ah...@apache.org
 * Arvind Prabhakar   arv...@apache.org
 * Brock Noland   br...@apache.org
 * Bruce Mitchenerbru...@apache.org
 * Derek Deeter   ddee...@apache.org
 * Eric Sammeresam...@apache.org
 * Hari Shreedharan   hshreedha...@apache.org
 * Henry Robinson he...@apache.org
 * Jaroslav Cecho jar...@apache.org
 * Jonathan Hsieh jmhs...@apache.org
 * Juhani Connollyjuha...@apache.org
 * Mike Percy mpe...@apache.org
 * Mingjie Laim...@apache.org
 * Nick Verbeck   nerdyn...@apache.org
 * Patrick Hunt   ph...@apache.org
 * Prasad Mujumdarpras...@apache.org
 * Ralph Goersrgo...@apache.org
 * Will McQueen   w...@apache.org
 
   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
   be appointed to the office of Vice President, Apache Flume, 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 Flume 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 Flume Project; and be it further
 
   RESOLVED, that the Apache Flume Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator Flume podling; and be it further
 
   RESOLVED, that all responsibilities pertaining to the Apache
   Incubator Flume podling encumbered upon the Apache Incubator
   Project are hereafter discharged.

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

Re: [PROPOSAL] Apache Parser

[Ralph Goers]

My initial reaction is that there may be some confusion between this project 
and Commons Configuration, at least from a naming standpoint.  However, I don't 
believe Commons Configuration currently supports this format of configuration.

Ralph

On May 30, 2012, at 11:18 PM, Seungyoung Kim wrote:

 Apache Parser
 ===
 
 General Purpose Apache-style Configuration File Parser
 
 * Definition
 
  - Apache-style Configuration:
  A configuration file syntax and format originally introduced and used
  in Apache HTTPd.
 
 * Abstract
 
  Apache-style configuration syntax provides powerful, versatile and flexible
 representation of data which can be adopted by many other applications.
 
 * Proposal
 
  We're proposing a developer library of General Purpose Configuration Parser
 based on and expanding Apache-style syntax.
 
 * Background
 
  One of common file format is INI-style configuration which provides key-value
 pairs and 1-depth section. This format is simple but does not provide much
 flexibility.
 
  XML and JSON format is another one which are used wided, but little bit
 too complecated and heavy from application's stand point of view.
 
  Apache-style syntax can cover both simple and complex layerd configuration.
 The syntax is very versatile to represent almost data format and the callback
 mechanism adds flexibility.
 
  Many cases, software engineers pay much of their time to define their
 configuration syntax. Apache-style configuration can be a good suggestion.
 
 * Rationale
 
  Apache configuration has originally introduced by Apache HTTPd. When this
 project is provided as a one of Apache projects, we believe this project can
 grow up with strong community and use base.
 
  It also helps future apache projects adopt this syntax for their new 
 projects.
 
 * Initial Goals
 
  Initial goal is providing core library logic in C implementation.
 Other language bindings will be provided after that.
 
  Initially, configuration parser will provide two way access of parsed
 entries. One is callback model which is the model Apache HTTPd is using.
 The other way is key-value model, primary for simple use and for other
 language bindings.
 
 * Current Status
 
  At this point, initial base codes has written.
 
 * Community
 
  This project needs engineers for other language bindings. This is one of
 reasons we want this project to be a Apache project.
 
 * Inexperience with Open Source
 
  The core developer, Seungyoung Kim, has been driven and involved in
 several open-source projects such as qDecoder, qLibc, qHttpd and RingFS.
 
 * Required Resources
 
  - Mailing lists:
  apacheparser-dev
  apacheparser-commits
 
  - Subversion Directory:
  https://svn.apache.org/repos/asf/incubator/apacheparser
 
  - Issue Tracking:
  Bugzilla
 
  - Other Resources:
  WIKI page
 
 * Initial Committers
 
  Seungyoung Kim (wolkykim at gmail dot com)
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


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

Re: [PROPOSAL] Apache Parser

[Ralph Goers]

On May 31, 2012, at 7:37 PM, Greg Stein wrote:

 On May 31, 2012 5:31 AM, Greg Stein gst...@gmail.com wrote:
 ...
 (that said, I agree: this seems like it should be a proposal to
 Commons, so we just need to handle that redirection)
 
 And I didn't read the proposal closely enough, but took from Ralph's
 comment that this was some Java code. ... but no, it is a C-based project.
 Thus, I don't think Apache Commons has any bearing here.

No, my comment wasn't about what the project is attempting to do but simply 
that a project named Apache Configuration Parser could be easily confused 
with Apache Commons Configuration.   However, it must have been late or 
something as the project isn't even proposing to call itself Configuration 
Parser.   However, Apache Parser is also a bit vague.

 
 I'm +1 on the proposal.
 
 Give it a shot to build a community. That is part of what the Incubator is
 all about.
 

I'm also +1 assuming there enough initial committers to get it going.

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

Re: JIRA and communities

[Ralph Goers]

On May 28, 2012, at 6:57 AM, Franklin, Matthew B. wrote:

 -Original Message-
 From: Benson Margulies [mailto:bimargul...@gmail.com]
 Sent: Saturday, May 26, 2012 10:51 AM
 To: general@incubator.apache.org
 Subject: Re: JIRA and communities
 
 So, what message here should the incubator send a podling, or the
 foundation send a TLP? I really don't mean this as a rhetorical
 question at all, I'm honestly puzzled. In the case of Lucene, I've
 been hanging out for months, and I feel perfectly confident that it's
 a healthy community by any foundation standard. At the same time, you
 all are perfectly correct: watching them means dealing with a tsunami
 of trivia. I'm stumped at what suggestion, let alone demand, I'd
 deliver to such a community.
 
 IMO, we wouldn't want to force a single workflow into each community just 
 because it appears to lower the barrier of entry.  I fully understand how 
 JIRA and ReviewBoard can pollute a mail list; however, if that is how the 
 community wants to operate, why stop them?  Since everything gets forwarded 
 to the dev list, IMO JIRA and ReviewBoard are perfectly legitimate tools for 
 managing  workflows within communities.   We can always suggest changes and 
 simplifications, or try out new processes and workflows, but forcing a 
 community to operate a specific way doesn't seem appropriate.  

The problem here is that discussions and decisions are supposed to happen on 
the dev list.  With ReviewBoard, while everything does get sent to the list, 
the discussion is extremely difficult to follow just by looking at the email.  
In fact, I'd wonder how many devs who are on projects that use ReviewBoard read 
those emails.  As far as Flume goes, if you take away the Jira and ReviewBoard 
noise I'd guess more technical discussion takes place on the user's list than 
on the dev list.  Of course, I haven't looked at the other projects that use it 
so I don't know if it is the same there.

By the way, if anyone can tell me how to configure gmail to filter the 
ReviewBoard stuff so I can put it in its own folder I would greatly appreciate 
it. 

 
 One thing I have seen a few podlings do is add a users mail list that offers 
 a lower barrier of entry and allows newcomers to gradually become more 
 immersed in the daily operations of the project.

IMO, every project should have a user's list, but that is really more for end 
users who have questions on how to use the project.

Ralph


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

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On May 26, 2012, at 9:29 PM, Arvind Prabhakar wrote:

 Hi Jukka,
 
 On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.comwrote:
 
 IIUC Flume operates under an RTC model where people are not supposed
 to commit their own changes, which obviously makes the above data less
 relevant for evaluating the true diversity of the community. However,
 seeing only a single trivial commit by both jarcec and juhanic even
 though they became committers already over three months ago does seem
 to suggest that they may not be as comfortable in their committer role
 as people from Cloudera are.
 
 
 As you noted in your comments above - the Flume project tends to follow RTC
 with the reviewer committing the code. I happen to have taken up the role
 of the reviewer for the most part and hence you see the skewed commit
 counts. If you want to see the actual contribution, I would suggest looking
 at fixed JIRA issues by assignees. A quick report yields the following:
 
aprabhkar - 26 - Cloudera [6]
brocknoland - 19 - Cloudera [7]
esammer - 56 - Cloudera [8]
hshreedharan - 34 - Cloudera [9]
jarcec - 6 - AVG Technologies [10]
jmhsieh - 8 - Cloudera [11]
juhanic - 9 - CyberAgent [12]
mpercy - 34 - Cloudera [13]
m...@apache.org - 1 - Trend Micro [14]
prasadm - 34 - Cloudera [15]
t...@cloudera.com - 3 - Cloudera [16]
w...@cloudera.com - 3 - Cloudera [17]
 
 Looking at this, the average number of issues resolved by Cloudera
 committers (not counting Tom who is a mentor) is 26, and that for
 non-Cloudera committers is 5. Note that this number does not include other
 committer work such as the number of code reviews they have done, the
 number of design discussions they have participated in, something that is
 very valuable to the project.

Another way of  looking at these same statistics:
Cloudera - 217
Other - 16

That means Cloudera is responsible for over 93% of the Jira issues.  It is 
great that Cloudera is doing so much work but those stats hardly prove 
diversity.


Ralph


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

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

Roy, What you are saying directly contradicts 
http://incubator.apache.org/guides/graduation.html#community, especially the 
statement Basically this means that when a project mostly consists of 
contributors from one company, this is a sign of not being diverse enough.  
Now, if that page is wrong and diversity is not a requirement for graduation 
then, of course, that would certainly remove any objections I have for Flume's 
graduation. However, I've heard it said that the ASF does not want to simply 
provide the infrastructure for companies to host their products on.

Ralph


On May 27, 2012, at 1:35 AM, Roy T. Fielding wrote:

 There is no diversity requirement for graduating from the incubator. In many 
 ways, incubation hinders community growth. The requirement is that the 
 project makes decisions as an Apache project, not in private, which is harder 
 to get used to doing if a lot of people share the same office. 
 
 Diversity is only a warning sign that means we need to check for decisions 
 made in our forums and advise accordingly. It is not an end in itself, nor 
 has lack of diversity hindered other projects from continuing on to build a 
 larger community as a TLP.
 
 Roy
 
 
 On May 26, 2012, at 11:44 PM, Ralph Goers ralph.go...@dslextreme.com wrote:
 
 
 On May 26, 2012, at 9:29 PM, Arvind Prabhakar wrote:
 
 Hi Jukka,
 
 On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting 
 jukka.zitt...@gmail.comwrote:
 
 IIUC Flume operates under an RTC model where people are not supposed
 to commit their own changes, which obviously makes the above data less
 relevant for evaluating the true diversity of the community. However,
 seeing only a single trivial commit by both jarcec and juhanic even
 though they became committers already over three months ago does seem
 to suggest that they may not be as comfortable in their committer role
 as people from Cloudera are.
 
 
 As you noted in your comments above - the Flume project tends to follow RTC
 with the reviewer committing the code. I happen to have taken up the role
 of the reviewer for the most part and hence you see the skewed commit
 counts. If you want to see the actual contribution, I would suggest looking
 at fixed JIRA issues by assignees. A quick report yields the following:
 
  aprabhkar - 26 - Cloudera [6]
  brocknoland - 19 - Cloudera [7]
  esammer - 56 - Cloudera [8]
  hshreedharan - 34 - Cloudera [9]
  jarcec - 6 - AVG Technologies [10]
  jmhsieh - 8 - Cloudera [11]
  juhanic - 9 - CyberAgent [12]
  mpercy - 34 - Cloudera [13]
  m...@apache.org - 1 - Trend Micro [14]
  prasadm - 34 - Cloudera [15]
  t...@cloudera.com - 3 - Cloudera [16]
  w...@cloudera.com - 3 - Cloudera [17]
 
 Looking at this, the average number of issues resolved by Cloudera
 committers (not counting Tom who is a mentor) is 26, and that for
 non-Cloudera committers is 5. Note that this number does not include other
 committer work such as the number of code reviews they have done, the
 number of design discussions they have participated in, something that is
 very valuable to the project.
 
 Another way of  looking at these same statistics:
 Cloudera - 217
 Other - 16
 
 That means Cloudera is responsible for over 93% of the Jira issues.  It is 
 great that Cloudera is doing so much work but those stats hardly prove 
 diversity.
 
 
 Ralph
 
 
 -
 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: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On May 26, 2012, at 10:11 AM, Arvind Prabhakar wrote:

 On Fri, May 25, 2012 at 12:29 PM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:
 
 At this point my recommendations are:
 1. Since the PPMC voted to separate being a committer and being a PMC
 member I would wait a couple of months and then add the new non-Cloudera
 committers to the PPMC if it is warranted.
 2. Of course, add any new committers who have earned it.
 3. Send an email to the entire PPMC asking them to confirm that they want
 to remain on the PMC after graduation.
 4. Based on that we will know what the making of the post-graduation PMC
 will look like.
 5. Raise the topic of graduation as a discussion item either on the PMC or
 dev list after the above 4 are completed.
 
 
 
 What purpose will these recommendations serve?
 * We have established that there is sufficient diversity in the committers
 list.
 * Without counting you, there are two other non-Cloudera PPMC who have
 expressed their commitment to the project.
 * The VOTE thread has overwhelmingly established what the community wants.
 * We, the active PPMC have demonstrated self-governance using accepted
 Apache practices and are committed to growing and diversifying the project
 further.
 
 If at this stage you insist on postponing the graduation, I am inclined to
 think that perhaps your own preferences outweigh that of the project and
 community. Please don't get me wrong - I am not accusing you of anything,
 just requesting you to please consider revoking your -1 vote.

Arvind - my preferences are my following through as a mentor for Flume and 
insuring the project's success.  That is my duty as a member of the ASF and the 
obligation I took on as a member of the IPMC.  One measure of that would be to 
consider what would happen if all the Cloudera people were to suddenly vanish 
from the project (this could easily happen if Cloudera were purchased by a 
larger company who had different goals).  As it stands today I don't believe 
the project would survive very long.


Ralph


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

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On May 25, 2012, at 2:46 AM, Arvind Prabhakar wrote:

 On Thu, May 24, 2012 at 11:49 AM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:
 
 
 On May 24, 2012, at 10:40 AM, Arvind Prabhakar wrote:
 
 There are four companies represented in this list: AVG Technologies,
 Cloudera, CyberAgent and Trend Micro. Compared to other projects that
 have
 successfully graduated from Incubator in the past, this meets the
 diversity
 requirements very well.
 
 I was mistaken and the list above is indeed correct.  For some reason I
 thought a couple of them had become Cloudera employees.
 
 However, none of those three are currently on the PPMC.  When you look at
 the PPMC list you should also include a few more Cloudera people who do
 participate in release votes and PPMC issues. Most, if not all, of the
 non-Cloudera PMC members don't.
 
 
 Back in October of 2011 the PPMC discussed and decided to use the process
 where new committers are not automatically added to PPMC. We have since
 followed this process and added one committer to the PPMC recently.
 
 The current PPMC consists of:
 
 * Andrew Bayer (Cloudera)
 * Ahmed Radwan (Cloudera)
 * Arvind Prabhakar(Cloudera)
 * Bruce Mitchener (Independent)
 * Derek Deeter (Intuit)
 * Eric Sammer (Cloudera)
 * Henry Robinson (Cloudera)
 * Jonathan Hsieh (Cloudera)
 * Aaron Kimball (Odiago)
 * Ralph Goers (Intuit)
 
 There is a representation of at least four companies in this list. This,
 plus the the fact that we have demonstrated our commitment to the policies
 that we set forth, give me the confidence that we are on the right track.
 Diversity is a priority and will continue to be post graduation.

Are you really going to resort to distortion of the truth to try to claim 
diversity?  I work with Derek and know that he has never participated in Flume 
since its inception. I also can't recall Bruce or Aaron participating after the 
podling started. All of them appear to have just signed the initial wiki page 
to get on the PPMC. 

I'm not sure why you left Tom White and Patrick Hunt off as they are both 
mentors and are PPMC members and both have participated in PMC discussions. 

That leaves just me as the only non-Cloudera PPMC member who actively 
participates and I don't commit code and I've been on the PPMC primarily as a 
mentor.  If you somehow believe that this constitutes diversity than my job as 
a mentor has a long way to go.

Ralph


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

Re: JIRA and communities

[Ralph Goers]

On May 25, 2012, at 8:37 AM, Benson Margulies wrote:

 On Fri, May 25, 2012 at 12:53 AM, Steve Loughran
 steve.lough...@gmail.com wrote:
 On 24 May 2012 06:15, Benson Margulies bimargul...@gmail.com wrote:
 
 I've met other groups of people who like a JIRA centric view
 of the world. I suspect that if they did a bunch of other good things
 called out below, you or others would find the JIRA business
 digestible. Also, on the other hand, I fear that the co-employed
 contributors are collaborating in the hallway, and the lack of the
 context in JIRA or on the list is contributing to the problem.
 
 
 I'm not convinced that JIRA helps communities. It's great in companies -IDE
 integration, you can bounce issues to others, it pings your phone so often
 you can use it as a network liveness test. It also lets you persist
 discussions in a way that can be searched. In a busy project, it helps you
 keep track of your workload, and can assist in sprint planning if you fill
 in the est/actual workload fields.
 
 I don't claim that JIRA helps, but I also don't accept the proposition
 that JIRA hurts.
 
 I think that we should focus on the community, not the tools. The
 JIRA-oriented projects I follow have JIRA set to send all new issues,
 and all new comments, to the dev list. So all community members, and,
 in particular, all PMC members with a duty to supervise, see all the
 traffic.

I have no problem with Jira, it is a great tool.  My problem - specific to the 
way Flume does things - is that they also use the Review tool and you end up 
with a copy of a message from the Review tool and another copy of the same 
thing from Jira.  A LOT of those messages are pure noise.  The ones that do 
contain content do a poor job of quoting whatever is being commented on.  So 
the only way to really tell what is going on is to go into Jira and look at 
every issue.  

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

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On May 25, 2012, at 11:03 AM, Arvind Prabhakar wrote:

 
 That leaves just me as the only non-Cloudera PPMC member who actively
 participates and I don't commit code and I've been on the PPMC primarily as
 a mentor.  If you somehow believe that this constitutes diversity than my
 job as a mentor has a long way to go.
 
 
 You were counted because three months ago you announced that you would like
 to stay with the project post graduation. I don't remember seeing any
 communication from you stating your change of mind. That said, I respect
 your choice either way.

Arvind, I don't take disagreements like this personally and I hope you don't 
either.   I have every intention of staying with the project after graduation 
and hopefully, finding a way to commit code as there are a number of areas I 
believe I can contribute.

At this point my recommendations are:
1. Since the PPMC voted to separate being a committer and being a PMC member I 
would wait a couple of months and then add the new non-Cloudera committers to 
the PPMC if it is warranted.
2. Of course, add any new committers who have earned it.
3. Send an email to the entire PPMC asking them to confirm that they want to 
remain on the PMC after graduation.
4. Based on that we will know what the making of the post-graduation PMC will 
look like.
5. Raise the topic of graduation as a discussion item either on the PMC or dev 
list after the above 4 are completed.   

Ralph



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

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On May 23, 2012, at 10:48 PM, Patrick Hunt wrote:

 On Wed, May 23, 2012 at 10:36 PM, Ralph Goers
 ralph.go...@dslextreme.com wrote:
 
 On May 23, 2012, at 10:15 PM, Benson Margulies wrote:
 
 On Wed, May 23, 2012 at 10:09 PM, Ralph Goers
 ralph.go...@dslextreme.com wrote:
 Right after I read Jukka's email that started this thread and I posted my 
 reply and discovered to my shock that they had started a graduation vote.  
 I am shocked because I have pointed out repeatedly the project's complete 
 lack of diversity.  Virtually all the active PMC members and committers 
 work for the same employer.  I have told them several times that I would 
 actually like to participate in the project but the way the project works 
 is very different then every other project I am involved with at the ASF 
 and the barriers to figure out what is actually going on is very high. 
 Almost nothing is discussed directly on the dev list - it is all done 
 through Jira issues or the Review tool.  While all the Jira issue updates 
 and reviews are sent to the dev list most of that is just noise.  Feel 
 free to review the dev list archives to see what I am talking about.
 
 I don't follow flume, but I'd propose to soften your objection only
 slightly. I've met other groups of people who like a JIRA centric view
 of the world. I suspect that if they did a bunch of other good things
 called out below, you or others would find the JIRA business
 digestible. Also, on the other hand, I fear that the co-employed
 contributors are collaborating in the hallway, and the lack of the
 context in JIRA or on the list is contributing to the problem.
 
 I have reason to doubt the collaboration in the hallway aspect and I 
 certainly do not doubt everyone's good intent.  I'm not objecting to the 
 collaboration style as an issue preventing graduation. I'm just saying I 
 find it difficult to participate with that style and that simply makes me 
 wonder if that is making it harder to attract new committers.  I fully 
 realize that that issue might just be with me, but the fact remains that 
 there is practically no diversity in the project and I cannot in good 
 conscience recommend graduation for a project in that situation.
 
 
 Hi Ralph, Benson, et. al., some background:
 
 Flume is similar to Hadoop and other related projects in that it is
 very jira heavy for development activity. No slouch in terms of
 mailing list traffic either though (1200 last month):
 http://flume.markmail.org/
 
 Also note the extensive new developer type detail that's available
 on the web/wiki:
 https://cwiki.apache.org/confluence/display/FLUME/Index
 
 The team list can provide insight into the diversity issue
 http://incubator.apache.org/flume/team-list.html My understanding is
 that there are at least 4 separate organizations represented by active
 commiters.
 

The team list is incorrect and is somewhat misleading.  To my knowledge at 
least two separate organizations represented in that list are now employed by 
Cloudera.  Others signed on when the project entered the incubator but have 
never participated.  This all became clear to me during the last release vote 
when, as I recall, I cast the only binding vote that didn't come from a 
Cloudera employee.

Ralph




 Regards,
 
 Patrick
 
 
 
 Needless to say, when the graduation proposal reaches this list, and I'm 
 sure it will, I will strongly endorse the IPMC to reject the proposal.
 
 FWIW, I found the post below to be 100% on target.
 
 Ralph
 
 
 
 On May 23, 2012, at 7:31 PM, Marvin Humphrey wrote:
 
 On Wed, May 23, 2012 at 5:36 PM, Patrick Hunt ph...@apache.org wrote:
 Perhaps someone will have some insight on how to gather new
 contributors that hasn't been tried yet?
 
 Jukka's written on this subject multiple times in the past.  Here are two
 gems, one from a while back, the other recent:
 
http://markmail.org/message/o3gbgam4ny2upqte
 
Most of the cases I've been involved so far of podlings in the hoping
some more people come along have had symptoms of the project team not
paying enough attention on making it easy for new contributors to show 
 up
and stick around. Things like complex and undocumented build steps,
missing Getting started or Getting involved guides, lack of quick 
 and
positive feedback to newcomers, etc., are all too common. Fixing even 
 just
some of such things will dramatically increase the odds of new people
showing up.
 
Those are things that are very easy to overlook when you're working on
your first open source projects (it took me years to learn those 
 lessons),
but we here have a massive amount of collective experience on such 
 things.
That's what we could and IMHO should be sharing with the podlings. 
 That's
what mentoring to me is about and that's where our most precious 
 added
value is. Otherwise incubation just boils down to an indoctrination
period on how to apply and conform to the various Apache

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On May 23, 2012, at 10:48 PM, Patrick Hunt wrote:

 On Wed, May 23, 2012 at 10:36 PM, Ralph Goers
 ralph.go...@dslextreme.com wrote:
 
 On May 23, 2012, at 10:15 PM, Benson Margulies wrote:
 
 On Wed, May 23, 2012 at 10:09 PM, Ralph Goers
 ralph.go...@dslextreme.com wrote:
 Right after I read Jukka's email that started this thread and I posted my 
 reply and discovered to my shock that they had started a graduation vote.  
 I am shocked because I have pointed out repeatedly the project's complete 
 lack of diversity.  Virtually all the active PMC members and committers 
 work for the same employer.  I have told them several times that I would 
 actually like to participate in the project but the way the project works 
 is very different then every other project I am involved with at the ASF 
 and the barriers to figure out what is actually going on is very high. 
 Almost nothing is discussed directly on the dev list - it is all done 
 through Jira issues or the Review tool.  While all the Jira issue updates 
 and reviews are sent to the dev list most of that is just noise.  Feel 
 free to review the dev list archives to see what I am talking about.
 
 I don't follow flume, but I'd propose to soften your objection only
 slightly. I've met other groups of people who like a JIRA centric view
 of the world. I suspect that if they did a bunch of other good things
 called out below, you or others would find the JIRA business
 digestible. Also, on the other hand, I fear that the co-employed
 contributors are collaborating in the hallway, and the lack of the
 context in JIRA or on the list is contributing to the problem.
 
 I have reason to doubt the collaboration in the hallway aspect and I 
 certainly do not doubt everyone's good intent.  I'm not objecting to the 
 collaboration style as an issue preventing graduation. I'm just saying I 
 find it difficult to participate with that style and that simply makes me 
 wonder if that is making it harder to attract new committers.  I fully 
 realize that that issue might just be with me, but the fact remains that 
 there is practically no diversity in the project and I cannot in good 
 conscience recommend graduation for a project in that situation.
 
 
 Hi Ralph, Benson, et. al., some background:
 
 Flume is similar to Hadoop and other related projects in that it is
 very jira heavy for development activity. No slouch in terms of
 mailing list traffic either though (1200 last month):
 http://flume.markmail.org/

Sorry I didn't include this in my prior post but here you are making my point 
exactly.  I participate in several other Apache projects. Wading through 1200+ 
emails per month that are largely Jira/Review noise makes it very difficult for 
me to find posts that have any value. As a consequence I am largely forced to 
simply delete everything generated by he Review tool and Jira.  And I'm a 
mentor. I just don't see how newcomers are going to find this style welcoming.

Ralph




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

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

The ONLY issue I see for Flume to graduate is diversity.  No one will convince 
me that the current makeup constitutes diversity of any kind.  

Perhaps I shouldn't have brought up the mailing list issues as that was only 
meant in the spirit of trying to offer some advice on how more diversity could 
be achieved.  Flume is really the only community I participate in that contains 
Cloudera employees so I do find myself wondering if the way the project is run 
is because that is the way all projects with a large number of Cloudera 
employees are run.  That might make all of those participants comfortable but 
might create a barrier to others.

In any case - I'm not insisting that the way the project is run needs to 
change. I'm simply saying I cannot support graduation with the current makeup 
of the committers and PMC. I don't have a hard and fast ratio - gaining 10 new 
unaffiliated committers who don't do much isn't nearly as good as 2 or 3 who 
are very active.  Ultimately the project needs to figure out how to solve this.


Ralph


On May 23, 2012, at 11:48 PM, Eric Sammer wrote:

 I appreciate your position Ralph and I don't want anyone to feel like they
 can't contribute. As we've talked about before, we've been quick to nurture
 new contributors to committer status successfully in a few cases. It's true
 that some of the more active committers are from Cloudera, but it's not to
 the exclusion of anyone. Others aren't from Cloudera. Those of us that work
 together are also very strict about abiding to the if it's not on the
 mailing list, it didn't happen rule (where mailing list can mean JIRA or
 other ASF infrastructure as well).
 
 I'm happy to take your guidance as a mentor, but you also need to
 understand that some of the ways the Flume project has elected to operate
 are just a matter of taste. They were proposed, discussed, voted on (and
 not as a block by Cloudera employees, IIRC - pretty sure I was -0), and put
 in place and do not violate the Apache Way (like RTC vs. CTR). They aren't
 unheard of and they do not work to the exclusion of contributors (RTC, for
 instance, only impacts committers). I think the vote that was started was
 only to gauge community opinion as a first step (although I'm not
 completely well versed in the graduation process, to be honest).
 
 If there are concrete things we can do to improve diversity, in your
 opinion, I am extremely open to hearing them. We already do many of the
 (excellent) things listed earlier in the thread. JIRA noise withstanding
 (again, it's a matter of taste - I use the email frequently as I find
 trolling through JIRA slow) I'm definitely open to ideas. Of course, if
 Flume simply needs to remain in the incubator until we develop greater
 diversity, that's fine too. If we're not ready, we're just not ready.
 
 On Wed, May 23, 2012 at 11:18 PM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:
 
 
 On May 23, 2012, at 10:48 PM, Patrick Hunt wrote:
 
 On Wed, May 23, 2012 at 10:36 PM, Ralph Goers
 ralph.go...@dslextreme.com wrote:
 
 On May 23, 2012, at 10:15 PM, Benson Margulies wrote:
 
 On Wed, May 23, 2012 at 10:09 PM, Ralph Goers
 ralph.go...@dslextreme.com wrote:
 Right after I read Jukka's email that started this thread and I
 posted my reply and discovered to my shock that they had started a
 graduation vote.  I am shocked because I have pointed out repeatedly the
 project's complete lack of diversity.  Virtually all the active PMC members
 and committers work for the same employer.  I have told them several times
 that I would actually like to participate in the project but the way the
 project works is very different then every other project I am involved with
 at the ASF and the barriers to figure out what is actually going on is very
 high. Almost nothing is discussed directly on the dev list - it is all done
 through Jira issues or the Review tool.  While all the Jira issue updates
 and reviews are sent to the dev list most of that is just noise.  Feel free
 to review the dev list archives to see what I am talking about.
 
 I don't follow flume, but I'd propose to soften your objection only
 slightly. I've met other groups of people who like a JIRA centric view
 of the world. I suspect that if they did a bunch of other good things
 called out below, you or others would find the JIRA business
 digestible. Also, on the other hand, I fear that the co-employed
 contributors are collaborating in the hallway, and the lack of the
 context in JIRA or on the list is contributing to the problem.
 
 I have reason to doubt the collaboration in the hallway aspect and I
 certainly do not doubt everyone's good intent.  I'm not objecting to the
 collaboration style as an issue preventing graduation. I'm just saying I
 find it difficult to participate with that style and that simply makes me
 wonder if that is making it harder to attract new committers.  I fully
 realize that that issue might just be with me, but the fact remains

Re: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On May 24, 2012, at 10:40 AM, Arvind Prabhakar wrote:

 Hi,
 
 On Thu, May 24, 2012 at 12:19 AM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:
 
 The ONLY issue I see for Flume to graduate is diversity.  No one will
 convince me that the current makeup constitutes diversity of any kind.
 
 Perhaps I shouldn't have brought up the mailing list issues as that was
 only meant in the spirit of trying to offer some advice on how more
 diversity could be achieved.  Flume is really the only community I
 participate in that contains Cloudera employees so I do find myself
 wondering if the way the project is run is because that is the way all
 projects with a large number of Cloudera employees are run.  That might
 make all of those participants comfortable but might create a barrier to
 others.
 
 
 Here are the committers who have been active in the past three months:
 
 * Brock Noland (Cloudera)
 * Hari Shreedharan  (Cloudera)
 * Jarek Jarcec Cecho (AVG Technologies)
 * Juhani Connolly   (CyberAgent)
 * Mike Percy (Cloudera)
 * Mingjie Lai (Trend Micro)
 * Prasad Mujumdar (Cloudera)
 * Will McQueen (Cloudera)
 * Arvind Prabhakar (Cloudera)
 
 There are four companies represented in this list: AVG Technologies,
 Cloudera, CyberAgent and Trend Micro. Compared to other projects that have
 successfully graduated from Incubator in the past, this meets the diversity
 requirements very well.

I was mistaken and the list above is indeed correct.  For some reason I thought 
a couple of them had become Cloudera employees.  

However, none of those three are currently on the PPMC.  When you look at the 
PPMC list you should also include a few more Cloudera people who do participate 
in release votes and PPMC issues. Most, if not all, of the non-Cloudera PMC 
members don't.



 
 
 
 In any case - I'm not insisting that the way the project is run needs to
 change. I'm simply saying I cannot support graduation with the current
 makeup of the committers and PMC. I don't have a hard and fast ratio -
 gaining 10 new unaffiliated committers who don't do much isn't nearly as
 good as 2 or 3 who are very active.  Ultimately the project needs to figure
 out how to solve this.
 
 
 Stating that some committers who don't do much isn't nearly as good as 2
 or 3 who are very active is an unfair characterization. This is more
 unfair for those who are part of the project but have not been active
 lately due to whatever reasons, but have played a foundational role in
 getting the project to a point where it is today. I think they are as
 important as any other committer who may be very active at the moment.
 Merit once earned, never expires [1].
 
 [1] http://www.apache.org/dev/committers.html#committer-set-term

I think you misunderstood my point or I didn't state it very well.  Diversity 
isn't achieved simply by having bodies.  IOW I am not suggesting offering 
commit rights to people who haven't earned it just to meet some ratio.  
However, I am not suggesting the project has ever even considered doing that.

Ralph 



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

Re: June reports in two weeks

[Ralph Goers]

Jukka, since the last report I have changed my opinion a bit and recommend you 
add Flume to the low diversity list.

Ralph

On May 23, 2012, at 4:28 PM, Jukka Zitting wrote:

 Hi all,
 
 There's plenty of time still before the June reports [1] start flowing
 in. As an early remainder to podlings starting to draft their reports,
 here's how the IPMC saw your status as of the previous quarterly
 report in March [2]:
 
  IP clearance: Openmeetings
  No release: Bloodhound, Cordova, OpenOffice
  Low activity: Kalumet, Kato
  Low diversity: Bigtop, Etch, Isis, HCatalog, S4, Wave
  Ready to graduate: Flume
 
 Has the situation in your podling changed over the last three months?
 If not, what's your plan for improving the situation? Is there
 anything for which you'd appreciate more help?
 
 I'm especially worried about Kato as it seems like the project has
 more or less died even though the JSR 326 / Oracle trouble got finally
 sorted out. Is it time to retire the project or can we hope for a
 revival?
 
 I also wanted to start preparing for this reporting round in good time
 by assigning shepherds [3] already now. Using a fuzzy algorithm based
 on the available volunteers, their stated preferences, and the
 podlings they're already mentoring, I came up with the following
 initial assignments that I've also recorded on the wiki page:
 
  Benson Margulies - CloudStack, HCatalog, Kato
  Dave Fisher  - Bloodhound, Flume
  Matt Franklin- Bigtop, Flex, Openmeetings
  Matt Hogstrom- Cordova, OpenOffice.org
  Jukka Zitting- Etch, Isis, S4
  Mohammad Nour- Kalumet
  Ross Gardler - Wave
 
 Feel free to shuffle these around or ask for someone else to fill in
 if you're expecting to be too busy for the extra reviews in early
 June. Other IPMC members and interested observers, please jump in and
 volunteer as extra shepherds if you'd like to help this effort.
 
 As discussed earlier, shepherds are not there to replace existing
 mentors. If everything is going well with a project, the shepherd can
 simply acknowledge a report and move on. If there are any relevant
 questions that the report doesn't answer, the shepherd may ask the
 podling and its mentors for more details. And finally if something
 seems wrong, the shepherd should raise a flag for the mentors and the
 rest of the IPMC to focus on. Most importantly, we need to be talking
 *with* the podlings, not just *about* them, so especially any
 constructive and encouraging feedback to them will be highly useful.
 
 [1] http://wiki.apache.org/incubator/June2012
 [2] http://wiki.apache.org/incubator/March2012
 [3] http://wiki.apache.org/incubator/IncubatorShepherds
 
 BR,
 
 Jukka Zitting
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


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

Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

Right after I read Jukka's email that started this thread and I posted my reply 
and discovered to my shock that they had started a graduation vote.  I am 
shocked because I have pointed out repeatedly the project's complete lack of 
diversity.  Virtually all the active PMC members and committers work for the 
same employer.  I have told them several times that I would actually like to 
participate in the project but the way the project works is very different then 
every other project I am involved with at the ASF and the barriers to figure 
out what is actually going on is very high. Almost nothing is discussed 
directly on the dev list - it is all done through Jira issues or the Review 
tool.  While all the Jira issue updates and reviews are sent to the dev list 
most of that is just noise.  Feel free to review the dev list archives to see 
what I am talking about.

Needless to say, when the graduation proposal reaches this list, and I'm sure 
it will, I will strongly endorse the IPMC to reject the proposal.

FWIW, I found the post below to be 100% on target.

Ralph



On May 23, 2012, at 7:31 PM, Marvin Humphrey wrote:

 On Wed, May 23, 2012 at 5:36 PM, Patrick Hunt ph...@apache.org wrote:
 Perhaps someone will have some insight on how to gather new
 contributors that hasn't been tried yet?
 
 Jukka's written on this subject multiple times in the past.  Here are two
 gems, one from a while back, the other recent:
 
http://markmail.org/message/o3gbgam4ny2upqte
 
Most of the cases I've been involved so far of podlings in the hoping
some more people come along have had symptoms of the project team not
paying enough attention on making it easy for new contributors to show up
and stick around. Things like complex and undocumented build steps,
missing Getting started or Getting involved guides, lack of quick and
positive feedback to newcomers, etc., are all too common. Fixing even just
some of such things will dramatically increase the odds of new people
showing up.
 
Those are things that are very easy to overlook when you're working on
your first open source projects (it took me years to learn those lessons),
but we here have a massive amount of collective experience on such things.
That's what we could and IMHO should be sharing with the podlings. That's
what mentoring to me is about and that's where our most precious added
value is. Otherwise incubation just boils down to an indoctrination
period on how to apply and conform to the various Apache rules and
policies.
 
http://incubator.markmail.org/thread/qpzg6wdoq7cwko55
 
I've been involved with quite a few podlings with similar problems in
attracting longer-term contributors. In my experience the best way to
solve that problem is to change your mindset of expecting most such people
to be just one-off contributors. If you instead treat them as your next
new committers and engage with them as peers, many (though of course not
all) will respond in kind and actually become more involved.
 
Many developers, especially from commercial backgrounds, tend to treat
such contributors as just users reporting a problem. A typical interaction
goes like What's the problem? Do you have a test case? OK, let me fix it
(when I get around to it). A better approach is something like What's
the problem? OK, here are some pointers to the relevant bits in code. How
do you think this should be fixed?
 
 Here's another tip I picked up from Joe Schaefer: when you're voting in a new
 committer and they have a big patch set sitting in the queue, hold off and let
 *them* commit it so that they get the satisfaction, the new experience, and 
 the
 appreciation all at once.
 
 It would be nice if stuff like this was collected in Steps to building a
 community documentation somewhere, rather than scattered through the email
 archives.  I suggest Steps as a format because different approaches are
 required at different phases of the project and sizes of the community.
 
 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: Flume Graduation (was Re: June reports in two weeks)

[Ralph Goers]

On May 23, 2012, at 10:15 PM, Benson Margulies wrote:

 On Wed, May 23, 2012 at 10:09 PM, Ralph Goers
 ralph.go...@dslextreme.com wrote:
 Right after I read Jukka's email that started this thread and I posted my 
 reply and discovered to my shock that they had started a graduation vote.  I 
 am shocked because I have pointed out repeatedly the project's complete lack 
 of diversity.  Virtually all the active PMC members and committers work for 
 the same employer.  I have told them several times that I would actually 
 like to participate in the project but the way the project works is very 
 different then every other project I am involved with at the ASF and the 
 barriers to figure out what is actually going on is very high. Almost 
 nothing is discussed directly on the dev list - it is all done through Jira 
 issues or the Review tool.  While all the Jira issue updates and reviews are 
 sent to the dev list most of that is just noise.  Feel free to review the 
 dev list archives to see what I am talking about.
 
 I don't follow flume, but I'd propose to soften your objection only
 slightly. I've met other groups of people who like a JIRA centric view
 of the world. I suspect that if they did a bunch of other good things
 called out below, you or others would find the JIRA business
 digestible. Also, on the other hand, I fear that the co-employed
 contributors are collaborating in the hallway, and the lack of the
 context in JIRA or on the list is contributing to the problem.

I have reason to doubt the collaboration in the hallway aspect and I certainly 
do not doubt everyone's good intent.  I'm not objecting to the collaboration 
style as an issue preventing graduation. I'm just saying I find it difficult to 
participate with that style and that simply makes me wonder if that is making 
it harder to attract new committers.  I fully realize that that issue might 
just be with me, but the fact remains that there is practically no diversity in 
the project and I cannot in good conscience recommend graduation for a project 
in that situation.

Ralph

 
 
 
 Needless to say, when the graduation proposal reaches this list, and I'm 
 sure it will, I will strongly endorse the IPMC to reject the proposal.
 
 FWIW, I found the post below to be 100% on target.
 
 Ralph
 
 
 
 On May 23, 2012, at 7:31 PM, Marvin Humphrey wrote:
 
 On Wed, May 23, 2012 at 5:36 PM, Patrick Hunt ph...@apache.org wrote:
 Perhaps someone will have some insight on how to gather new
 contributors that hasn't been tried yet?
 
 Jukka's written on this subject multiple times in the past.  Here are two
 gems, one from a while back, the other recent:
 
http://markmail.org/message/o3gbgam4ny2upqte
 
Most of the cases I've been involved so far of podlings in the hoping
some more people come along have had symptoms of the project team not
paying enough attention on making it easy for new contributors to show up
and stick around. Things like complex and undocumented build steps,
missing Getting started or Getting involved guides, lack of quick and
positive feedback to newcomers, etc., are all too common. Fixing even 
 just
some of such things will dramatically increase the odds of new people
showing up.
 
Those are things that are very easy to overlook when you're working on
your first open source projects (it took me years to learn those 
 lessons),
but we here have a massive amount of collective experience on such 
 things.
That's what we could and IMHO should be sharing with the podlings. That's
what mentoring to me is about and that's where our most precious added
value is. Otherwise incubation just boils down to an indoctrination
period on how to apply and conform to the various Apache rules and
policies.
 
http://incubator.markmail.org/thread/qpzg6wdoq7cwko55
 
I've been involved with quite a few podlings with similar problems in
attracting longer-term contributors. In my experience the best way to
solve that problem is to change your mindset of expecting most such 
 people
to be just one-off contributors. If you instead treat them as your next
new committers and engage with them as peers, many (though of course not
all) will respond in kind and actually become more involved.
 
Many developers, especially from commercial backgrounds, tend to treat
such contributors as just users reporting a problem. A typical 
 interaction
goes like What's the problem? Do you have a test case? OK, let me fix it
(when I get around to it). A better approach is something like What's
the problem? OK, here are some pointers to the relevant bits in code. How
do you think this should be fixed?
 
 Here's another tip I picked up from Joe Schaefer: when you're voting in a 
 new
 committer and they have a big patch set sitting in the queue, hold off and 
 let
 *them* commit it so that they get the satisfaction, the new experience

Re: [VOTE] Let the retired Zeta Components project keep their name

[Ralph Goers]

Why does the IPMC need to vote on this? I don't see it as part of the list 
below of things the trademarks committee requires.

Ralph

On May 14, 2012, at 5:30 AM, Christian Grobmeier wrote:

 Hello,
 
 Zeta Components has been retired and the committers want to go to
 github with the project. They have requested to keep their name and
 reached out for trademarks if this is possible. Shane explained he
 would agree in this case if:
 
 A) the IPMC confirms the podling is retired
 B) the retirement guide has been fulfilled
 C) the community clearly note on their homepage that they are not
 longer associated with the ASF
 
 We have a successful vote for A).
 B) has been completed by me (pending some closing tasks from Infra)
 
 Assuming C) will be done by the community this vote is now to allow
 them to use their old name Zeta Components.
 
 Please note, no release has happened so far.
 
 Please choose:
 
 [] +1, allow them to use Zeta Components as name
 [] -1, don't, because
 
 This vote is open for 72h.
 
 Cheers
 Christian
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


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

Re: [VOTE] retire zeta components from incubation

[Ralph Goers]

+1 (binding)

Ralph

On May 3, 2012, at 1:12 AM, Julien Vermillard wrote:

 Hi,
 
 As discussed earlier the Zeta components community has voted
 to retire the project. Following the retirement guide [1], I now call
 the Incubator PMC to vote on confirming this decision. This vote is
 open for the next 72 hours.
 
   [ ] +1 Retire the Zeta components project
   [ ] -1 Do not retire the project, because ...
 
 [1] http://incubator.apache.org/guides/retirement.html
 
 Cheers,
 
 Julien
 
 -- Forwarded message --
 From: Julien Vermillard jvermill...@gmail.com
 Date: Fri, Apr 20, 2012 at 3:05 PM
 Subject: [RESULT] Re: [VOTE] retire zeta components from incubation
 To: zeta-...@incubator.apache.org
 Cc: general@incubator.apache.org
 
 
 So let's close the vote :
 
 +1 binding : grobmeier, beberlei, derick, jpic, oms, rolandb,
 +0 binding : kore, toby
 -1 none
 
 So let's close this podling.
 
 Julien
 
 -
 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] CloudStack for Apache Incubator

[Ralph Goers]

+1 binding

Ralph

On Apr 9, 2012, at 6:32 PM, Kevin Kluge wrote:

 Hi All.  I'd like to call for a VOTE for CloudStack to enter the Incubator.  
 The proposal is available at [1] and I have also included it below.   Please 
 vote with:
 +1: accept CloudStack into Incubator
 +0: don't care
 -1: do not accept CloudStack into Incubator (please explain the objection)
 
 The vote is open for at least 72 hours from now (until at least 19:00 US-PST 
 on April 12, 2012).
 
 Thanks for the consideration.
 
 -kevin
 
 [1] http://wiki.apache.org/incubator/CloudStackProposal
 
 
 
 
 Abstract
 
 CloudStack is an IaaS (Infrastracture as a Service) cloud orchestration 
 platform.
 
 Proposal
 
 CloudStack provides control plane software that can be used to create an IaaS 
 cloud. It includes an HTTP-based API for user and administrator functions and 
 a web UI for user and administrator access. Administrators can provision 
 physical infrastructure (e.g., servers, network elements, storage) into an 
 instance of CloudStack, while end users can use the CloudStack self-service 
 API and UI for the provisioning and management of virtual machines, virtual 
 disks, and virtual networks.
 
 Citrix Systems, Inc. submits this proposal to donate the CloudStack source 
 code, documentation, websites, and trademarks to the Apache Software 
 Foundation (ASF).
 
 Background
 
 Amazon and other cloud pioneers invented IaaS clouds. Typically these clouds 
 provide virtual machines to end users. CloudStack additionally provides 
 baremetal OS installation to end users via a self-service interface. The 
 management of physical resources to provide the larger goal of cloud service 
 delivery is known as orchestration. IaaS clouds are usually described as 
 elastic -- an elastic service is one that allows its user to rapidly scale 
 up or down their need for resources.
 
 A number of open source projects and companies have been created to implement 
 IaaS clouds. Cloud.com started CloudStack in 2008 and released the source 
 under GNU General Public License version 3 (GPL v3) in 2010. Citrix 
 acquired Cloud.com, including CloudStack, in 2011. Citrix re-licensed the 
 CloudStack source under Apache License v2 in April, 2012.
 
 Rationale
 
 IaaS clouds provide the ability to implement datacenter operations in a 
 programmable fashion. This functionality is tremendously powerful and 
 benefits the community by providing:
 
 - More efficient use of datacenter personnel
 - More efficient use of datacenter hardware
 - Better responsiveness to user requests
 - Better uptime/availability through automation
 
 While there are several open source IaaS efforts today, none are governed by 
 an independent foundation such as ASF. Vendor influence and/or proprietary 
 implementations may limit the community's ability to choose the hardware and 
 software for use in the datacenter. The community at large will benefit from 
 the ability to enhance the orchestration layer as needed for particular 
 hardware or software support, and to implement algorithms and features that 
 may reduce cost or increase user satisfaction for specific use cases. In this 
 respect the independent nature of the ASF is key to the long term health and 
 success of the project.
 
 Initial Goals
 
 The CloudStack project has two initial goals after the proposal is accepted 
 and the incubation has begun.
 
 The Cloudstack Project's first goal is to ensure that the CloudStack source 
 includes only third party code that is licensed under the Apache License or 
 open source licenses that are approved by the ASF for use in ASF projects. 
 The CloudStack Project has begun the process of removing third party code 
 that is not licensed under an ASF approved license. This is an ongoing 
 process that will continue into the incubation period. Third party code 
 contributed to CloudStack under the CloudStack contribution agreement was 
 assigned to Cloud.com in exchange for distributing CloudStack under GPLv3. 
 The CloudStack project has begun the process of amending the previous 
 CloudStack contribution agreements to obtain consent from existing 
 contributors to change the CloudStack project's license. In the event that an 
 existing contributor does not consent to this change, the project is prepared 
 to remove that contributor's code. Additionally, there are binary 
 dependencies on redistributed libraries that are not provided with an 
 ASF-approved license. Finally, the CloudStack has source files incorporated 
 from third parties that were not provided with an ASF-approved license. We 
 have begun the process of re-writing this software. This is an ongoing 
 process that will extend into the incubation period. These issues are 
 discussed in more detail later in the proposal.
 
 Although CloudStack is open source, many design documents and discussions 
 that should have been publicly available and accessible were not publicized. 
 The Project's second goal will be to fix 

Re: [VOTE] Release Apache Flume version 1.1.0-incubating (rc1)

[Ralph Goers]

Thanks, Matt. That provides the 3 IPMC votes required.

Ralph

On Mar 25, 2012, at 3:37 PM, Matt Hogstrom wrote:

 Compiled, verified checksums, review notices and spot checked source for 
 licenses. 
 
 +1 (binding)
 
 Matt Hogstrom
 m...@hogstrom.org
 
 A Day Without Nuclear Fusion Is a Day Without Sunshine
 
 On Mar 23, 2012, at 11:06 AM, Prasad Mujumdar wrote:
 
 +1
 Verified checksums, signatures, and ran build/test.
 
 thanks
 Prasad
 
 On Mon, Mar 19, 2012 at 5:46 PM, Arvind Prabhakar arv...@apache.org wrote:
 
 This is the second incubator release for Apache Flume, version
 1.1.0-incubating. We are now voting on release candidate rc1.
 
 *** Please cast your vote within the next 72 hours ***
 
 The list of fixed issues:
 
 https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc1/CHANGELOG
 
 The tarball (*.tar.gz), signature (*.asc), checksum (*.md5sum,
 *.sha1sum) for the source and binary can be found at:
 http://people.apache.org/~arvind/flume/110rc1/
 
 The tag to be voted upon:
 
 https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc1/
 
 The KEYS file:
 http://www.apache.org/dist/incubator/flume/KEYS
 
 Changes since last build:
 * FLUME-1032. Fix Flume NG build for binary distribution
 * Updated change log and release notes.
 
 
 
 -
 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