[GitHub] incubator-rocketmq issue #69: [ROCKETMQ-111] fix possible MQClientException ...

[zhouxinyu]

Github user zhouxinyu commented on the issue:

https://github.com/apache/incubator-rocketmq/pull/69
  
Hi @yilingfeng @shroman , there is no need to open a new PR, the new commit 
will be merged to `develop` branch directly.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Suggestions

[Xin Wang]

Hi devs,

Here are some suggestions about documents in rocketmq-site.

1. "Versioned" documents.
2. Some important parts are missing in documents:
  APIs, as well as examples (Producer, Consumer)
  Configurations (Broker, NameServer, Producer, Consumer)

Thanks,

Xin Wang (vesense)

[GitHub] incubator-rocketmq issue #72: [ROCKETMQ-134]the offset of message filter by ...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/incubator-rocketmq/pull/72
  

[![Coverage 
Status](https://coveralls.io/builds/10498533/badge)](https://coveralls.io/builds/10498533)

Changes Unknown when pulling **a4e22b6d8008ab0402b9e1909ef4c8061b8e9908 on 
StyleTang:message-tags** into ** on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Podling Report Reminder - March 2017

[Bruce Snyder]

The commit mode (RTC vs. CTR) is up to the PPMC. As Justin mentioned, RTC
can cause scalability issues. We should discuss it in the PPMC to come to a
decision as a community.

Bruce

On Wed, Mar 8, 2017 at 2:48 AM, Justin Mclean 
wrote:

> Hi,
>
> > we hope to one repository for all RocketMQ integration projects, is it
> ok ? j
>
> One or many repo are possible and ether are fine. It’s up to the PPMC.
>
> > I’m also wondering how sustainable / scalable the "3 guys review
> mechanism” is going to be going forward. Anyone have any thoughts on that?
> >
> > Is there any suggestion or good choice about RTC mode :-)
>
> Most projects I’m involved in are CTR than RTC so perhaps my view is off
> here. However no other project use this style of review AFAIK and I’m just
> wondering how scalable it and if it may put people off contributing?
>
> I don't think it’s an issue but my be good to have some discussion on the
> list about this.
>
> Thanks,
> Justin




-- 
perl -e 'print
unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
Twitter: http://twitter.com/brucesnyder

Re: Podling Report Reminder - March 2017

[Justin Mclean]

Hi,

Sorry if I misunderstand anything her or something is getting lost in 
translation.

> As we have control for these repos, we are able to control the quality of 
> releases.

Who is we here? The we should be Apache RocketMQ project not an external 
project on GitHub.

> So the current state is OK.

IMO (and others may have other opinions) it is not and this need to be fixed, 
preferably before graduation.

> as normal contributors do not have permission to commit to the apache repos.

Which IMO is where the project is doing itself a disservice, you should want 
people involved in the wider community to be committers. So bring he code to 
Apache and vote them in as committers. Again other people may have other views 
but it seems to me this would be a good way to grow the community.

> Maybe the right time to do so is when the sub project is mature and important.

You are in incubation, there no requirements for the project to be mature, just 
that you grow a community around you.

Thanks,
Justin

Re: Podling Report Reminder - March 2017

[dongeforever]

Hi:
  Maybe we should think highly of encouragement instead of management. 
  Just like https://github.com/rocketmq,  all integration projects stay under 
the same organization instead of one repo. They are independent and also easy 
for users to find what they need. As we have control for these repos, we are 
able to control the quality of releases. The only problem is the package name, 
as they are not apache repos, they cannot not use package name of 
"org.apache.XXX", but they may share another name prefixed with "rocketmq.io", 
or some other good prefixes.
  So the current state is OK. Move these projects into apache repos, either one 
repo or many, is not a good idea, especially in the early stage, as normal 
contributors do not have permission to commit to the apache repos. Maybe the 
right time to do so is when the sub project is mature and important.


Best Regards
dongeforever


-- Original --
From:  "Justin Mclean";;
Date:  Wed, Mar 8, 2017 05:48 PM
To:  "dev"; 

Subject:  Re: Podling Report Reminder - March 2017



Hi,

> we hope to one repository for all RocketMQ integration projects, is it ok ? j

One or many repo are possible and ether are fine. It??s up to the PPMC.

> I??m also wondering how sustainable / scalable the "3 guys review mechanism?? 
> is going to be going forward. Anyone have any thoughts on that?
> 
> Is there any suggestion or good choice about RTC mode :-)

Most projects I??m involved in are CTR than RTC so perhaps my view is off here. 
However no other project use this style of review AFAIK and I??m just wondering 
how scalable it and if it may put people off contributing?

I don't think it??s an issue but my be good to have some discussion on the list 
about this.

Thanks,
Justin

[GitHub] incubator-rocketmq issue #68: [ROCKETMQ-107] fix possible concurrency proble...

[shroman]

Github user shroman commented on the issue:

https://github.com/apache/incubator-rocketmq/pull/68
  
@Jaskey I agree that `setServiceState` should be deprecated. I overlooked 
it was _public_.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---