You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@gearpump.apache.org by Andrew Purtell <ap...@apache.org> on 2016/04/01 19:59:28 UTC
Podling status report - draft v1
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 dev@gearpump.incubator.apache.org
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)
Re: Podling status report - draft v1
Posted by Kam Kasravi <ka...@yahoo.com.INVALID>.
+1
Sent from my iPad
> On Apr 5, 2016, at 8:04 PM, Sean Zhong <cl...@gmail.com> 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
> b. Fix code style and code quality to align with Apache practice GEARPUMP-11
> c. Request maven artifact id 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)
> 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)
> 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)
> d. On the website, document milestones, roadmaps, release calendars. Of course it requires a consensus from the community first. (GEARPUMP-16)
>
>
> The list satisfy your expectations? Please advice.
>
> Sean
>
>
>> On Wed, Apr 6, 2016 at 8:35 AM, Andrew Purtell <ap...@apache.org> 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 <ka...@yahoo.com> 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 <ap...@apache.org>
>> > 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 <ka...@gmail.com> 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
>> > <ka...@yahoo.com.INVALID> 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 <wh...@outlook.com>
>> > 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”<fv...@gmail.com> 写入:
>> >
>> > >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 <cl...@gmail.com>:
>> > >
>> > >> 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 <cl...@gmail.com> wrote:
>> > >>
>> > >> > Hi Andrew,
>> > >> >
>> > >> > Got it! Let's discuss it here.
>> > >> >
>> > >> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
>> > andrew.purtell@gmail.com
>> > >> >
>> > >> > 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 <cl...@gmail.com> wrote:
>> > >> >> >
>> > >> >> > Thanks, Andrew,
>> > >> >> >
>> > >> >> > Let me collect some thoughts before replying you.
>> > >> >> >
>> > >> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
>> > apurtell@apache.org>
>> > >> >> 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
>> > >> >> >> dev@gearpump.incubator.apache.org
>> > >> >> >>
>> > >> >> >> 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)
>
Re: Podling status report - draft v1
Posted by Weihua Jiang <wh...@outlook.com>.
+1.
在 16/4/6 上午11:04，“Sean Zhong”<cl...@gmail.com> 写入:
>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 <ap...@apache.org> 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 <ka...@yahoo.com> 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 <ap...@apache.org>
>> > 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 <ka...@gmail.com>
>> 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
>> > <ka...@yahoo.com.INVALID> 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 <whjiang@outlook.com
>> >
>> > 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”<fv...@gmail.com> 写入:
>> >
>> > >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 <cl...@gmail.com>:
>> > >
>> > >> 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 <cl...@gmail.com>
>> wrote:
>> > >>
>> > >> > Hi Andrew,
>> > >> >
>> > >> > Got it! Let's discuss it here.
>> > >> >
>> > >> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
>> > andrew.purtell@gmail.com
>> > >> >
>> > >> > 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 <cl...@gmail.com>
>> wrote:
>> > >> >> >
>> > >> >> > Thanks, Andrew,
>> > >> >> >
>> > >> >> > Let me collect some thoughts before replying you.
>> > >> >> >
>> > >> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
>> > apurtell@apache.org>
>> > >> >> 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
>> > >> >> >> dev@gearpump.incubator.apache.org
>> > >> >> >>
>> > >> >> >> 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)
>>
Re: Podling status report - draft v1
Posted by Sean Zhong <cl...@gmail.com>.
Thanks, Andy!
On Thu, Apr 7, 2016 at 12:18 AM, Andrew Purtell <an...@gmail.com>
wrote:
> I have edit permissions so will update it tonight.
>
> > On Apr 6, 2016, at 4:12 AM, Sean Zhong <cl...@gmail.com> 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 <fv...@gmail.com>
> wrote:
> >>
> >> +1
> >>
> >> Best regards
> >> Vincent Wang
> >>
> >> 2016-04-06 17:58 GMT+08:00 Xu, Qian <sx...@googlemail.com>:
> >>
> >>> +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 <cl...@gmail.com>
> 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 <ap...@apache.org>
> >>>> 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 <ka...@yahoo.com>
> >>>>> 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 <
> >>> apurtell@apache.org
> >>>>>
> >>>>>> 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 <ka...@gmail.com>
> >>>>>> 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
> >>>>>> <ka...@yahoo.com.INVALID> 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 <
> >>>> whjiang@outlook.com
> >>>>>>
> >>>>>> 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”<fv...@gmail.com> 写入:
> >>>>>>
> >>>>>>> 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 <cl...@gmail.com>:
> >>>>>>>
> >>>>>>>> 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 <clockfly@gmail.com
> >>>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Andrew,
> >>>>>>>>>
> >>>>>>>>> Got it! Let's discuss it here.
> >>>>>>>>>
> >>>>>>>>> On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
> >>>>>> andrew.purtell@gmail.com
> >>>>>>>>>
> >>>>>>>>> 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 <clockfly@gmail.com
> >>>
> >>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks, Andrew,
> >>>>>>>>>>>
> >>>>>>>>>>> Let me collect some thoughts before replying you.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
> >>>>>> apurtell@apache.org>
> >>>>>>>>>> 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
> >>>>>>>>>>>> dev@gearpump.incubator.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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.
> >>
>
Re: Podling status report - draft v1
Posted by Andrew Purtell <an...@gmail.com>.
I have edit permissions so will update it tonight.
> On Apr 6, 2016, at 4:12 AM, Sean Zhong <cl...@gmail.com> 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 <fv...@gmail.com> wrote:
>>
>> +1
>>
>> Best regards
>> Vincent Wang
>>
>> 2016-04-06 17:58 GMT+08:00 Xu, Qian <sx...@googlemail.com>:
>>
>>> +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 <cl...@gmail.com> 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 <ap...@apache.org>
>>>> 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 <ka...@yahoo.com>
>>>>> 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 <
>>> apurtell@apache.org
>>>>>
>>>>>> 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 <ka...@gmail.com>
>>>>>> 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
>>>>>> <ka...@yahoo.com.INVALID> 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 <
>>>> whjiang@outlook.com
>>>>>>
>>>>>> 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”<fv...@gmail.com> 写入:
>>>>>>
>>>>>>> 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 <cl...@gmail.com>:
>>>>>>>
>>>>>>>> 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 <clockfly@gmail.com
>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Andrew,
>>>>>>>>>
>>>>>>>>> Got it! Let's discuss it here.
>>>>>>>>>
>>>>>>>>> On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
>>>>>> andrew.purtell@gmail.com
>>>>>>>>>
>>>>>>>>> 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 <clockfly@gmail.com
>>>
>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Andrew,
>>>>>>>>>>>
>>>>>>>>>>> Let me collect some thoughts before replying you.
>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
>>>>>> apurtell@apache.org>
>>>>>>>>>> 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
>>>>>>>>>>>> dev@gearpump.incubator.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>
Re: Podling status report - draft v1
Posted by Sean Zhong <cl...@gmail.com>.
@Andrew,
Should I post it to http://wiki.apache.org/incubator/April2016 myself?
On Wed, Apr 6, 2016 at 6:14 PM, Vincent Wang <fv...@gmail.com> wrote:
> +1
>
> Best regards
> Vincent Wang
>
> 2016-04-06 17:58 GMT+08:00 Xu, Qian <sx...@googlemail.com>:
>
> > +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 <cl...@gmail.com> 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 <ap...@apache.org>
> > > 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 <ka...@yahoo.com>
> > > 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 <
> > apurtell@apache.org
> > > >
> > > > > 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 <ka...@gmail.com>
> > > > 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
> > > > > <ka...@yahoo.com.INVALID> 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 <
> > > whjiang@outlook.com
> > > > >
> > > > > 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”<fv...@gmail.com> 写入:
> > > > >
> > > > > >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 <cl...@gmail.com>:
> > > > > >
> > > > > >> 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 <clockfly@gmail.com
> >
> > > > wrote:
> > > > > >>
> > > > > >> > Hi Andrew,
> > > > > >> >
> > > > > >> > Got it! Let's discuss it here.
> > > > > >> >
> > > > > >> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
> > > > > andrew.purtell@gmail.com
> > > > > >> >
> > > > > >> > 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 <clockfly@gmail.com
> >
> > > > wrote:
> > > > > >> >> >
> > > > > >> >> > Thanks, Andrew,
> > > > > >> >> >
> > > > > >> >> > Let me collect some thoughts before replying you.
> > > > > >> >> >
> > > > > >> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
> > > > > apurtell@apache.org>
> > > > > >> >> 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
> > > > > >> >> >> dev@gearpump.incubator.apache.org
> > > > > >> >> >>
> > > > > >> >> >> 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.
> >
>
Re: Podling status report - draft v1
Posted by Vincent Wang <fv...@gmail.com>.
+1
Best regards
Vincent Wang
2016-04-06 17:58 GMT+08:00 Xu, Qian <sx...@googlemail.com>:
> +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 <cl...@gmail.com> 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 <ap...@apache.org>
> > 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 <ka...@yahoo.com>
> > 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 <
> apurtell@apache.org
> > >
> > > > 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 <ka...@gmail.com>
> > > 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
> > > > <ka...@yahoo.com.INVALID> 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 <
> > whjiang@outlook.com
> > > >
> > > > 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”<fv...@gmail.com> 写入:
> > > >
> > > > >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 <cl...@gmail.com>:
> > > > >
> > > > >> 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 <cl...@gmail.com>
> > > wrote:
> > > > >>
> > > > >> > Hi Andrew,
> > > > >> >
> > > > >> > Got it! Let's discuss it here.
> > > > >> >
> > > > >> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
> > > > andrew.purtell@gmail.com
> > > > >> >
> > > > >> > 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 <cl...@gmail.com>
> > > wrote:
> > > > >> >> >
> > > > >> >> > Thanks, Andrew,
> > > > >> >> >
> > > > >> >> > Let me collect some thoughts before replying you.
> > > > >> >> >
> > > > >> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
> > > > apurtell@apache.org>
> > > > >> >> 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
> > > > >> >> >> dev@gearpump.incubator.apache.org
> > > > >> >> >>
> > > > >> >> >> 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.
>
Re: Podling status report - draft v1
Posted by "Xu, Qian" <sx...@googlemail.com>.
+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 <cl...@gmail.com> 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 <ap...@apache.org>
> 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 <ka...@yahoo.com>
> 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 <apurtell@apache.org
> >
> > > 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 <ka...@gmail.com>
> > 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
> > > <ka...@yahoo.com.INVALID> 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 <
> whjiang@outlook.com
> > >
> > > 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”<fv...@gmail.com> 写入:
> > >
> > > >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 <cl...@gmail.com>:
> > > >
> > > >> 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 <cl...@gmail.com>
> > wrote:
> > > >>
> > > >> > Hi Andrew,
> > > >> >
> > > >> > Got it! Let's discuss it here.
> > > >> >
> > > >> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
> > > andrew.purtell@gmail.com
> > > >> >
> > > >> > 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 <cl...@gmail.com>
> > wrote:
> > > >> >> >
> > > >> >> > Thanks, Andrew,
> > > >> >> >
> > > >> >> > Let me collect some thoughts before replying you.
> > > >> >> >
> > > >> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
> > > apurtell@apache.org>
> > > >> >> 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
> > > >> >> >> dev@gearpump.incubator.apache.org
> > > >> >> >>
> > > >> >> >> 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.
Re: Podling status report - draft v1
Posted by Sean Zhong <cl...@gmail.com>.
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 <ap...@apache.org> 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 <ka...@yahoo.com> 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 <ap...@apache.org>
> > 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 <ka...@gmail.com>
> 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
> > <ka...@yahoo.com.INVALID> 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 <whjiang@outlook.com
> >
> > 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”<fv...@gmail.com> 写入:
> >
> > >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 <cl...@gmail.com>:
> > >
> > >> 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 <cl...@gmail.com>
> wrote:
> > >>
> > >> > Hi Andrew,
> > >> >
> > >> > Got it! Let's discuss it here.
> > >> >
> > >> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
> > andrew.purtell@gmail.com
> > >> >
> > >> > 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 <cl...@gmail.com>
> wrote:
> > >> >> >
> > >> >> > Thanks, Andrew,
> > >> >> >
> > >> >> > Let me collect some thoughts before replying you.
> > >> >> >
> > >> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
> > apurtell@apache.org>
> > >> >> 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
> > >> >> >> dev@gearpump.incubator.apache.org
> > >> >> >>
> > >> >> >> 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)
>
Re: Podling status report - draft v1
Posted by Andrew Purtell <ap...@apache.org>.
> 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 <ka...@yahoo.com> 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 <ap...@apache.org>
> 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 <ka...@gmail.com> 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
> <ka...@yahoo.com.INVALID> 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 <wh...@outlook.com>
> 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”<fv...@gmail.com> 写入:
>
> >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 <cl...@gmail.com>:
> >
> >> 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 <cl...@gmail.com> wrote:
> >>
> >> > Hi Andrew,
> >> >
> >> > Got it! Let's discuss it here.
> >> >
> >> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
> andrew.purtell@gmail.com
> >> >
> >> > 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 <cl...@gmail.com> wrote:
> >> >> >
> >> >> > Thanks, Andrew,
> >> >> >
> >> >> > Let me collect some thoughts before replying you.
> >> >> >
> >> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
> apurtell@apache.org>
> >> >> 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
> >> >> >> dev@gearpump.incubator.apache.org
> >> >> >>
> >> >> >> 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)
Re: Podling status report - draft v1
Posted by Kam Kasravi <ka...@yahoo.com.INVALID>.
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 linkshttps://github.com/apache/sparkhttps://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 <ap...@apache.org> 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 <ka...@gmail.com> 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 <ka...@yahoo.com.INVALID> 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 <wh...@outlook.com> 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”<fv...@gmail.com> 写入:
>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 <cl...@gmail.com>:
>
>> 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 <cl...@gmail.com> wrote:
>>
>> > Hi Andrew,
>> >
>> > Got it! Let's discuss it here.
>> >
>> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <andrew.purtell@gmail.com
>> >
>> > 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 <cl...@gmail.com> wrote:
>> >> >
>> >> > Thanks, Andrew,
>> >> >
>> >> > Let me collect some thoughts before replying you.
>> >> >
>> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <ap...@apache.org>
>> >> 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
>> >> >> dev@gearpump.incubator.apache.org
>> >> >>
>> >> >> 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)
Re: Podling status report - draft v1
Posted by Andrew Purtell <ap...@apache.org>.
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 <ka...@gmail.com> 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
> <ka...@yahoo.com.INVALID> 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 <wh...@outlook.com>
> 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”<fv...@gmail.com> 写入:
>
> >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 <cl...@gmail.com>:
> >
> >> 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 <cl...@gmail.com> wrote:
> >>
> >> > Hi Andrew,
> >> >
> >> > Got it! Let's discuss it here.
> >> >
> >> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <
> andrew.purtell@gmail.com
> >> >
> >> > 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 <cl...@gmail.com> wrote:
> >> >> >
> >> >> > Thanks, Andrew,
> >> >> >
> >> >> > Let me collect some thoughts before replying you.
> >> >> >
> >> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <
> apurtell@apache.org>
> >> >> 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
> >> >> >> dev@gearpump.incubator.apache.org
> >> >> >>
> >> >> >> 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)
Re: Podling status report - draft v1
Posted by Kam Kasravi <ka...@gmail.com>.
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 <ka...@yahoo.com.INVALID> 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 <wh...@outlook.com> 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”<fv...@gmail.com> 写入:
>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 <cl...@gmail.com>:
>
>> 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 <cl...@gmail.com> wrote:
>>
>> > Hi Andrew,
>> >
>> > Got it! Let's discuss it here.
>> >
>> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <andrew.purtell@gmail.com
>> >
>> > 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 <cl...@gmail.com> wrote:
>> >> >
>> >> > Thanks, Andrew,
>> >> >
>> >> > Let me collect some thoughts before replying you.
>> >> >
>> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <ap...@apache.org>
>> >> 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
>> >> >> dev@gearpump.incubator.apache.org
>> >> >>
>> >> >> 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)
>> >> >>
>> >>
>> >
>> >
>>
Re: Podling status report - draft v1
Posted by Kam Kasravi <ka...@yahoo.com.INVALID>.
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 <wh...@outlook.com> 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”<fv...@gmail.com> 写入:
>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 <cl...@gmail.com>:
>
>> 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 <cl...@gmail.com> wrote:
>>
>> > Hi Andrew,
>> >
>> > Got it! Let's discuss it here.
>> >
>> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <andrew.purtell@gmail.com
>> >
>> > 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 <cl...@gmail.com> wrote:
>> >> >
>> >> > Thanks, Andrew,
>> >> >
>> >> > Let me collect some thoughts before replying you.
>> >> >
>> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <ap...@apache.org>
>> >> 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
>> >> >> dev@gearpump.incubator.apache.org
>> >> >>
>> >> >> 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)
>> >> >>
>> >>
>> >
>> >
>>
Re: Podling status report - draft v1
Posted by Weihua Jiang <wh...@outlook.com>.
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”<fv...@gmail.com> 写入:
>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 <cl...@gmail.com>:
>
>> 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 <cl...@gmail.com> wrote:
>>
>> > Hi Andrew,
>> >
>> > Got it! Let's discuss it here.
>> >
>> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <andrew.purtell@gmail.com
>> >
>> > 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 <cl...@gmail.com> wrote:
>> >> >
>> >> > Thanks, Andrew,
>> >> >
>> >> > Let me collect some thoughts before replying you.
>> >> >
>> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <ap...@apache.org>
>> >> 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
>> >> >> dev@gearpump.incubator.apache.org
>> >> >>
>> >> >> 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)
>> >> >>
>> >>
>> >
>> >
>>
Re: Podling status report - draft v1
Posted by Vincent Wang <fv...@gmail.com>.
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 <cl...@gmail.com>:
> 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 <cl...@gmail.com> wrote:
>
> > Hi Andrew,
> >
> > Got it! Let's discuss it here.
> >
> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <andrew.purtell@gmail.com
> >
> > 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 <cl...@gmail.com> wrote:
> >> >
> >> > Thanks, Andrew,
> >> >
> >> > Let me collect some thoughts before replying you.
> >> >
> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <ap...@apache.org>
> >> 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
> >> >> dev@gearpump.incubator.apache.org
> >> >>
> >> >> 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)
> >> >>
> >>
> >
> >
>
Re: Podling status report - draft v1
Posted by Sean Zhong <cl...@gmail.com>.
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 <cl...@gmail.com> wrote:
> Hi Andrew,
>
> Got it! Let's discuss it here.
>
> On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <an...@gmail.com>
> 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 <cl...@gmail.com> wrote:
>> >
>> > Thanks, Andrew,
>> >
>> > Let me collect some thoughts before replying you.
>> >
>> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <ap...@apache.org>
>> 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
>> >> dev@gearpump.incubator.apache.org
>> >>
>> >> 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)
>> >>
>>
>
>
Re: Podling status report - draft v1
Posted by Sean Zhong <cl...@gmail.com>.
Hi Andrew,
Got it! Let's discuss it here.
On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell <an...@gmail.com>
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 <cl...@gmail.com> wrote:
> >
> > Thanks, Andrew,
> >
> > Let me collect some thoughts before replying you.
> >
> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <ap...@apache.org>
> 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
> >> dev@gearpump.incubator.apache.org
> >>
> >> 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)
> >>
>
Re: Podling status report - draft v1
Posted by Andrew Purtell <an...@gmail.com>.
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 <cl...@gmail.com> wrote:
>
> Thanks, Andrew,
>
> Let me collect some thoughts before replying you.
>
>> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <ap...@apache.org> 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
>> dev@gearpump.incubator.apache.org
>>
>> 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)
>>
Re: Podling status report - draft v1
Posted by Sean Zhong <cl...@gmail.com>.
Thanks, Andrew,
Let me collect some thoughts before replying you.
On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell <ap...@apache.org> 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
> dev@gearpump.incubator.apache.org
>
> 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)
>