gearpump-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: Podling status report - draft v1
Date Wed, 06 Apr 2016 16:18:21 GMT
I have edit permissions so will update it tonight. 

> On Apr 6, 2016, at 4:12 AM, Sean Zhong <clockfly@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 <fvunicorn@gmail.com> wrote:
>> 
>> +1
>> 
>> Best regards
>> Vincent Wang
>> 
>> 2016-04-06 17:58 GMT+08:00 Xu, Qian <sx.away@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 <clockfly@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 <apurtell@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 <kamkasravi@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 <kamkasravi@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
>>>>>> <kamkasravi@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”<fvunicorn@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 <clockfly@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.
>> 

Mime
View raw message