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

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  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  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  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  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 
>>>> 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 relevant here.
>>>>> 
>>>>> -Taylor
>>>>> 
>>>>>> On Ju

[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&focusedCommentId=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: Web site branding

[Julian Hyde]

Looks much better, thanks.

Someone should update the twitter account's description now that
goeagle.io has gone away: https://twitter.com/TheApacheEagle.

On Mon, Aug 1, 2016 at 2:16 AM, Michael Wu  wrote:
> Hi there,
>
> Ticket Eagle-380 is closed, and eagle site has been updated with all the
> modifications. This time, in pages, we add footnotes to indicate some words
> representing Apache projects,  such as "hadoop", "hbase", "storm", etc, and
> tag the corresponding footnote number at the top-right corner of these
> words for readers to refer to. The reason we use this approach is that it
> not only claims the branding of Apache, but also keeps the best readability
> of the entire documentation tree.
>
> BTW, in this update, we also move Disclaimer up to the middle of the home
> page so that it's easier to be found.
>
> If convenient, please help review it at: https://eagle.incubator.apache.org/
> and https://eagle.incubator.apache.org/docs/.
>
> @Julian, the "fork me on github" has been removed, and we are working on
> the task to cite steps on readme file into development-quick-quide page.
>
>
> Anything missed, please do let me know. Thanks.
>
> Michael
>
> On Wed, Jul 20, 2016 at 4:22 AM, Julian Hyde  wrote:
>
>> I’ve replied to the JIRA ticket. Let’s move the conversation there.
>>
>> > On Jul 19, 2016, at 12:43 AM, Michael Wu  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  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  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  wrote:
>> >>>
>> >>>> I added the following comments to the JIRA case:
>> >>>>
>> >>>> * Also, make the disclaimer more prominent o

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  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,  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: [DISCUSS] Is Eagle ready to graduate?

[Julian Hyde]

> … also want to discuss this with other
> contributors.

Why not discuss with them on this list?

Julian

[DISCUSS] Is Eagle ready to graduate?

[Julian Hyde]

Eagle is making good progress on working in the open, building community, and 
making releases. In short, I feel that it is following the Apache Way.

Let’s discuss whether Eagle is ready to graduate. Do you feel that you can 
govern yourself? What tasks remain before graduation? How long will it take to 
achieve these?

There is a maturity level model [1] that several projects use to assess the 
readiness to graduate. I think it would be useful if Eagle self-assesses using 
this model. What do you all think?

Julian

[1] https://community.apache.org/apache-way/apache-project-maturity-model.html

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

[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&focusedCommentId=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  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  <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 > <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  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  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 
>> 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 
>>> wrote:
>>> 
>>>> 
>>>> 
>>>> On 2016-06-29 20:48 (-0400), Henry Saputra 
>>>> 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 
>>>> 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 >>>>> > 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
>>>>>> >
>>>>>>> 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 >>>&

[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&focusedCommentId=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  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  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  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 > >
>> > 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  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)
>> >>>  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 sour

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

[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=15372034#comment-15372034
 ] 

Julian Hyde commented on EAGLE-371:
---

The ASF cannot guarantee the hygiene of Eagle's IP (and yes, documentation is 
part of the IP) if it is not managed on ASF hardware. A github MIRROR of the 
ASF git under github.com/apache/incubator-eagle is OK, but Eagle should be 
moving away from https://github.com/eaglemonitoring as fast as possible.

Also, maybe I missed the discussion, but it sounds as if this decision was made 
off-list. 

If it's not possible to move off of https://github.com/eaglemonitoring 
immediately, let's at least create some JIRA cases so that we know where we are 
heading.

> 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&focusedCommentId=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: [VOTE] Release: Apache Eagle 0.4.0-incubating (Release Candidate 2)

[Julian Hyde]

Yes, that's right. It's even optional to have a reason. 

The basic idea is that a vote thread should be identifiable using message 
headers, should contain a minimum of discussion, and should be terminated 
either by a result (pass or fail) or a cancel. 

It's the release manager's call whether to cancel a vote. 

Sometimes I've terminated a vote with a message like this: "The vote passed 
with 5 +1 votes. I have logged jira cases X and Y for issues raised during the 
vote, and will start a thread to discuss ..."

Julian

> On Jul 9, 2016, at 00:48, Liangfei.Su  wrote:
> 
> Mike,
> 
> I found a sample cancel vote thread. I think a simple cancel with reason
> stated should be ok, detailed result could be better. You might follow the
> same.
> 
> @Julian, comment?
> 
> 
>  reference ( don't know how to make email as attached directly, simply
> copy here for refernece.)
> 
> [CANCEL][VOTE] Release Mynewt 0.9.0-incubating-rc1
> 
> Christopher Collins 
> May 28
> 
> Hello all,
> 
> Voting for the release of 0.9.0-incubating-rc1 has been cancelled due to
> some incorrectly packaged source [*].
> 
> Sorry for the confusion, and thank you to everyone who voted.  A second
> release candidate will be put up for a vote on the dev list shortly.
> 
> Thanks,
> Chris
> 
> [*] For the newt release, a subdirectory was packaged rather than the
> entire repo.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 
> 
> 
> 
>> On Sat, Jul 9, 2016 at 3:10 PM, Michael Wu  wrote:
>> 
>> Hi Julian,
>> 
>> I'd say, it's the quality of the release that is more important than
>> anything else. As you mentioned, I'll bring another discussion for this
>> issue. BTW, could you let me know if I have to send a result email of the 2
>> rejected RC to cancel the VOTE? Thanks.
>> 
>> Michael
>> 
>>> On Sat, Jul 9, 2016 at 2:29 AM, Julian Hyde  wrote:
>>> 
>>> I feel your pain: it's painful to have two RCs shot down. But let's
>>> not have design discussions on a VOTE thread. Let's cancel the vote,
>>> and start a discussion in another thread. If there is an existing JIRA
>>> for this issue, please forward that; it will help us avoid going over
>>> the same old ground.
>>> 
>>>> On Fri, Jul 8, 2016 at 10:01 AM, Michael Wu  wrote:
>>>> @ Hemanth,
>>>> 
>>>> Indeed, we could have kept the tar containing only source code, without
>>>> packaged non-open-source stuffs, I know it's required by Apache policy,
>>> and
>>>> agree with the policy totally.
>>>> 
>>>> However, for our project, let's just make an imagination, if we move
>> the
>>>> jars out of the project and create the source tar, so far for voting
>> and
>>>> consequently for releasing in the future, each time customers of the
>>>> project download the source code, they may be unable to build the
>> project
>>>> with merely executing maven build commands, on the contrary, they have
>> to
>>>> download and place these depended jars appropriately by themselves,
>> isn't
>>>> it unfriendly and a super boring manner?
>>>> 
>>>> Then, that's why I asked you guys who may know the use of the jars and
>>> may
>>>> give valuable suggestions for how to deal better with them, on 1 hand
>> not
>>>> blocking future maven builds, on the other hand can make it satisfy
>>>> apache's release policy. Currently, I'm still not sure if it may bring
>>> many
>>>> additional efforts, but customer friendly seems very important to a
>>> project.
>>>> 
>>>> So, could you give some details on how much the removal of jars will
>>> affect
>>>> the build? Appreciated!
>>>> 
>>>> @ all, do you guys have any thought on this issue, please? We seem to
>>> have
>>>> been blocked a bit at it. Thanks.
>>>> 
>>>> Michael
>>>> 
>>>> Michael
>>>> 
>>>> On Sat, Jul 9, 2016 at 12:21 AM, Dendukuri, Hemanth <
>> hdenduk...@ebay.com
>>>> 
>>>> wrote:
>>>> 
>>>>> Michael, Since this is voting for source only, we need to make sure
>> only
>>>>> eagle source if voted.

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

[Julian Hyde]

I feel your pain: it's painful to have two RCs shot down. But let's
not have design discussions on a VOTE thread. Let's cancel the vote,
and start a discussion in another thread. If there is an existing JIRA
for this issue, please forward that; it will help us avoid going over
the same old ground.

On Fri, Jul 8, 2016 at 10:01 AM, Michael Wu  wrote:
> @ Hemanth,
>
> Indeed, we could have kept the tar containing only source code, without
> packaged non-open-source stuffs, I know it's required by Apache policy, and
> agree with the policy totally.
>
> However, for our project, let's just make an imagination, if we move the
> jars out of the project and create the source tar, so far for voting and
> consequently for releasing in the future, each time customers of the
> project download the source code, they may be unable to build the project
> with merely executing maven build commands, on the contrary, they have to
> download and place these depended jars appropriately by themselves, isn't
> it unfriendly and a super boring manner?
>
> Then, that's why I asked you guys who may know the use of the jars and may
> give valuable suggestions for how to deal better with them, on 1 hand not
> blocking future maven builds, on the other hand can make it satisfy
> apache's release policy. Currently, I'm still not sure if it may bring many
> additional efforts, but customer friendly seems very important to a project.
>
> So, could you give some details on how much the removal of jars will affect
> the build? Appreciated!
>
> @ all, do you guys have any thought on this issue, please? We seem to have
> been blocked a bit at it. Thanks.
>
> Michael
>
> Michael
>
> On Sat, Jul 9, 2016 at 12:21 AM, Dendukuri, Hemanth 
> wrote:
>
>> Michael, Since this is voting for source only, we need to make sure only
>> eagle source if voted.
>>
>> The artifacts should be uploaded for voting before packaging ("mvn
>> package”), I believe.
>>
>> You can provide the instructions on how to get required tomcat jars for
>> the build, if eagle has dependencies.
>>
>> Regards
>> Hemanth
>>
>>
>>
>>
>>
>>
>> On 7/7/16, 11:30 PM, "Michael Wu"  wrote:
>>
>> >@ Hemanth,
>> >
>> >Did you mean to directly remove the eagle-assembly/src/main/lib/tomcat
>> >directory before packaging the source? I saw the directory removed in
>> >0.3.0-incubating release, do you have any idea about the following 2:
>> >1. does this removal impact building approach and behavior?
>> >2. if we remove it, after "mvn package" phase, will the final jar
>> assembled
>> >have potential running issue with eagle-service?
>> >
>> >If the jars have dependencies on them, we may have to make more efforts to
>> >fix it before voting RC3.
>> >
>> >Thanks.
>> >Michael
>> >
>> >
>> >On Fri, Jul 8, 2016 at 1:04 PM, Daniel Zhou 
>> >wrote:
>> >
>> >> +1
>> >> * Built and tested successfully in centos 7 with  jdk1.7
>> >>
>> >> Regards,
>> >> Da
>> >>
>> >> > On Jul 7, 2016, at 8:33 PM, Jinhu Wu  wrote:
>> >> >
>> >> > +1
>> >> > * Get the tar package and built successfully on MAC OS X with JDK
>> >> 1.7(java
>> >> > version "1.7.0_80")
>> >> > * checked md5, sha1 successfully
>> >> > * rat checked and is ok
>> >> >
>> >> >
>> >> >> On Fri, Jul 8, 2016 at 11:03 AM, Jilin  wrote:
>> >> >>
>> >> >> +1
>> >> >> * Downloaded & built successfully on windows7 64-bit JDK 1.7
>> >> >> * md5, sha1 check passed
>> >> >> * tag matches
>> >> >>
>> >> >> Thanks for your help
>> >> >>
>> >> >> 2016-07-08 10:15 GMT+08:00 Zhao Qingwen :
>> >> >>
>> >> >>> +1 (binding)
>> >> >>>
>> >> >>>
>> >> >>> Best Regards,
>> >> >>> Qingwen Zhao | 赵晴雯
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> 2016-07-08 8:37 GMT+08:00 Edward Zhang :
>> >> >>>
>> >>  Sorry, correct my vote from "non-binding" to "binding" :-)
>> >> 
>> >>  Thanks
>> >>  Edward
>> >> 
>> >>  On Thu, Jul 7, 2016 at 9:29 AM, Edward Zhang <
>> yonzhang2...@apache.org
>> >> >
>> >>  wrote:
>> >> 
>> >> > +1 (not-binding)
>> >> >
>> >> > * Downloaded & built successfully with Hotspot JDK1.7 on OSX
>> >> > * Signature checked, md5, sha1 verified (
>> >> > https://httpd.apache.org/dev/verification.html)
>> >> > * Apache rat:check passed (mvn apache-rat:check)
>> >> >
>> >> > * Commit and tag matched
>> >> >
>> >> >
>> >> > Thanks
>> >> >
>> >> > Edward
>> >> >
>> >> > On Tue, 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
>> >> 

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  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  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  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  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  wrote:
>>> 
>>> Will continue to verify and update the fix.
>>> 
>>> - Hao
>>> 
>>>> On Wed, Jun 29, 2016 at 10:21 AM, Julian Hyde  wrote:
>>>> 
>>>> Did you find any other violations of branding policy?
>>>> 
>>>>> On Jun 29, 2016, at 10:13 AM, Hao Chen  wrote:
>>>>> 
>>>>> Updated with (incubating), thanks for advising.
>>>>> 
>>>>> - Hao
>>>>> 
>>>>>> On Wed, Jun 29, 2016 at 9:48 AM, Julian Hyde 
>> 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  wrote:
> 
> Updated with (incubating), thanks for advising.
> 
> - Hao
> 
> On Wed, Jun 29, 2016 at 9:48 AM, Julian Hyde  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 
> mailto:h...@apache.org>> 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  wrote:
> 
> Download link added http://goeagle.io/docs/download.html
> 
> 
> 
> 
> On 5/1/16, 8:32 AM, "Julian Hyde"  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: Podling Report Reminder - May 2016

[Julian Hyde]

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 
. 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 mailto:h...@apache.org>>
> Reply-To: 
> "dev@eagle.incubator.apache.org" 
> mailto:dev@eagle.incubator.apache.org>>
> Date: Wednesday, April 6, 2016 at 1:35 AM
> To: 經年錯ミ莫失莫忘 <378032...@qq.com>, 
> "dev@eagle.incubator.apache.org" 
> mailto:dev@eagle.incubator.apache.org>>, 
> "u...@eagle.incubator.apache.org" 
> mailto: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  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"  <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  wrote:
>>> 
>>> Sure my bad, will consider and resend.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 3/26/16, 7:26 PM, "Julian Hyde"  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  
>>>>> 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

Release votes

[Julian Hyde]

(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-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  wrote:
> 
> Sure my bad, will consider and resend.
> 
> 
> 
> 
> 
> On 3/26/16, 7:26 PM, "Julian Hyde"  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  
>>> 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  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 this package because...
 
 
 
 Thanks,
 
>

Re: [VOTE] Release Eagle Incubating Version 0.3.0

[Julian Hyde]

> On Mar 21, 2016, at 12:50 PM, Dendukuri, Hemanth  wrote:
> 
> The Voting is closed. I already sent out details with subject “[CANCEL] 
> [VOTE] Release Eagle Incubating Version 0.3.0”

You’re right; sorry; somehow I missed it when I checked the archive.

Julian

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
>> 
>> 
>> 
> 
 
>>> 
>> incubator-eagle-release-0.3.0/eagle-security/eagle-security-hdfs-auditlog/src/main/resources/h

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: [VOTE] Release Eagle Incubating Version 0.3.0

[Julian Hyde]

> Should this be voted in dev list or private list.

Dev list. Very few things in Apache need to happen in private.

The artifacts are in the right place, checksums look good, directory
structure of .tar.gz looks good.

There's no tag in git yet; I presume you intend to apply that later.

I unzipped .tar.gz and tried to build. Building using JDK 1.8 and
Maven 3.2.1 on Ubuntu, I got the following errors:

[INFO] --- maven-scala-plugin:2.15.0:compile (scala-compile-first) @
eagle-stream-process-base ---
[INFO] Checking for multiple versions of scala
[WARNING]  Expected all dependencies to require Scala version: 2.10.0
[WARNING]  org.apache.kafka:kafka_2.10:0.8.1.2.2.0.0-2041 requires
scala version: 2.10.4
[WARNING] Multiple versions of scala libraries detected!
[INFO] includes = [**/*.java,**/*.scala,]
[INFO] excludes = []
[INFO] 
/tmp/incubator-eagle-release-0.3.0/eagle-core/eagle-data-process/eagle-stream-process-base/src/main/java:-1:
info: compiling
[INFO] 
/tmp/incubator-eagle-release-0.3.0/eagle-core/eagle-data-process/eagle-stream-process-base/src/main/scala:-1:
info: compiling
[INFO] Compiling 16 source files to
/tmp/incubator-eagle-release-0.3.0/eagle-core/eagle-data-process/eagle-stream-process-base/target/classes
at 1457213608788
[ERROR] error: error while loading CharSequence, class file
'/usr/lib/jvm/jdk1.8.0_72/jre/lib/rt.jar(java/lang/CharSequence.class)'
is broken
[INFO] (class java.lang.RuntimeException/bad constant pool tag 18 at byte 10)
[ERROR] error: error while loading AnnotatedElement, class file
'/usr/lib/jvm/jdk1.8.0_72/jre/lib/rt.jar(java/lang/reflect/AnnotatedElement.class)'
is broken
[INFO] (class java.lang.RuntimeException/bad constant pool tag 18 at byte 76)
[ERROR] error: error while loading ConcurrentMap, class file
'/usr/lib/jvm/jdk1.8.0_72/jre/lib/rt.jar(java/util/concurrent/ConcurrentMap.class)'
is broken
[INFO] (class java.lang.RuntimeException/bad constant pool tag 18 at byte 61)
[ERROR] three errors found

There are 3 .jar files present (bootstream.jar, commons-daemon.jar,
tomcat-juli.jar). I guess that is a binary distribution of
apache-tomcat?

Checked DISCLAIMER, LICENSE present. There should be a NOTICE file,
and the additions to that you made to the LICENSE file for fonts
should instead be in the NOTICE file.

I checked that there were instructions on how to build in README.md.
Would be useful if it stated which JDKs are supported. I assumed 1.8.

The version number in pom.xml is 0.3.0, should include "incubating",
say 0.3.0-incubating.

My vote:

 [x] -1 Do not release this package because there is no NOTICE file,
and because there are binary files, and because the release does not
build.

Julian

On Sat, Mar 5, 2016 at 9:00 AM, Hao Chen  wrote:
> +1
>
> Thanks very much Hemanth for raising vote for the first release of Eagle.
>
> Regards,
> Hao
>
> On Fri, Mar 4, 2016 at 9:31 PM, arun karthick manoharan <
> aruncarth...@gmail.com> wrote:
>
>> Should this be voted in dev list or private list.
>>
>> +1
>>
>> Thanks Hemanth for your support and guidance.
>>
>> - Arun
>> Sent from my iPhone
>>
>> > On Mar 5, 2016, at 10:31 AM, Edward Zhang 
>> wrote:
>> >
>> > +1
>> >
>> > Thanks for taking care of this first incubator Eagle release, Hemanth.
>> >
>> > Thanks
>> > Edward
>> >
>> > On Fri, Mar 4, 2016 at 7:38 PM, Dendukuri, Hemanth 
>> > wrote:
>> >
>> >> Hi all,
>> >>
>> >>
>> >>   This is the incubator release of Apache Eagle, 0.3.0.
>> >>
>> >>   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/
>> >>
>> >>   The commit to be voted upon:
>> >>
>> https://github.com/apache/incubator-eagle/commit/d9ef76d9756fbf7c8992918b6f99fa2ca4c392fd
>> >>
>> >>   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.tar.gz.md5
>> >> c8d88e11c782e2e88e9909e6dcc0d47e
>> >>
>> >> apache-eagle-0.3.0-incubating-src.tar.gz.sha
>> >> 08640f2041847dd719c72d950ade9ea55a0ca870
>> >>
>> >>
>> >>
>> >>   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 Version.
>> >>
>> >>[ ]  0 I don't feel strongly about it, but I'm okay with the
>> >> release
>> >>
>> >>[ ] -1 Do not release this package because...
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> Hemanth Dendukuri
>> >>
>>

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

Incubation status page

[Julian Hyde]

This from Henri Yandell note prompted me to take a look at Eagle’s incubation 
status page[1]. As Henri notes, the Copyright items have not been signed off as 
complete.

But I suspect there are several tasks that are complete just not signed off. 
What needs to be updated on that page?

Julian


> Begin forwarded message:
> 
> From: Henri Yandell 
> Subject: Copyright sign offs
> Date: February 26, 2016 at 5:28:18 PM PST
> To: gene...@incubator.apache.org
> Reply-To: gene...@incubator.apache.org
> 
> Haven't done this in a while :)
> 
> Thought I'd share that the following podlings have not yet signed off on
> their Copyright sections in their status reports. I mention this because I
> believe it's one of the first elements that should be signed off on the
> status report and it's a worry if projects have not done so:
> 
>  cmda
>  datafu
>  horn
>  johnzon
>  odftoolkit
>  openaz
>  samoa
>  slider
>  streams
>  taverna
> 
> I'd be interested to hear about any reasons why the above aren't able to
> sign that element of their status file off.
> 
> (same, but for those who are < 6 months in the incubator, ie) still working
> on it)
> 
>  beam
>  concerted
>  eagle
>  fineract
>  guacamole
>  iota
>  impala
>  joshua
>  metron
>  milagro
>  rya
>  systemml
>  toree
>  unomi
> 
> Hen

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

It’s worth reading through Calcite’s process, not that you need to follow it, 
but to find out what you don’t know.

  
https://calcite.apache.org/docs/howto.html#publishing-a-release-for-calcite-committers

Julian


> On Jan 22, 2016, at 2:15 PM, Prasad Mujumdar  wrote:
> 
>  ah ok. Thanks! I wasn't aware of the release plugin. will try it out.
> 
> thanks
> Prasad
> 
> 
> On Fri, Jan 22, 2016 at 2:08 PM, Julian Hyde  wrote:
> 
>> You should consider using the maven release plugin. A lot of those steps
>> you describe can be replaced with
>> 
>>  mvn -Papache release:prepare
>>  mvn -Papache release:perform
>> 
>> That said, that can wait until the second release. For the first release,
>> making source tarball (with the requisite LICENSE, NOTICE files, etc.) by
>> any means is acceptable!
>> 
>> Julian
>> 
>> 
>>> On Jan 22, 2016, at 1:50 PM, Prasad Mujumdar 
>> wrote:
>>> 
>>>  Looks like the formatting is bit messed up. My apologies. Hopefully it
>>> will be better formatted on the wiki.
>>> 
>>> thanks
>>> Prasad
>>> 
>>> 
>>> On Fri, Jan 22, 2016 at 1:48 PM, Prasad Mujumdar 
>> wrote:
>>> 
>>>> 
>>>>  @Julian, strong +1 to making release soon. Thanks for bring that up.
>>>> @Ed and @Julien, we did some recent license cleanup (EAGLE-114). Based
>> on
>>>> my experience with other incubating project releases (as Julian
>> mentioned,
>>>> primarily based on Justin's feedback in past) there some work that still
>>>> needed. We EAGLE-115 to tracking that. I will try to prioritize getting
>> a
>>>> patch ready for that.
>>>> 
>>>> Looks like we don't have a 'how to release' page that outlines the
>> release
>>>> steps. Here's a draft that I put together (using some of the existing
>>>> incubator project templates).
>>>> @Ed and @Arun, if one of you could give me access to the wiki, I can
>>>> upload the draft there so that community members can directly edit the
>> page.
>>>> 
>>>> 
>>>> *How to Release*
>>>> 
>>>> This document describes the release process for Apache Eagle release
>> from
>>>> Incubator. This is a working progress document till we have a few
>> releases
>>>> and ironed out the process.
>>>> 
>>>> *Release manager*
>>>> 
>>>> Someone from the community should volunteer to become a release
>>>> manager(RM) and coordinate the release process. The release steps listed
>>>> below will mostly be carried out by the release manager. Ideally this
>>>> person should be a committer or PPMC member, however it should be fine
>> for
>>>> a contributor to take that responsibility with one of the committer or
>> PPMC
>>>> to mentor him/her to make the release.
>>>> 
>>>> The Release Manager (RM) must go through the policy document to
>> understand
>>>> all the tasks and responsibilities of running a release.  Frequently
>> asked
>>>> questions for making Apache releases are available on Releases FAQ
>>>> <http://www.apache.org/dev/release.html>page. Guide to Release
>> Management
>>>> During Incubation
>>>> <
>> http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager>
>> also
>>>> has good information on best practices for releasing artifacts from an
>>>> incubating Apache project.
>>>> 
>>>> 
>>>> 
>>>> *Give a heads up*
>>>> 
>>>> The RM should first create an umbrella issue to create the release and
>>>> then setup a timeline for release branch point. The community should
>> decide
>>>> on the cutoff point for the release branch on the release discussion
>>>> thread.
>>>> 
>>>> To: dev@eagle.incubator.apache.org
>>>> 
>>>> Subject: Work on $release release has started
>>>> 
>>>> 
>>>> Created a tracking jira (jira#) for the eagle $release and plan to
>> branch
>>>> tentatively on $date.
>>>> 
>>>> 
>>>> 
>>>> What would you like to see included?
>>>> 
>>>> Thanks,
>>>> 
>>>> $RM
>>>> 
>>>> *Sanitize JIRA*
>>>> 
>>>>  1. Before a rele

Re: Release?

[Julian Hyde]

   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 
>> 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  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"  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: Release?

[Julian Hyde]

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

Release?

[Julian Hyde]

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

Re: [Proposal] Dynamical Topology Manager

[Julian Hyde]

Can I make a high-level observation? (And, although I’m a mentor of this 
project, I’m not speaking as a mentor, just someone who has built various 
database and streaming systems over the years.)

I’ve noticed that Eagle is taking on several problems that — architecturally 
speaking — should be part of the underlying streaming system. This topology 
manager and also, a DSL declarative streaming queries, and making sure that 
streaming queries continue where they left off, even in the presence of 
failures of individual stream-processing nodes.

These are very hard distributed systems problems, and they are horizontal 
problems that have nothing to do with Eagle’s problem domain (security). It 
would be analogous to an application that is selling concert tickets deciding 
to develop HBase as part of the application.

If the Eagle community wants to solve these problems, that’s awesome, and you 
should go for it. Apache projects are great at pulling in people with diverse 
skills and when they gather momentum they can build some amazing technology. 
But I think Eagle should consider putting more architectural separation between 
your stream management technology and your application. You could do that by 
building separate modules (and testing them independently). Or you could 
contribute the functionality you need to the underlying system (e.g. 
Storm/Nimbus). Your project will run much more smoothly if you call out the 
hard problems you are trying to solve.

And, as a side benefit, projects that have nothing to do with Hadoop security 
will be able to use (and test, and bug-fix) the technology you are developing.

Julian


> On Jan 11, 2016, at 8:57 AM, Hao Chen  wrote:
> 
> Currently eagle is requiring user to manually manage topologies completely
> independent of eagle components,  which is not very smooth for the user and
> management experience end-to-end from on-boarding datasource, starting
> topologies, defining policy and also monitoring policy and execution
> status, so how do you think we manage everything in single place and
> dynamically manage topology lifecycle like
> starting/stopping/status/monitoring as well policy
> creation/modification/monitoring all in eagle ui only? So that user don't
> need to touch storm anymore except specifying where the nimbus is when
> setting up eagle.
> 
> 
> --
> 
> Hao

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 mailto:s...@wso2.com>>
>> Date: Thursday, December 10, 20

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: Eagle New Release.

[Julian Hyde]

I suggest that you use maven to make the release, and that -- for the
first release -- you release from master branch. Maven will make a
tag, and you can branch from that tag after the event.

Have you nominated a release manager? The release manager will need to
"stop traffic" and tell people to stop checking into master until the
release is done.

When you are familiar with the release process you can release from a branch.

On Fri, Dec 4, 2015 at 6:09 PM, Julian Hyde  wrote:
> I strongly suggest that you do not attempt to create a binary release
> at this time. (Binary releases physically include your dependencies,
> so licensing is much more complicated.)
>
> Get the source release right first.
>
> On Fri, Dec 4, 2015 at 4:29 PM, Edward Zhang  wrote:
>> In this case, we want to cut a release branch/tag from master branch, and
>> based on the release branch/tag, we create tarball for source and binary,
>> so community can consistently download the same bits and we can also have a
>> document to describe what we have in this release. Please suggest
>>
>> Thanks
>> Edward
>>
>> On Fri, Dec 4, 2015 at 2:48 PM, Henry Saputra 
>> wrote:
>>
>>> How is it master is not stable enough? Master should be stable and
>>> contains code that should pass all tests.
>>>
>>> Could you elaborate more about proposed dev cycle?
>>>
>>> - Henry
>>>
>>>
>>> On Fri, Dec 4, 2015 at 11:49 AM, Dendukuri, Hemanth 
>>> wrote:
>>> > Hello Eagle Dev,
>>> >
>>> > I noticed that Master branch is not
>>> stable enough for End2End functional testing.
>>> > I see a need to create a new tag to test
>>> and release the new stable eagle version, with the changes that went into
>>> it , since our last release.
>>> > Reply if anyone need time to merge their
>>> new feature or have any other questions regarding this effort.
>>> >
>>> > Regards
>>> > Hemanth
>>> >
>>>

Re: Eagle New Release.

[Julian Hyde]

I strongly suggest that you do not attempt to create a binary release
at this time. (Binary releases physically include your dependencies,
so licensing is much more complicated.)

Get the source release right first.

On Fri, Dec 4, 2015 at 4:29 PM, Edward Zhang  wrote:
> In this case, we want to cut a release branch/tag from master branch, and
> based on the release branch/tag, we create tarball for source and binary,
> so community can consistently download the same bits and we can also have a
> document to describe what we have in this release. Please suggest
>
> Thanks
> Edward
>
> On Fri, Dec 4, 2015 at 2:48 PM, Henry Saputra 
> wrote:
>
>> How is it master is not stable enough? Master should be stable and
>> contains code that should pass all tests.
>>
>> Could you elaborate more about proposed dev cycle?
>>
>> - Henry
>>
>>
>> On Fri, Dec 4, 2015 at 11:49 AM, Dendukuri, Hemanth 
>> wrote:
>> > Hello Eagle Dev,
>> >
>> > I noticed that Master branch is not
>> stable enough for End2End functional testing.
>> > I see a need to create a new tag to test
>> and release the new stable eagle version, with the changes that went into
>> it , since our last release.
>> > Reply if anyone need time to merge their
>> new feature or have any other questions regarding this effort.
>> >
>> > Regards
>> > Hemanth
>> >
>>

Re: December 2015 Report

[Julian Hyde]

Thank you, Arun, for putting together the report at short notice.

I have signed off.

I moved your report up the page, into alphabetical order. (The Eagle
is just before the HAWQ, appropriately! Shame Falcon already
graduated, otherwise we'd have a threesome.)

I also reformatted to the 70 character line length required by the board.

Don't worry about shepherds -- the mentors keep an eye on the project,
and the shephers basically keep an eye on the mentors. :)

For next month's report: I think one of the most important issues is
producing a release. (I know you are working on a release, so you
probably just forgot to mention it because you were writing the report
in a hurry.) Ability to make a release (and associated IP hygiene) is
one of the key skills required for incubation.

Julian


On Fri, Dec 4, 2015 at 5:24 PM, arunkarthick m  wrote:
> Eagle is the last entry in that page. I don't know what's the shepherding
> means.
>
> On Fri, Dec 4, 2015 at 5:06 PM, P. Taylor Goetz  wrote:
>
>> I don't see it here: https://wiki.apache.org/incubator/December2015
>>
>> Where did you post it?
>>
>> -Taylor
>>
>> > On Dec 4, 2015, at 7:22 PM, Arun Manoharan 
>> wrote:
>> >
>> > Hi,
>> >
>> > I have added the report on Eagle with information from bugs/features and
>> > community growth. I used HAWQ as an example.
>> >
>> > Actually going thru other reports i learned how to make progress and what
>> > to focus on.
>> >
>> > Please let me know your comments.
>> >
>> > Thanks,
>> > Arun
>> >
>> >> On Fri, Dec 4, 2015 at 4:04 PM, P. Taylor Goetz 
>> wrote:
>> >>
>> >> And if you have trouble or need more time to put together a meaningful
>> >> report, I thinks it's okay to slide the reporting schedule a month.
>> >>
>> >> I'd rather wait to see a good report than see one that is rushed and
>> less
>> >> than complete.
>> >>
>> >> -Taylor
>> >>
>> >>> On Dec 4, 2015, at 6:57 PM, Julian Hyde  wrote:
>> >>>
>> >>> Great. Sorry for the fire drill - you should have received more notice
>> >> for this.
>> >>>
>> >>> Please let the mentors know when you have written the report, so we
>> >>> can check it over and sign off. (I recommend mailing the mentors
>> >>> directly -- i.e. on the To: list -- to get their attention for report
>> >>> sign off, this month and other months. Of course they SHOULD be
>> >>> reading every message on dev@eagle closely but they are busy people!)
>> >>>
>> >>> I have fixed the podlings.xml metadata file, so you should get timely
>> >>> reminders for subsequent reports in Jan, Feb and May, Aug, etc.
>> >>>
>> >>> Julian
>> >>>
>> >>>
>> >>>> On Fri, Dec 4, 2015 at 3:14 PM, Arun Manoharan <
>> >> arunmanoha...@apache.org> wrote:
>> >>>> Hi Julian,
>> >>>>
>> >>>> I will look at an example and will prepare the first monthly report.
>> >>>>
>> >>>> Thanks,
>> >>>> Arun
>> >>>>
>> >>>>> On Fri, Dec 4, 2015 at 3:06 PM, Julian Hyde 
>> wrote:
>> >>>>>
>> >>>>> 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
>> >>>>>
>> >>>>>
>> >>>>>
>> >

Re: December 2015 Report

[Julian Hyde]

Great. Sorry for the fire drill - you should have received more notice for this.

Please let the mentors know when you have written the report, so we
can check it over and sign off. (I recommend mailing the mentors
directly -- i.e. on the To: list -- to get their attention for report
sign off, this month and other months. Of course they SHOULD be
reading every message on dev@eagle closely but they are busy people!)

I have fixed the podlings.xml metadata file, so you should get timely
reminders for subsequent reports in Jan, Feb and May, Aug, etc.

Julian


On Fri, Dec 4, 2015 at 3:14 PM, Arun Manoharan  wrote:
> Hi Julian,
>
> I will look at an example and will prepare the first monthly report.
>
> Thanks,
> Arun
>
> On Fri, Dec 4, 2015 at 3:06 PM, Julian Hyde  wrote:
>
>> 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: 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&view=planning.nodetail
>  and we plan to start the first sprint next week. 
> RegardsEddy 

[jira] [Commented] (EAGLE-46) track the work before moving code to apache site

[Julian Hyde (JIRA)]

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

Julian Hyde commented on EAGLE-46:
--

I haven't reviewed your changes. If you've addressed the issues I raised (or 
logged tickets for anything not yet addressed), go ahead and close.

> track the work before moving code to apache site
> 
>
> Key: EAGLE-46
> URL: https://issues.apache.org/jira/browse/EAGLE-46
> Project: Eagle
>  Issue Type: New Feature
>Reporter: Edward Zhang
>Assignee: Hao Chen
>
> 1. resolve all existing pull requests
> 2. change version to 0.3.0
> 3. change all package name to prefixed by "org.apache"



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

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

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

[jira] [Commented] (EAGLE-46) track the work before moving code to apache site

[Julian Hyde (JIRA)]

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

Julian Hyde commented on EAGLE-46:
--

I'll add:

4. remove files that are not part of the code donation. (For example, font 
files that are part of your web site and are MIT licensed.) You should add 
these files directly to Apache Eagle, with appropriate changes to 
LICENSE/NOTICE file.

Very soon after moving to apache I encourage you enable apache-rat (add 
apache-rat-plugin to your pom.xml if you are using maven) and run it regularly. 
It will force you to fix things (e.g. license headers at the top of files) that 
you will need to fix before your first release.

> track the work before moving code to apache site
> 
>
> Key: EAGLE-46
> URL: https://issues.apache.org/jira/browse/EAGLE-46
> Project: Eagle
>  Issue Type: New Feature
>Reporter: Edward Zhang
>
> 1. resolve all existing pull requests
> 2. change version to 0.3.0
> 3. change all package name to prefixed by "org.apache"



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

Re: Do all PPMCs get their Apache username created?

[Julian Hyde]

Confirmed: I’m subscribed to dev and private.

> On Nov 17, 2015, at 9:30 PM, Henry Saputra  wrote:
> 
> By subscribe I meant to send email to :
> 
>  dev-subscr...@eagle.incubator.apache.org
>  private-subscr...@eagle.incubator.apache.org
> 
> to subscribe.
> 
> - Henry
> 
> 
> On Tue, Nov 17, 2015 at 8:54 PM, Henry Saputra  
> wrote:
>> Hi,
>> 
>> This is checkpoint to make sure all PPMCs have their Apache username created?
>> 
>> Also please subscribe to priv...@eagle.incubator.apache.org list
>> 
>> - Henry

Re: Github and Site

[Julian Hyde]

See the last comment in
https://issues.apache.org/jira/browse/INFRA-10676. You need to request
github integration by going to infrahelp.apache.org.

On Tue, Nov 17, 2015 at 11:58 AM, Zhang, Edward (GDI Hadoop)
 wrote:
> Thanks Julian. I am now able to create one file in
> https://git-wip-us.apache.org/repos/asf/incubator-eagle.git
>
> But https://github.com/apache/incubator-eagle.git/ is not updated/synced
> from git-wip-us.apache.org. Probably we need some administration work to
> enable sync up between git-wip-us and github.com.
>
> Thanks
> Edward Zhang
>
> On 11/17/15, 11:45, "Julian Hyde"  wrote:
>
>>On Tue, Nov 17, 2015 at 11:30 AM, Zhang, Edward (GDI Hadoop)
>> wrote:
>>> I tried but failed with authentication issue when I committed changes to
>>> incubator/eagle/site. I think Henry is working on enabling checkout for
>>> eagle committers.
>>>
>>> svn: E195023: Changing file
>>> '/Users/yonzhang/projects/apacheeagle/eagle/site/index.html' is
>>>forbidden
>>> by the server
>>> svn: E175013: Access to
>>> '/repos/asf/!svn/txr/1714854-11mpw/incubator/eagle/site/index.html'
>>> forbidden
>>
>>I'm no expert on svn, but the error message is a bit surprising to me.
>>I'd expect the path to be
>>https://svn.apache.org/repos/asf/incubator/eagle/site/.
>>
>>I trust Henry will give us an update when he has one.
>>
>>
>>> Another question is: for source code, do we use git directly or use svn?
>>> Now this page is not accessible.
>>>https://github.com/apache/incubator-eagle
>>
>>Use git. As a committer, you should set up your repo as follows:
>>
>>  git clone https://git-wip-us.apache.org/repos/asf/incubator-eagle.git
>>
>>That will allow you to push to the definitive git repo in Apache.
>>Non-committers can use
>>
>>  git clone https://github.com/apache/incubator-eagle.git
>>
>>because a read-only mirror is sufficient. However, when I try it I get
>>the following:
>>
>>  $ git clone https://git-wip-us.apache.org/repos/asf/incubator-eagle.git
>>eagle
>>  Cloning into 'eagle'...
>>  warning: You appear to have cloned an empty repository.
>>  Checking connectivity... done.
>>
>>So, someone needs to initialize the git repository by checking in a
>>file. Shall I do that?
>>
>>Julian
>

Re: Github and Site

[Julian Hyde]

On Tue, Nov 17, 2015 at 11:30 AM, Zhang, Edward (GDI Hadoop)
 wrote:
> I tried but failed with authentication issue when I committed changes to
> incubator/eagle/site. I think Henry is working on enabling checkout for
> eagle committers.
>
> svn: E195023: Changing file
> '/Users/yonzhang/projects/apacheeagle/eagle/site/index.html' is forbidden
> by the server
> svn: E175013: Access to
> '/repos/asf/!svn/txr/1714854-11mpw/incubator/eagle/site/index.html'
> forbidden

I'm no expert on svn, but the error message is a bit surprising to me.
I'd expect the path to be
https://svn.apache.org/repos/asf/incubator/eagle/site/.

I trust Henry will give us an update when he has one.


> Another question is: for source code, do we use git directly or use svn?
> Now this page is not accessible. https://github.com/apache/incubator-eagle

Use git. As a committer, you should set up your repo as follows:

  git clone https://git-wip-us.apache.org/repos/asf/incubator-eagle.git

That will allow you to push to the definitive git repo in Apache.
Non-committers can use

  git clone https://github.com/apache/incubator-eagle.git

because a read-only mirror is sufficient. However, when I try it I get
the following:

  $ git clone https://git-wip-us.apache.org/repos/asf/incubator-eagle.git eagle
  Cloning into 'eagle'...
  warning: You appear to have cloned an empty repository.
  Checking connectivity... done.

So, someone needs to initialize the git repository by checking in a
file. Shall I do that?

Julian

Re: Github and Site

[Julian Hyde]

I see there's a "hello world" page up. Are committers able to modify that page 
in svn, commit, and see the changes?

If so there is what Henry calls "publish" but what I'd call "page generation". 
Which is simple because it happens in the developer's sandbox. 

Julian

> On Nov 17, 2015, at 08:01, Henry Saputra  wrote:
> 
> I will start adding karma to Eagle committers so you could start
> checking out svn and Git to add code.
> 
> Any specific question about Git?
> 
> As for the website, we are using svn pubsub, meaning everything
> committed to  https://svn.apache.org/repos/asf/incubator/eagle/site
> would be automatically sync and publish to show up at
> eagle.incubator.apache.org.
> For publishing it, we need to figure out the best way to do it. Some
> projects have used Jekyll to translate static doc to HTML and publish
> it to website repo.
> 
> 
> - Henry
> 
> On Tue, Nov 17, 2015 at 7:46 AM, Arun Manoharan
>  wrote:
>> Hi Mentors,
>> 
>> Can you help with the github project for Eagle ? and regarding the site if
>> there is a documentation you can point us to ?
>> 
>> svn for Eagle web site https://svn.apache.org/repos/asf/incubator/eagle and
>> submitted svn pub subs request to INFRA and also add entry to
>> asf-authorization-template.
>> 
>> Thanks,
>> 
>> Arun

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  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  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 :
>> 
>>> 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: Best Practice for Code Collaboration in Apache Way

[Julian Hyde]

I agree on the importance of a clean, readable commit history.

I suggest that you ask contributors to squash and if necessary rebase. The 
committer can re-title the commit to give it a meaningful title.

Some projects incorporate commits via merge but my personal preference is to 
incorporate commits using rebase. You end up with a linear commit history, the 
same effect as sequentially applying patches.

Julian


> On Nov 11, 2015, at 12:43 AM, Hao Chen  wrote:
> 
> Thanks Julian, I think pull request is ok for us. The only concern is the
> commit history may not very clean and meaningful.
> 
> Regards,
> Hao
> 
> 
> On Wed, Nov 11, 2015 at 3:08 AM, Julian Hyde  wrote:
> 
>> 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: 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