gearpump-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Zhong <clock...@gmail.com>
Subject Re: Podling status report - draft v1
Date Wed, 06 Apr 2016 11:12:55 GMT
@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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message