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 03:04:47 GMT
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)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message