Graduation resolution

[Julian Hyde]

Now the IPMC vote has passed, next step is to get the resolution onto the board 
agenda. The meeting is on Wed 21st, so we are just about in time. I am doing 
that this morning.

Julian

Re: Please take notice to check-in only meaningful javadoc.

[Julian Hyde]

This bugs me too. FWIW, in Calcite we run ‘mvn javadoc:javadoc 
javadoc:test-javadoc’ as part of the automated build (as of JDK 1.8, javadoc is 
quite strict). Neither javadoc nor checkstyle will flag useless javadoc like 
‘@param x’, so I wrote a checkstyle module[1] and call it from Calcite’s check 
style config[2].

Julian

[1] https://github.com/julianhyde/toolbox 


[2] https://issues.apache.org/jira/browse/CALCITE-1034 


> On Aug 24, 2016, at 12:13 AM, Hao Chen  wrote:
> 
> Good reminding. @Contributors, not only about java docs, pls. make sure all
> the code style matches the checkstyle, currently I just keep the checkstyle
> as WARNING as we still have lots of style warning to clean, in future we
> should throw ERROR if any check-style doesn't match. Pls. start to spend
> sometime cleaning the checkstyle warning in your code right now.
> 
> - Hao
> 
> On Wed, Aug 24, 2016 at 3:04 PM, Michael Wu  wrote:
> 
>> Hi guys,
>> 
>> Recently, when I tried to deploy eagle 0.5.0-incubating-snapshot artifacts
>> based on develop branch, the entire build flow was broken by lots of faulty
>> javadoc, which are classified in following aspects. I'll try to erase
>> illegal/meaningless javadoc, and please PAY ATTENTION to your contribution
>> and avoid checking-in such inappropriate javadoc:
>> 
>> 1. Illegal character found, e.g. "<", or ">". Except for recognized html
>> tags, such as "", "", etc., other angle brackets should
>> be replaced with entities, say, "<" should be "", and ">" should be
>> "".
>> 
>> 2. Many "" and "" found in apache license comment, enclosing the
>> license url. This kind of "p" tag is not allowed by javadoc, and actually,
>> it's useless to be placed in the license comment either. Next time you
>> create a new java file, please refer to another existing java file and
>> copy+paste the correct license comment to the head of your new file, and
>> make sure it does contain the "" pair around the license url.
>> 
>> 3. Many meaningless parameters and javadoc blocks found in files. This
>> issue could be more descriptive with a sample, see below javadoc fragment
>> that appears many times in eagle project on develop branch:
>>/**
>> *
>> * @param arg1
>> * @param arg2
>> * @return
>> */
>>This is a sample for rather meaningless javadoc. First, if there is no
>> description, why shall we add this javadoc? Seconds, if we don't add
>> description for arguments, who can know what to pass to the methods exactly
>> by reading the javadoc? Third, if we don't add description for return
>> value, how can customers understand the returning stuff by reading the
>> javadoc? As a whole, such javadoc should be erased because we are not
>> adding javadoc just for "adding", but for users or even code writers
>> themselves to understand code more clearly.
>> 
>> 4. Wrong upper case javadoc tag found. E.g. "@since" should be written in
>> all lowercase, but found as "@Since", which make the javadoc generator
>> complain with errors.
>> 
>> So far, I've deployed eagle 0.5.0-incubating-snapshot to apache maven
>> snapshot repository (
>> https://repository.apache.org/content/repositories/
>> snapshots/org/apache/eagle/).
>> It currently doesn't include javadoc jars because there were too many
>> javadoc error occurring while I was building the artifacts. When I erased
>> incorrect ones in a sub model, that model ran pass and the next model in
>> building chain raised up to complain. Therefore, it may cost me more time
>> to erase all the faulty javadoc until all models are built successfully.
>> 
>> Thank you for your understanding and cooperation.
>> 
>> Michael
>> 

Re: [DISCUSS] Is Eagle ready to graduate?

[Julian Hyde]

I did a quick survey, and it seems that most projects do not have a security 
team[1], which means that vulnerabilities should be reported to 
secur...@apache.org. Of the projects that do, Kafka seems a good model to 
follow; its security page is simple and clear[2].

Julian

[1] http://www.apache.org/security/projects.html 
<http://www.apache.org/security/projects.html>

[2] http://kafka.apache.org/project-security.html 
<http://kafka.apache.org/project-security.html> 


> On Aug 23, 2016, at 6:29 PM, P. Taylor Goetz <ptgo...@gmail.com> wrote:
> 
> 
> The maturity model assessment looks good to me, though I haven't delved deep 
> into it.
> 
> Regarding security issues, since Eagle is a security-related product I would 
> expect there to be a well-defined process/protocol that ensured vulnerability 
> reports were kept private until patched, CVE process, etc. Eagle hasn't had 
> any major security issues during incubation, but should be prepared for them 
> after graduation.
> 
> Here [1] [2] are two great resources for understanding what is expected from 
> an ASF standpoint.
> 
> -Taylor
> 
> [1] http://www.apache.org/security/
> [2] http://www.apache.org/security/committers.html
> 
>> On Aug 23, 2016, at 6:52 PM, Julian Hyde <jh...@apache.org> wrote:
>> 
>> I reviewed 
>> https://cwiki.apache.org/confluence/display/EAG/Eagle+Podling+Maturity+Assessment
>>  
>> <https://cwiki.apache.org/confluence/display/EAG/Eagle+Podling+Maturity+Assessment>
>>  and it looks good. 
>> 
>> Only one issue. Regarding QU30: The dev list and JIRA (listed in 
>> http://eagle.incubator.apache.org/sup/index.html 
>> <http://eagle.incubator.apache.org/sup/index.html>) do not seem appropriate 
>> places to report security issues, because they are public. Is a private 
>> channel needed?
>> 
>> Can some other mentors please review?
>> 
>> I think the consensus is emerging that Eagle is ready to graduate. The 
>> community should start taking steps to graduate, including agreeing bylaws 
>> (or deciding that bylaws are not necessary), choosing an initial PMC chair, 
>> crafting the resolution for the Board, and starting a vote thread.
>> 
>> Julian
>> 
>> 
>> 
>>> On Jul 31, 2016, at 9:05 PM, Edward Zhang <yonzhang2...@apache.org> wrote:
>>> 
>>> I have commented some assessment points and we can remove that once after
>>> they are reviewed.
>>> 
>>> Thanks
>>> Edward
>>> 
>>>> On Sun, Jul 31, 2016 at 7:09 PM, Hao Chen <h...@apache.org> wrote:
>>>> 
>>>> Thanks Michael for preparing the "Eagle Podling Maturity Assessment".
>>>> 
>>>> Eagle community,
>>>> 
>>>> could you (in particular Mentors & PPMC) please help review and comment?
>>>> 
>>>> - Hao
>>>> 
>>>>> On Fri, Jul 29, 2016 at 4:36 PM, Michael Wu <mchl@gmail.com> wrote:
>>>>> 
>>>>> Hi guys,
>>>>> 
>>>>> Following the model Julian cited, we created a wiki page for
>>>>> self-assessment at:
>>>>> 
>>>>> 
>>>> https://cwiki.apache.org/confluence/display/EAG/Eagle+Podling+Maturity+Assessment
>>>>> .
>>>>> Please take a look at it and make your valuable judgement and
>>>> instructions.
>>>>> 
>>>>> Overall, according to the aspects that the model values and inspects, and
>>>>> traverse the results listed in the wiki page, personally, I think Eagle
>>>> is
>>>>> approaching the point of graduation, and is facing the right way towards
>>>>> it. (please correct me if i'm wrong, thanks)
>>>>> 
>>>>> In this assessment wiki page, status "OK" stands for the all resolved
>>>>> items, status "ON GOING" stands for 2 items that we're striving to work
>>>> on
>>>>> and will update. Additionally, there is 1 item marked as "NOT APPLY"
>>>>> because the "convenient binaries" model seems not fitting for eagle,
>>>> could
>>>>> you please verify if it's true and rule RE40
>>>>> <
>>>>> 
>>>> https://cwiki.apache.org/confluence/display/EAG/Eagle+Podling+Maturity+Assessment#EaglePodlingMaturityAssessment-RE40
>>>>>> 
>>>>> could be skipped?
>>>>> 
>>>>> Any comment and instruction will be appreciated, as all we ma

Re: [DISCUSS] Is Eagle ready to graduate?

[Julian Hyde]

I reviewed 
https://cwiki.apache.org/confluence/display/EAG/Eagle+Podling+Maturity+Assessment
 
<https://cwiki.apache.org/confluence/display/EAG/Eagle+Podling+Maturity+Assessment>
 and it looks good. 

Only one issue. Regarding QU30: The dev list and JIRA (listed in 
http://eagle.incubator.apache.org/sup/index.html 
<http://eagle.incubator.apache.org/sup/index.html>) do not seem appropriate 
places to report security issues, because they are public. Is a private channel 
needed?

Can some other mentors please review?

I think the consensus is emerging that Eagle is ready to graduate. The 
community should start taking steps to graduate, including agreeing bylaws (or 
deciding that bylaws are not necessary), choosing an initial PMC chair, 
crafting the resolution for the Board, and starting a vote thread.

Julian



> On Jul 31, 2016, at 9:05 PM, Edward Zhang <yonzhang2...@apache.org> wrote:
> 
> I have commented some assessment points and we can remove that once after
> they are reviewed.
> 
> Thanks
> Edward
> 
> On Sun, Jul 31, 2016 at 7:09 PM, Hao Chen <h...@apache.org> wrote:
> 
>> Thanks Michael for preparing the "Eagle Podling Maturity Assessment".
>> 
>> Eagle community,
>> 
>> could you (in particular Mentors & PPMC) please help review and comment?
>> 
>> - Hao
>> 
>> On Fri, Jul 29, 2016 at 4:36 PM, Michael Wu <mchl@gmail.com> wrote:
>> 
>>> Hi guys,
>>> 
>>> Following the model Julian cited, we created a wiki page for
>>> self-assessment at:
>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/EAG/Eagle+Podling+Maturity+Assessment
>>> .
>>> Please take a look at it and make your valuable judgement and
>> instructions.
>>> 
>>> Overall, according to the aspects that the model values and inspects, and
>>> traverse the results listed in the wiki page, personally, I think Eagle
>> is
>>> approaching the point of graduation, and is facing the right way towards
>>> it. (please correct me if i'm wrong, thanks)
>>> 
>>> In this assessment wiki page, status "OK" stands for the all resolved
>>> items, status "ON GOING" stands for 2 items that we're striving to work
>> on
>>> and will update. Additionally, there is 1 item marked as "NOT APPLY"
>>> because the "convenient binaries" model seems not fitting for eagle,
>> could
>>> you please verify if it's true and rule RE40
>>> <
>>> 
>> https://cwiki.apache.org/confluence/display/EAG/Eagle+Podling+Maturity+Assessment#EaglePodlingMaturityAssessment-RE40
>>>> 
>>> could be skipped?
>>> 
>>> Any comment and instruction will be appreciated, as all we made or will
>>> make is to keep the project running in the right way. :)
>>> 
>>> Michael
>>> 
>>> On Fri, Jul 29, 2016 at 12:28 PM, Hao Chen <h...@apache.org> wrote:
>>> 
>>>> Thanks very much for bringing up graduation discussion for Eagle.
>>>> 
>>>> Eagle community has almost fully understand how to run an open source
>>>> project in apache way.  Apache Eagle (incubating) is now open to be
>>>> contributed and adopted by lots of different organizations including
>> but
>>>> not limited to eBay, Paypal, Dataguides, Yihaodian, etc. The community
>>> has
>>>> continuously been building and expanding itself by sharing and talking
>>>> eagle with the word industry in international conferences like Hadoop
>>>> Summit, Hadoop Stratus, QCon in San Jose, London, Dublin, Shanghai,
>>>> Beijing, etc. and also lots of meetups. And the community has
>>> successfully
>>>> release v0.3.0, v0.4.0 and is actively preparing v0.5.0 following
>> apache
>>>> releasing process.
>>>> 
>>>> To make it clear how close is eagle ready to graduate, right now the
>>>> community is working on preparing an "Eagle Podling Maturity
>> Assessment"
>>> to
>>>> measure how mature eagle is and what tasks may remain before
>> graduation,
>>>> will be sent out very soon.
>>>> 
>>>> - Hao
>>>> 
>>>> On Fri, Jul 29, 2016 at 11:25 AM, P. Taylor Goetz <ptgo...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Graduation is mostly about whether a podling is healthy in terms of
>>>>> growing the community and making releases. I don't think technical
>>> issues
>>>>> are relevan

[jira] [Commented] (EAGLE-331) avoid to use junit.framework.Assert

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15418085#comment-15418085
 ] 

Julian Hyde commented on EAGLE-331:
---

And instead, I presume, use {{org.junit.Assert}}?

> avoid to use junit.framework.Assert
> ---
>
> Key: EAGLE-331
> URL: https://issues.apache.org/jira/browse/EAGLE-331
> Project: Eagle
>  Issue Type: Bug
>Reporter: Edward Zhang
>Assignee: Lingang Deng
>Priority: Trivial
>
> all eagle code should not use deprecated Assert



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [Discuss] How do you think rename "develop" branch to "trunk"branch so that able to close pull request automatically?

[Julian Hyde]

+1 moving to “trunk” or “master”.

Regarding the name. These days more projects use the name “master” rather than 
“trunk”. (At least, that’s my impression. Hive, for instance, used “trunk” when 
it was primarily svn, and switched to “master” now it’s based on git.) But 
frankly either would be fine.

Julian



> On Aug 7, 2016, at 7:47 PM, Don Bosco Durai  wrote:
> 
> I also feel that moving development to “trunk” will be a good thing. Right 
> now, synchronizing the final release branch to the “trunk” seems to be a 
> redundant activity. In the release notes, we can always ask the users to use 
> the release branch and also when we create sub releases, they would be off 
> the previous release branch, so it would just work naturally.
> 
> Bosco
> 
> 
> 
> On 8/7/16, 7:12 PM, "Michael Wu"  wrote:
> 
>Sounds good to me, as long as it benefits the project.
> 
>On Fri, Aug 5, 2016 at 3:22 PM, Hao Chen  wrote:
> 
>> Currently we are faced a problem that we can't close the pull request from
>> contributors automatically.
>> 
>> When a pull request is merged in develop branch, github could not close the
>> pull request automatically and committers don't have permission to close
>> the pull request manually on github page, so that we have to ask the
>> contributor to close the branch manually otherwise there would be lots of
>> "OPEN" pull requests listed though most are merged.
>> 
>> Learning from github service:
>> 
>> "
>> To close this pull request, make a commit to your *master/trunk *branch
>> with (at least) the following in the commit message:
>> 
>>This closes #305
>> "
>> 
>> Commits with *"Closes #PULL-REQUEST-ID"* will only work on master/trunk, in
>> fact *trunk* branch should be our *develo *in purpose and would be better
>> for management.
>> 
>> Any comments are appreciated.
>> 
>> - Hao
>> 
> 
> 
> 

Re: Podling Report Reminder - August 2016

[Julian Hyde]

I think you should mention that the community is discussing
graduation, and that is completed the maturity assessment.

Maybe revise the "steps to graduation" in the light of those
discussions. None of those 3 came up when I asked "What is left to do
before Eagle graduates?". I think Eagle is close to the end game;
there is some housekeeping to do, and needs to agree on things like
bylaws (if any), PMC composition, and the text of the motion to put
before the Board.

Julian


On Sun, Jul 31, 2016 at 12:13 PM, Edward Zhang <yonzhang2...@gmail.com> wrote:
> I listed some achievement we have made for Eagle in last quarter, it should
> not be sufficient, please review and add back
>
>
> Eagle
>
>
> 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 has been incubating since 2015-10-26.
>
>
> Three most important issues to address in the move towards graduation:
>
> 1. Release of Apache Eagle 0.4.0
>
> 2. Community is growing and contributors built multiple use cases on top of
> Eagle framework
>
> 3. Eagle site is modified to have more useful user guide content and to be
> more aligned with Apache Podling policies.
>
>
> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
>
> aware of?
>
> NIL
>
>
> How has the community developed since the last report?
>
> . Presented in Apache Con, May 2016
>
> . Presented in London Stratus + Hadoop, May 2016
>
> . Presented in San Jose Hadoop Summit, June 2016
>
> . Presented in China ...
>
> Communities showed continuous interest in Apache Eagle project. Some
> company tried to integrate Eagle as part of whole solution and some
> contributed different use case to Eagle platform, for example MapR support,
> Oozie monitoring support etc.
>
>
> How has the project developed since the last report?
>
> Technically we added more documents for user to easily use Eagle
>
> Besides Hadoop security monitoring, we have started working on performance
> monitoring design and development based on the requests from community.
>
> As we may have multiple different use cases running on top of Eagle, a
> design discussion and prototype is conducted to make sure Eagle is a
> framework to host multiple use cases and user will use Eagle to manage
> those use cases.
>
> Alert engine is going to be decoupled from data processing so that alert
> engine will be multi-tenant and easy to be used by multiple use cases by
> incorporating well-designed metadata.
>
>
> Date of last release:
>
> 2016-07-19
>
>
> When were the last committers or PMC members elected?
>
> Daniel Zhou, 2016-06-15
>
> Michael Wu, 2016-06-17
>
>
> Signed-off-by:
>
> [ ](eagle) Owen O'Malley
>
> [](eagle) Henry Saputra
>
> [](eagle) Julian Hyde
>
> [](eagle) P. Taylor Goetz
>
> [](eagle) Amareshwari Sriramdasu
>
> Shepherd/Mentor notes:
>
>
>
> On Sun, Jul 31, 2016 at 6:15 AM, <johndam...@apache.org> wrote:
>
>> Dear podling,
>>
>> This email was sent by an automated system on behalf of the Apache
>> Incubator PMC. It is an initial reminder to give you plenty of time to
>> prepare your quarterly board report.
>>
>> The board meeting is scheduled for Wed, 17 August 2016, 10:30 am PDT.
>> The report for your podling will form a part of the Incubator PMC
>> report. The Incubator PMC requires your report to be submitted 2 weeks
>> before the board meeting, to allow sufficient time for review and
>> submission (Wed, August 03).
>>
>> Please submit your report with sufficient time to allow the Incubator
>> PMC, and subsequently board members to review and digest. Again, the
>> very latest you should submit your report is 2 weeks prior to the board
>> meeting.
>>
>> Thanks,
>>
>> The Apache Incubator PMC
>>
>> Submitting your Report
>>
>> --
>>
>> Your report should contain the following:
>>
>> *   Your project name
>> *   A brief description of your project, which assumes no knowledge of
>> the project or necessarily of its field
>> *   A list of the three most important issues to address in the move
>> towards graduation.
>> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>> aware of
>> *   How has the community developed since the last report
>> *   How has the project developed since the last report.
>>
>> This should be appended to the Incubator Wiki page at:
>>
>> http://wiki.apache.org/incubator/August2016
>>
>> Note: This is manually populated. You may need to wait a little before
>> this page is created from a template.
>>
>> Mentors
>> ---
>>
>> Mentors should review reports for their project(s) and sign them off on
>> the Incubator wiki page. Signing off reports shows that you are
>> following the project - projects that are not signed may raise alarms
>> for the Incubator PMC.
>>
>> Incubator PMC
>>

Re: Could u add jianxu1 into Eagle JIRA Assignee List

[Julian Hyde]

It looks as if you’re already on the “committers” and “developers” lists, and 
your name appears in the assignees drop down. Let me know if you still can’t 
assign to yourself.

> On Jul 25, 2016, at 2:56 AM, Xu, Jian (SysDev)  wrote:
> 
> Eagle Dev
> 
> I want to be eagle dev,  could u add jianxu1 into assignee list so I can 
> assign tasks to me.

Re: [ANNOUNCE] Apache Eagle 0.4.0-incubating released

[Julian Hyde]

Thanks, Michael. You did a great job as release manager. I know it was a lot of 
work.

> On Jul 20, 2016, at 10:36 PM, Liangfei.Su  wrote:
> 
> Cheers!
> 
> Thanks, Michael.
> 
> 
> On Thu, Jul 21, 2016 at 11:53 AM, Michael Wu  wrote:
> 
>> Hi,
>> 
>> The Apache Eagle (incubating) Community is happy to announce the release of
>> version 0.4.0-incubating from the Apache Incubator.
>> 
>> Apache Eagle (incubating) is a monitoring framework to analyze big data
>> platforms for security and performance.
>> 
>> The release bits are available at:
>> 
>> http://www.apache.org/dyn/closer.cgi?path=/incubator/eagle/apache-eagle-0.4.0-incubating
>> 
>> The change list is available at:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/tags/v0.4.0-incubating
>> 
>> We would like to thank all contributors who made the release possible.
>> 
>> Disclaimer :
>> Apache Eagle is an effort undergoing incubation at The Apache Software
>> Foundation
>> (ASF), sponsored by the Apache Incubator PMC.
>> Incubation is required of all newly accepted projects until a further
>> review
>> indicates that the infrastructure, communications, and decision making
>> process have stabilized in a manner consistent with other successful ASF
>> projects.
>> While incubation status is not necessarily a reflection of the completeness
>> or stability of the code, it does indicate that the project has yet to be
>> fully endorsed by the ASF.
>> 
>> Regards,
>> Apache Eagle (incubating) Community
>> 

Re: Web site branding

[Julian Hyde]

I’ve replied to the JIRA ticket. Let’s move the conversation there.

> On Jul 19, 2016, at 12:43 AM, Michael Wu <mchl@gmail.com> wrote:
> 
> @ Julian, or you may give your further comments on ticket EAGLE-380
> <https://issues.apache.org/jira/browse/EAGLE-380>. Thanks.
> 
> On Tue, Jul 19, 2016 at 3:28 PM, Michael Wu <mchl@gmail.com> wrote:
> 
>> Hi Julian,
>> 
>> Could you take a look at the 1st (disclaimer more prominent) and 3rd
>> (remove forking flag) topic in the last sending, please? I may need your
>> confirmation to make it clear in my mind, thanks a lot!
>> 
>> Michael
>> 
>> On Mon, Jul 18, 2016 at 5:09 PM, Michael Wu <mchl@gmail.com> wrote:
>> 
>>> @Julian,
>>> 
>>> (copy my reply from another thread and paste it as below)
>>> 
>>> Just copy your comments here and adding my comments. Thank you for the
>>> suggestions.
>>> 
>>> [Julian] - Also, make the disclaimer more prominent on the front page. It
>>> is buried at the bottom of a very long page. I think it should appear in
>>> the first screen-full.
>>> [Michael] - a find an example from Apache Blur Incubating, do you mean
>>> something similar to its disclaimer appears on front page? Such as:
>>> http://incubator.apache.org/blur/.
>>> 
>>> [Julian] - In the docs, qualify all Apache projects with Apache. I think
>>> you can skip "Apache" in the tag line "Secure Hadoop in real time" but you
>>> must acknowledge trademarks.
>>> [Michael] -
>>> 1. in the new site doc, I have added "Apache" preceding first mention of
>>> "eagle" on every page, and commented the following "Eagle" on the page is
>>> pointing to "Apache Eagle (incubating)".
>>> 2. "acknowledge trademarks", do you mean the trademarks of "hadoop". If I
>>> understand right, the "tag line" you mentioned has been modified, it would
>>> never mention "Hadoop" again.
>>> 
>>> [Julian] - In the docs, remove "fork me on github" from the top right
>>> corner. The call to action is to join the Apache community.
>>> [Michael] - Not quite clear with this tip. I'm wondering, where is the
>>> appropriate position for us to place the "forking" element on the page? As
>>> least, people may contribute by firstly forking a git repository. Do you
>>> think the top-nav tag bar is good to add forking components?
>>> 
>>> 
>>> Thanks.
>>> Michael
>>> 
>>> On Mon, Jul 18, 2016 at 4:02 PM, Julian Hyde <jh...@apache.org> wrote:
>>> 
>>>> I added the following comments to the JIRA case:
>>>> 
>>>> * Also, make the disclaimer more prominent on the front page. It is
>>>> buried at the bottom of a very long page. I think it should appear in the
>>>> first screen-full.
>>>> 
>>>> * Apply these guidelines throughout the site, in particular to the docs,
>>>> https://eagle.incubator.apache.org/docs/.
>>>> 
>>>> * In the docs, qualify all Apache projects with Apache. I think you can
>>>> skip "Apache" in the tag line "Secure Hadoop in real time" but you must
>>>> acknowledge trademarks.
>>>> 
>>>> * In the docs, remove "fork me on github" from the top right corner. The
>>>> call to action is to join the Apache community.
>>>> 
>>>> Julian
>>>> 
>>>>> On Jul 17, 2016, at 8:32 PM, Michael Wu <mchl@gmail.com> wrote:
>>>>> 
>>>>> BTW, here is a jira ticket for trying to fix this issue: EAGLE-380
>>>>> <https://issues.apache.org/jira/browse/EAGLE-380>. It'll be thankful
>>>> to see
>>>>> your comments on it. :)
>>>>> 
>>>>> On Mon, Jul 18, 2016 at 11:29 AM, Michael Wu <mchl@gmail.com>
>>>> wrote:
>>>>> 
>>>>>> Hi guys,
>>>>>> 
>>>>>> To my understanding on your suggestions, we could modify our docs in
>>>> the
>>>>>> following ways, please help review if they are satisfying the request:
>>>>>> 1. if "eagle" is in doc page title, change it to "Apache Eagle
>>>>>> (incubating)".
>>>>>> 2. if there are many "eagle"s appear in the doc page content, change
>>>

[jira] [Commented] (EAGLE-380) fix eagle site/doc branding issue

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384698#comment-15384698
 ] 

Julian Hyde commented on EAGLE-380:
---

1. Yes, something like blur. Or, since there is already the line "Eagle has 
been accepted as an Apache Incubator Project on Oct 26, 2015", the disclaimer 
could replace that line.

2a. Sounds good.

2b. Yes, if you use Hadoop you should add "Hadoop" to the list "Apache Eagle, 
Eagle, Apache, the Apache feather logo, and the Apache Incubator project logo 
are trademarks of The Apache Software Foundation". Maybe you no longer mention 
Hadoop. But currently you mention several Apache projects, including Storm, 
Spark, Ambari, Hive, so you should qualify them with "Apache" and add them to 
the list.

3. It's not appropriate for an Apache project to be saying "Fork me on Github". 
Sure, you want people to get the source code, but you also want them to know 
about mailing lists, JIRA etc.

Let's suppose I want to know how to get started as a developer. I'd probably 
click on "Community" then click "How to contribute", which takes me to... 
https://github.com/eBay/Eagle/wiki/How-to-Contribute. Oops, let's fix that!

Or, if I was starting at https://eagle.incubator.apache.org/docs/ I'd click 
"Development Quick Guide". Put a paragraph there, showing them how to "git 
clone ...; mvn install ...".

The information in 
https://github.com/apache/incubator-eagle/blob/master/README.md is great; maybe 
it should be in the Development Quick Guide.

> fix eagle site/doc branding issue
> -
>
> Key: EAGLE-380
> URL: https://issues.apache.org/jira/browse/EAGLE-380
> Project: Eagle
>  Issue Type: Task
>Reporter: Michael Wu
>Assignee: Michael Wu
>
> We may solve this issue in the following way:
> 1. if "eagle" is in doc page title, change it to "Apache Eagle (incubating)".
> 2. if there are many "eagle"s appear in the doc page content, change the 
> first mention of it to "Apache Eagle (incubating, called Eagle in the 
> following)".
> 3. change logo size or position.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Why?

[Julian Hyde]

Thanks for the explanation. But I hope you took note of my main point: code 
changes should be accompanied by sufficient explanation so that the community 
can review/understand them. We shouldn’t have to ask for an explanation.

Making code changes transparent helps to build community.

> On Jul 17, 2016, at 7:26 PM, Michael Wu <mchl@gmail.com> wrote:
> 
> @Julian,
> 
> it does seem confusing in this special case, let me explain why:
> 1. at the time we had the discussion, 0.4.0-incubating PPMC vote had not
> finished, and therefore I was not quite sure if it's the appropriate moment
> to create the patch for .jar files. So, that's why EAGLE-378 came later
> than EAGLE-377.
> 2. conventionally, we used to make a pull request bound to a jira ticket,
> so that's why I created the ticket just before the commit. If this is not a
> good manner, I will try to avoid it in the future.
> 3. EAGLE-377 was created based on the result of our discussion, and
> pointing to 0.5.0 as its "fix version", which could be seen as a bug-fix
> plan for 0.5.0.
> 
> Thanks for pointing the problem out.
> 
> Michael
> 
> On Sat, Jul 16, 2016 at 1:28 AM, Edward Zhang <yonzhang2...@apache.org 
> <mailto:yonzhang2...@apache.org>>
> wrote:
> 
>> I feel the same. Eagle project today needs more discussion in Eagle dev DL.
>> I do see many discussions and code reviews within individual emails instead
>> of going through Eagle dev DL. And some users also ask questions to
>> individual email directly :-)
>> 
>> Could I suggest Eagle committers and community please discuss important
>> plans and issues in Eagle dev DL to have public record for people to review
>> at any time?
>> 
>> Thanks
>> Edward
>> 
>> 
>> On Fri, Jul 15, 2016 at 10:07 AM, Julian Hyde <jh...@apache.org 
>> <mailto:jh...@apache.org>> wrote:
>> 
>>> I am seeing a few JIRA cases which are basically just check-in comments.
>>> They are created just before the commit, they explain what was done in
>> the
>>> commit, do not explain why, do not link to any previous or future work.
>>> 
>>> An example of this is EAGLE-378. It arrives a couple of days after I had
>> a
>>> conversation with Michael [1] about cleaning up included jars, yet it
>> seems
>>> to be doing exactly the opposite.
>>> 
>>> Is the Eagle project operating commit-then-review or review-then-commit?
>>> It seems to be operating commit-then-review, but if so, there’s not
>> enough
>>> information in the public record for people to review what is happening.
>>> 
>>> As my math teacher used to say: don’t just write down the answer, you
>> need
>>> to show your working!
>>> 
>>> Julian
>>> 
>>> [1] https://issues.apache.org/jira/browse/EAGLE-378 <
>>> https://issues.apache.org/jira/browse/EAGLE-378 
>>> <https://issues.apache.org/jira/browse/EAGLE-378>>
>>> 
>>> [2] https://issues.apache.org/jira/browse/EAGLE-377 
>>> <https://issues.apache.org/jira/browse/EAGLE-377> <
>>> https://issues.apache.org/jira/browse/EAGLE-377 
>>> <https://issues.apache.org/jira/browse/EAGLE-377>>

Re: Web site branding

[Julian Hyde]

I added the following comments to the JIRA case:

* Also, make the disclaimer more prominent on the front page. It is buried at 
the bottom of a very long page. I think it should appear in the first 
screen-full.

* Apply these guidelines throughout the site, in particular to the docs, 
https://eagle.incubator.apache.org/docs/.

* In the docs, qualify all Apache projects with Apache. I think you can skip 
"Apache" in the tag line "Secure Hadoop in real time" but you must acknowledge 
trademarks.

* In the docs, remove "fork me on github" from the top right corner. The call 
to action is to join the Apache community.

Julian

> On Jul 17, 2016, at 8:32 PM, Michael Wu <mchl@gmail.com> wrote:
> 
> BTW, here is a jira ticket for trying to fix this issue: EAGLE-380
> <https://issues.apache.org/jira/browse/EAGLE-380>. It'll be thankful to see
> your comments on it. :)
> 
> On Mon, Jul 18, 2016 at 11:29 AM, Michael Wu <mchl@gmail.com> wrote:
> 
>> Hi guys,
>> 
>> To my understanding on your suggestions, we could modify our docs in the
>> following ways, please help review if they are satisfying the request:
>> 1. if "eagle" is in doc page title, change it to "Apache Eagle
>> (incubating)".
>> 2. if there are many "eagle"s appear in the doc page content, change the
>> first mention of it to "Apache Eagle (incubating, called Eagle in the
>> following)".
>> 3. change logo size or position.
>> 
>> Anything missed, please DO correct me. Thanks.
>> Michael
>> 
>> 
>> On Thu, Jun 30, 2016 at 11:05 PM, Henry Saputra <henry.sapu...@gmail.com>
>> wrote:
>> 
>>> Yeah, thinking moving the link and incubator logo up in the header and
>>> keep
>>> the incubator disclaimer as footer.
>>> 
>>> Also move some content in between to separate page to make visitor scroll
>>> less for homepage.
>>> 
>>> Thoughts?
>>> 
>>> - Henry
>>> 
>>> On Thu, Jun 30, 2016 at 6:31 PM, John D. Ament <johndam...@apache.org>
>>> wrote:
>>> 
>>>> 
>>>> 
>>>> On 2016-06-29 20:48 (-0400), Henry Saputra <henry.sapu...@gmail.com>
>>>> wrote:
>>>>> Probably we could move this section to Powered By Eagle page so
>>> homepage
>>>>> could be more clear it is part of ASF and also include Incubator
>>>>> description on top of page.
>>>> 
>>>> So you're thinking about moving some of the ASF logos up, not buried in
>>>> the footer?
>>>> 
>>>>> 
>>>>> On Thursday, June 30, 2016, arunkarthick m <aruncarth...@gmail.com>
>>>> wrote:
>>>>> 
>>>>>> The eBay logo and Paypal logo under who uses Eagle part is taking up
>>>> too
>>>>>> much screen space. Apart from that ebay is mentioned only in one
>>> place.
>>>>>> 
>>>>>> Thanks,
>>>>>> Arun
>>>>>> 
>>>>>> On Wed, Jun 29, 2016 at 2:40 PM, Julian Hyde <jh...@apache.org
>>>>>> <javascript:;>> wrote:
>>>>>> 
>>>>>>> Check what the branding guide says. I think only the first
>>> occurrence
>>>>>>> needs to be fully-qualified.
>>>>>>> 
>>>>>>> But also ask yourself: Does this page make it look like the
>>> project
>>>> is
>>>>>>> controlled by a particular company?
>>>>>>> 
>>>>>>>> On Jun 29, 2016, at 1:57 PM, arunkarthick m <
>>>> aruncarth...@gmail.com
>>>>>> <javascript:;>>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> There are lots of places where we mentioned "Eagle". We need to
>>>> change
>>>>>>> them
>>>>>>>> to be Apache Eagle.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Arun
>>>>>>>> 
>>>>>>>> On Wed, Jun 29, 2016 at 11:52 AM, arun karthick manoharan <
>>>>>>>> aruncarth...@gmail.com <javascript:;>> wrote:
>>>>>>>> 
>>>>>>>>> I'm looking at the branding guide will send what I find.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Arun
>>

[jira] [Commented] (EAGLE-380) fix eagle site/doc branding issue

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381860#comment-15381860
 ] 

Julian Hyde commented on EAGLE-380:
---

Also, make the disclaimer more prominent on the front page. It is buried at the 
bottom of a very long page. I think it should appear in the first screen-full.

Apply these guidelines throughout the site, in particular to the docs, 
https://eagle.incubator.apache.org/docs/.

In the docs, qualify all Apache projects with Apache. I think you can skip 
"Apache" in the tag line "Secure Hadoop in real time" but you must acknowledge 
trademarks.

In the docs, remove "fork me on github" from the top right corner. The call to 
action is to join the Apache community.

> fix eagle site/doc branding issue
> -
>
> Key: EAGLE-380
> URL: https://issues.apache.org/jira/browse/EAGLE-380
> Project: Eagle
>  Issue Type: Task
>Reporter: Michael Wu
>Assignee: Michael Wu
>
> We may solve this issue in the following way:
> 1. if "eagle" is in doc page title, change it to "Apache Eagle (incubating)".
> 2. if there are many "eagle"s appear in the doc page content, change the 
> first mention of it to "Apache Eagle (incubating, called Eagle in the 
> following)".
> 3. change logo size or position.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Why?

[Julian Hyde]

I am seeing a few JIRA cases which are basically just check-in comments. They 
are created just before the commit, they explain what was done in the commit, 
do not explain why, do not link to any previous or future work.

An example of this is EAGLE-378. It arrives a couple of days after I had a 
conversation with Michael [1] about cleaning up included jars, yet it seems to 
be doing exactly the opposite.

Is the Eagle project operating commit-then-review or review-then-commit? It 
seems to be operating commit-then-review, but if so, there’s not enough 
information in the public record for people to review what is happening.

As my math teacher used to say: don’t just write down the answer, you need to 
show your working!

Julian

[1] https://issues.apache.org/jira/browse/EAGLE-378 


[2] https://issues.apache.org/jira/browse/EAGLE-377 

Re: [Discuss] what will be the decent way to remove jars from source code for releases

[Julian Hyde]

Great - thanks!

On Thu, Jul 14, 2016 at 2:44 AM, Michael Wu <mchl@gmail.com> wrote:
> Hi Julian,
>
> Ticket EAGLE-377 <https://issues.apache.org/jira/browse/EAGLE-377> has been
> created. We'll fix it in 0.5.0-incubating version. Thanks for your kindly
> reminding. Anything missed, please do let me know.
>
> Michael
>
> On Thu, Jul 14, 2016 at 11:21 AM, Julian Hyde <jh...@apache.org> wrote:
>
>> I understand now. But I have to say, even though I have read the git
>> commit logs and JIRA cases it’s very difficult to figure out why this
>> particular solution was chosen. And asking users to download a patch from
>> github is still a hack, yes? If you agree it’s a hack, why didn’t anyone
>> think to log a JIRA case to clean up?
>>
>> Julian
>>
>> [1] https://issues.apache.org/jira/browse/EAGLE-365 <
>> https://issues.apache.org/jira/browse/EAGLE-365>
>> [2]
>> https://github.com/apache/incubator-eagle/commit/9cd75b188941bf476878a2210984546e4e257c7a
>> <
>> https://github.com/apache/incubator-eagle/commit/9cd75b188941bf476878a2210984546e4e257c7a
>> >
>> [3] http://eagle.incubator.apache.org/docs/quick-start.html <
>> http://eagle.incubator.apache.org/docs/quick-start.html>
>> [4] https://github.com/apache/incubator-eagle/pull/180 <
>> https://github.com/apache/incubator-eagle/pull/180>
>>
>>
>> > On Jul 13, 2016, at 7:41 PM, Michael Wu <mchl@gmail.com> wrote:
>> >
>> > Hi Henry,
>> >
>> > The solution is we removed the jars out of the project source code
>> folder,
>> > and will use a PR patch to hold the files for downloading, so that
>> > customers can succeed to build in this flow: download source code
>> tar-ball
>> > -> extract tar-ball -> apply the patch -> maven build.
>> >
>> > This approach has been documented on apache eagle quick-start guide page.
>> >
>> > Thanks.
>> > Michael
>> >
>> > On Thu, Jul 14, 2016 at 12:33 AM, Henry Saputra <henry.sapu...@gmail.com
>> >
>> > wrote:
>> >
>> >> So what was the solution for this? Could someone points to JIRA or
>> Github
>> >> PR to fix this?
>> >>
>> >> Thanks much!
>> >>
>> >> - Henry
>> >>
>> >> On Mon, Jul 11, 2016 at 1:30 AM, Julian Hyde <jh...@apache.org> wrote:
>> >>
>> >>> Can someone explain why these jar files have to be checked into git?
>> >>> Many other jar (and other binary) files are retrieved from a maven
>> >>> repo when you build; why not these? You can use maven magic to
>> >>> extract/filter/copy these files exactly where you need them on the
>> >>> first build.
>> >>>
>> >>> Source files have a sacred role in open source because (a) they can be
>> >>> edited (a fundamental right granted by an open source license), (b)
>> >>> they can be audited during a release.
>> >>>
>> >>> And, leaving the open source issues aside and just looking at the
>> >>> software engineering, checking non-source files into a source-control
>> >>> system, and especially into git, is often a bad idea. For instance,
>> >>> projects hotly debate whether to check in java files generated by
>> >>> protobuf, because the .proto file is the "source", and the .java files
>> >>> are generated. Git doesn't handle binary files particularly well, and
>> >>> if the binary is modified a few times the git repo starts to become
>> >>> bloated in size.
>> >>>
>> >>> Julian
>> >>>
>> >>>
>> >>> On Sun, Jul 10, 2016 at 8:28 PM, Zhang, Edward (GDI Hadoop)
>> >>> <yonzh...@ebay.com> wrote:
>> >>>> In 0.3 release, Hemanth uses a patch to work around this issue. Can we
>> >>> use the same approach in 0.4 and in 0.5 we have decided to remove
>> >>> dependency on tomcat.
>> >>>>
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>> Edward
>> >>>>
>> >>>> 
>> >>>> From: Hao Chen <h...@apache.org>
>> >>>> Sent: Sunday, July 10, 2016 8:17:48 PM
>> >>>> To: dev@eagle.incubator.apache.org
>> >>>> Subject: Re: [Discuss] what will be the decent way to

Re: [Discuss] what will be the decent way to remove jars from source code for releases

[Julian Hyde]

I understand now. But I have to say, even though I have read the git commit 
logs and JIRA cases it’s very difficult to figure out why this particular 
solution was chosen. And asking users to download a patch from github is still 
a hack, yes? If you agree it’s a hack, why didn’t anyone think to log a JIRA 
case to clean up?

Julian

[1] https://issues.apache.org/jira/browse/EAGLE-365 
<https://issues.apache.org/jira/browse/EAGLE-365>
[2] 
https://github.com/apache/incubator-eagle/commit/9cd75b188941bf476878a2210984546e4e257c7a
 
<https://github.com/apache/incubator-eagle/commit/9cd75b188941bf476878a2210984546e4e257c7a>
[3] http://eagle.incubator.apache.org/docs/quick-start.html 
<http://eagle.incubator.apache.org/docs/quick-start.html>
[4] https://github.com/apache/incubator-eagle/pull/180 
<https://github.com/apache/incubator-eagle/pull/180>


> On Jul 13, 2016, at 7:41 PM, Michael Wu <mchl@gmail.com> wrote:
> 
> Hi Henry,
> 
> The solution is we removed the jars out of the project source code folder,
> and will use a PR patch to hold the files for downloading, so that
> customers can succeed to build in this flow: download source code tar-ball
> -> extract tar-ball -> apply the patch -> maven build.
> 
> This approach has been documented on apache eagle quick-start guide page.
> 
> Thanks.
> Michael
> 
> On Thu, Jul 14, 2016 at 12:33 AM, Henry Saputra <henry.sapu...@gmail.com>
> wrote:
> 
>> So what was the solution for this? Could someone points to JIRA or Github
>> PR to fix this?
>> 
>> Thanks much!
>> 
>> - Henry
>> 
>> On Mon, Jul 11, 2016 at 1:30 AM, Julian Hyde <jh...@apache.org> wrote:
>> 
>>> Can someone explain why these jar files have to be checked into git?
>>> Many other jar (and other binary) files are retrieved from a maven
>>> repo when you build; why not these? You can use maven magic to
>>> extract/filter/copy these files exactly where you need them on the
>>> first build.
>>> 
>>> Source files have a sacred role in open source because (a) they can be
>>> edited (a fundamental right granted by an open source license), (b)
>>> they can be audited during a release.
>>> 
>>> And, leaving the open source issues aside and just looking at the
>>> software engineering, checking non-source files into a source-control
>>> system, and especially into git, is often a bad idea. For instance,
>>> projects hotly debate whether to check in java files generated by
>>> protobuf, because the .proto file is the "source", and the .java files
>>> are generated. Git doesn't handle binary files particularly well, and
>>> if the binary is modified a few times the git repo starts to become
>>> bloated in size.
>>> 
>>> Julian
>>> 
>>> 
>>> On Sun, Jul 10, 2016 at 8:28 PM, Zhang, Edward (GDI Hadoop)
>>> <yonzh...@ebay.com> wrote:
>>>> In 0.3 release, Hemanth uses a patch to work around this issue. Can we
>>> use the same approach in 0.4 and in 0.5 we have decided to remove
>>> dependency on tomcat.
>>>> 
>>>> 
>>>> Thanks
>>>> 
>>>> Edward
>>>> 
>>>> 
>>>> From: Hao Chen <h...@apache.org>
>>>> Sent: Sunday, July 10, 2016 8:17:48 PM
>>>> To: dev@eagle.incubator.apache.org
>>>> Subject: Re: [Discuss] what will be the decent way to remove jars from
>>> source code for releases
>>>> 
>>>> Yes, the jars are added into the source package intentionally, which is
>>>> necessary for bootstrapping eagle service. So maybe it possible for us
>>> the
>>>> keep the jars following apache way? Otherwise we may need some
>> additional
>>>> work to refactoring our package method.
>>>> 
>>>> - Hao
>>>> 
>>>> On Mon, Jul 11, 2016 at 11:07 AM, Michael Wu <mchl@gmail.com>
>> wrote:
>>>> 
>>>>> Hi guys,
>>>>> 
>>>>> Further tested and verified, the 3 jar dependencies are NECESSARY for
>>> the
>>>>> eagle-service to start up. Without them, we can build the project but
>>> when
>>>>> we deploy it, eagle-service fails to start up complaining the lack of
>>> the
>>>>> dependencies. So, we cannot simply remove them before packaging the
>>> source
>>>>> tar ball.
>>>>> 
>>>>> @PPMC, so far, we can tell that the 3 rem

[jira] [Commented] (EAGLE-373) Move Eagle document to Eagle source code control

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374076#comment-15374076
 ] 

Julian Hyde commented on EAGLE-373:
---

In my experience keeping docs on a branch is tricky. (It is impossible to fix 
the code AND update the doc in a single patch.) I find it easier to put them in 
a sub-directory of the source code. Or you could create a separate git repo.

This issue must be fixed before Eagle graduates.

> Move Eagle document to Eagle source code control
> 
>
> Key: EAGLE-373
> URL: https://issues.apache.org/jira/browse/EAGLE-373
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Edward Zhang
>Assignee: Edward Zhang
>Priority: Minor
> Fix For: 0.5
>
>
> Today Eagle's document is maintained in 
> https://github.com/eaglemonitoring/eaglemonitoring.github.io, it does not 
> conform to Apache policy. We should move this into Apache git source control. 
> The approach is to create a branch called document in 
> https://github.com/apache/incubator-eagle/tree/document and put document into 
> it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (EAGLE-371) remove eagle-docs from develop branch

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374066#comment-15374066
 ] 

Julian Hyde commented on EAGLE-371:
---

Thanks for logging this case, [~yonzhang2012]. Have you considered combining 
the web site with the documentation? You could put this into a directory of 
your source code (not a branch), or you could create a new git repo (hosted 
under apache.org, and mirrored under github.com/apache). 

> remove eagle-docs from develop branch
> -
>
> Key: EAGLE-371
> URL: https://issues.apache.org/jira/browse/EAGLE-371
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Edward Zhang
>Assignee: Edward Zhang
>Priority: Trivial
> Fix For: 0.5
>
>
> eagle-docs will be maintained in 
> https://github.com/eaglemonitoring/eaglemonitoring.github.io, so we don't 
> need maintain duplicated documentation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (EAGLE-371) remove eagle-docs from develop branch

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372004#comment-15372004
 ] 

Julian Hyde commented on EAGLE-371:
---

Does this mean that eagle-docs are being removed from Apache git? That doesn't 
sound good.

Also, what is the URL where the documents are being published? Does that remain 
http://eagle.incubator.apache.org/docs?

> remove eagle-docs from develop branch
> -
>
> Key: EAGLE-371
> URL: https://issues.apache.org/jira/browse/EAGLE-371
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Edward Zhang
>Assignee: Edward Zhang
>Priority: Trivial
> Fix For: 0.5
>
>
> eagle-docs will be maintained in 
> https://github.com/eaglemonitoring/eaglemonitoring.github.io, so we don't 
> need maintain duplicated documentation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release: Apache Eagle 0.4.0-incubating (Release Candidate 3)

[Julian Hyde]

Downloaded, checked license, notice, signatures, built on OS X JDK 1.7.

Checked that the JARs have gone.

+1 (binding)

Julian


> On Jul 11, 2016, at 2:40 AM, Michael Wu  wrote:
> 
> Hi all,
> 
> This is a release vote for Apache Eagle, version 0.4.0-incubating, release
> candidate 3.
> 
> Highlighted changes in this release are as the following:
>  * JBDC Metadata Storage Extension
>  * Topology management in remote mode including start/stop/status
> operations
>  * Auditlogparser for MapR's audit log
>  * Oozie auditlog integration for Oozie security monitoring
>  * Add applicaiton "maprFSAuditLog"
>  * Refactor bin/eagle-sandbox-starter.sh to make it easier to use
> 
> Thanks to everyone who has contributed to this release.
> 
> Here's the release note:
> *https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/branch-0.4.0
> *
> 
> The artifacts to be voted on are located at:
> *https://dist.apache.org/repos/dist/dev/incubator/eagle/0.4.0-incubating-rc3/
> *
> 
> The commit to be voted upon:
> *https://github.com/apache/incubator-eagle/commit/eac0f27958f2ed8c6842938dad0a995a87fd0715
> *
> 
> Release tag is:
> *https://github.com/apache/incubator-eagle/releases/tag/v0.4.0-incubating-rc3
> *
> 
> Release artifacts are signed with the following key:
> http://people.apache.org/keys/committer/mw.asc
> 
> The hashes of the artifacts are as follows:
> apache-eagle-0.4.0-incubating-src-rc3.tar.gz.md5:
> 5781048a2fc2b3dcfe5e30a09be86d25
> apache-eagle-0.4.0-incubating-src-rc3.tar.gz.sha1:
> a98b565604b3921a4ea5c53e30479427b227e1e2
> 
> Please vote on releasing this package as: Apache Eagle 0.4.0-incubating.
> 
> The vote is open for the next 72 hours and passes if a majority of at least
> three +1 PPMC votes are cast.
> 
> [ ] +1 Release this Apache Eagle 0.4.0-incubating Release Candidate 3.
> 
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> 
> [ ] -1 Do not release this package because...
> 
> 
> Thanks.
> Michael

Re: [Discuss] what will be the decent way to remove jars from source code for releases

[Julian Hyde]

Can someone explain why these jar files have to be checked into git?
Many other jar (and other binary) files are retrieved from a maven
repo when you build; why not these? You can use maven magic to
extract/filter/copy these files exactly where you need them on the
first build.

Source files have a sacred role in open source because (a) they can be
edited (a fundamental right granted by an open source license), (b)
they can be audited during a release.

And, leaving the open source issues aside and just looking at the
software engineering, checking non-source files into a source-control
system, and especially into git, is often a bad idea. For instance,
projects hotly debate whether to check in java files generated by
protobuf, because the .proto file is the "source", and the .java files
are generated. Git doesn't handle binary files particularly well, and
if the binary is modified a few times the git repo starts to become
bloated in size.

Julian


On Sun, Jul 10, 2016 at 8:28 PM, Zhang, Edward (GDI Hadoop)
 wrote:
> In 0.3 release, Hemanth uses a patch to work around this issue. Can we use 
> the same approach in 0.4 and in 0.5 we have decided to remove dependency on 
> tomcat.
>
>
> Thanks
>
> Edward
>
> 
> From: Hao Chen 
> Sent: Sunday, July 10, 2016 8:17:48 PM
> To: dev@eagle.incubator.apache.org
> Subject: Re: [Discuss] what will be the decent way to remove jars from source 
> code for releases
>
> Yes, the jars are added into the source package intentionally, which is
> necessary for bootstrapping eagle service. So maybe it possible for us the
> keep the jars following apache way? Otherwise we may need some additional
> work to refactoring our package method.
>
> - Hao
>
> On Mon, Jul 11, 2016 at 11:07 AM, Michael Wu  wrote:
>
>> Hi guys,
>>
>> Further tested and verified, the 3 jar dependencies are NECESSARY for the
>> eagle-service to start up. Without them, we can build the project but when
>> we deploy it, eagle-service fails to start up complaining the lack of the
>> dependencies. So, we cannot simply remove them before packaging the source
>> tar ball.
>>
>> @PPMC, so far, we can tell that the 3 remaining jars are intended to be
>> there for the project's normal functionalities, they are important and
>> cannot be removed, can we just vote them as passed, please?
>>
>> Michael
>>
>> On Sat, Jul 9, 2016 at 3:46 PM, Michael Wu  wrote:
>>
>> > Hi dev group,
>> >
>> > As you may know, we encountered the issue of having depended jars within
>> > the source tar ball of 0.4.0-incubating RC1 and RC2, they are:
>> > ***
>> > eagle-assembly/src/main/lib/tomcat/bin/bootstrap.jar
>> > eagle-assembly/src/main/lib/tomcat/bin/commons-daemon.jar
>> > eagle-assembly/src/main/lib/tomcat/bin/tomcat-juli.jar
>> > ***
>> >
>> > I've verified, if the 3 jars are removed, maven build can also get
>> passed.
>> > But I'm still curious about what's the use of these jars, and will the
>> > removal of them affects eagle service while the service is deployed
>> > somewhere?
>> >
>> > So could anyone tell some details of the jars and give some advice on
>> > "shall we also remove the jars in git repository"?
>> >
>> > To my understanding, if we just remove the jars from source-RCx, then the
>> > packaged tar ball will contain different files than the view we can see
>> in
>> > git repository, will this situation violate release policy? Please you
>> guys
>> > know well about it DO give instructions. It's highly appreciated!
>> >
>> > Michael
>> >
>>

Re: PLEASE HELP sign michael's gpg public key

[Julian Hyde]

These things are best done face-to-face.

Think about it: the purpose of a signed public key is so that I can be 
absolutely sure that it was you who signed the release. Not someone who gained 
temporary access to your email address.

Is there someone in your company who is in the web of trust? Are you going to a 
conference or meetup sometime soon?

Julian



> On Jul 7, 2016, at 9:22 PM, Michael Wu  wrote:
> 
> Hi dev group,
> 
> Could anyone that has certified gpg key help sign my gpg pub-key, please?
> 
> My public key is at: http://people.apache.org/keys/committer/mw.asc
> My apache email address is: m...@apache.org
> 
> Anything else has to be provided, please do let me know. Thanks!
> 
> Michael

Re: [VOTE] Release: Apache Eagle 0.4.0-incubating (Release Candidate 2)

[Julian Hyde]

+1 (binding)

* Downloaded & built successfully on JDK 1.7 OS X
* Checked license, notice, signatures
* Ran apache-rat:check, and it passed
* Checked that release matches tag at github

* I saw you added ‘brew install node’ to README.md - thanks!
* I saw that CHANGELOG.txt now contains previous releases — good idea
* I saw that you fixed the branding in CHANGELOG.txt - thanks!
* I noticed that you renamed the directory to apache-eagle-0.4.0-incubating — 
thanks!

Nice work.

Julian



> On Jul 5, 2016, at 11:04 PM, Michael Wu  wrote:
> 
> Hi all,
> 
> This is a release vote for Apache Eagle, version 0.4.0-incubating, release
> candidate 2.
> 
> Highlighted changes in this release are as the following:
>  * JBDC Metadata Storage Extension
>  * Topology management in remote mode including start/stop/status
> operations
>  * Auditlogparser for MapR's audit log
>  * Oozie auditlog integration for Oozie security monitoring
>  * Add applicaiton "maprFSAuditLog"
>  * Refactor bin/eagle-sandbox-starter.sh to make it easier to use
> 
> Thanks to everyone who has contributed to this release.
> 
> Here's the release note:
> https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/branch-0.4
> 
> The artifacts to be voted on are located at:
> https://dist.apache.org/repos/dist/dev/incubator/eagle/0.4.0-incubating-rc2/
> 
> The commit to be voted upon:
> *https://github.com/apache/incubator-eagle/commit/23d3ca604a37ccb89d7a95e5c75cfba651673b2a
> *
> 
> Release tag is:
> *https://github.com/apache/incubator-eagle/releases/tag/v0.4.0-incubating-rc2
> *
> 
> Release artifacts are signed with the following key:
> http://people.apache.org/keys/committer/mw.asc
> 
> The hashes of the artifacts are as follows:
> apache-eagle-0.4.0-incubating-src-rc2.tar.gz.md5:
> 0a78ed6c36ba57194f6721a8d6bae6f4
> apache-eagle-0.4.0-incubating-src-rc2.tar.gz.sha1:
> f59b3d7d894181eb2019bb55f4cf6079a47339eb
> 
> Please vote on releasing this package as: Apache Eagle 0.4.0-incubating.
> 
> The vote is open for the next 72 hours and passes if a majority of at least
> three +1 PPMC votes are cast.
> 
> [ ] +1 Release this Apache Eagle 0.4.0-incubating Release Candidate 2.
> 
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> 
> [ ] -1 Do not release this package because...
> 
> 
> Thanks.
> 
> Michael

Re: [VOTE] Release Apache Incubator Eagle Version 0.4.0 (Release Candidate 1)

[Julian Hyde]

“Apache" has to be present, and so does “incubating”, and your version number 
should not start with “v". As for the order of words, I did a search[1] for 
recent releases and there’s no clear standard:

* Apache Taverna Command-line 3.1.0-incubating
* Apache Trafodion (incubating) release 2.0.1-incubating
* Apache Slider 0.91.0-incubating
* Apache Atlas version 0.7-incubating

I think I’d go with “Apache Eagle x.y.z-incubating” as the release name. I’d 
refer to the project as “Apache Eagle (incubating)” on first mention and 
“Eagle” thereafter.

Julian

[1] 
https://lists.apache.org/list.html?gene...@incubator.apache.org:lte=1M:release

> On Jun 30, 2016, at 7:20 PM, Michael Wu <mchl@gmail.com> wrote:
> 
> @Julian,
> 
> Thanks for your valuable instructions. I have a chronic uncertainty on
> which text we should use: "Apache Incubator Eagle vX.Y.Z" or "Apache Eagle
> vX.Y.Z (incubator)", now looking at your suggestions, it seems we can use
> the latter (with "incubator" enclosed by brackets), am I correct?
> 
> Next, I'll change the dir name inside the tar, modify release note
> head-line, highlight the building requirement of npm in README.md, add
> LICENSE to asf_logo.svg, they could be done shortly. As to branding issues,
> it may take some time to detect and change all the clauses. I'll raise
> another VOTE for rc2 when they are all done.
> 
> Thank you.
> Michael
> 
> On Fri, Jul 1, 2016 at 6:21 AM, Julian Hyde <jh...@apache.org> wrote:
> 
>> Downloaded, built successfully using JDK 1.7 on OS X. Checked signatures,
>> license, notice.
>> 
>> The directory inside the tar file is called
>> apache-eagle-0.4.0-incubating-src-rc1. I would name it
>> apache-eagle-0.4.0-incubating-src, because when it is released it will be a
>> release, not a release candidate.
>> 
>> The first line of the release notes doesn’t meet branding guidelines:
>> "Release Notes - Eagle - Version v0.4.0” should be "Release Notes - Apache
>> Eagle 0.4.0 (integrating)”
>> 
>> The first build failed because npm was not installed. You should probably
>> mention that in README.md.
>> 
>> I ran apache-rat and got one failure: eagle-docs/images/asf_logo.svg.
>> 
>> -1 because of the branding issues. It would be nice if you fixed the other
>> issues this release, but it would be OK if you fixed them in the previous
>> release.
>> 
>> Julian
>> 
>> 
>> 
>> 
>> 
>>> On Jun 30, 2016, at 7:55 AM, Michael Wu <mchl@gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> This is a release vote for Apache Incubator Eagle, version 0.4.0, release
>>> candidate 1.
>>> 
>>> Highlighted changes in this release are as the following:
>>> * JBDC Metadata Storage Extension
>>> * Topology management in remote mode including start/stop/status
>>> operations
>>> * Auditlogparser for MapR's audit log
>>> * Oozie auditlog integration for Oozie security monitoring
>>> * Add applicaiton "maprFSAuditLog"
>>> * Refactor bin/eagle-sandbox-starter.sh to make it easier to use
>>> 
>>> Thanks to everyone who has contributed to this release.
>>> 
>>> Here's the release note:
>>> 
>> https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/branch-0.4
>>> 
>>> The artifacts to be voted on are located at:
>>> 
>> https://dist.apache.org/repos/dist/dev/incubator/eagle/v0.4.0-incubating-rc1/
>>> 
>>> The commit to be voted upon:
>>> 
>> https://github.com/apache/incubator-eagle/commit/73c8e023bd2c9d620c4938773fa147756f48ce0a
>>> 
>>> Release tag is:
>>> 
>> https://github.com/apache/incubator-eagle/releases/tag/v0.4.0-incubating-rc1
>>> 
>>> Release artifacts are signed with the following key:
>>> http://people.apache.org/keys/committer/mw.asc
>>> 
>>> The hashes of the artifacts are as follows:
>>> apache-eagle-0.4.0-incubating-src-rc1.tar.gz.md5:
>>> d22c91d7eb6a0c5a9067b2ae69f98bfe
>>> apache-eagle-0.4.0-incubating-src-rc1.tar.gz.sha1:
>>> 6c337c0d6239f40879eba2a4c535d2b737b44fea
>>> 
>>> Please vote on releasing this package as: Apache Incubator Eagle v0.4.0.
>>> 
>>> The vote is open for the next 72 hours and passes if a majority of at
>> least
>>> three +1 PPMC votes are cast.
>>> 
>>> [ ] +1 Release this Apache Eagle 0.4.0-incubating Release Candidate 1.
>>> 
>>> [ ]  0 I don't feel strongly about it, but I'm okay with the release
>>> 
>>> [ ] -1 Do not release this package because...
>>> 
>>> 
>>> Thanks.
>>> Michael Wu
>> 
>> 

Re: [VOTE] Release Apache Incubator Eagle Version 0.4.0 (Release Candidate 1)

[Julian Hyde]

Downloaded, built successfully using JDK 1.7 on OS X. Checked signatures, 
license, notice.

The directory inside the tar file is called 
apache-eagle-0.4.0-incubating-src-rc1. I would name it 
apache-eagle-0.4.0-incubating-src, because when it is released it will be a 
release, not a release candidate.

The first line of the release notes doesn’t meet branding guidelines: "Release 
Notes - Eagle - Version v0.4.0” should be "Release Notes - Apache Eagle 0.4.0 
(integrating)”

The first build failed because npm was not installed. You should probably 
mention that in README.md.

I ran apache-rat and got one failure: eagle-docs/images/asf_logo.svg.

-1 because of the branding issues. It would be nice if you fixed the other 
issues this release, but it would be OK if you fixed them in the previous 
release.

Julian





> On Jun 30, 2016, at 7:55 AM, Michael Wu  wrote:
> 
> Hi all,
> 
> This is a release vote for Apache Incubator Eagle, version 0.4.0, release
> candidate 1.
> 
> Highlighted changes in this release are as the following:
>  * JBDC Metadata Storage Extension
>  * Topology management in remote mode including start/stop/status
> operations
>  * Auditlogparser for MapR's audit log
>  * Oozie auditlog integration for Oozie security monitoring
>  * Add applicaiton "maprFSAuditLog"
>  * Refactor bin/eagle-sandbox-starter.sh to make it easier to use
> 
> Thanks to everyone who has contributed to this release.
> 
> Here's the release note:
> https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/branch-0.4
> 
> The artifacts to be voted on are located at:
> https://dist.apache.org/repos/dist/dev/incubator/eagle/v0.4.0-incubating-rc1/
> 
> The commit to be voted upon:
> https://github.com/apache/incubator-eagle/commit/73c8e023bd2c9d620c4938773fa147756f48ce0a
> 
> Release tag is:
> https://github.com/apache/incubator-eagle/releases/tag/v0.4.0-incubating-rc1
> 
> Release artifacts are signed with the following key:
> http://people.apache.org/keys/committer/mw.asc
> 
> The hashes of the artifacts are as follows:
> apache-eagle-0.4.0-incubating-src-rc1.tar.gz.md5:
> d22c91d7eb6a0c5a9067b2ae69f98bfe
> apache-eagle-0.4.0-incubating-src-rc1.tar.gz.sha1:
> 6c337c0d6239f40879eba2a4c535d2b737b44fea
> 
> Please vote on releasing this package as: Apache Incubator Eagle v0.4.0.
> 
> The vote is open for the next 72 hours and passes if a majority of at least
> three +1 PPMC votes are cast.
> 
> [ ] +1 Release this Apache Eagle 0.4.0-incubating Release Candidate 1.
> 
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> 
> [ ] -1 Do not release this package because...
> 
> 
> Thanks.
> Michael Wu

Re: Web site branding

[Julian Hyde]

Check what the branding guide says. I think only the first occurrence needs to 
be fully-qualified.

But also ask yourself: Does this page make it look like the project is 
controlled by a particular company?

> On Jun 29, 2016, at 1:57 PM, arunkarthick m <aruncarth...@gmail.com> wrote:
> 
> There are lots of places where we mentioned "Eagle". We need to change them
> to be Apache Eagle.
> 
> Thanks,
> Arun
> 
> On Wed, Jun 29, 2016 at 11:52 AM, arun karthick manoharan <
> aruncarth...@gmail.com> wrote:
> 
>> I'm looking at the branding guide will send what I find.
>> 
>> Thanks,
>> Arun
>> 
>> Sent from my iPhone
>> 
>>> On Jun 29, 2016, at 11:15 AM, Hao Chen <h...@apache.org> wrote:
>>> 
>>> Will continue to verify and update the fix.
>>> 
>>> - Hao
>>> 
>>>> On Wed, Jun 29, 2016 at 10:21 AM, Julian Hyde <jh...@apache.org> wrote:
>>>> 
>>>> Did you find any other violations of branding policy?
>>>> 
>>>>> On Jun 29, 2016, at 10:13 AM, Hao Chen <h...@apache.org> wrote:
>>>>> 
>>>>> Updated with (incubating), thanks for advising.
>>>>> 
>>>>> - Hao
>>>>> 
>>>>>> On Wed, Jun 29, 2016 at 9:48 AM, Julian Hyde <jh...@apache.org>
>> wrote:
>>>>>> 
>>>>>> There is a discussion on general@incubator about podlings’ web sites
>>>> and
>>>>>> URLs, and Eagle came in for some criticism. Can someone please review
>>>> the
>>>>>> site for compliance with Apache’s branding guidelines for podlings?
>>>>>> 
>>>>>> For instance, the first mention of Eagle on each page must be followed
>>>> by
>>>>>> “(incubating)”, and that does not happen. There may be other
>> violations
>>>>>> too. During incubation we are looking to see whether the PPMC is
>>>> capable of
>>>>>> proactively enforcing the Apache brand.
>>>>>> 
>>>>>> Julian
>>>> 
>>>> 
>> 
> 
> 
> 
> -- 
> Arun Karthick
> 201-850-9399

Re: Web site branding

[Julian Hyde]

Did you find any other violations of branding policy?

> On Jun 29, 2016, at 10:13 AM, Hao Chen <h...@apache.org> wrote:
> 
> Updated with (incubating), thanks for advising.
> 
> - Hao
> 
> On Wed, Jun 29, 2016 at 9:48 AM, Julian Hyde <jh...@apache.org> wrote:
> 
>> There is a discussion on general@incubator about podlings’ web sites and
>> URLs, and Eagle came in for some criticism. Can someone please review the
>> site for compliance with Apache’s branding guidelines for podlings?
>> 
>> For instance, the first mention of Eagle on each page must be followed by
>> “(incubating)”, and that does not happen. There may be other violations
>> too. During incubation we are looking to see whether the PPMC is capable of
>> proactively enforcing the Apache brand.
>> 
>> Julian
>> 
>> 

Web site branding

[Julian Hyde]

There is a discussion on general@incubator about podlings’ web sites and URLs, 
and Eagle came in for some criticism. Can someone please review the site for 
compliance with Apache’s branding guidelines for podlings?

For instance, the first mention of Eagle on each page must be followed by 
“(incubating)”, and that does not happen. There may be other violations too. 
During incubation we are looking to see whether the PPMC is capable of 
proactively enforcing the Apache brand.

Julian

Re: [ANNOUNCE] New Apache Eagle Committer: Michael Wu

[Julian Hyde]

Congratulations, Michael, and welcome! Thanks for all the work you
have done already in the Eagle community.

On Fri, Jun 17, 2016 at 7:56 AM, Hao Chen  wrote:
> Eagle Community,
>
> The Project Management Committee (PMC) for Apache Eagle has asked Michael
> (Ziyang) Wu  to become a committer and PPMC member, we are pleased to
> announce that he has accepted.
>
> Micheal have demonstrated a strong commitment to the Apache Eagle community
> through active participation in driving eagle community infrastructure set
> up (Wiki,Github and Jenkins CI, etc.) and quality engineering (Function and
> integration testing).
>
> He also authored many enhancements and bug fixes spanning both Eagle’s core
> code base, as well as a numerous integration components.
>
> We think Micheal's experience and passion will continuously contribute and
> guide eagle community to deliver high-quality features and releases as part
> of the Eagle Committer family.
>
> Michael,
>
> Welcome! Would you like have a brief self-introduction to the community?
>
> Yours,
> Hao on behalf of Apache Eagle PPMC

Re: [Announce] New Apache Eagle Committer: Daniel Zhou

[Julian Hyde]

Daniel,

Congratulations, thanks for all your contributions so far, and welcome!

Julian

> On Jun 13, 2016, at 9:33 AM, Daniel Zhou  wrote:
> 
> 
> Hi Eagle Community ,
> 
> Thank you all :).
> My name is Da Zhou. I'm a software engineer working at Dataguise, Inc, 
> focusing on detecting and protecting sensitive data in cloud service and big 
> data platforms.
> 
> It's my great honor to be a member of Apache Eagle Committer.  In fact it 
> already makes me thrilled when I start thinking about working in this vibrant 
> community and delivering cool features in the near future. XD
> 
> Let's fly and contribute more code together!
> 
> Thanks and regards,
> Daniel
> 
> 
> On Jun 12, 2016, at 10:13 PM, Hao Chen 
> > wrote:
> 
> Eagle Community,
> 
> The Project Management Committee (PPMC) for Apache Eagle has asked Daniel 
> Zhou to become a committer and we are pleased to announce that he has 
> accepted.
> 
> Daniel has continuously participated in discussion, bug reporting and fixing 
> in eagle community, and also actively made code contribution, especially like 
> independently implementing integration of Eagle with MapR, which made it 
> possible for eagle to monitor MapR hadoop cluster as well. We think he's 
> experience may also help the community to drive eagle to be more and more 
> powerful in big data security monitoring.
> 
> Daniel,
> 
> Welcome! Would you like have a brief self-introduction to the community?
> 
> Yours,
> Hao on behalf of Apache Eagle PPMC

Re: Podling Report Reminder - May 2016

[Julian Hyde]

Excellent — thanks!

> On May 11, 2016, at 11:59 AM, Dendukuri, Hemanth <hdenduk...@ebay.com> wrote:
> 
> Download link added http://goeagle.io/docs/download.html
> 
> 
> 
> 
> On 5/1/16, 8:32 AM, "Julian Hyde" <jh...@apache.org> wrote:
> 
>> Anyone volunteer to write the report this month? This should be a good one — 
>> you get to announce your first release!
>> 
>> (Having said that I couldn’t find a downloads link on the web site. Only a 
>> very old link on https://eagle.incubator.apache.org/docs/quick-start.html 
>> <https://eagle.incubator.apache.org/docs/quick-start.html>. Can someone fix 
>> that?)
>> 
>> Julian
>> 
>>> On May 1, 2016, at 6:10 AM, johndam...@apache.org wrote:
>>> 
>>> Dear podling,
>>> 
>>> This email was sent by an automated system on behalf of the Apache
>>> Incubator PMC. It is an initial reminder to give you plenty of time to
>>> prepare your quarterly board report.
>>> 
>>> The board meeting is scheduled for Wed, 18 May 2016, 10:30 am PDT.
>>> The report for your podling will form a part of the Incubator PMC
>>> report. The Incubator PMC requires your report to be submitted 2 weeks
>>> before the board meeting, to allow sufficient time for review and
>>> submission (Wed, May 4th).
>>> 
>>> Please submit your report with sufficient time to allow the Incubator
>>> PMC, and subsequently board members to review and digest. Again, the
>>> very latest you should submit your report is 2 weeks prior to the board
>>> meeting.
>>> 
>>> Thanks,
>>> 
>>> The Apache Incubator PMC
>>> 
>>> Submitting your Report
>>> 
>>> --
>>> 
>>> Your report should contain the following:
>>> 
>>> *   Your project name
>>> *   A brief description of your project, which assumes no knowledge of
>>>   the project or necessarily of its field
>>> *   A list of the three most important issues to address in the move
>>>   towards graduation.
>>> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>>>   aware of
>>> *   How has the community developed since the last report
>>> *   How has the project developed since the last report.
>>> 
>>> This should be appended to the Incubator Wiki page at:
>>> 
>>> http://wiki.apache.org/incubator/May2016
>>> 
>>> Note: This is manually populated. You may need to wait a little before
>>> this page is created from a template.
>>> 
>>> Mentors
>>> ---
>>> 
>>> Mentors should review reports for their project(s) and sign them off on
>>> the Incubator wiki page. Signing off reports shows that you are
>>> following the project - projects that are not signed may raise alarms
>>> for the Incubator PMC.
>>> 
>>> Incubator PMC
>> 

Re: Branch name and tag names are confusing

[Julian Hyde]

It is certainly useful to have a convention. I tend to use the one supplied by 
maven, which would be “eagle-0.3.0-incubating” (since the project is “eagle” 
and the version is “0.3.0-incubating”.

In Calcite we are now making releases of two different projects (calcite and 
avatica) from the same git repo, so I’m glad we used “{project}-{version}” 
rather than “v{version}”.

In addition to making a tag for each release, we also post the commit SHA[1], 
to make it absolutely clear what source code when into the release.

At some point you might need maintenance branches, e.g. a branch from which 
several releases, say 0.3.0-incubating, 0.3.1-incubating, 0.3.2-incubating are 
subsequently made. I’m not sure what such branches should be called.

Julian

[1] http://calcite.apache.org/downloads/#source-releases 

> On Apr 10, 2016, at 9:00 AM, Hao Chen  wrote:
> 
> I found the branch names and tag names are confusing for user.
> 
> *https://github.com/apache/incubator-eagle/releases
> *
> 
> 
> *release-0.3.0-rc3*
> 
> *eagle-0.3.0-incubating*
> *release-0.3.0*
> 
> We should have single tag for each release in format "*v${VERSION}*"
> 
> And also the branch names:
> 
> *branch-0.3.0-rc1*
> *branch-0.3.0*
> 
> We should have single branch for each release in format "
> *release-${VERSION}*"
> 
> Otherwise the community maybe not know which code is actually released for
> certain version.
> 
> I think it's not very good to create a individual branch or release tag for
> RC. We should make sure the name clear for community and users.
> 
> How do you think?
> 
> - Hao

Re: Question Regarding the folder/file name.

[Julian Hyde]

Don’t include the release candidate suffix (“-rc3”) in the name of the released 
artifact. Do include ‘-incubating’.

Kylin’s artifacts are good examples to follow: 
https://dist.apache.org/repos/dist/release/kylin/

By the way, I saw that in git you have tag without the ‘-rc3’, namely 
‘release-0.3.0’ tag. This is good. Better would be to have a tag with the same 
name as the release, namely ‘eagle-0.3.0-incubating’. This is what Kylin does.

It’s up to you whether you keep the ‘release-0.3.0-rc3’ tag. I’d be inclined to 
delete it now the release is out. The hash is already on record in the release 
vote.

Julian


> On Apr 8, 2016, at 1:47 PM, Dendukuri, Hemanth  wrote:
> 
> Julian, Please provide your input.  
> 
> 
> 
> 
> On 4/8/16, 12:15 PM, "Zhang, Edward (GDI Hadoop)"  wrote:
> 
>> looks 0.3.0-incubating naming is more informational, like kylin
>> https://dist.apache.org/repos/dist/release/kylin/
>> 
>> On 4/6/16, 2:49, "Dendukuri, Hemanth"  wrote:
>> 
>>> Hi,
>>> 
>>> I want to upload voted "eagle release candidate 3" artifacts to apache
>>> release distribution
>>> https://dist.apache.org/repos/dist/release/incubator/eagle/
>>> 
>>> Should the name of folder/files contain ³rc3² suffix  or can I rename it
>>> to just "0.3.0-incubating² and have voted rc3 artifacts in it.
>>> 
>>> Regards
>>> Hemanth
>> 

Re: apache eagle roadmap seek help

[Julian Hyde]

From a product perspective I agree with Seshu. Create a best- of-breed product 
focused on one task. 

But from a community perspective I say have at it! Communities grow when they 
discover new use cases outside the original scope. 

Clearly there need to be new resources working on the increased scope (not just 
spreading the original resources more thinly). And it presents a product design 
challenge. You might need to create a new tool (or a new UI) to keep things 
simple for the user. 

Julian

> On Apr 6, 2016, at 05:59, Adunuthula, Seshu  wrote:
> 
> Hao,
> 
> Monitoring has many different facets to it, My recommendation is to not 
> expand the scope of Eagle beyond security monitoring. We have barely 
> scratched the surface with respect to Security Monitoring, expanding the 
> scope to General Health Monitoring would dilute the value proposition of 
> Eagle.
> 
> Regards
> Seshu Adunuthula
> 
> 
> From: Hao Chen >
> Reply-To: 
> "dev@eagle.incubator.apache.org" 
> >
> Date: Wednesday, April 6, 2016 at 1:35 AM
> To: 經年錯ミ莫失莫忘 <378032...@qq.com>, 
> "dev@eagle.incubator.apache.org" 
> >, 
> "u...@eagle.incubator.apache.org" 
> >
> Subject: Re: apache eagle roadmap seek help
> 
> Hi,
> 
> Thanks very much for being interested in Eagle.
> 
> In fact part features of hadoop system metric monitoring has been published 
> into 
> https://github.com/apache/incubator-eagle/tree/master/eagle-hadoop-metric, 
> while the spark application performance monitoring is still under development.
> 
> So could you please just have a try about the system monitoring firstly? And 
> pls. let us know if any problems, i think the community will actively support 
> you. :-)
> 
> @Community,  also I think the documentation for this part has not been well 
> documented yet. Could any contributor volunteer to contribute? 
> https://github.com/apache/incubator-eagle/tree/document/
> 
> - Hao
> 
> On Wed, Apr 6, 2016 at 11:55 AM, 經年錯ミ莫失莫忘 
> <378032...@qq.com> wrote:
> Hi chen:
> I'm very interested in eagle feature if System Monitoring. And I see a 
> roadmap follow this:
> 
> [cid:3200F60B@6CF64419.A6880457]
> 
> So, i want to know when is it could sopport?
> 
> 
> 
> 

Re: Release votes

[Julian Hyde]

It’s customary to post both the vote proposal (i.e. the mail message that 
started the vote, from which it is easy to find all of the votes, since they 
are in the same thread) and the result.

You could make https://s.apache.org/eagle-0.3.0-vote as a link to 
http://mail-archives.apache.org/mod_mbox/incubator-eagle-dev/201603.mbox/%3cf4699940-ffba-4868-8ae9-eb1f90daa...@ebay.com%3E
 
<http://mail-archives.apache.org/mod_mbox/incubator-eagle-dev/201603.mbox/%3cf4699940-ffba-4868-8ae9-eb1f90daa...@ebay.com%3E>.

Julian




> On Mar 28, 2016, at 3:53 PM, Dendukuri, Hemanth <hdenduk...@ebay.com> wrote:
> 
> Julian. 
> 
> The link "https://s.apache.org/eagle-0.3.0-result 
> <https://s.apache.org/eagle-0.3.0-result>" does not list the entire thread of 
> Votes. 
> I assume that the link should provide the proof(Thread) listing all 
> votes. Is there anyway to show this ?   
> 
> Regards
> Hemanth 
> 
> 
> 
> 
> On 3/28/16, 12:18 PM, "Julian Hyde" <jh...@apache.org 
> <mailto:jh...@apache.org>> wrote:
> 
>> (Changed subject; was: "Re: [RESULT][VOTE] Release Eagle Incubating Version 
>> 0.3.0(RC3)”.)
>> 
>> Remember, the vote period is a *minimum* of 72 hours to give everyone ample 
>> time to review. It doesn’t matter if you receive 3 +1 votes within 10 
>> minutes of the vote starting. You still need to keep it open 72 hours to 
>> give people chance to vote against the release.
>> 
>> If you haven’t received 3 +1 votes after 72 hours, you can keep it open 
>> longer if you like.
>> 
>> Many projects make the period longer if the vote occurs over a weekend and 
>> especially if it is over a long weekend. (This weekend was Easter, and a 3 
>> or 4 day weekend in many countries, so this particular vote may have had 
>> very little overlap with people’s working hours.)
>> 
>> Having said that, voters should do their best to vote early. It helps the 
>> project iterate more quickly. It a negative vote is received early, the 
>> release manager might be able to cancel the vote and start a vote on a new 
>> release candidate in one working day.
>> 
>> Also, I recommend you use Apache URLs for vote threads and results. Other 
>> archives are outside Apache’s control so are not guaranteed immutable. If 
>> you like, you can use the Apache shortener, http://s.apache.org, to convert 
>> to a more manageable URL:
>> 
>> For example,
>> 
>> http://mail-archives.apache.org/mod_mbox/incubator-eagle-dev/201603.mbox/%3C46F16004-755D-4659-89C7-365CC4A15459%40ebay.com%3E
>>  
>> <http://mail-archives.apache.org/mod_mbox/incubator-eagle-dev/201603.mbox/%3C46F16004-755D-4659-89C7-365CC4A15459%40ebay.com%3E>
>>  
>> <http://mail-archives.apache.org/mod_mbox/incubator-eagle-dev/201603.mbox/%3c46f16004-755d-4659-89c7-365cc4a15...@ebay.com%3E
>>  
>> <http://mail-archives.apache.org/mod_mbox/incubator-eagle-dev/201603.mbox/%3c46f16004-755d-4659-89c7-365cc4a15...@ebay.com%3E>>
>> 
>> is shortened to
>> 
>> https://s.apache.org/eagle-0.3.0-result 
>> 
>> Julian
>> 
>> 
>>> On Mar 28, 2016, at 8:16 AM, Dendukuri, Hemanth <hdenduk...@ebay.com> wrote:
>>> 
>>> Sure my bad, will consider and resend.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 3/26/16, 7:26 PM, "Julian Hyde" <jh...@apache.org> wrote:
>>> 
>>>> I thought you said it would be open 72 hours. By my reckoning we have 
>>>> about another 12 hours. I think we should accept any votes received in the 
>>>> next few hours, provided they are in the period.
>>>> 
>>>>> On Mar 26, 2016, at 10:59 AM, Dendukuri, Hemanth <hdenduk...@ebay.com> 
>>>>> wrote:
>>>>> 
>>>>> The voting for "Apache Eagle, 0.3.0 Release Candidate 3" passed with 3 
>>>>> binding +1 votes from the Incubator PMC members and One +1 VOTE from 
>>>>> apache contributor. There are no 0 or -1 votes.
>>>>> 
>>>>> Votes:
>>>>> +1 Julian Hyde(binding)
>>>>> +1 amareshwarisr(binding)
>>>>> +1 Hao Chen(binding)
>>>>> 
>>>>> +1 (Liangfei.Su)
>>>>> 
>>>>> 
>>>>> Thread: 
>>>>> https://www.mail-archive.com/dev@eagle.incubator.apache.org/msg02766.html
>>>>> 
>>>>> 
>>>>> Thanks to all who reviewed and voted.
>>>>> I will proceed for Voting on General Incubation.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Hemanth

Re: [RESULT][VOTE] Release Eagle Incubating Version 0.3.0(RC3)

[Julian Hyde]

I thought you said it would be open 72 hours. By my reckoning we have about 
another 12 hours. I think we should accept any votes received in the next few 
hours, provided they are in the period.

> On Mar 26, 2016, at 10:59 AM, Dendukuri, Hemanth <hdenduk...@ebay.com> wrote:
> 
> The voting for "Apache Eagle, 0.3.0 Release Candidate 3" passed with 3 
> binding +1 votes from the Incubator PMC members and One +1 VOTE from apache 
> contributor. There are no 0 or -1 votes.
> 
> Votes:
> +1 Julian Hyde(binding)
> +1 amareshwarisr(binding)
> +1 Hao Chen(binding)
> 
> +1 (Liangfei.Su)
> 
> 
> Thread: 
> https://www.mail-archive.com/dev@eagle.incubator.apache.org/msg02766.html
> 
> 
> Thanks to all who reviewed and voted.
> I will proceed for Voting on General Incubation.
> 
> 
> Regards,
> Hemanth

Re: [VOTE] Release Eagle Incubating Version 0.3.0(RC3)

[Julian Hyde]

I saw you have implemented the suggestions from previous RCs — thank you!

Downloaded & built on JDK 1.7 Mac OS X. LICENSE, NOTICE, README files present 
and correct. No binaries.

Ran apache-rat; there were 4 RAT failures in eagle-webservice but they were for 
files that did not need headers.

+1 (binding)

Julian


> On Mar 25, 2016, at 6:07 PM, Liangfei.Su  wrote:
> 
> +1, check sum verified.
> mvn clean install runs ok
> mvn apache-rat:check looks good
> 
> 
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ md5sum
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
> a211a151d7f66c2516c5e41da1345128
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ cat
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz.md5
> a211a151d7f66c2516c5e41da1345128
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ sha
> sha1sum   sha224sum sha256sum sha384sum sha512sum
> shadowconfig  shasum
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ sha1sum
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
> da7b4e60228cf1421dde4342c957aff16de81cbd
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ cat
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz.sha1
> da7b4e60228cf1421dde4342c957aff16de81cbd
> 
> 
> 
> 
> 
> 
> On Thu, Mar 24, 2016 at 11:47 PM, Amareshwari Sriramdasu <
> amareshw...@apache.org> wrote:
> 
>> +1 (Binding)
>> 
>> + Verified signature
>> + Verified checksum
>> + Rat check (mvn apache-rat:check) is fine. Had to add the following to
>> pom.xml. Would be good to have in pom itself.
>> ---
>> 
>> 
>> 
>>  **/*.json
>> 
>>  **/*.patch
>> 
>>  **/README.md
>> 
>>  **/*.txt
>> 
>>  **/*.log
>> 
>>  **/kafka-python/**
>> 
>>  **/six/**
>> 
>>  **/securityAuditLog
>> 
>>  **/MANIFEST.MF
>> 
>> 
>> 
>> 
>> + License and NOTICE looks good.
>> + DISCLAIMER exists
>> + mvn clean package -DskipTests passes
>> - Unit test fail for me.
>> 
>> 
>> 
>> Failed tests:
>> 
>>  testRound2(org.apache.eagle.common.TestDateTimeUtil)
>> 
>> ---
>> 
>> Thanks
>> 
>> Amareshwari
>> 
>> On Fri, Mar 25, 2016 at 11:00 AM, Hao Chen  wrote:
>> 
>>> *+1 (Binding)*
>>> 
>>> *md5, shasum, gpg, mvn clean install passed.*
>>> 
>>> $md5 apache-eagle-0.3.0-incubating-src-rc3.tar.gz
>>> MD5 (apache-eagle-0.3.0-incubating-src-rc3.tar.gz) =
>>> a211a151d7f66c2516c5e41da1345128
>>> 
>>> $ shasum apache-eagle-0.3.0-incubating-src-rc3.tar.gz
>>> da7b4e60228cf1421dde4342c957aff16de81cbd
>>> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
>>> 
>>> $ gpg --verify apache-eagle-0.3.0-incubating-src-rc3.tar.gz.asc.txt
>>> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
>>> gpg: Signature made Tue Mar 22 07:33:30 2016 CST using RSA key ID
>> BB7D5724
>>> gpg: Good signature from "Hemanth Dendukuri (CODE SIGNING KEY) <
>>> hdenduk...@apache.org>"
>>> 
>>> $ mvn clean install
>>> ...
>>> [INFO]
>>> 
>>> [INFO] BUILD SUCCESS
>>> [INFO]
>>> 
>>> [INFO] Total time: 6:57.329s
>>> [INFO] Finished at: Fri Mar 25 13:28:59 CST 2016
>>> [INFO] Final Memory: 376M/1948M
>>> [INFO]
>>> 
>>> 
>>> - Hao
>>> 
>>> On Fri, Mar 25, 2016 at 1:29 AM, Dendukuri, Hemanth >> 
>>> wrote:
>>> 
 Hi all,
 
 
   This is the incubator release of Apache Eagle, 0.3.0 Release
 Candidate 3.
 
   We fixed all comments.
 
   Thanks to everyone who has contributed to this release.
 
   Here’s release notes:
 
>>> 
>> https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/branch-0.3.0
 
   The artifacts to be voted on are located here:
 
>>> 
>> https://dist.apache.org/repos/dist/dev/incubator/eagle/0.3.0-incubating-rc3/
 
The commit to be voted upon:
 
>>> 
>> https://github.com/apache/incubator-eagle/commit/b1d0a87ac0df1cc881427faafc637c152c180872
 
Release Tag  :
 
>> https://github.com/apache/incubator-eagle/releases/tag/release-0.3.0-rc3
 
   Release artifacts are signed with the following key:
 https://people.apache.org/keys/committer/hdendukuri.asc
 
 
 
 
The hashes of the artifacts are as follows:
 
   apache-eagle-0.3.0-incubating-src-rc3.tar.gz.md5
 a211a151d7f66c2516c5e41da1345128
 
apache-eagle-0.3.0-incubating-src-rc3.tar.gz.sha1
 da7b4e60228cf1421dde4342c957aff16de81cbd
 
 
 
   The vote is open for the next 72 hours and passes if a majority
>> of
 at least three +1 PPMC votes are cast.
 
[ ] +1 Release this Eagle 0.3.0 Incubator Release Candidate 3.
 
[ ]  0 I don't feel strongly about it, but I'm okay with the
 release
 
[ ] -1 Do not release 

Re: [VOTE] Release Eagle Incubating Version 0.3.0

[Julian Hyde]

Medha,

Your ‘+1’ is ambiguous. I suspect that your ‘+1’ meant you agreed with Langfei 
about modifying READ.me. But this is a vote thread, so your ‘+1’ could be 
interpreted to mean that you approve of the release.

Eagle devs, 

Vote threads are for voting only. If you need to have wider discussion, please 
start a new thread, or log a JIRA case, and discuss there.

Hemanth,

The vote thread has been open for a while, and with amareshwarisr’s -1 I think 
it’s clear that the vote will not pass. Can you close the thread by sending an 
email with the subject “[RESULT] [VOTE] Release Eagle Incubating Version 
0.3.0”. Also remember to include the release candidate number in the subject 
when you start the next vote.

Julian


> On Mar 21, 2016, at 11:22 AM, Medha Samant  wrote:
> 
> +1
> 
> -Medha
> 
> 
> On Wed, Mar 16, 2016 at 10:43 PM, Liangfei.Su  wrote:
> 
>> Should we doc this in READ.me. And more on the MAVEN_OTPS, i'm able to
>> build with
>> 
>> export MAVEN_OPTS="-Xmx2048m -XX:MaxPermSize=256m"; mvn clean install
>> 
>> 
>> 1024m doesnt work.
>> 
>> On Wed, Mar 16, 2016 at 12:13 PM, Hemanth Dendukuri 
>> wrote:
>> 
>>> I had similar test failure issues before, it got resolved by increasing
>>> Java Heap space under Maven.
>>> 
>>> export MAVEN_OPTS="-Xmx3012m -XX:MaxPermSize=3012m"
>>> Please try and let us know.
>>> 
>>> 
>>> On Wed, Mar 16, 2016 at 11:32 AM, Liangfei.Su 
>>> wrote:
>>> 
 Julian already have statement on test. Just one note that unit test
>> runs
>>> ok
 for me too.
 
 On Wed, Mar 16, 2016 at 2:52 AM, Hao Chen  wrote:
 
> Amareshwari,
> 
> 1) As to LICENSE, do you think my modification is ok here:
> 
>>> https://github.com/haoch/incubator-eagle/blob/fix-release-v0.3.0/LICENSE
 ?
> 
> 2) As to missing source headers problems about some files like
> json/MANIFEST.MF
> which don't support comments for license header, how should we handle
 with
> these kinds of sources?
> 
> 3) The test passed by my side.
> 
> Regards,
> Hao
> 
> On Wed, Mar 16, 2016 at 4:36 PM, amareshwarisr . <
>>> amareshw...@gmail.com>
> wrote:
> 
>> -1 (Binding)
>> 
>> + Signature looks good
>> + Checksums look fine, except .sha file.
>> + No binary files found
>> - LICENSE and NOTICE look OK. Have some comments as put below.
>> - Rat-check (mvn apache-rat:check) fails.  Not all files have
>> source
>> headers. See http://www.apache.org/legal/src-headers.html. Details
> below.
>> - Please make all dependencies you are pulling are Apache
>> compatible
>>> as
> per
>> http://apache.org/legal/
>> - Unit tests failed, details below
>> + mvn clean package -DskipTests passed.
>> 
>> -
>> Licensing comments :
>> -> kafka-python is under Apache License, so need not be mentioned
>> in
 top
>> level License.
>> -> >> This product bundles AdminLTE
>> What are these files? I dont see any files source with headers
 This product bundles "Google Fonts: Source Sans Pro"
>> What are these files? I dont see any files source with headers
>> 
>> Are they coming with apache headers by any chance?
>> -> For other licenses just giving weblink from top level license is
>>> not
>> enough. Full license need to be copied See
>> 
>> 
> 
 
>>> 
>> http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
>> and the example at
>> https://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE
>> 
>> -
>> 
>> Missing source headers:
>> 
>> 
>> 
>> 
> 
 
>>> 
>> incubator-eagle-release-0.3.0/eagle-webservice/src/main/webapp/app/partials/config/application.html
>> 
>> 
>> 
> 
 
>>> 
>> incubator-eagle-release-0.3.0/eagle-webservice/src/main/webapp/app/partials/config/feature.html
>> 
>> 
>> 
>> 
> 
 
>>> 
>> incubator-eagle-release-0.3.0/eagle-webservice/src/main/webapp/app/partials/config/site.html
>> 
>> 
>> 
> 
 
>>> 
>> incubator-eagle-release-0.3.0/eagle-webservice/src/main/webapp/app/partials/landing.html
>> 
>> 
>> 
> 
 
>>> 
>> incubator-eagle-release-0.3.0/eagle-webservice/src/main/webapp/app/public/feature/common/page/dataSrcConfig.html
>> 
>> 
> 
>>> incubator-eagle-release-0.3.0/eagle-webservice/src/main/webapp/grunt.json
>> 
>> 
>> 
>> 
> 
 
>>> 
>> incubator-eagle-release-0.3.0/eagle-webservice/src/main/webapp/META-INF/MANIFEST.MF
>> 
>> 
>> 
> 
 
>>> 
>> incubator-eagle-release-0.3.0/eagle-webservice/src/main/webapp/package.json
>> 
>> 
>> 
>> 
> 
 
>>> 
>> incubator-eagle-release-0.3.0/eagle-webservice/WebContent/META-INF/MANIFEST.MF
>> 
>> 
>> 
> 
 

Re: [VOTE] Release Eagle Incubating Version 0.3.0

[Julian Hyde]

> On Mar 16, 2016, at 1:36 AM, amareshwarisr .  wrote:
> 
> - Unit tests failed, details below

I’ll state, for the record, that it’s OK make a release with unit tests that 
fail. You just have to decide, as a community, that all unit tests passing is 
not a goal of the release. README.md says “ mvn -DskipTests clean package”, so 
I didn’t bother to run tests. Obviously it would be better if unit tests 
succeeded. But at this point, I wouldn’t let failing tests derail a release.

> - Rat-check (mvn apache-rat:check) fails.  Not all files have source
> headers. See http://www.apache.org/legal/src-headers.html. Details below.

None of the files that are missing source headers concern me. (For example, it 
is not possible to add source headers to .json files, because the JSON standard 
does not allow comments.) They could be fixed in the next release by adding 
rat-exclusions.

I have not looked into amareshwarisr’s concerns about LICENSE.

Julian

Re: [VOTE] Release Eagle Incubating Version 0.3.0

[Julian Hyde]

Downloaded, checked hashes, KEYS, built using JDK 1.7 on Ubuntu Linux,
checked README, LICENSE, NOTICE, DISCLAIMER, file headers, checked
dependent licenses using "mvn rat:rat".

+1 binding

But see comments/questions inline; maybe you can answer them in a
separate thread after the vote completes.

On Tue, Mar 15, 2016 at 9:25 PM, amareshwarisr .  wrote:
> MD5, SHA1 and SHA512 matches. I think we should not keep other .sha file.

Next release, I think you only need the .sha1 file; omit the .sha and
.sha512 files.

> Also, I'm not sure if you can add and drop files from directory once the
> vote is called out.

In future, do not alter the contents of the release candidate being
voted on. If there are serious issues you will need to cancel the vote
and make a new release candidate; if the issues are not serious you
should make sure to fix them in your next release. Either way, each
release candidate is immutable.

In this case, the sha of the file matched the sha in the vote thread,
so everything is fine.

This is the second release candidate, but the email has the same
subject as the first RC. Next time, I suggest that you include the RC
number in the email subject line and the directory name e.g.
https://dist.apache.org/repos/dist/dev/incubator/eagle/0.3.0-incubating-rc2/
so that it is clear what is being voted on.

Also, I don't think I saw a "[CANCEL] [VOTE] Release Eagle Incubating
Version 0.3.0" or "[RESULT] [VOTE] Release Eagle Incubating Version
0.3.0" message. Remember to terminate each vote thread.

Can you tell where
eagle-external/eagle-ambari/lib/EAGLE/package/patches/app.js comes
from? Although it is a text file, it is 1.7M lines long so I doubt
that you can call it "source code". Was it generated? Was it copied
from another project?

Julian

Re: [DISCUSS] Adding new mailing list to contain JIRA and Github updates

[Julian Hyde]

+1 on keeping the volume on the list manageable. A project with a high volume 
list is difficult to contribute to if that project is not your main job, and we 
want to encourage a diversity of contributors.  

A variation on what Henry is suggesting is to have jira send a message to the 
dev list only when a jira case is created. Subsequent updates go only to the 
issues list. But the initial email allows anyone interested to press "watch" on 
a case and receive all further updates for that case.  

Julian

> On Mar 10, 2016, at 10:42 PM, Henry Saputra  wrote:
> 
> Hi All,
> 
> With Apache Eagle podling getting more active every day, it seemed like
> JIRA updates and Github mirror updates start to become clutter to the dev
> list.
> 
> I think it is time to introduce new list, typically called issues@ as the
> reservoir for the updates.
> 
> We will still need to make JIRA create event to be delivered to dev@ for
> bookeeping but updates could be redirected to issues@
> 
> This is one of the "good" problems to have =)
> 
> Let me know what you guys think.
> 
> Thanks,
> 
> Henry

Re: Cannot svn commit the release for eagle.

[Julian Hyde]

Sorry, my previous message sounded snippy. I meant to say: concentrate
on the source release, and don't worry about binaries. If it is a good
release, your users will be able to build it easily enough. After all,
they are by definition early adopters at this point.

On Fri, Mar 4, 2016 at 11:41 AM, Julian Hyde <jh...@apache.org> wrote:
> My suggestion is to listen to Owen's suggestion. Make your first
> release source only. The most complicated part of the release process
> is IP vetting and binary releases are much harder to vet.
>
> On Fri, Mar 4, 2016 at 10:06 AM, Edward Zhang <yonzhang2...@apache.org> wrote:
>> This sounds a good suggestion. We can host binary into Eagle site. Any more
>> suggestions?
>>
>> Thanks
>> Edward
>>
>> On Fri, Mar 4, 2016 at 9:58 AM, Owen O'Malley <omal...@apache.org> wrote:
>>
>>> I would encourage you to make a source only release artifact, which
>>> hopefully stays less than 100mb.
>>>
>>> Convenience binaries can be hosted elsewhere based on the source release
>>> artifact.
>>>
>>> .. Owen
>>>
>>> On Thu, Mar 3, 2016 at 7:23 PM, Zhang, Edward (GDI Hadoop) <
>>> yonzh...@ebay.com> wrote:
>>>
>>> > We can skip Hadoop/storm related dependency but need test how to run
>>> > within sandbox.
>>> >
>>> > Thanks
>>> > Edward
>>> >
>>> > On 3/3/16, 19:12, "Dendukuri, Hemanth" <hdenduk...@ebay.com> wrote:
>>> >
>>> > >I got this comment for infrastructure bug.
>>> > >
>>> > >That's your problem: we have upload limits in place that defaults to
>>> > >200MB.
>>> > >
>>> > >
>>> > >
>>> > >On 3/3/16, 4:56 PM, "Dendukuri, Hemanth" <hdenduk...@ebay.com> wrote:
>>> > >
>>> > >>Hi All,
>>> > >>
>>> > >>I am not abel to commit eagle release artifact to
>>> > >>https://dist.apache.org/repos/dist/dev/incubator/eagle/
>>> > >>
>>> > >>The artifact I am trying to commit is 363 MB in size.
>>> > >>
>>> > >>Error message :
>>> > >>svn commit apache-eagle-0.3.0-incubating-bin.tar.gz -m "Eagle
>>> Incubating
>>> > >>Release 0.3.0 main Artifact"
>>> > >>Adding (bin) apache-eagle-0.3.0-incubating-bin.tar.gz
>>> > >>Transmitting file data .svn: E175002: Commit failed (details follow):
>>> > >>svn: E175002: PUT request on
>>> >
>>> >>'/repos/dist/!svn/txr/12608-atn/dev/incubator/eagle/0.3.0-incubating/apac
>>> > >>he-eagle-0.3.0-incubating-bin.tar.gz' failed
>>> > >>
>>> > >>Note : I am able to upload other files.
>>> > >>
>>> > >>I filed a infrastructure ticket for this issue
>>> > >>https://issues.apache.org/jira/browse/INFRA-11372 . Please let us know
>>> > >>you thoughts on this issue.
>>> > >>
>>> > >>Regards
>>> > >>Hemanth
>>> >
>>> >
>>>

Re: Cannot svn commit the release for eagle.

[Julian Hyde]

My suggestion is to listen to Owen's suggestion. Make your first
release source only. The most complicated part of the release process
is IP vetting and binary releases are much harder to vet.

On Fri, Mar 4, 2016 at 10:06 AM, Edward Zhang  wrote:
> This sounds a good suggestion. We can host binary into Eagle site. Any more
> suggestions?
>
> Thanks
> Edward
>
> On Fri, Mar 4, 2016 at 9:58 AM, Owen O'Malley  wrote:
>
>> I would encourage you to make a source only release artifact, which
>> hopefully stays less than 100mb.
>>
>> Convenience binaries can be hosted elsewhere based on the source release
>> artifact.
>>
>> .. Owen
>>
>> On Thu, Mar 3, 2016 at 7:23 PM, Zhang, Edward (GDI Hadoop) <
>> yonzh...@ebay.com> wrote:
>>
>> > We can skip Hadoop/storm related dependency but need test how to run
>> > within sandbox.
>> >
>> > Thanks
>> > Edward
>> >
>> > On 3/3/16, 19:12, "Dendukuri, Hemanth"  wrote:
>> >
>> > >I got this comment for infrastructure bug.
>> > >
>> > >That's your problem: we have upload limits in place that defaults to
>> > >200MB.
>> > >
>> > >
>> > >
>> > >On 3/3/16, 4:56 PM, "Dendukuri, Hemanth"  wrote:
>> > >
>> > >>Hi All,
>> > >>
>> > >>I am not abel to commit eagle release artifact to
>> > >>https://dist.apache.org/repos/dist/dev/incubator/eagle/
>> > >>
>> > >>The artifact I am trying to commit is 363 MB in size.
>> > >>
>> > >>Error message :
>> > >>svn commit apache-eagle-0.3.0-incubating-bin.tar.gz -m "Eagle
>> Incubating
>> > >>Release 0.3.0 main Artifact"
>> > >>Adding (bin) apache-eagle-0.3.0-incubating-bin.tar.gz
>> > >>Transmitting file data .svn: E175002: Commit failed (details follow):
>> > >>svn: E175002: PUT request on
>> >
>> >>'/repos/dist/!svn/txr/12608-atn/dev/incubator/eagle/0.3.0-incubating/apac
>> > >>he-eagle-0.3.0-incubating-bin.tar.gz' failed
>> > >>
>> > >>Note : I am able to upload other files.
>> > >>
>> > >>I filed a infrastructure ticket for this issue
>> > >>https://issues.apache.org/jira/browse/INFRA-11372 . Please let us know
>> > >>you thoughts on this issue.
>> > >>
>> > >>Regards
>> > >>Hemanth
>> >
>> >
>>

Re: February 2016 Report

[Julian Hyde]

Looks good — I signed off a couple of days ago.

> On Feb 3, 2016, at 5:00 PM, arun karthick manoharan <aruncarth...@gmail.com> 
> wrote:
> 
> Hi Julian,
> 
> Can you please take look at the report?
> 
> Thanks
> Arun
> 
> Sent from my iPhone
> 
>> On Feb 1, 2016, at 4:02 PM, Julian Hyde <jh...@apache.org> wrote:
>> 
>> Note that I didn’t say “Make a release”; I said “Put ‘Make a release’ on the 
>> list of priorities in the report”. There’s definitely time for that. :)
>> 
>> 
>>> On Jan 31, 2016, at 8:50 PM, Luke Han <luke...@gmail.com> wrote:
>>> 
>>> I think it's too short to have a release this time, the report should
>>> be submitted before Wed, February 3rd.
>>> 
>>> Please do not miss it:)
>>> 
>>> Thanks.
>>> 
>>> 
>>> Best Regards!
>>> -
>>> 
>>> Luke Han
>>> 
>>> On Mon, Feb 1, 2016 at 12:33 AM, Edward Zhang <yonzhang2...@gmail.com>
>>> wrote:
>>> 
>>>> Sure, we will go through release process soon. I or Hao will be release
>>>> manager this time.
>>>> 
>>>> Thanks
>>>> Edward
>>>> 
>>>>> On Sat, Jan 30, 2016 at 4:28 AM, Julian Hyde <jh...@apache.org> wrote:
>>>>> 
>>>>> In my opinion, in this month’s report, “Make a release” should be on your
>>>>> list of things to do before graduation.
>>>>> 
>>>>> Julian
>>>>> 
>>>>> 
>>>>>> On Jan 28, 2016, at 9:22 PM, Marvin Humphrey <mar...@apache.org>
>>>> wrote:
>>>>>> 
>>>>>> Greetings, {podling} developers!
>>>>>> 
>>>>>> This is a reminder that your report is due next Wednesday, February
>>>>>> 3rd.  Details below.
>>>>>> 
>>>>>> Best,
>>>>>> 
>>>>>> Marvin Humphrey, Report Manager for February, on behalf of the
>>>>>> Incubator PMC
>>>>>> 
>>>>>> ---
>>>>>> 
>>>>>> Dear podling,
>>>>>> 
>>>>>> This email was sent by an automated system on behalf of the Apache
>>>>>> Incubator PMC. It is an initial reminder to give you plenty of time to
>>>>>> prepare your quarterly board report.
>>>>>> 
>>>>>> The board meeting is scheduled for Wed, 17 February 2016, 10:30 am PDT.
>>>>>> The report for your podling will form a part of the Incubator PMC
>>>>>> report. The Incubator PMC requires your report to be submitted 2 weeks
>>>>>> before the board meeting, to allow sufficient time for review and
>>>>>> submission (Wed, February 3rd).
>>>>>> 
>>>>>> Please submit your report with sufficient time to allow the Incubator
>>>>>> PMC, and subsequently board members to review and digest. Again, the
>>>>>> very latest you should submit your report is 2 weeks prior to the board
>>>>>> meeting.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> The Apache Incubator PMC
>>>>>> 
>>>>>> Submitting your Report
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>> Your report should contain the following:
>>>>>> 
>>>>>> *   Your project name
>>>>>> *   A brief description of your project, which assumes no knowledge of
>>>>>> the project or necessarily of its field
>>>>>> *   A list of the three most important issues to address in the move
>>>>>> towards graduation.
>>>>>> *   Any issues that the Incubator PMC or ASF Board might wish/need to
>>>> be
>>>>>> aware of
>>>>>> *   How has the community developed since the last report
>>>>>> *   How has the project developed since the last report.
>>>>>> 
>>>>>> This should be appended to the Incubator Wiki page at:
>>>>>> 
>>>>>> http://wiki.apache.org/incubator/February2016
>>>>>> 
>>>>>> Note: This is manually populated. You may need to wait a little before
>>>>>> this page is created from a template.
>>>>>> 
>>>>>> Mentors
>>>>>> ---
>>>>>> 
>>>>>> Mentors should review reports for their project(s) and sign them off on
>>>>>> the Incubator wiki page. Signing off reports shows that you are
>>>>>> following the project - projects that are not signed may raise alarms
>>>>>> for the Incubator PMC.
>>>>>> 
>>>>>> Incubator PMC
>> 

Re: February 2016 Report

[Julian Hyde]

Note that I didn’t say “Make a release”; I said “Put ‘Make a release’ on the 
list of priorities in the report”. There’s definitely time for that. :)


> On Jan 31, 2016, at 8:50 PM, Luke Han <luke...@gmail.com> wrote:
> 
> I think it's too short to have a release this time, the report should
> be submitted before Wed, February 3rd.
> 
> Please do not miss it:)
> 
> Thanks.
> 
> 
> Best Regards!
> -
> 
> Luke Han
> 
> On Mon, Feb 1, 2016 at 12:33 AM, Edward Zhang <yonzhang2...@gmail.com>
> wrote:
> 
>> Sure, we will go through release process soon. I or Hao will be release
>> manager this time.
>> 
>> Thanks
>> Edward
>> 
>> On Sat, Jan 30, 2016 at 4:28 AM, Julian Hyde <jh...@apache.org> wrote:
>> 
>>> In my opinion, in this month’s report, “Make a release” should be on your
>>> list of things to do before graduation.
>>> 
>>> Julian
>>> 
>>> 
>>>> On Jan 28, 2016, at 9:22 PM, Marvin Humphrey <mar...@apache.org>
>> wrote:
>>>> 
>>>> Greetings, {podling} developers!
>>>> 
>>>> This is a reminder that your report is due next Wednesday, February
>>>> 3rd.  Details below.
>>>> 
>>>> Best,
>>>> 
>>>> Marvin Humphrey, Report Manager for February, on behalf of the
>>>> Incubator PMC
>>>> 
>>>> ---
>>>> 
>>>> Dear podling,
>>>> 
>>>> This email was sent by an automated system on behalf of the Apache
>>>> Incubator PMC. It is an initial reminder to give you plenty of time to
>>>> prepare your quarterly board report.
>>>> 
>>>> The board meeting is scheduled for Wed, 17 February 2016, 10:30 am PDT.
>>>> The report for your podling will form a part of the Incubator PMC
>>>> report. The Incubator PMC requires your report to be submitted 2 weeks
>>>> before the board meeting, to allow sufficient time for review and
>>>> submission (Wed, February 3rd).
>>>> 
>>>> Please submit your report with sufficient time to allow the Incubator
>>>> PMC, and subsequently board members to review and digest. Again, the
>>>> very latest you should submit your report is 2 weeks prior to the board
>>>> meeting.
>>>> 
>>>> Thanks,
>>>> 
>>>> The Apache Incubator PMC
>>>> 
>>>> Submitting your Report
>>>> 
>>>> --
>>>> 
>>>> Your report should contain the following:
>>>> 
>>>> *   Your project name
>>>> *   A brief description of your project, which assumes no knowledge of
>>>>   the project or necessarily of its field
>>>> *   A list of the three most important issues to address in the move
>>>>   towards graduation.
>>>> *   Any issues that the Incubator PMC or ASF Board might wish/need to
>> be
>>>>   aware of
>>>> *   How has the community developed since the last report
>>>> *   How has the project developed since the last report.
>>>> 
>>>> This should be appended to the Incubator Wiki page at:
>>>> 
>>>> http://wiki.apache.org/incubator/February2016
>>>> 
>>>> Note: This is manually populated. You may need to wait a little before
>>>> this page is created from a template.
>>>> 
>>>> Mentors
>>>> ---
>>>> 
>>>> Mentors should review reports for their project(s) and sign them off on
>>>> the Incubator wiki page. Signing off reports shows that you are
>>>> following the project - projects that are not signed may raise alarms
>>>> for the Incubator PMC.
>>>> 
>>>> Incubator PMC
>>> 
>>> 
>> 

Re: February 2016 Report

[Julian Hyde]

In my opinion, in this month’s report, “Make a release” should be on your list 
of things to do before graduation.

Julian


> On Jan 28, 2016, at 9:22 PM, Marvin Humphrey  wrote:
> 
> Greetings, {podling} developers!
> 
> This is a reminder that your report is due next Wednesday, February 
> 3rd.  Details below.
> 
> Best,
> 
> Marvin Humphrey, Report Manager for February, on behalf of the
> Incubator PMC
> 
> ---
> 
> Dear podling,
> 
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
> 
> The board meeting is scheduled for Wed, 17 February 2016, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, February 3rd).
> 
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
> 
> Thanks,
> 
> The Apache Incubator PMC
> 
> Submitting your Report
> 
> --
> 
> Your report should contain the following:
> 
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
>the project or necessarily of its field
> *   A list of the three most important issues to address in the move
>towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> 
> This should be appended to the Incubator Wiki page at:
> 
> http://wiki.apache.org/incubator/February2016
> 
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
> 
> Mentors
> ---
> 
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
> 
> Incubator PMC 

Re: Release?

[Julian Hyde]

r 
>> record
>>  keeping in the mail archive.
>> 
>> 
>> 
>>  Example close email:
>> 
>>  To: gene...@incubator.apache.org
>> 
>>  Subject: [RESULT][VOTE] Release Eagle incubating version
>>  
>> 
>> 
>> 
>>  Voting is now closed and has passed with the following tally,
>> 
>> 
>>  Binding +1s: 
>> 
>>  Non binding +1s: 
>> 
>> 
>>  Thanks to everyone who voted! I'll continue with the rest of the
>>  release process.
>> 
>> 
>> 
>>  $RM
>> 
>>  Rolling out the Release
>> 
>> 
>>  Close JIRA version
>> 
>>  You need to close the release in JIRA so that everyone knows that
>>  your version should not be used as "fixVersion" for new bugs. Go to
>>  JIRA "Administer project" page and follow "Versions" in left menu.
>>  Table with list of all releases should appear, click on additional menu
>>  on the right of your release and choose "Release" option. Submit
>>  release date and you're done.
>> 
>>  Upload the artifacts
>> 
>>  In order to release you have to checkout release repository
>>  located on
>>  https://dist.apache.org/repos/dist/release/incubator/eagle/
>>  <https://dist.apache.org/repos/dist/release/incubator/sentry/> and
>>  add release artifacts there.
>> 
>>  svn co https://dist.apache.org/repos/dist/release/incubator/eagle/
>>  eagle-release
>> 
>>  cd eagle-release
>> 
>>  mkdir -incubating/
>> 
>>  cp $source_to_your_artifacts -incubating/
>> 
>>  svn add -incubating
>> 
>>  It may take up to 24 hours for all mirrors to sync up (
>>  http://www.apache.org/dyn/closer.cgi/incubator/eagle/
>>  <http://www.apache.org/dyn/closer.cgi/incubator/sentry/>)
>> 
>>  Announce the release
>> 
>>  Send an email to annou...@apache.org (the from: address must be @
>>  apache.org). For example,
>> 
>>  To: annou...@apache.org, dev@eagle.incubator.apache.org
>> 
>>  Subject: [ANNOUNCE] Apache Eagle  incubating
>>  released
>> 
>> 
>>  The Apache Eagle community is happy to announce the release of
>>  version -incubating from the Apache Incubator. Apache 
>> Eagle
>>  is a monitoring framework for Hadoop to identify access to sensitive 
>> data,
>>  recognize malicious activities and take action in real time.
>> 
>>  The release bits are available at:
>>  http://www.apache.org/dyn/closer.cgi/incubator/eagle
>> 
>>  The change list is available at: 
>> 
>>  We would like to thank all contributors who made the release
>>  possible.
>> 
>> 
>>  Disclaimer
>> 
>>  Apache Eagle is an effort undergoing incubation at The Apache
>>  Software Foundation (ASF), sponsored by the Apache Incubator PMC.
>>  Incubation is required of all newly accepted projects until a further
>>  review indicates that the infrastructure, communications, and decision
>>  making process have stabilized in a manner consistent with other 
>> successful
>>  ASF projects. While incubation status is not necessarily a reflection of
>>  the completeness or stability of the code, it does indicate that the
>>  project has yet to be fully endorsed by the ASF.
>> 
>> 
>>  Regards,
>> 
>>  Eagle Community
>> 
>>  Update the website
>>  1. Update the website:
>>1. Add the release to the downloads
>><http://eagle.incubator.apache.org/general/downloads.html>
>>2. Add the release to the history page
>><http://eagle.incubator.apache.org/general/history.html>
>> 2. Update the "News" section in the podling status page
>> <http://incubator.apache.org/projects/eagle.html>.
>> 3. Update how to release page with your experience
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Fri, Jan 22, 2016 at 12:02 PM, arunkarthick m <aruncarth...@gmail.com>
>> wrote:
>> 
>>> I agree with Julian. Edward is starting to collect the list of features
>>> that are ready. I'm guessing Michael Wu will be a good release manager and
>>> start getting educated on the apache process.
>>> 
>>> Thanks,
>>> Arun
>>> 
>>> 
>>> 
>>> On Fri, Jan 22, 2016 at 11:59 AM, Julian Hyde <jh...@apache.org> wrote:
>>> 
>>>> It’s difficult to describe the “licensing issues”. I suggest that you
>>>> nominate a release manager and that person subscribes to the
>>>> general@incubator list [1] and follows the discussions there. Watch the
>>>> kind of due diligence that people such as Justin McLean apply to the
>>>> releases, e.g. the Freemarker release [2]. (It seems onerous but is much
>>>> appreciated by your community, because it means they are getting
>>> spotlessly
>>>> clean IP.)
>>>> 
>>>> You will need to go through the same process: after a vote on this dev
>>>> list, there is a second vote on the generator@incubator list.
>>>> 
>>>> I can’t stress this strongly enough: The actual features (and bugs) in
>>> the
>>>> first release is very unimportant. It is all about the legal packaging,
>>> and
>>>> the process by which you make the release. No reason not to start now.
>>>> 
>>>> Julian
>>>> 
>>>> [1] http://mail-archives.apache.org/mod_mbox/incubator-general/
>>>> 
>>>> [2]
>>>> 
>>> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CB538B622-B173-4778-97AB-12E66D480FE8%40classsoftware.com%3E
>>>> 
>>>>> On Jan 22, 2016, at 11:46 AM, Zhang, Edward (GDI Hadoop) <
>>>> yonzh...@ebay.com> wrote:
>>>>> 
>>>>> Thanks for initiating this discussion. I also wonder how to do the
>>> first
>>>>> release, what it the timing, what is the version number and what
>>> features
>>>>> we should include and what is release notes.
>>>>> 
>>>>> But I am not aware of licensing issues. Does that because that not all
>>>> our
>>>>> source files are for apache license so we need explicitly tell that in
>>>>> public?
>>>>> 
>>>>> I volunteer to collect the features for the first release. A lot more
>>>> work
>>>>> should be identified while we are progressing.
>>>>> 
>>>>> Thanks
>>>>> Edward
>>>>> 
>>>>> On 1/22/16, 8:44, "Julian Hyde" <jh...@apache.org> wrote:
>>>>> 
>>>>>> Hi eagle community,
>>>>>> 
>>>>>> How¹s progress on the first Eagle release?
>>>>>> 
>>>>>> The Eagle project is progressing at an admirable rate in terms of
>>>>>> features and community engagement. However, you¹ve not yet made a
>>>>>> release. Making a release is more tricky than you would imagine ‹ and
>>>>>> it¹s usually due to licensing issues, not due to bugs or other code
>>>>>> issues ‹ so the first one takes a month or two. But making releases
>>> is a
>>>>>> key part of learning the Apache way and demonstrating that you¹re
>>> ready
>>>>>> to graduate; and, it helps to build community.
>>>>>> 
>>>>>> Also remember that the project does not need to be ³perfect². Your
>>> first
>>>>>> release will have lots of bugs in it. If it compiles and has a
>>> README,
>>>>>> that is enough.
>>>>>> 
>>>>>> Julian
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Arun Karthick
>>> 201-850-9399
>>> 
>> 
>> 

Re: [Discuss] Eagle Policy State Management

[Julian Hyde]

State management of streams (including what I’d call “derived streams”) is a 
hard distributed systems problem. Ideally it would be solved by the stream 
provider, not by the Eagle project. I think you should talk to the various 
streaming projects — Storm, Samza, Kafka, Flink — and find out whether they can 
solve this, or whether it is on their roadmap. 

I can make introductions to the leaders of those projects if needed.

If the problem is solved at source, Eagle can focus on the actual problem 
rather than infrastructure.

Julian


> On Dec 10, 2015, at 7:48 PM, Liangfei.Su  wrote:
> 
> Great proposal, this is important and could be general served for policy
> capability and analytic feature.
> 
> Periodically taken the snapshot independently on each bolt could make
> status recoverable from recent history, but from whole topology store point
> of view, this could not hand bolt status dependency exactly.
> 
> Another point is should the state restore be triggered not only when
> topology restarts but also when
> a. topology re-balance
> b. single bolt movement by underling stream framework for one executor to
> another?
> 
> Thanks,
> Ralph
> 
> 
> On Fri, Dec 11, 2015 at 9:49 AM, Zhang, Edward (GDI Hadoop) <
> yonzh...@ebay.com> wrote:
> 
>> This topic has been discussed offline for a while and it is time we
>> document problems and solutions. With clear problem statements and proposed
>> solutions, I believe we can do better before we start implementing.
>> 
>> [Problem Statement] For Eagle as real-time big data monitoring framework
>> evaluating policies efficiently is the core functionality. Most of
>> meaningful polices are stateful in that policy evaluation is not based on a
>> single event but on both previous events and current event. This
>> potentially brings 2 fundamental problems, one is policy state loss upon
>> machine failures or topology restart, the other is lacking history data
>> upon fresh start. One simple example is for a policy like “from
>> userActivity[cmd==‘delete’]time.window(1 month) select user, count() as cnt
>> group by user having cnt > 1000”, if the task is restarted, the state of
>> accumulated user/count map is missing. Also when the topology is started at
>> the first time, the window is empty even if we have historic data in
>> database.
>> 
>> [Proposed Solutions] The natural way of solving the above 2 problems is
>> 1) do policy state persist periodically and restore policy state after
>> task is restarted
>> Underlying policy engine should support snapshot and restore operations.
>> In Siddhi 3.x, it already supports snapshot and restore, though I found
>> some bugs with their state management.
>> https://wso2.org/jira/browse/CEP-1433
>> For restore, it is not that straight-forward unless all input events to
>> policy evaluator are backed by a reliable and rewindable storage like Kafka.
>> If input events to policy evaluator is backed by Kafka, then each time
>> when EAGLE takes snapshot, we records the current offset together and
>> persist both of them to deep storage.
>> If input events to policy evaluator is not backed by Kafka, then we need
>> record every event since last snapshot. That looks very expensive. Apache
>> Flink uses efficient algorithm called stream barrier to do group
>> acknowledgement, but in Storm we don’t have this feature. But remember
>> Apache Flink requires that each task do snapshot not only for policy
>> evaluator.
>> 
>> 2) transparently load historical data when topology is started at the
>> first time
>> If policy evaluator accepts data which is already persisted in database or
>> Kafka, we can provide API to retrieve data from database or Kafka. This
>> loading is transparent to developer, but developer/user needs to specify
>> the deep storage for storing historical data.
>> 
>> Also be aware that if we have the right solution for policy evaluator, the
>> solution should be also applied to event aggregation.
>> https://cwiki.apache.org/confluence/display/EAG/Stream+Analyze
>> 
>> Another aggressive way is to use Flink stream barrier similar solution
>> http://data-artisans.com/high-throughput-low-latency-and-exactly-once-stream-processing-with-apache-flink/
>> to take snapshot to all eagle tasks(typically spout and bolt) but turn off
>> storm ACK mechanism.
>> 
>> trait StormStreamExecutor[R <: EagleTuple] extends FlatMapper[Seq[AnyRef],
>> R] {
>>  def prepareConfig(config : Config)
>>  def init
>>  def fields : Array[String]
>> }
>> 
>> 
>> ==>
>> 
>> 
>> trait StormStreamExecutor[R <: EagleTuple] extends FlatMapper[Seq[AnyRef],
>> R] {
>>  def prepareConfig(config : Config)
>>  def init
>>  def fields : Array[String]
>> 
>>  def snapshot : Array[Byte]
>> 
>>  def restore(state: Array[Byte])
>> }
>> 
>> This is pretty much important to Eagle if we want Eagle to be a monitoring
>> framework with fault-tolerance.
>> 
>> Thanks
>> Edward
>> From: Sriskandarajah Suhothayan 

Re: About dev process

[Julian Hyde]

One minor problem with the "[EAGLE-${ticket_number}] message" format is the
'git am' command. When it reads patches from a mail box, it uses the
subject of each email as the commit message but it strips off any [ ... ]
at the start of the subject. So, even though we use this format in Calcite,
if we started over, I think we might use something like
"EAGLE-{ticket_number}: message" (without brackets) instead.

Strictly, you don't need the "Author:" and "Reviewer:" lines because they
are contained in the git metadata. But you probably know that already.

Julian


On Tue, Dec 8, 2015 at 6:46 PM, Liangfei.Su  wrote:

> Hi, PMCs
>
> To help clear the dev process, i'm trying to put this into eagle WIKI.
> Please advise if it's OK to all.
>
> The referenced commit msg format is:
>
>
> [EAGLE-${ticket_number}] ${ticket_title}
>
> ${ticket_url}
>
> Author: ${commiter}
> Reviewer: ${reviewer}
>
> Closes #${pr_number} from ${do_person}
>
>
>
>
> ​
> Thanks,
> Ralph
>

Re: December 2015 Report

[Julian Hyde]

If I am not mistaken Eagle should be filing its first monthly report. (It 
should report December, January, February and then move to quarterly reporting.)

The report should be in https://wiki.apache.org/incubator/December2015.

Usually a reminder is sent out, like the one below. There was not a reminder 
this time, but that doesn’t get you off the hook! The report was due on Wed Dec 
2nd but I think there is still time to file.

Can we have a volunteer to write the report? 

Marvin, Any idea why there was no reminder sent to Eagle? (It is entirely 
possible that I set up the schedule wrong.)

Julian



> On Nov 26, 2015, at 12:40 PM, Marvin Humphrey  wrote:
> 
> 
> Greetings, {podling} developers!
> 
> This is a reminder that your report is due next Wednesday, December
> 2nd.  Details below.
> 
> Best,
> 
> Marvin Humphrey, Report Manager for December, on behalf of the
> Incubator PMC
> 
> ---
> 
> Dear podling,
> 
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
> 
> The board meeting is scheduled for Wed, 16 December 2015, 10:30 am PST.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, December 2nd).
> 
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
> 
> Thanks,
> 
> The Apache Incubator PMC
> 
> Submitting your Report
> 
> --
> 
> Your report should contain the following:
> 
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
>the project or necessarily of its field
> *   A list of the three most important issues to address in the move
>towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> 
> This should be appended to the Incubator Wiki page at:
> 
> http://wiki.apache.org/incubator/December2015
> 
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
> 
> Mentors
> ---
> 
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
> 
> Incubator PMC 
> 

Re: Apache Eagle Scrum Board

[Julian Hyde]

I tried to give you karma but apparently I don’t have the meta-karma to do this.

Amareshwari, you are listed in JIRA [1] as the project lead. Can you do this?

Julian

[1] https://issues.apache.org/jira/browse/EAGLE


> On Dec 2, 2015, at 5:28 PM, CaiEddy  wrote:
> 
> Hi Mentors:
> I'm member of Apache Eagle project, and I would like have my account granted 
> with Administrator role on Apache Eagle JIRA project so that I can create 
> sprint.  My Jira account is: wzcyc
> BTW, I have created "Apache Eagle" on board. 
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=103=planning.nodetail
>  and we plan to start the first sprint next week. 
> RegardsEddy 

Re: Github and Site

[Julian Hyde]

Looks great!

Can you make the “github” link point to 
https://github.com/apache/incubator-eagle 
 not https://github.com/ebay/eagle?

Julian


> On Nov 19, 2015, at 7:27 AM, Luke Han  wrote:
> 
> Site looks great
> 
> 
> Best Regards!
> -
> 
> Luke Han
> 
> On Thu, Nov 19, 2015 at 10:10 PM, Adunuthula, Seshu 
> wrote:
> 
>> Awesome!
>> 
>> On 11/19/15, 5:56 AM, "Hao Chen"  wrote:
>> 
>>> The Github and Site for Apache Eagle (Incubating) is ready now.
>>> 
>>> Github: https://github.com/apache/incubator-eagle
>>> Site: http://eagle.incubator.apache.org
>>> 
>>> Regards,
>>> Hao
>>> 
>>> On Thu, Nov 19, 2015 at 4:01 AM, Henry Saputra 
>>> wrote:
>>> 
 Alright, has just submiitted the update to grant karma. Wait for few
 hours to let LDAP sync and give it a spin.
 
 - Henry
 
 On Wed, Nov 18, 2015 at 11:05 AM, arunkarthick m
 
 wrote:
> Hi Henry,
> 
> Did you get to add the SVN karma to Edward ?
> 
> We want to push our site from goeagle.io to
 eagle.apache.incubator.org.
> 
> Thanks,
> Arun
> 
> On Tue, Nov 17, 2015 at 9:34 PM, Luke Han  wrote:
> 
>> Would like to suggest to go through all INFA jira tickets opened by
 me
 and
>> Henry for Kylin's one.
>> There are many infrastructure stuff should to be ready including code
 repo,
>> site, maven, release and so on.
>> 
>> 
>> Best Regards!
>> -
>> 
>> Luke Han
>> 
> 
> 
> 
> --
> Arun Karthick
> 201-850-9399
 
>> 
>> 

Re: Github and Site

[Julian Hyde]

Thanks for fixing this promptly.

For the record, I don’t see this as particularly urgent. Things are always a 
bit messy at this stage. But we should aim to have no external links by the 
time of the first or second release.

> On Nov 19, 2015, at 10:58 AM, Zhang, Edward (GDI Hadoop) <yonzh...@ebay.com> 
> wrote:
> 
> Thanks. Just fixed and another link.
> But looks we don¹t have link for wiki in incubator-eagle, so ³how to
> contribute² link is broken. Will look into.
> 
> Thanks
> Edward Zhang
> 
> On 11/19/15, 10:42, "Julian Hyde" <jh...@apache.org> wrote:
> 
>> Looks great!
>> 
>> Can you make the ³github² link point to
>> https://github.com/apache/incubator-eagle
>> <https://github.com/apache/incubator-eagle> not
>> https://github.com/ebay/eagle?
>> 
>> Julian
>> 
>> 
>>> On Nov 19, 2015, at 7:27 AM, Luke Han <luke...@gmail.com> wrote:
>>> 
>>> Site looks great
>>> 
>>> 
>>> Best Regards!
>>> -
>>> 
>>> Luke Han
>>> 
>>> On Thu, Nov 19, 2015 at 10:10 PM, Adunuthula, Seshu
>>> <sadunuth...@ebay.com>
>>> wrote:
>>> 
>>>> Awesome!
>>>> 
>>>> On 11/19/15, 5:56 AM, "Hao Chen" <h...@apache.org> wrote:
>>>> 
>>>>> The Github and Site for Apache Eagle (Incubating) is ready now.
>>>>> 
>>>>> Github: https://github.com/apache/incubator-eagle
>>>>> Site: http://eagle.incubator.apache.org
>>>>> 
>>>>> Regards,
>>>>> Hao
>>>>> 
>>>>> On Thu, Nov 19, 2015 at 4:01 AM, Henry Saputra
>>>>> <henry.sapu...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Alright, has just submiitted the update to grant karma. Wait for few
>>>>>> hours to let LDAP sync and give it a spin.
>>>>>> 
>>>>>> - Henry
>>>>>> 
>>>>>> On Wed, Nov 18, 2015 at 11:05 AM, arunkarthick m
>>>>>> <aruncarth...@gmail.com>
>>>>>> wrote:
>>>>>>> Hi Henry,
>>>>>>> 
>>>>>>> Did you get to add the SVN karma to Edward ?
>>>>>>> 
>>>>>>> We want to push our site from goeagle.io to
>>>>>> eagle.apache.incubator.org.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Arun
>>>>>>> 
>>>>>>> On Tue, Nov 17, 2015 at 9:34 PM, Luke Han <luke...@gmail.com> wrote:
>>>>>>> 
>>>>>>>> Would like to suggest to go through all INFA jira tickets opened by
>>>>>> me
>>>>>> and
>>>>>>>> Henry for Kylin's one.
>>>>>>>> There are many infrastructure stuff should to be ready including
>>>>>>>> code
>>>>>> repo,
>>>>>>>> site, maven, release and so on.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Best Regards!
>>>>>>>> -
>>>>>>>> 
>>>>>>>> Luke Han
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Arun Karthick
>>>>>>> 201-850-9399
>>>>>> 
>>>> 
>>>> 
>> 
> 

Re: Best Practice for Code Collaboration in Apache Way

[Julian Hyde]

What you are describing — creating a branch in the central repository so that 
developers can collaborate — is often called a “feature branch”.

However I find that the majority of tasks are accomplished by just one 
developer. For this, the developer creates a branch in his/her own fork and 
creates a pull request from it.

Even if a task is large enough to require several developers to collaborate, it 
often preferable to have them check their sub-tasks into the master branch 
periodically, perhaps with the feature disabled by default. That way you avoid 
integration pain later.

So, feature branches in the central repo are relatively rare.

Julian


> On Nov 11, 2015, at 12:46 AM, Hao Chen <h...@apache.org> wrote:
> 
> Jilin,
> 
> I think the practice is good for situation when multiple developers work on
> the same task, so that the end-to-end process in such case should be:
> 
> 1. Create JIRAP ticket for certain works say JIRAP-N
> 2. Create a branch named "JIRAP-N"
> 3. Different developers works on the same task will work on the same branch
> (in such situation, the developers are required to commit directly to root
> repository)
> 4. After the work described in the JIRAP-N finished, we should merge the
> branch JIRAP-N into master branch. (Here we may care about  how to make
> sure the master commit history is clean and beautiful)
> 
> Regards,
> Hao
> 
> On Wed, Nov 11, 2015 at 4:31 PM, Jilin <ji...@apache.org> wrote:
> 
>> For cooperation development. We can create the branch on the eagle repo
>> named by the jira ticket. So that developers can develop in the same line.
>> After finish the development & code review, merge the branch into master.
>> 
>> how do you think about it?
>> 
>> 2015-11-11 3:08 GMT+08:00 Julian Hyde <jh...@apache.org>:
>> 
>>> I think using http://github.com/apache/incubator-eagle with pull
>>> requests would be perfect. Some projects accept also patches but I
>>> think it's simpler & better if your community is OK with just doing
>>> pull requests.
>>> 
>>> On Tue, Nov 10, 2015 at 1:00 AM, Hao Chen <h...@apache.org> wrote:
>>>> Hi Eagle Mentors,
>>>> 
>>>> I would like to consult about what is the Best Practice for Code
>>>> Collaboration in Apache Way?
>>>> 
>>>> Currently we are using github https://github.com/eBay/Eagle with pull
>>>> request.
>>>> 
>>>> What practice should we follow after migrating into Apache code
>>> repository?
>>>> 
>>>> --
>>>> 
>>>> Hao
>>> 
>> 

Re: Best Practice for Code Collaboration in Apache Way

[Julian Hyde]

I think using http://github.com/apache/incubator-eagle with pull
requests would be perfect. Some projects accept also patches but I
think it's simpler & better if your community is OK with just doing
pull requests.

On Tue, Nov 10, 2015 at 1:00 AM, Hao Chen  wrote:
> Hi Eagle Mentors,
>
> I would like to consult about what is the Best Practice for Code
> Collaboration in Apache Way?
>
> Currently we are using github https://github.com/eBay/Eagle with pull
> request.
>
> What practice should we follow after migrating into Apache code repository?
>
> --
>
> Hao

Re: eagle.incubator.apache.org

[Julian Hyde]

I’m not sure that that is consistent with Apache’s branding guidelines. I may 
be wrong, but I believe that the web site needs to be hosted on an Apache 
domain.

Also, the web site needs the standard disclaimer about Eagle’s incubation 
status.

Julian

 

> On Nov 9, 2015, at 3:10 PM, Adunuthula, Seshu  wrote:
> 
> Also we should get the website redirected to goeagle.io
> 
> Regards
> Seshu