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 Thu, 07 Apr 2016 06:40:52 GMT
Thanks, Andy!

On Thu, Apr 7, 2016 at 12:18 AM, Andrew Purtell <andrew.purtell@gmail.com>
wrote:

> I have edit permissions so will update it tonight.
>
> > On Apr 6, 2016, at 4:12 AM, Sean Zhong <clockfly@gmail.com> wrote:
> >
> > @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