Re: Discussion: Migrate Github issues to Apache JIra

[Kam Kasravi]

+1 although I thought this was already in a PR? 

On Tuesday, April 5, 2016 6:23 PM, Manu Zhang  
wrote:
 

 Hi all,

I'd like to include https://github.com/gearpump/gearpump/issues/2013 (Refactor
DataSource API).
What do you think ?

On Wed, Apr 6, 2016 at 8:50 AM Kam Kasravi 
wrote:

> Sonatype project for gearpump ticket has been createdhttps://
> issues.sonatype.org/browse/OSSRH-21642
>
>
>
>
>    On Tuesday, April 5, 2016 9:24 AM, Kam Kasravi
>  wrote:
>
>
>  These are the issues that are excluded from migration
> https://github.com/gearpump/gearpump/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone
>
>
>
>
>    On Monday, April 4, 2016 11:41 PM, Sean Zhong 
> wrote:
>
>
>  Hi all,
>
> I have created a milestone named "Apache Migration" at
>
> https://github.com/gearpump/gearpump/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Apache+Migration%22
>
> Would you please check whether this list contains all issues that we want
> to migrate? And please modify them if you think the list is missing some
> items.
>
> Reminder: All issues that are not in this list will be closed in Github
> after the migration.
>
>
> Sean
>
> On Tue, Apr 5, 2016 at 2:38 PM, Sean Zhong  wrote:
>
> > @Andrew,
> >
> > Thanks, we probably should only do manual migration, so that the text in
> > Jira is not messed up.
> > And I  think we should only import issues that are still open.
> >
> >
> >
> > On Sat, Apr 2, 2016 at 2:53 AM, Andrew Purtell 
> > wrote:
> >
> >> We used the GitHub to JIRA import option when starting up the Phoenix
> >> podling. I didn't like the outcome. As an example please see
> >> https://issues.apache.org/jira/browse/PHOENIX-672
> >>
> >> On Fri, Apr 1, 2016 at 12:11 AM, Karol Brejna 
> >> wrote:
> >>
> >> > ’ve extracted open issues to excel file. Maybe we could put them on
> >> google
> >> > docs (sheet) and do „marking” of which should „survive” the migration
> >> there
> >> > (collaboratively, maybe each reporter could decide on his own request,
> >> > whatever).
> >> >
> >> >  I also see “import issues” in apache jira. If we are brave enough we
> >> could
> >> > try this option (needs issues stored in csv – no problem here).
> >> >
> >> > If not we could cherry pick issues and insert them manually.
> >> >
> >> > Karol
> >> >
> >> > śr., 30.03.2016 o 05:37 użytkownik Weihua Jiang 
> >> > napisał:
> >> >
> >> > > Do we want a 1:1 mapping or cherry picking?
> >> > >
> >> > > Thanks
> >> > > Weihua
> >> > >
> >> > >
> >> > >
> >> > > 在 16/3/30 上午11:05，“Sean Zhong” 写入:
> >> > >
> >> > > >If everyone is OK, I'd like to migrate the Github issues to Apache
> >> Jira.
> >> > > It
> >> > > >means we need to copy the issue list from Github and re-create them
> >> in
> >> > > Jira.
> >> > > >
> >> > > >The Github issue list: https://github.com/gearpump/gearpump/issues
> >> > > >The Apache Jira home:
> https://issues.apache.org/jira/browse/GEARPUMP
> >> > > >
> >> > > >Thanks
> >> > > >
> >> > > >Sean
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >>    - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >>
> >
> >
>
>
>
>

  

[jira] [Created] (GEARPUMP-14) Define and document process to make contributions, voting rule, and make releases.

[Sean Zhong (JIRA)]

Sean Zhong created GEARPUMP-14:
--

 Summary: Define and document process to make contributions, voting 
rule, and make releases.
 Key: GEARPUMP-14
 URL: https://issues.apache.org/jira/browse/GEARPUMP-14
 Project: Apache Gearpump
  Issue Type: Bug
Reporter: Sean Zhong


We should define and document process to make contributions, voting rule, and 
make releases. And make it easy for everyone to access.

Also, we should form some consensus on how to response to community questions 
in a  timely manner.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Board Report

[John D. Ament]

Dear Gearpump Podling,

Just a reminder about your board report, its due tomorrow.

John

Re: Podling status report - draft v1

[Kam Kasravi]

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 
 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  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” 写入:

>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 :
>
>> 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  wrote:
>>
>> > 

Re: Podling status report - draft v1

[Kam Kasravi]

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  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” 写入:

>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 :
>
>> 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  wrote:
>>
>> > Hi Andrew,
>> >
>> > Got it! Let's discuss it here.
>> >
>> > On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell > >
>> > 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  wrote:
>> >> >
>> >> > Thanks, Andrew,
>> >> >
>> >> > Let me collect some thoughts before replying you.
>> >> >
>> >> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell 
>> >> 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 

Re: Discussion: About customization of Apache Gearpump Jira

[Sean Zhong]

@Andrew,

It seems I don't have permission to do operation like:

1. Everyone can report the issue and change the issue assignee.
2.  Add a new field called “Issue Links” so that we can link the pull
request here. Like: https://issues.apache.org/jira/browse/SPARK-14359

The functions are locked.


On Tue, Apr 5, 2016 at 2:57 PM, Weihua Jiang  wrote:

> +1.
>
>
>
>
> 在 16/4/5 下午2:55，“Sean Zhong” 写入:
>
> >Jira customization allows us to add new "required field", "optional field"
> >for new issue submission, and also allow us  to define component list, and
> >etc...
> >
> >Here are several customization that make sense to me, please contribute
> >your thoughts on this:
> >
> >1. Add a field called “Issue Links” so that we can link the pull request
> >here.
> >Like how Spark does: https://issues.apache.org/jira/browse/SPARK-14359
> >
> >2. Create component by following the list at
> >https://github.com/gearpump/gearpump/labels
> >akkastream, build system, core  dashboard  docs  kafkaperformance
> restapi
> >   scalajssecurity   storage   storm  transaction  use case  yarn
> >
> >3. Everyone can report the issue and change the issue assignee.
> >
> >Do these  three items make sense to you? Please add to the list if you
> have
> >suggestions.
> >
> >Sean
>
>

Re: Discussion: About customization of Apache Gearpump Jira

[Weihua Jiang]

+1.




在 16/4/5 下午2:55，“Sean Zhong” 写入:

>Jira customization allows us to add new "required field", "optional field"
>for new issue submission, and also allow us  to define component list, and
>etc...
>
>Here are several customization that make sense to me, please contribute
>your thoughts on this:
>
>1. Add a field called “Issue Links” so that we can link the pull request
>here.
>Like how Spark does: https://issues.apache.org/jira/browse/SPARK-14359
>
>2. Create component by following the list at
>https://github.com/gearpump/gearpump/labels
>akkastream, build system, core  dashboard  docs  kafkaperformance  restapi
>   scalajssecurity   storage   storm  transaction  use case  yarn
>
>3. Everyone can report the issue and change the issue assignee.
>
>Do these  three items make sense to you? Please add to the list if you have
>suggestions.
>
>Sean

Discussion: About customization of Apache Gearpump Jira

[Sean Zhong]

Jira customization allows us to add new "required field", "optional field"
for new issue submission, and also allow us  to define component list, and
etc...

Here are several customization that make sense to me, please contribute
your thoughts on this:

1. Add a field called “Issue Links” so that we can link the pull request
here.
Like how Spark does: https://issues.apache.org/jira/browse/SPARK-14359

2. Create component by following the list at
https://github.com/gearpump/gearpump/labels
akkastream, build system, core  dashboard  docs  kafkaperformance  restapi
   scalajssecurity   storage   storm  transaction  use case  yarn

3. Everyone can report the issue and change the issue assignee.

Do these  three items make sense to you? Please add to the list if you have
suggestions.

Sean

Re: Discussion: Migrate Github issues to Apache JIra

[Sean Zhong]

@Andrew,

Thanks, we probably should only do manual migration, so that the text in
Jira is not messed up.
And I  think we should only import issues that are still open.



On Sat, Apr 2, 2016 at 2:53 AM, Andrew Purtell  wrote:

> We used the GitHub to JIRA import option when starting up the Phoenix
> podling. I didn't like the outcome. As an example please see
> https://issues.apache.org/jira/browse/PHOENIX-672
>
> On Fri, Apr 1, 2016 at 12:11 AM, Karol Brejna 
> wrote:
>
> > ’ve extracted open issues to excel file. Maybe we could put them on
> google
> > docs (sheet) and do „marking” of which should „survive” the migration
> there
> > (collaboratively, maybe each reporter could decide on his own request,
> > whatever).
> >
> >  I also see “import issues” in apache jira. If we are brave enough we
> could
> > try this option (needs issues stored in csv – no problem here).
> >
> > If not we could cherry pick issues and insert them manually.
> >
> > Karol
> >
> > śr., 30.03.2016 o 05:37 użytkownik Weihua Jiang 
> > napisał:
> >
> > > Do we want a 1:1 mapping or cherry picking?
> > >
> > > Thanks
> > > Weihua
> > >
> > >
> > >
> > > 在 16/3/30 上午11:05，“Sean Zhong” 写入:
> > >
> > > >If everyone is OK, I'd like to migrate the Github issues to Apache
> Jira.
> > > It
> > > >means we need to copy the issue list from Github and re-create them in
> > > Jira.
> > > >
> > > >The Github issue list: https://github.com/gearpump/gearpump/issues
> > > >The Apache Jira home: https://issues.apache.org/jira/browse/GEARPUMP
> > > >
> > > >Thanks
> > > >
> > > >Sean
> > >
> > >
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: Podling status report - draft v1

[Sean Zhong]

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  wrote:

> Hi Andrew,
>
> Got it! Let's discuss it here.
>
> On Sun, Apr 3, 2016 at 1:13 AM, Andrew Purtell 
> 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  wrote:
>> >
>> > Thanks, Andrew,
>> >
>> > Let me collect some thoughts before replying you.
>> >
>> >> On Sat, Apr 2, 2016 at 1:59 AM, Andrew Purtell 
>> 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)
>> >>
>>
>
>