@Andrew, Should I post it to http://wiki.apache.org/incubator/April2016 myself?
On Wed, Apr 6, 2016 at 6:14 PM, Vincent Wang <[email protected]> wrote: > +1 > > Best regards > Vincent Wang > > 2016-04-06 17:58 GMT+08:00 Xu, Qian <[email protected]>: > > > +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 <[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 > > > <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 <[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) > > > > > > > > > > > > > > > -- > > 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. > > >
