I have edit permissions so will update it tonight.
> On Apr 6, 2016, at 4:12 AM, Sean Zhong <[email protected]> wrote: > > @Andrew, > > Should I post it to http://wiki.apache.org/incubator/April2016 myself? > >> On Wed, Apr 6, 2016 at 6:14 PM, Vincent Wang <[email protected]> wrote: >> >> +1 >> >> Best regards >> Vincent Wang >> >> 2016-04-06 17:58 GMT+08:00 Xu, Qian <[email protected]>: >> >>> +1 for the proposal. >>> >>> And regarding to grow up an active community, I'm strongly agree with >>> having a *well designed code convention*, so that the code will be very >>> easy to read and maintain. and also remove existing tricky code. >>> >>>> On Wed, Apr 6, 2016 at 11:04 AM, Sean Zhong <[email protected]> wrote: >>>> >>>> Hi All, >>>> >>>> Andy make it clear that the list of three things can "*evolve over >>> time*", >>>> and the readers are board members who don't understand the details. We >>>> should use *different terms* to describe "*our view of progress*", and >>>> "*board >>>> members'* *view*". And the link Andy gave is very informative >> http://community.apache.org/apache-way/apache-project-maturity-model.html, >>>> let's use it as a major reference: >>>> >>>> For Kam's option on long term roadmap and vision, I think we can put it >>>> under umbrella of website building. >>>> >>>> After consolidating the outputs above, in my opinion, here are the >> three >>>> important things in *ONE MONTH's *time frame (As this is a monthly >>> report): >>>> >>>> 1. Make initial *Apache branded release*, things to fix: >>>> a. Importing code to Apache Git is still blocked by INFRA-11435 >>>> <https://issues.apache.org/jira/browse/INFRA-11435> >>>> b. Fix code style and code quality to align with Apache practice >>>> GEARPUMP-11 <https://issues.apache.org/jira/browse/GEARPUMP-11> >>>> c. Request maven artifact id OSSRH-21642 >>>> <https://issues.sonatype.org/browse/OSSRH-21642> >>>> >>>> 2. *Initial community process definition *and practice enforcement by >>>> *following >>>> Apache policies*, things to fix: >>>> a. Define and document code style guide. (GEAPUMP-12 >>>> <https://issues.apache.org/jira/browse/GEARPUMP-12>) >>>> b. Define and document process to make contributions, voting rule, >> and >>>> make releases. And also how we response to community questions in a >>> timely >>>> manner. (GEARPUMP-13 < >> https://issues.apache.org/jira/browse/GEARPUMP-13 >>>> ) >>>> c. Get familiar with and practice with "transparency" and >> "Consensus" >>>> rules, use the PMC maillist and Dev maillist as the main channel for >>>> big decisions. >>>> >>>> 3. *Build the first Apache branded Informative website* to make >> Gearpump >>>> contributor and end-user friendly. >>>> a. Find out where to place the website. >>>> b. Define a slogan for Gearpump (From Kam: Develop a tag line that >>>> describes gearpump) >>>> c. Work out the website with Apache logo, and meet quality >> criteria. ( >>>> GEARPUMP-15 <https://issues.apache.org/jira/browse/GEARPUMP-15>) >>>> d. On the website, document *milestones*, *roadmaps*, *release >>>> calendars*. >>>> Of course it requires a consensus from the community first. >> (GEARPUMP-16 >>>> <https://issues.apache.org/jira/browse/GEARPUMP-16>) >>>> >>>> >>>> The list satisfy your expectations? Please advice. >>>> >>>> Sean >>>> >>>> >>>> On Wed, Apr 6, 2016 at 8:35 AM, Andrew Purtell <[email protected]> >>>> wrote: >>>> >>>>>> How uniform are apache projects in terms of documentation >> structure, >>>>> release, roadmap, etc? >>>>> >>>>> Not uniform. The Foundation provides some developer tooling and is >>>>> prescriptive on project governance, IP provenance, and release >>>>> requirements, but there's so much more involved with producing >>> software. >>>> To >>>>> help you figure out what the Foundation cares about you might want to >>>> poke >>>>> around http://community.apache.org/ and consider >> http://community.apache.org/apache-way/apache-project-maturity-model.html >>>>> - >>>>> although note that maturity model is not an official yardstick. >>>>> >>>>>> I imagine ASF members use both github and JIRA to ascertain a >>> project's >>>>> health. >>>>> >>>>> Yes, but I used the word 'measure' instead of 'metric' because >>> evaluation >>>>> is more qualitative than quantitative. Abiding by policy is good. >>> Making >>>>> releases is good. Inducting new committers and PMC every so often is >>>> good. >>>>> Long periods without such things is not good. Producing releases of >>> poor >>>>> quality or contrary to policy is not good. >>>>> >>>>>> Do ASF members receive summary reports showing trending of >>>> contributors, >>>>> issues, releases, etc (if not it seems like they should)? >>>>> >>>>> There is a reporting tool available to Members and PMC Chairs that >>> rolls >>>> up >>>>> some of this information. Many chairs use it when writing up reports >> to >>>> the >>>>> Board. Podlings don't have access AFAIK. >>>>> >>>>> >>>>> >>>>>> On Tue, Apr 5, 2016 at 4:31 PM, Kam Kasravi <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Andy >>>>>> >>>>>> How uniform are apache projects in terms of documentation >> structure, >>>>>> release, roadmap, etc? >>>>>> Is an apache goal one where for example, one browse to each project >>>>>> >>>>>> http://spark.apache.org/ >>>>>> http://kafka.apache.org/ >>>>>> http://storm.apache.org/ >>>>>> http://hbase.apache.org/ >>>>>> http://bigtop.apache.org/ >>>>>> ... >>>>>> >>>>>> and expect to find certain links in common? >>>>>> For example - pointers to ASF, download links, ... >>>>>> >>>>>> This doesn't seem to be the case. Each project has its own style of >>>> html >>>>>> and way of introducing the interested user to the project. >>>>>> >>>>>> Given each project has it's own style in introducing what the >> project >>>> is >>>>>> about, >>>>>> I imagine ASF members use both github and JIRA to ascertain a >>> project's >>>>>> health. >>>>>> >>>>>> That is - it's fairly easy to go to the following github links >>>>>> https://github.com/apache/spark >>>>>> https://github.com/apache/kafka >>>>>> https://github.com/apache/storm >>>>>> https://github.com/apache/hbase >>>>>> https://github.com/apache/bigtop >>>>>> >>>>>> and get a sense of forks, favorites, stars, contributors. >>>>>> In the same way - going to JIRA - one could get a sense of issues >>> burn >>>>>> down, release schedule etc. >>>>>> There's also probably a way to judge a given projects usage within >>>> other >>>>>> ASF projects if you were to cull >>>>>> maven dependency information. >>>>>> >>>>>> Both github and JIRA have good API's. Do ASF members receive >> summary >>>>>> reports showing >>>>>> trending of contributors, issues, releases, etc (if not it seems >> like >>>>> they >>>>>> should)? >>>>>> >>>>>> For Gearpump, we certainly want to progress along accepted criteria >>> ASF >>>>>> uses to judge health. >>>>>> I think we also want to focus (based on the teams comments) on >> making >>>>>> areas of contribution crystal clear, >>>>>> with easy ways to onboard a developer. This will also imply very >>> clear >>>>>> roadmaps and >>>>>> establishing a predictable release cadence. Judging from some of >> the >>>> more >>>>>> popular projects, it looks like >>>>>> the committers take great care in providing a 'getting started' >> page. >>>>>> >>>>>> http://beam.apache.org/getting_started/ >>>>>> http://spark.apache.org/docs/latest/quick-start.html >> https://ci.apache.org/projects/flink/flink-docs-release-1.0/quickstart/setup_quickstart.html >>>>>> http://hbase.apache.org/book.html#quickstart >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, April 5, 2016 2:10 PM, Andrew Purtell < >>> [email protected] >>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> This is great. >>>>>> >>>>>> Note the list of three things can evolve over time as the podling >>> makes >>>>>> progress. >>>>>> >>>>>> In my opinion, the most important thing an Apache project can do is >>>>>> release software. While it is true there is a mantra here which >> goes >>>>>> "community over code", communities need code around which to form. >>>>>> Therefore I submit to you that the most important task the Gearpump >>>>> podling >>>>>> can currently accomplish is an Apache branded release of the >> Gearpump >>>>> code, >>>>>> conforming to our release and IP policies. >>>>>> >>>>>> Also, for what it's worth, consider at the Foundation level there >> are >>>>> ~280 >>>>>> projects and ~40 podlings, each with their own specific set of >>>> technical >>>>>> issues and goals, of which the Board and Membership cannot possibly >>>>>> understand all in detail. Try to place yourself in such an >> oversight >>>> role >>>>>> and think about how you would judge the health of any given >> project. >>>> What >>>>>> measures would you consider? Community building? Policy >> conformance? >>>>>> Releasing? Governance? >>>>>> >>>>>> Anyway I await the outcome of your discussion oh _the_ list of >> three >>>>>> things for tomorrow's report. >>>>>> >>>>>> >>>>>>> On Tue, Apr 5, 2016 at 9:03 AM, Kam Kasravi <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Three most important issues to address in the move towards >>> graduation: >>>>>> >>>>>> 1. Develop a tag line that describes gearpump. For example others >>>>>> - Apache Flink is an open source platform for distributed stream >>> and >>>>>> batch data processing >>>>>> >>>>>> - Apache Spark™ is a fast and general engine for large-scale data >>>>>> processing >>>>>> >>>>>> - Apache Storm is a free and open source distributed realtime >>>>>> computation system. >>>>>> >>>>>> - Apache Beam is an open source, unified model and set of >>>>>> language-specific SDKs for defining data processing workflows that >>> may >>>>> then >>>>>> be executed on top of a set of supported runners >>>>>> >>>>>> 2. Focus on use cases that leverage akka strengths (location >>>>>> transparency, remoting, code provisioning, dynamic deployment) >>>>>> 3. Target areas within apache ecosystem where gearpump can >> provide >>>>>> significant value. >>>>>> - Many real time data processing engines are exploring reusable >>>>>> pipelines including spark (ml pipelines), akka-streams (blueprints) >>>>>> - Other real time data processing engines are targeting a common >>>> data >>>>>> model DSL which allows different execution engines (apache beam and >>>>>> 'runners') >>>>>> >>>>>> Show original message >>>>>> >>>>>> >>>>>> On Tuesday, April 5, 2016 8:51 AM, Kam Kasravi >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> Three most important issues to address in the move towards >>> graduation: >>>>>> >>>>>> 1. Develop a tag line that describes gearpump. For example others >>>>>> - Apache Flink is an open source platform for distributed stream >>> and >>>>>> batch data processing >>>>>> >>>>>> - Apache Spark™ is a fast and general engine for large-scale data >>>>>> processing >>>>>> >>>>>> - Apache Storm is a free and open source distributed realtime >>>>>> computation system. >>>>>> >>>>>> - Apache Beam is an open source, unified model and set of >>>>>> language-specific SDKs for defining data processing workflows that >>> may >>>>> then >>>>>> be executed on top of a set of supported runners >>>>>> >>>>>> >>>>>> >>>>>> 2. Focus on use cases that leverage akka strengths (location >>>>>> transparency, remoting, code provisioning, dynamic deployment) >>>>>> 3. Target areas within apache ecosystem where gearpump can >> provide >>>>>> significant value. >>>>>> >>>>>> >>>>>> On Tuesday, April 5, 2016 1:06 AM, Weihua Jiang < >>>> [email protected] >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> I agree with Sean and Vincent. >>>>>> >>>>>> To graduate, we need to create a healthy community. To me, a >> healthy >>>>>> community has: >>>>>> 1. Enough contributors who actively contribute to this project. >>>>>> 2. Enough users who actively using this project in their >> environment. >>>> And >>>>>> they are willing to interact with community for issues and >> features. >>>>> Their >>>>>> requests can be handled in a timely way. >>>>>> >>>>>> So, to me, pre-conditions to graduation shall include: >>>>>> 1. Fully follow Apache project best practices. That is, doc style, >>>>>> process, releases etc. And it is better to have 2 or more releases >>>> before >>>>>> graduation to get everyone familiar with the new process. >>>>>> 2. Code quality. It is better if we can meet certain code quality >>>> metrics >>>>>> before graduation and integrated in Apache infrastructure. E.g. >> Code >>>>>> coverage, auto-checkin test, etc. >>>>>> 3. Contributor friendly as Sean mentioned. >>>>>> 4. User friendly as Vincent mentioned. >>>>>> >>>>>> >>>>>> >>>>>> 在 16/4/5 下午3:08，“Vincent Wang”<[email protected]> 写入: >>>>>> >>>>>>> Hi Xiang, >>>>>>> >>>>>>> I think your third point is kind of related to the first one. We >>>> should >>>>>>> also reduce the challenges for the users who want to try Gearpump, >>>>> better >>>>>>> documentations, easy-to-use API and more external connectors. >>>>>>> >>>>>>> Thanks, >>>>>>> Huafeng >>>>>>> >>>>>>> Best regards >>>>>>> Vincent Wang >>>>>>> >>>>>>> 2016-04-05 14:14 GMT+08:00 Sean Zhong <[email protected]>: >>>>>>> >>>>>>>> Here is my thoughts about pre-condition for graduation: >>>>>>>> >>>>>>>> 1. We should setup the environment to reduce the challenges for >>> new >>>>>>>> contributors to make contribution. Currently, it is not very >> easy >>>> for >>>>>> new >>>>>>>> developer to make contribution, we need a environment like this: >>>>>>>> a. Document clearly on contribution process so that new >>> developer >>>>>> know >>>>>>>> exactly how to submit an issue, a PR, and ... >>>>>>>> b. Better and more documents to walk new developers through >> to >>>> help >>>>>> them >>>>>>>> better understand Gearpump without spending too many time on >>> source >>>>>> code. >>>>>>>> c. Clearly identity the scenarios that Gearpump works best, >> and >>>> why >>>>>>>> Gearpump is good at this. >>>>>>>> d. Have a clear document on the milestone, and the timeline, >> so >>>>> that >>>>>> the >>>>>>>> community can form a consensus on what is coming next. >>>>>>>> e. Gradually form a convention of SLA for issues and >> questions. >>>> The >>>>>>>> committers need to take ownership so that all issues and >> questions >>>> are >>>>>>>> taken care in a timely manner. >>>>>>>> f. Move project discussions offline to online, and publish >> them >>>> on >>>>>> the >>>>>>>> mail list. >>>>>>>> >>>>>>>> The goal is to serve new contributors best so that they feel it >> is >>>>> easy >>>>>> to >>>>>>>> get started, and be comfortable in the community. >>>>>>>> >>>>>>>> 2. More examination and adoption on various use cases by >> different >>>>>>>> companies. We need more examinations in real production clusters >>> of >>>>> huge >>>>>>>> size, and having complex network environment. >>>>>>>> >>>>>>>> 3. A busy and noisy user community and developer community. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 5, 2016 at 11:01 AM, Sean Zhong <[email protected] >>> >>>>> wrote: >>>>>>>> >>>>>>>>> Hi Andrew, >>>>>>>>> >>>>>>>>> Got it! Let's discuss it here. >>>>>>>>> >>>>>>>>> On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell < >>>>>> [email protected] >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sure. >>>>>>>>>> >>>>>>>>>> If by 'collect thoughts' you mean yourself spending time to >>>> think, >>>>>>>> great. >>>>>>>>>> >>>>>>>>>> If by 'collect thoughts' you mean to talk with others on the >>>>> project >>>>>>>>>> before replying with a summary or conclusion, let me >> recommend >>>> not >>>>>> doing >>>>>>>>>> that and instead have that discussion here on dev@. >>>>>>>>>> >>>>>>>>>>> On Apr 2, 2016, at 5:39 AM, Sean Zhong <[email protected] >>> >>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Thanks, Andrew, >>>>>>>>>>> >>>>>>>>>>> Let me collect some thoughts before replying you. >>>>>>>>>>> >>>>>>>>>>>> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell < >>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Greetings ..., >>>>>>>>>>>> >>>>>>>>>>>> (What should be the nickname for your community? >>> Gearpumpers? >>>>>>>>>> Gearheads? >>>>>>>>>>>> (smile) ) >>>>>>>>>>>> >>>>>>>>>>>> It's time to file the first podling status report, due up >> on >>>>>>>>>>>> http://wiki.apache.org/incubator/April2016 by April 6, >> this >>>>>> coming >>>>>>>>>>>> Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> I have started a draft for you. Let me ask you: What do >> you >>>>> think >>>>>> are >>>>>>>>>> the >>>>>>>>>>>> three most important issues for you to address before >>>>> graduation? >>>>>> I >>>>>>>>>> left >>>>>>>>>>>> that blank. If you would like to see additional changes in >>> the >>>>>>>> report, >>>>>>>>>>>> please discuss. >>>>>>>>>>>> >>>>>>>>>>>> Gearpump >>>>>>>>>>>> >>>>>>>>>>>> Gearpump is a reactive real-time streaming engine based on >>> the >>>>>>>>>>>> micro-service >>>>>>>>>>>> Actor model. >>>>>>>>>>>> >>>>>>>>>>>> Gearpump has been incubating since 2016-03-08. >>>>>>>>>>>> >>>>>>>>>>>> Three most important issues to address in the move towards >>>>>>>> graduation: >>>>>>>>>>>> >>>>>>>>>>>> 1. >>>>>>>>>>>> 2. >>>>>>>>>>>> 3. >>>>>>>>>>>> >>>>>>>>>>>> Any issues that the Incubator PMC (IPMC) or ASF Board >>>> wish/need >>>>>> to be >>>>>>>>>>>> aware of? >>>>>>>>>>>> >>>>>>>>>>>> The rights holder of the Gearpump copyright filed a CCLA >>>>>> including a >>>>>>>>>>>> Schedule B granting the Gearpump codebase to the >> Foundation. >>>> We >>>>>> are >>>>>>>>>>>> awaiting assistance from Infrastructure on INFRA-11435 to >>>>> perform >>>>>> the >>>>>>>>>>>> import. >>>>>>>>>>>> >>>>>>>>>>>> How has the community developed since the last report? >>>>>>>>>>>> >>>>>>>>>>>> All of the initial committers/PPMC have set up with Apache >>>>>> accounts >>>>>>>> and >>>>>>>>>>>> Apache JIRA accounts. >>>>>>>>>>>> >>>>>>>>>>>> Discussion among developers has started on >>>>>>>>>>>> [email protected] >>>>>>>>>>>> >>>>>>>>>>>> How has the project developed since the last report? >>>>>>>>>>>> >>>>>>>>>>>> The JIRA for the podling is active at >>>>>>>>>>>> https://issues.apache.org/jira/browse/GEARPUMP and seeing >>>>>> activity. >>>>>>>>>>>> >>>>>>>>>>>> Date of last release: >>>>>>>>>>>> >>>>>>>>>>>> No release yet. >>>>>>>>>>>> >>>>>>>>>>>> When were the last committers or PMC members elected? >>>>>>>>>>>> >>>>>>>>>>>> No new committers or PMC members elected yet. >>>>>>>>>>>> >>>>>>>>>>>> <<< >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Best regards, >>>>>>>>>>>> >>>>>>>>>>>> - Andy >>>>>>>>>>>> >>>>>>>>>>>> Problems worthy of attack prove their worth by hitting >>> back. - >>>>>> Piet >>>>>>>>>> Hein >>>>>>>>>>>> (via Tom White) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> >>>>>> - Andy >>>>>> >>>>>> Problems worthy of attack prove their worth by hitting back. - Piet >>>> Hein >>>>>> (via Tom White) >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> >>>>> - Andy >>>>> >>>>> Problems worthy of attack prove their worth by hitting back. - Piet >>> Hein >>>>> (via Tom White) >>> >>> >>> >>> -- >>> Qian Xu (Stanley) >>> _______________________________________________________________________ >>> >>> This e-mail may contain confidential material for the sole use of the >>> intended recipient(s). Any review or distribution by others is strictly >>> prohibited. If you are not the intended recipient, please contact the >>> sender and delete all copies. >>
