gearpump-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Weihua Jiang <whji...@outlook.com>
Subject Re: Podling status report - draft v1
Date Wed, 06 Apr 2016 03:55:24 GMT
+1.




在 16/4/6 上午11:04,“Sean Zhong”<clockfly@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 <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
View raw message