+1 Sent from my iPad
> On Apr 5, 2016, at 8:04 PM, Sean Zhong <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> > 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 <[email protected]> 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 >> > <[email protected]> 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 <[email protected]> >> > 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”<[email protected]> 写入: >> > >> > >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 <[email protected]>: >> > > >> > >> 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 <[email protected]> wrote: >> > >> >> > >> > Hi Andrew, >> > >> > >> > >> > Got it! Let's discuss it here. >> > >> > >> > >> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell < >> > [email protected] >> > >> > >> > >> > 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 <[email protected]> wrote: >> > >> >> > >> > >> >> > Thanks, Andrew, >> > >> >> > >> > >> >> > Let me collect some thoughts before replying you. >> > >> >> > >> > >> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell < >> > [email protected]> >> > >> >> 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 >> > >> >> >> [email protected] >> > >> >> >> >> > >> >> >> 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) >
