Re: [DISCUSSION] create a new project servicecomb-samples
My suggestion is moving all the cross sub projects examples there to show the big picture of ServiceComb, but we still keep basic function examples in the old repo. Any thoughts? Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Jan 22, 2019 at 9:55 AM Yang Bo wrote: > > +1 > We can move all the examples for java-chassis and saga to this scb-example > repo. > > On Tue, Jan 22, 2019 at 9:52 AM yhs0092 wrote: > > > +1 > > This is a good idea. Currently the samples of ServiceComb-Java-Chassis is > > mixed in our project code, and the maven dependency management is kind of > > complex. For the new comers, it's a little bit hard to understand and hard > > to run them. > > > > > > Yours sincerely > > > > > > Yao Haishi > > yhs0...@163.com > > > > > > On 1/21/2019 16:58，Willem Jiang wrote： > > I think it's a good idea to use the sample to demonstrate the usage > > across the subprojects of ServiceComb. > > Current we have an example[1] in servicecomb-pack for using the > > java-chasis with pack. Maybe we can put it as the first example of > > servicecomb-samples. > > > > [1] > > https://github.com/apache/servicecomb-pack/tree/master/demo/saga-servicecomb-demo > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Mon, Jan 21, 2019 at 3:34 PM bismy wrote: > > > > Hello all, > > > > > > I suggest the create a new project servicecomb-samples to hosting code of > > servicecomb examples. Currently we have samples in each project, but is not > > enough for reasons: > > > > > > 1. Create new examples will make project huge and hard to distribute. > > 2. We can not create examples based on released version. > > 3. Lack of examples to show integrated features use both of java-chassis > > and saga features. > > > > > > Any ideas? > > > > > -- > Best Regards, > Yang.
Re: [DISCUSSION] create a new project servicecomb-samples
+1 iPhone -- Original -- From: Yang Bo Date: Tue,Jan 22,2019 9:55 AM To: dev Subject: Re: [DISCUSSION] create a new project servicecomb-samples +1 We can move all the examples for java-chassis and saga to this scb-example repo. On Tue, Jan 22, 2019 at 9:52 AM yhs0092 wrote: > +1 > This is a good idea. Currently the samples of ServiceComb-Java-Chassis is > mixed in our project code, and the maven dependency management is kind of > complex. For the new comers, it's a little bit hard to understand and hard > to run them. > > > Yours sincerely > > > Yao Haishi > yhs0...@163.com > > > On 1/21/2019 16:58??Willem Jiang wrote?? > I think it's a good idea to use the sample to demonstrate the usage > across the subprojects of ServiceComb. > Current we have an example[1] in servicecomb-pack for using the > java-chasis with pack. Maybe we can put it as the first example of > servicecomb-samples. > > [1] > https://github.com/apache/servicecomb-pack/tree/master/demo/saga-servicecomb-demo > > Willem Jiang > > Twitter: willemjiang > Weibo: willem > > On Mon, Jan 21, 2019 at 3:34 PM bismy wrote: > > Hello all, > > > I suggest the create a new project servicecomb-samples to hosting code of > servicecomb examples. Currently we have samples in each project, but is not > enough for reasons: > > > 1. Create new examples will make project huge and hard to distribute. > 2. We can not create examples based on released version. > 3. Lack of examples to show integrated features use both of java-chassis > and saga features. > > > Any ideas? > -- Best Regards, Yang.
Re: [DISCUSSION] create a new project servicecomb-samples
+1 bismy 于2019年1月21日周一 下午3:34写道： > Hello all, > > > I suggest the create a new project servicecomb-samples to hosting code of > servicecomb examples. Currently we have samples in each project, but is not > enough for reasons: > > > 1. Create new examples will make project huge and hard to distribute. > 2. We can not create examples based on released version. > 3. Lack of examples to show integrated features use both of java-chassis > and saga features. > > > Any ideas?
Re: [DISCUSSION] create a new project servicecomb-samples
+1 We can move all the examples for java-chassis and saga to this scb-example repo. On Tue, Jan 22, 2019 at 9:52 AM yhs0092 wrote: > +1 > This is a good idea. Currently the samples of ServiceComb-Java-Chassis is > mixed in our project code, and the maven dependency management is kind of > complex. For the new comers, it's a little bit hard to understand and hard > to run them. > > > Yours sincerely > > > Yao Haishi > yhs0...@163.com > > > On 1/21/2019 16:58，Willem Jiang wrote： > I think it's a good idea to use the sample to demonstrate the usage > across the subprojects of ServiceComb. > Current we have an example[1] in servicecomb-pack for using the > java-chasis with pack. Maybe we can put it as the first example of > servicecomb-samples. > > [1] > https://github.com/apache/servicecomb-pack/tree/master/demo/saga-servicecomb-demo > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, Jan 21, 2019 at 3:34 PM bismy wrote: > > Hello all, > > > I suggest the create a new project servicecomb-samples to hosting code of > servicecomb examples. Currently we have samples in each project, but is not > enough for reasons: > > > 1. Create new examples will make project huge and hard to distribute. > 2. We can not create examples based on released version. > 3. Lack of examples to show integrated features use both of java-chassis > and saga features. > > > Any ideas? > -- Best Regards, Yang.
Re: [DISCUSSION] create a new project servicecomb-samples
+1 This is a good idea. Currently the samples of ServiceComb-Java-Chassis is mixed in our project code, and the maven dependency management is kind of complex. For the new comers, it's a little bit hard to understand and hard to run them. Yours sincerely Yao Haishi yhs0...@163.com On 1/21/2019 16:58，Willem Jiang wrote： I think it's a good idea to use the sample to demonstrate the usage across the subprojects of ServiceComb. Current we have an example[1] in servicecomb-pack for using the java-chasis with pack. Maybe we can put it as the first example of servicecomb-samples. [1]https://github.com/apache/servicecomb-pack/tree/master/demo/saga-servicecomb-demo Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Jan 21, 2019 at 3:34 PM bismy wrote: Hello all, I suggest the create a new project servicecomb-samples to hosting code of servicecomb examples. Currently we have samples in each project, but is not enough for reasons: 1. Create new examples will make project huge and hard to distribute. 2. We can not create examples based on released version. 3. Lack of examples to show integrated features use both of java-chassis and saga features. Any ideas?
Re: [DISCUSSION] create a new project servicecomb-samples
+1 no-binding Good idea 2019-01-21 16:56 GMT+08:00, wjm wjm : > +1 > > and old samples can move to new repository > > bismy 于2019年1月21日周一 下午3:34写道： > >> Hello all, >> >> >> I suggest the create a new project servicecomb-samples to hosting code of >> servicecomb examples. Currently we have samples in each project, but is >> not >> enough for reasons: >> >> >> 1. Create new examples will make project huge and hard to distribute. >> 2. We can not create examples based on released version. >> 3. Lack of examples to show integrated features use both of java-chassis >> and saga features. >> >> >> Any ideas? >
Re: Java-Chassis interceptor
for option 2, the two events must be the same thread, and can set and clear
safely
Willem Jiang 于2019年1月22日周二 上午9:12写道：
> Hi jimin,
>
> Thanks for the suggestion.
> I think the hardest part of this work is handling thread switching
> work, event we could clean up the OmegaContext when the
> InvocationBusinessMethodFinishEvent happened, we still need to find
> the right moment to setup the OmegaContext. So I think the option 1
> is the best way to go.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jan 21, 2019 at 10:51 PM wjm wjm wrote:
> >
> > all the following solutions can support this:
> > 1.implement a handle, and require customers to configure it to be the
> last
> > handler
> >
> > @Override
> > public void handle(Invocation invocation, AsyncResponse asyncResp)
> > throws Exception {
> > set context
> >
> > try {
> > invocation.next(asyncResp);
> > } finally {
> > clear context
> > }
> > }
> >
> >
> > 2.subscribe events:
> > org.apache.servicecomb.core.event.InvocationBusinessMethodStartEvent
> to
> > set context, this event means business method will be invoked in this
> thread
> >
> org.apache.servicecomb.core.event.InvocationBusinessMethodFinishEvent to
> > clear context, this event means business method already returned in this
> > thread, for async method, this not means response data model is ready.
> >
> > we can get EventBus by
> org.apache.servicecomb.core.SCBEngine#getEventBus
> >
> > Willem Jiang 于2019年1月21日周一 下午5:16写道：
> >
> > > Hi,
> > >
> > > Current we got an issue[1] to clean up the OmegaContext after the
> > > invocation on the server side to clean up the thread local variable
> > > which OmegaContext set.
> > > Now I have a question for the handler of servicecomb java-chassis. How
> > > can I do the same thing on the java-chassis SagaProviderHandler[2]?
> > >
> > > [1]https://github.com/apache/servicecomb-pack/issues/384
> > > [2]
> > >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-transport/omega-transport-servicecomb/src/main/java/org/apache/servicecomb/pack/omega/transport/servicecomb/SagaProviderHandler.java
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
>
Re: Java-Chassis interceptor
Hi jimin,
Thanks for the suggestion.
I think the hardest part of this work is handling thread switching
work, event we could clean up the OmegaContext when the
InvocationBusinessMethodFinishEvent happened, we still need to find
the right moment to setup the OmegaContext. So I think the option 1
is the best way to go.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Mon, Jan 21, 2019 at 10:51 PM wjm wjm wrote:
>
> all the following solutions can support this:
> 1.implement a handle, and require customers to configure it to be the last
> handler
>
> @Override
> public void handle(Invocation invocation, AsyncResponse asyncResp)
> throws Exception {
> set context
>
> try {
> invocation.next(asyncResp);
> } finally {
> clear context
> }
> }
>
>
> 2.subscribe events:
> org.apache.servicecomb.core.event.InvocationBusinessMethodStartEvent to
> set context, this event means business method will be invoked in this thread
> org.apache.servicecomb.core.event.InvocationBusinessMethodFinishEvent to
> clear context, this event means business method already returned in this
> thread, for async method, this not means response data model is ready.
>
> we can get EventBus by org.apache.servicecomb.core.SCBEngine#getEventBus
>
> Willem Jiang 于2019年1月21日周一 下午5:16写道：
>
> > Hi,
> >
> > Current we got an issue[1] to clean up the OmegaContext after the
> > invocation on the server side to clean up the thread local variable
> > which OmegaContext set.
> > Now I have a question for the handler of servicecomb java-chassis. How
> > can I do the same thing on the java-chassis SagaProviderHandler[2]?
> >
> > [1]https://github.com/apache/servicecomb-pack/issues/384
> > [2]
> > https://github.com/apache/servicecomb-pack/blob/master/omega/omega-transport/omega-transport-servicecomb/src/main/java/org/apache/servicecomb/pack/omega/transport/servicecomb/SagaProviderHandler.java
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
Re: [discuss] change mechanism of java chassis POJO consumerparamters mapping
in most times, customers can add one parameter in producer, but compatible
to old versions
in this time, we force customers must upgrade their consumers, it's too bad.
if map parameters by index, add any new parameter in a wrapper like
"QueryWrapper", a logic error will occur
but if map parameters by name, only add new parameters which
have duplicated name will cause the error
so i think, map by name still is better.
bismy 于2019年1月21日周一 下午3:28写道：
> I do not think your suggestion is a good idea, and I'd prefer not change
> it and remain the same.
>
>
> You problem comes from the semantics of the definition:
>void method(QueryWrapper querys, int p2);
> For query parameter querys (type of QueryWrapper) do not mean one
> parameter, but many parameters based on it's structure, it a special
> grammar for POJO queries. So the client code can be:
>void method(int x, int y, int p2)
> or
>void method(int x, int y, int z, int p2)
>
>
> When you add a new name for QueryWrapper, it equals to you add a parameter
> for
>void method(int x, int y, int p2) to void method(int x, int y, int z,
> int p2)
> and it's a change should be noticed that client should change the
> invocation code.
>
>
> Benefit for your suggestion is that users can add new parameters for an
> API, and I think this scenario is a CHANGE, and should change client code,
> but not adapt to it.
>
>
> And if you use parameter name to handle this, their will cause conflicts.
> For example, add an x for this method:
>void method(QueryWrapper querys, int x, int y);
>
>
> And We need to consider other problems like name in
> @RequestParam("name1") is different with parameter name.
>
>
> In conclusion, I prefer not to handle this scenario.
>
>
> -- 原始邮件 --
> 发件人: "zzzwjm";
> 发送时间: 2019年1月18日(星期五) 凌晨0:17
> 收件人: "dev@servicecomb.apache.org";
>
> 主题: Re: [discuss] change mechanism of java chassis POJO consumerparamters
> mapping
>
>
>
> java8 support present interface method parameter name
> need to add compile argument, not debug option
>
> 在 2019年1月17日星期四，Willem Jiang 写道：
>
> > Java compile will remove the parameters name by default. We faced the
> > same problem in CXF simple frontend.
> > The solution could be enable the debug option in the compiler or add
> > annotation to the parameters.
> >
> > If we decide to setting the option on the compiler, we should not only
> > throw exception in the runtime, but also document it.
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Jan 17, 2019 at 5:23 PM wjm wjm wrote:
> > >
> > > Scenes：
> > > 1.producer is springMVC dev mode
> > > class QueryWrapper {
> > > int x;
> > > int y;
> > > }
> > > void method(QueryWrapper querys, int p2);
> > >
> > > will produce swagger operation, have 3 parameters: x, y, p2
> > >
> > > 2.consumer is POJO dev mode, declare a interface:
> > > interface TestIntf {
> > > void method(int x, int y, int p2);
> > > }
> > > until now, everything is ok.
> > >
> > > 3.producer upgrade
> > > class QueryWrapper {
> > > int x;
> > > int y;
> > > int z;
> > > }
> > > will produce swagger operation, have 4 parameters: x,y,z,p2
> > >
> > > in this time, old POJO consumers will have problems:
> > > assign x to x, y to y, p2 to z
> > > that's because we map parameters by their index
> > >
> > > to resolve the problem:
> > > we need to map parameters by their name
> > > this require customers change their compile argument in pom.xml to
> > allow
> > > interface present method parameter name
> > > if did not add compile argument, SDK can throw exception, and print
> how
> > > to add the compile argument.
> > >
> > > any idea?
> >
Re: Java-Chassis interceptor
all the following solutions can support this:
1.implement a handle, and require customers to configure it to be the last
handler
@Override
public void handle(Invocation invocation, AsyncResponse asyncResp)
throws Exception {
set context
try {
invocation.next(asyncResp);
} finally {
clear context
}
}
2.subscribe events:
org.apache.servicecomb.core.event.InvocationBusinessMethodStartEvent to
set context, this event means business method will be invoked in this thread
org.apache.servicecomb.core.event.InvocationBusinessMethodFinishEvent to
clear context, this event means business method already returned in this
thread, for async method, this not means response data model is ready.
we can get EventBus by org.apache.servicecomb.core.SCBEngine#getEventBus
Willem Jiang 于2019年1月21日周一 下午5:16写道：
> Hi,
>
> Current we got an issue[1] to clean up the OmegaContext after the
> invocation on the server side to clean up the thread local variable
> which OmegaContext set.
> Now I have a question for the handler of servicecomb java-chassis. How
> can I do the same thing on the java-chassis SagaProviderHandler[2]?
>
> [1]https://github.com/apache/servicecomb-pack/issues/384
> [2]
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-transport/omega-transport-servicecomb/src/main/java/org/apache/servicecomb/pack/omega/transport/servicecomb/SagaProviderHandler.java
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
Java-Chassis interceptor
Hi, Current we got an issue[1] to clean up the OmegaContext after the invocation on the server side to clean up the thread local variable which OmegaContext set. Now I have a question for the handler of servicecomb java-chassis. How can I do the same thing on the java-chassis SagaProviderHandler[2]? [1]https://github.com/apache/servicecomb-pack/issues/384 [2]https://github.com/apache/servicecomb-pack/blob/master/omega/omega-transport/omega-transport-servicecomb/src/main/java/org/apache/servicecomb/pack/omega/transport/servicecomb/SagaProviderHandler.java Willem Jiang Twitter: willemjiang Weibo: 姜宁willem
Re: [DISCUSSION] create a new project servicecomb-samples
+1 and old samples can move to new repository bismy 于2019年1月21日周一 下午3:34写道： > Hello all, > > > I suggest the create a new project servicecomb-samples to hosting code of > servicecomb examples. Currently we have samples in each project, but is not > enough for reasons: > > > 1. Create new examples will make project huge and hard to distribute. > 2. We can not create examples based on released version. > 3. Lack of examples to show integrated features use both of java-chassis > and saga features. > > > Any ideas?
Re: [DISCUSSION] create a new project servicecomb-samples
I think it's a good idea to use the sample to demonstrate the usage across the subprojects of ServiceComb. Current we have an example[1] in servicecomb-pack for using the java-chasis with pack. Maybe we can put it as the first example of servicecomb-samples. [1]https://github.com/apache/servicecomb-pack/tree/master/demo/saga-servicecomb-demo Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Jan 21, 2019 at 3:34 PM bismy wrote: > > Hello all, > > > I suggest the create a new project servicecomb-samples to hosting code of > servicecomb examples. Currently we have samples in each project, but is not > enough for reasons: > > > 1. Create new examples will make project huge and hard to distribute. > 2. We can not create examples based on released version. > 3. Lack of examples to show integrated features use both of java-chassis and > saga features. > > > Any ideas?
Re: [VOTE]Tracking the Github issue discussions to dev@servicecomb.apache.org
+1 just one change: keep answer questions. Willem Jiang 于2019年1月21日周一 下午4:05写道： > I'm agree with Liubao. > > The background of moving the github issue is to attract more users by > sporting the popular way of asking question in github issue. > If we treat github issue as the mailing list of > us...@servicecomb.apache.org, if we can keep answer the question and > the question are archived, I think it should be fine. We don't need to > do anything to routing the mail around. > > BTW, when I draft the board report, I include the github activities > with the mail activities. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, Jan 21, 2019 at 3:36 PM bismy wrote: > > > > For my personal preferences, we don't need to change anything, and now > everything works fine. > > > > > > 1. We discussion problem is dev mailing list. Users can send their > questions though mail. > > 2. Users submit issues or ask questions in issues @github, I subscribe > notifications from github and answers questions @github. > > > > > > We can encourage users to discuss problems using mailing list and > submit/discuss issues @github. > > > > > > -- 原始邮件 -- > > 发件人: "Zen Lin"; > > 发送时间: 2019年1月15日(星期二) 中午12:07 > > 收件人: "dev"; > > > > 主题: Re: [VOTE]Tracking the Github issue discussions to > dev@servicecomb.apache.org > > > > > > > > If there is no one knows how the Infra team track the github notification > > to commits list, I am going to ask the Infra team for the details, and > will > > help to research the feasibility of separation. > > > > Best Regards, > > --- > > Zen Lin > > zenlintechnofr...@gmail.com > > Focused on Micro Service and Apache ServiceComb > > > > > > Zen Lin 于2019年1月15日周二 上午11:56写道： > > > > > Is there anyone knows how Infra group track the github notification to > > > comm...@servicecomb.apache.org? > > > If it is using github API, it is work to seperate github issue. > > > > > > Best Regards, > > > --- > > > Zen Lin > > > zenlintechnofr...@gmail.com > > > Focused on Micro Service and Apache ServiceComb > > > > > > > > > Willem Jiang 于2019年1月15日周二 上午11:44写道： > > > > > >> We cannot just redirect the question to the Infra team without doing > > >> the research first. > > >> My suggestion is we need to do some research to figure out how to > > >> separate the github issue notification from the github notification > > >> stream. > > >> Then we can give the Infra team instructions to do the work with their > > >> admin right. > > >> If we cannot get there, we could consider to disable the github issue > > >> function to let user use mail to ask questions directly. > > >> > > >> Willem Jiang > > >> > > >> Twitter: willemjiang > > >> Weibo: 姜宁willem > > >> > > >> On Tue, Jan 15, 2019 at 9:54 AM Zen Lin > > >> wrote: > > >> > > > >> > Yeah, > > >> > If we track the github issue to dev mail, we can watch the issue > > >> > contents in the dev mailing list. > > >> > If you want your reply can posted to the github issue, you can > > >> > reply the mail sent by github, in that way, the reply can be posted > > >> > on issue and also be sent to the dev mailing list. > > >> > > > >> > Anyway, as Willem said, we now have tracked the github > > >> > notification to comm...@servicecomb.apache.org, we just need > > >> > to seperate them from the github notification. > > >> > > > >> > Hi Willem, > > >> > As I known, this will be implemented by Apache Infra group. > > >> > What about to create a vote for this, and then I will create an > > >> > issue to Apache Infra, > > >> > or just create a mail to copy to infrastructure-...@apache.org > > >> > > > >> > Best Regards, > > >> > --- > > >> > Zen Lin > > >> > zenlintechnofr...@gmail.com > > >> > Focused on Micro Service and Apache ServiceComb > > >> > > > >> > > > >> > Willem Jiang 于2019年1月15日周二 上午9:27写道： > > >> > > > >> > > I don't think we can bridge the dev mail to the github issue, but > it > > >> > > makes sense that to send the notification or the github issue to > the > > >> > > dev mailing list. > > >> > > Now we need to figure out if we can seperate the github > notification > > >> > > by checking if it comes from github issues. > > >> > > > > >> > > Willem Jiang > > >> > > > > >> > > Twitter: willemjiang > > >> > > Weibo: 姜宁willem > > >> > > > > >> > > On Mon, Jan 14, 2019 at 10:00 PM Zheng Feng > > >> wrote: > > >> > > > > > >> > > > I wonder if it can only watch the github issues by using the dev > > >> mailing > > >> > > > list or we can reply the thread and it could be posted to the > github > > >> > > issue > > >> > > > automatically ? > > >> > > > > > >> > > > Zen Lin 于2019年1月14日周一 下午8:38写道： > > >> > > > > > >> > > > > How about to create a new proposal discussion for split github > > >> issue > > >> > > track > > >> > > > > from commits mailing list to dev mailing list? > > >> > > > > I think discussion in github issue is quite different from > > >> commits, > > >> > > they > > >> > > > > are similar to the
Re: [VOTE]Tracking the Github issue discussions to dev@servicecomb.apache.org
I'm agree with Liubao. The background of moving the github issue is to attract more users by sporting the popular way of asking question in github issue. If we treat github issue as the mailing list of us...@servicecomb.apache.org, if we can keep answer the question and the question are archived, I think it should be fine. We don't need to do anything to routing the mail around. BTW, when I draft the board report, I include the github activities with the mail activities. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Jan 21, 2019 at 3:36 PM bismy wrote: > > For my personal preferences, we don't need to change anything, and now > everything works fine. > > > 1. We discussion problem is dev mailing list. Users can send their questions > though mail. > 2. Users submit issues or ask questions in issues @github, I subscribe > notifications from github and answers questions @github. > > > We can encourage users to discuss problems using mailing list and > submit/discuss issues @github. > > > -- 原始邮件 -- > 发件人: "Zen Lin"; > 发送时间: 2019年1月15日(星期二) 中午12:07 > 收件人: "dev"; > > 主题: Re: [VOTE]Tracking the Github issue discussions to > dev@servicecomb.apache.org > > > > If there is no one knows how the Infra team track the github notification > to commits list, I am going to ask the Infra team for the details, and will > help to research the feasibility of separation. > > Best Regards, > --- > Zen Lin > zenlintechnofr...@gmail.com > Focused on Micro Service and Apache ServiceComb > > > Zen Lin 于2019年1月15日周二 上午11:56写道： > > > Is there anyone knows how Infra group track the github notification to > > comm...@servicecomb.apache.org? > > If it is using github API, it is work to seperate github issue. > > > > Best Regards, > > --- > > Zen Lin > > zenlintechnofr...@gmail.com > > Focused on Micro Service and Apache ServiceComb > > > > > > Willem Jiang 于2019年1月15日周二 上午11:44写道： > > > >> We cannot just redirect the question to the Infra team without doing > >> the research first. > >> My suggestion is we need to do some research to figure out how to > >> separate the github issue notification from the github notification > >> stream. > >> Then we can give the Infra team instructions to do the work with their > >> admin right. > >> If we cannot get there, we could consider to disable the github issue > >> function to let user use mail to ask questions directly. > >> > >> Willem Jiang > >> > >> Twitter: willemjiang > >> Weibo: 姜宁willem > >> > >> On Tue, Jan 15, 2019 at 9:54 AM Zen Lin > >> wrote: > >> > > >> > Yeah, > >> > If we track the github issue to dev mail, we can watch the issue > >> > contents in the dev mailing list. > >> > If you want your reply can posted to the github issue, you can > >> > reply the mail sent by github, in that way, the reply can be posted > >> > on issue and also be sent to the dev mailing list. > >> > > >> > Anyway, as Willem said, we now have tracked the github > >> > notification to comm...@servicecomb.apache.org, we just need > >> > to seperate them from the github notification. > >> > > >> > Hi Willem, > >> > As I known, this will be implemented by Apache Infra group. > >> > What about to create a vote for this, and then I will create an > >> > issue to Apache Infra, > >> > or just create a mail to copy to infrastructure-...@apache.org > >> > > >> > Best Regards, > >> > --- > >> > Zen Lin > >> > zenlintechnofr...@gmail.com > >> > Focused on Micro Service and Apache ServiceComb > >> > > >> > > >> > Willem Jiang 于2019年1月15日周二 上午9:27写道： > >> > > >> > > I don't think we can bridge the dev mail to the github issue, but it > >> > > makes sense that to send the notification or the github issue to the > >> > > dev mailing list. > >> > > Now we need to figure out if we can seperate the github notification > >> > > by checking if it comes from github issues. > >> > > > >> > > Willem Jiang > >> > > > >> > > Twitter: willemjiang > >> > > Weibo: 姜宁willem > >> > > > >> > > On Mon, Jan 14, 2019 at 10:00 PM Zheng Feng > >> wrote: > >> > > > > >> > > > I wonder if it can only watch the github issues by using the dev > >> mailing > >> > > > list or we can reply the thread and it could be posted to the github > >> > > issue > >> > > > automatically ? > >> > > > > >> > > > Zen Lin 于2019年1月14日周一 下午8:38写道： > >> > > > > >> > > > > How about to create a new proposal discussion for split github > >> issue > >> > > track > >> > > > > from commits mailing list to dev mailing list? > >> > > > > I think discussion in github issue is quite different from > >> commits, > >> > > they > >> > > > > are similar to the contents in the dev list. > >> > > > > > >> > > > > Best Regards, > >> > > > > --- > >> > > > > Zen Lin > >> > > > > zenlintechnofr...@gmail.com > >> > > > > Focused on Micro Service and Apache ServiceComb > >> > > > > > >> > > > > > >> > > > > Willem Jiang 于2019年1月14日周一 下午8:20写道： > >> > > > > > >> > > > > > Actually we already had the vote[1] of moving the
