Re: JIRA email notification

[Justin Mclean]

Hi,

> Individual notifications should be working now but I'm still not seeing
> mails to issues@dubbo.a.o yet.

I’m seeing them.

Thanks,
Justin

Re: JIRA email notification

[Justin Mclean]

HI,

> There were three issues.
> 1. Dubbo had not be assigned a notification scheme.
> 2. j...@apache.org was not on the allow list for issues@dubbo.a.o
> 3. The permission scheme was set incorrectly which was preventing mail
> from being sent to issues@dubbo.a.o


This was set up via the infra self serve app [1], perhaps it needs some work?

Thanks,
Justin

1. https://selfserve.apache.org

Re: Private channel for reporting security issues

[Justin Mclean]

Hi,

> Thanks for the information.
> In that case, I am +1 for secur...@dubbo.apache.org.

Requested and the email list should be created soon.

> Further question: if the venerability report is related to some
> project Dubbo depends on, what kind of action should Dubbo security
> team take?
> Should we accepted, update to the fixed version, and then announce it?

In sort but its a bit more involved that that. for full details see [1].

Note that as an exception to the usual talk about it on the dev list dicussion 
should be kept to private lists to reduce the risk of someone taking advantage 
of the security issue before it is fixed.

Thanks,
Justin

1. https://www.apache.org/security/committers.html

Re: [Draft] Dubbo Incubator Report - March 2018

[Justin Mclean]

Hi,

> Three most important issues to address in the move towards graduation:
> 
>  1. Get 6 ICLA signed of 9 initial comitters.
>  2. Create mailing list(including security@, dev@, issues@, commits@), JIRA

These have been created. Perhaps change this to getting community to sign up 
and move discussion to dev@?

>  3. Working to confirm that SGA is needed or not


The biggest issue I see is not having the code base at apache yet. [1]

Thanks,
Justin

1. https://issues.apache.org/jira/projects/DUBBO/issues/DUBBO-3

Re: On double dubbo starters

[Justin Mclean]

Hi,

> I think Mark means you could publish dubbo starter(also same for dubbo in 
> another discussion) with ‘old’ group and ‘old’ name before transition to the 
> ASF.

Yes that is what Mark means and is fine as long as it’s not branded as an 
Apache release.

Thanks,
Justin

Re: How to add Apache license head to the files of hessian-lite sub project

[Justin Mclean]

Hi,

> The text from section 3 should appear in the NOTICE file.

It seems to be a combination of a BSD license and Apache which is slightly 
confusing. IMO nothing needs to go in NOTICE but we probably need to look into 
it in a little more detail.

Thanks,
Justin

Re: How to add Apache license head to the files of hessian-lite sub project

[Justin Mclean]

Hi,

> Should the author info be removed?  @author Scott Ferguson

I’d leave any existing author tags in but not add any new ones.

Thanks,
Justin

Re: How to add Apache license head to the files of hessian-lite sub project

[Justin Mclean]

Hi,

> It seems to be a combination of a BSD license and Apache which is slightly 
> confusing. IMO nothing needs to go in NOTICE but we probably need to look 
> into it in a little more detail.

Which is what The Apache 1.1 license is (i.e. a modified BSD one) it’s been a 
while since I’ve looked at the text from ALv1.1. As far as a release goes IMO 
the LICENSE txt needs to go in (or be pointed at) in LICENSE, [1] nothing 
should be added to NOTICE [2] (as the text is included in LICENSE) and the 
headers should be left on the existing code as is.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#permissive-deps
2. https://www.apache.org/legal/resolved.html#required-third-party-notices

Re: Suggestions on the organizational form of the code repository after confirming the submission of the dubbo code to apache

[Justin Mclean]

Hi,

>> Are you looking to continue to use github as the primary repository
>> location, or switch to our internal git? I'd recommend github since you're
>> already there.
> 
> +1 stick to github, just transfer to github/apache after the IP Clearance 
> sort of things

With my mentors hat on I think it would be better to transfer the code to the 
ASF repos and work on it there. The IP clearance only really needs to be sorted 
out before graduation.

Thanks,
Justin

Re: Suggestions on the organizational form of the code repository after confirming the submission of the dubbo code to apache

[Justin Mclean]

Hi,

>  1.  Can we put the project at 
> https://github.com/apache/ ？
> 
> for example:
> a.  alibaba/dubbo move to https://github.com/apache/incubator-dubbo
> b.  dubbo/dubbo.github.io move to 
> https://github.com/apache/incubator-dubbo-website
> c.  dubbo/dubbo-spring-boot-project move to 
> https://github.com/apache/incubator-dubbo-spring-boot.
> d.  dubbo/dubbo-rpc-jsonrpc move to 
> https://github.com/apache/incubator-dubbo-jsonrpc.
> e.  dubbo/dubbo-feature-test move to 
> https://github.com/apache/incubator-dubbo-feature-test .

Looks good to me. Getting the website published from that repo may take a 
little work.

> 2.  If the IP clearance( and some other tasks, eg  contributors cla) only 
> really needs to be sorted out before graduation， we may work on it there not 
> current existing github repo (https://github.com/alibaba/dubbo).

The earlier these are sorted out the better IMO, so I wouldn’t put it off until 
just before graduation, I would get started on it now, it may talk some time to 
sort everything out.

Thanks,
Justin

Re: How to add Apache license head to the files of hessian-lite sub project

[Justin Mclean]

Hi,

> Then we need to rollback what we made in hessian-lite module and keep the 
> original license/author info as is. As Justin suggested, pls. also cross 
> check LICENSE file.

Don’t be too concern about what goes in LICENCE and NOTICE right now we can fix 
that up before the first release.

Thanks,
Justin

Re: Prepare for release of v2.6.1

[Justin Mclean]

HI,

This is not going o be an official Apache release is it?

Thanks,
Justin

Re: Suggestions on the organizational form of the code repository after confirming the submission of the dubbo code to apache

[Justin Mclean]

Hi,

> They are release individually. Is it a problem after moving to ASF?

No issue at all.

Thanks,
Justin

Re: Prepare for release of v2.6.1

[Justin Mclean]

Hi,

> I have learned in the previous mail that we can still release as usual before 
> transfer to apache officially. An official Apache release should follow 
> another process, right?

Yep all good.

Thanks,
Justin

Re: dubbo.io is not accessible, working to fix it

[Justin Mclean]

Hi,

> dubbo.io is not accessible right now, because the code repo has been 
> transferred to Apache repo, we are working to fix it.

At some point it would be best to transfer the information from dubbo.io to 
dubbo.apache.org. I assume that is the intention?

Thanks,
Justin

Re: dubbo.io is not accessible, working to fix it

[Justin Mclean]

Hi,

> Right now I think it is better to keep both since dubbo.io is already
> widely known.

I suggest you read up on ASF branding policy in particular [1] and [2]. While 
there have been a couple of exceptions to this it’s probably best to migrate 
that content over to the apache.org site.

Thanks,
Justin

1. https://www.apache.org/foundation/marks/pmcs#websites
2. https://www.apache.org/foundation/marks/pmcs#nonapache

Re: dubbo.io is not accessible, working to fix it

[Justin Mclean]

Hi,

>> A suggestion is that we host all web resources to dubbo.apache.org, and
>> also keep dubbo.io by redirecting dubbo.io to dubbo.apache.org because of
>> the existing users.
> 
> +1 for that.
> 
> Reading the branding policy shows that it is possible to keep dubbo.io
> by redirecting to dubbo.apache.org.

+1 An ideal solution.

Justin

Re: Prepare for release of v2.6.1

[Justin Mclean]

Hi,

> As we are going to move the repo to Apache, will that block your release?

I don’t believe so. As long as it not advertised as an Apache release IMO all 
is good.

Thanks,
Justin

Re: Website Branding Policy

[Justin Mclean]

Hi,

> 1. Gitter channel: https://gitter.im/alibaba/dubbo, is it necessary to
> change to  https://gitter.im/apache/incubator-dubbo?

Necessary probably not, a good idea to do so yes.

> 2. At the bottom of the page, there is a link to promote EDAS, which a
> product in Alibaba Cloud, is that proper to do so?

IMO I’d say no. You could make a page and link to projects that use Dubbo but 
it mustn’t be seen as promotion of one particular vendor or solution.

> 3. In quick start section, the com.alibaba.* group id in still in use,
> is it possible to keep it until next release?

I would be OK with that as long as the long term plan is removed prior to 
graduation.

> 4. According to the policy, we need to add a link back to
> www.apache.org, may be at the bottom of the page?

There a number of other missing links, but these can be worked out over time. 
It best you add the feature logo and link to the ASF in the header.

Does dubbo have a logo? Should it be changed now it’s an ASF project?

> 5. About the trademarks, shall we confirm with trademark@ before
> adding ™ or ® to Apache Dubbo (incubating)? Google tells me that ™
> means it is an unregistered trademark while  ® means it is registered
> trademark in US. So probably we should go for ™ ?

Go with TM. May need another discussion if we need to register it.

> 6. Do we have official logo for Dubbo? If we have one, we need to add
> ™ to that logo.

No expert on this but AFAIK there’s no need to add TM in the logo.

This would help if it was working [1] but as you can see most podling are still 
working on it. [2]

Thanks,
Justin

1. https://whimsy.apache.org/pods/project/dubbo
2. https://whimsy.apache.org/pods/

Re: Website Branding Policy

[Justin Mclean]

Hi,

> It isn't required legally but it is ASF policy. See:
> http://www.apache.org/foundation/marks/pmcs#graphics

" it includes a small "TM" symbol in the graphic or immediately adjacent to it.”

Interesting. I had always thought it's more the later than former

Thanks,
Justin.

Re: Website Branding Policy

[Justin Mclean]

Hi,

Some suggestions:
- I’d remove the download .zip and download .tar.gz buttons. [1]
- Add to the footer word to the effect of "Apache and the Apache feather logo 
are trademarks of The Apache Software Foundation”

Thanks,
Justin

1. http://www.apache.org/legal/release-policy.html#publication

Re: Delete the two duplicated projects: (dubbo/dubbo and dubbo/dubbo.github.io)？

[Justin Mclean]

Hi,

If dubbo.github.io is redirecting to dubbo.apache.opg then there's no need to 
have any of the old content in the https://github.com/dubbo/dubbo.github.io 
repo right? We may still need the repo for the redirect but the content in the 
repo can be removed?

Perhaps it would be a good idea to add a README point to the new repo?

Thanks,.
Justin

Re: Where is the document for the restful configuration?

[Justin Mclean]

Hi,

> Unfortunately it is under Creative Commons 3.0 which is incompatible
> with (category X) Apache.

There’s a lot of variation in CC licenses and not all are Category X in this 
case it’s CC BY-ND 3.0 which would indeed be category X (mostly because of the 
no derivatives part).

Thanks,
Justin

Re: How do we judge whether SGA is need for a contribution?

[Justin Mclean]

Hi,

> Actually I am curious about how to judge whether a SGA is needed for a
> contribution.
> How do we define the amount of code that will meet the criteria?

There’s no exact limit  IMO if it just changes a few lines then no SGA is 
needed and an ICLA may not be needed, if it change dozens of files then it’s 
best to have an ICLA from the person, if it adds new functionality and is 
mostly new code rather than modifies existing code and is many files or a lot 
of code then a SGA is needed. It may also depend on who is submitting it, how 
they are employed and what their employment contact states re ownership of the 
code they wrote as well.

Thanks,
Justin

Re: [DISCUSS] Dubbo Release schedule

[Justin Mclean]

Hi,

> 0. Should we have release manager for these artifacts? Is there any
> committer volunteer to be release manager?

In general Apache project do have release managers.

> 1. Should we keep the release cycle for 2.6.x?  Our first Apache
> release might take some time because we have bunch of things to do
> [1][2][3]. If we need to do keep it, we'd better enter code freeze
> soon as start to prepare for the release.

I would suggest making a release branch and not doing a code freeze as the 
release may take a little time to get right.

One issue I’m concerned about is IP clearance [1] as that is likely to block 
the release.

Thanks,
Justin

1 https://issues.apache.org/jira/browse/DUBBO-3

Re: [DISCUSS] Dubbo Release schedule

[Justin Mclean]

Hi,

> It is not mandatory to change the project groupId to org.apache.dubbo in
> the first release. Is that right? We will finished it before graduating.

It a good idea to change it but some Apache projects never change it as it 
would break too much existing user code.

In Dubbo's case as the packages includes a companies name (com.alibaba.dubbo) 
rather than a product name IMO it would need to change at some point.

If it was changed how much work would it be for existing users? Will it be more 
work for them it the change was done later?

Thanks,
Justin

Re: Suggestions collection for release of dubbo v2.6.2

[Justin Mclean]

Hi,

How is the IP clearance progressing? Do we have a list of the contributors who 
have signed a ICLA?

Thanks,
Justin

1. https://issues.apache.org/jira/browse/DUBBO-3

Re: Suggestions collection for release of dubbo v2.6.2

[Justin Mclean]

Hi,

This is the best guide. [1] Please don’t follow what some TLPs have done like 
Apache Spark or Apache Hadoop as they have way far too much information in 
their NOTICE files.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html

Re: Set up Nexus staging profile for Dubbo (Incubating)

[Justin Mclean]

Hi,

> We are preparing for the first apache incubating release for dubbo, turns out 
> we lack of some nexus permissions, this blocks our process.

The offical release area is not nexus it on the Apache mirrors so this (while 
inconvenient) isn’t a blocker to making an release.

Thanks,
Justin

Re: [DRAFT] Incubator PMC Board Report - May 2018

[Justin Mclean]

Hi,

> We have 2 podlings missing reports, and 3 podlings missing sign offs.  They
> are all CC'd.

I’ve signed off the report if the other mentors could do so that would be great.

Thanks,
Justin

Re: Set up Nexus staging profile for Dubbo (Incubating)

[Justin Mclean]

Hi,

> Most of the dubbo users depend on the maven artifact, therefore I
> think a maven artifact is mandatory from Dubbo's point of view,
> although it is not mandatory according to ASF release policy.

Is it something you could possibly put off until your second ASF second release?

> Can we make a release to the Apache mirror system, and publish it
> separately to nexus?

Yes that’s fine.

Thanks,
Justin

Re: Set up Nexus staging profile for Dubbo (Incubating)

[Justin Mclean]

Hi,

> I don't think so, I think each Dubbo release should contain a maven artifact.

Projects can also release convenience binary artefacts at the same time of a 
source release. It’s a good idea to vote on both at the same time. [1][2]

> That will be great, so after the Apache release, we can publish the
> artifact to nexus just as we used to do (before joining Apache).

Just remember if not voted on then it’s not an official ASF release. It's OK if 
a 3rd party makes available a binary releases from an Apache source release 
just as long as they don’t claim it’s an official ASF release.

Thanks,
Justin

1. http://www.apache.org/legal/release-policy.html#what
2. http://www.apache.org/legal/release-policy.html#compiled-packages

Re: Set up Nexus staging profile for Dubbo (Incubating)

[Justin Mclean]

Hi,

> So that means it is better to publish both the source and binary
> artifact to the Apache mirror system and vote them there.
> The only thing that block us is we can not publish to
> https://repository.apache.org (since our group id not starting with
> org.apache), then to nexus, we want to work around by skipping
> repository.apache.org and publishing to nexus directly.

That works for me and no issues re ASF policy that I can see. I assume this 
will change in the future once the package names have been changed.

Thanks,
Justin

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,

> But nothing prevents Alibaba from publishing under coordinates that they
> control.
> 
> It needs to be clear however that it is alibaba publishing there, not
> Apache.

The has been discussed on list with Dubbo and that’s the approach they are 
going to take with their first release. They are aware will need to change the 
package name at some later point.

Thanks,
Justin

Re: Set up Nexus staging profile for Dubbo (Incubating)

[Justin Mclean]

Hi,

> Was there discussion somewhere that decided to allow an Apache project to 
> publish coordinates using com.alibaba?

The maven artefacts would not be an ASF release only the source release would 
be and published and named as such is my understanding. Maven artefacts are not 
not offical releases. The package name will change in a future release.

Thanks,
Justin

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,

> Maybe the first release should be Apache for the source with Alibaba making 
> the binary release through their current Maven release process.

Which is my understanding of what they are going to do. They were also going to 
vote on the binary to check it’s OK but not have that as part of the ASF 
release. I think we’re all on the same page here.

Thanks,
Justin

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,

>> ...The maven artifact is the most significant for most of the Dubbo
>> users, so we want to include a maven artifact in the release
> 
> Binaries are NOT part of Apache Releases, as mentioned earlier in this thread.

Apache Dubbo is aware of that and it has been made clear on the dev list 
several times. The context above is that it’s users are not aware of that 
(currently) and not all want to compile from source. Other projects (ie Apache 
Flex or Apache Open Office) face the same issue, although probably to a greater 
extent.

> Dubbo mentors, I think we need a clear description of how these
> "hybrid" releases are done, to avoid any misunderstandings.

The release process will be documented as part of the release to document and 
help future release managers.

Here’s two threads on the release [1][2] that might help. (Note most of the 
emails there predates this discussion).

Thanks,
Justin 

1. 
https://lists.apache.org/thread.html/114d04c1aaa8141ba99ef14bc75081c512989b55c9b0a81636704fa6@%3Cdev.dubbo.apache.org%3E
2. 
https://lists.apache.org/thread.html/5265f8fc0315270f5b908f38a4e47c856784bc39214af6ffa3efcdf4@%3Cdev.dubbo.apache.org%3E

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,

> There is NO WAY to verify a binary. Even compiling from source to binary on
> your machine, and trying to compare against a target binary will generally
> fail since timestamps are embedded. Or maybe there are different compilers
> being used.

As per ASF policy a connivance binary can be release as the same time [1] and 
it needs to comply with license and notice policy [2].

It usually very easy to check a binary (and I’ve done it 100’s of time) by 
uncompress the jar or just editing it directly to see what is bundled inside it.

Thanks,
Justin

1. http://www.apache.org/legal/release-policy.html#compiled-packages
2. http://www.apache.org/dev/licensing-howto.html#binary

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,

>> As a mentor, I strongly advise against podlings making binary releases, 
>> especially for the first release.
>> It’s difficult enough to get L&N correct for source releases, and when a 
>> binary release is being make
>> at the same time with necessarily different L&N, the PPMC tend to get 
>> hopelessly confused.
> 
> Big +1 here. This is exactly what I advise my podlings as well.

Which was the advice given here but as most of their users use the binary not 
the source it was decided to do both.

Thanks,
Justin

Dubbo release candidate

[Justin Mclean]

Hi,

I saw that a release candidate has been put up here [1] and I had a quick look 
at it. It looks good to me with a couple of minor issues:
- The binary LICENSE fails to mention FastJSON (but as this is ALv2 it’s not 
required) Not this will make the connivance binary LICENSE file different to 
the source LICENSE file
- The binary jars in libs are missing LICENSE and NOTICE files in META-INF

You may want to fix these before calling a vote but I think this sees could be 
fixed in the next release if you prefer that. Other mentors/PMC member may have 
a different opinion to me.

Thanks,
Justin

1. https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.2/

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,

Looking at the release candidate just made both the license and notice for the 
source release and the connivance binary are going to be just about identical 
as there's only 2 3rd party jars included and none of the other jars contain 
3rd party code (other than what is mentioned in LICENSE), both the 3rd party 
jars are apache licensed so it’s optional if they are mention in LICENSE. Nice 
if they are but not essential. [1] Neither have NOTICE file so there no effect 
on the Apache Dubbo’s NOTICE.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#alv2-dep

Re: Dubbo release candidate

[Justin Mclean]

Hi,

> Just a quick question, should the LICENSE and NOTICE file in META-INF
> only contain information in this specific jar, or should contain
> information of the entire binary?

I’d go with what is in the jar as per [1] (as I jar could be pulled out and 
used on it’s own) but it’s not a big deal for the first release. Having them al 
the same IMO as having a little too much is a documentation issue not a 
licensing issue.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#guiding-principle

Re: Dubbo release candidate

[Justin Mclean]

Hi,

>> - The binary LICENSE fails to mention FastJSON (but as this is ALv2 it’s not 
>> required) Not this will make the connivance binary LICENSE file different to 
>> the source LICENSE file
> 
> FastJSON should not be part of the binary release, should be caused by a bug 
> of filters, i will remove it.

Which is another way of fixing it and you don’t need to change the LICENSE or 
NOTICE. 

What about hessian-lite-3.2.2.jar should that be there?

Thanks,
Justin

Re: Dubbo release candidate

[Justin Mclean]

Hi,

> hessian-lite-3.2.2.jar is a part of this release, both resource and binary 
> should include hessian-lite. So now we need add clarification of hessian-lite 
> in the LICENSE and NOTICE files in libs, right?

It’s ALv2 and from what I can see there no notice file. Is that correct? If so 
it could be added to LICENSE but it’s not required and no changes are needed 
for NOTICE.

Thanks,
Justin

Re: Moving hessian-lite from Dubbo codebase to eco-system

[Justin Mclean]

Hi,

> Now we are considering that moving it to Dubbo eco-system, which is
> https://github/dubbo.
> 
> How do you think about this?

I don’t know the history here so the answer to these questions may be obvious 
to someone eon the project. What do the owner / maintainers of hessian-lite 
think about that? Is there any need to fork their version? Can you just use 
their released version?

Thanks,
Justin

[Mentors] IP clearance

[Justin Mclean]

Hi,

A lot of work has been done on the IP clearance. [1]

IMO given the 4 people mention in the JIRA to be contacted has all contributed 
less than 10 lines of code each I don't see this as holding up the release 
while we wait for a reply / ICLA from them. Absolute worse case code can be 
removed in a later release.

What do other mentors think about this?

Thanks,
Justin

1. https://issues.apache.org/jira/browse/DUBBO-3

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.2 [RC1]

[Justin Mclean]

HI,

> I don’t think we need to change the release tag hash. Tag ‘dubbo-2.6.2’ has 
> never changed, so the source release, binary release and the release tag are 
> still in consistent to each other.  Be aware that CHANGES.md only exists in 
> the ‘2.6.2-release’ branch,  a branch we used for release purpose, it serves 
> for the release process but not bounded. 

As tags are mutable in git it best to specify the hash in the release vote 
email (ie afab04c).

Thanks,
Justin

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.2 [RC1]

[Justin Mclean]

Hi,

+1 (binding)

I checked:
- Incubating in name
- Signatures and hashes good
- DISCLAIMER exists
- LICENSE and NOTICE good
- A number of pom.xml and log4j.xml files haven’t had their headers changed to 
the standard ASF one and are still copyright Alibaba (about 14 files) e.g [4][5]
- A couple of .sh files are missing ASF headers in [6] also here [9] and here 
[10]
- No unexpected binary files in the release
- Can compile from source

I also checked the binary convenience release and it's all good re signatures, 
naming, disclaimer, licenses and notice.

Some very minor issues (and IMO except for the MD5 issue) can be fixed next 
release:
- Can you remove the MD5 hashes please they are not needed and don’t follow the 
current release policy. [1]
- The source unzips into an odd directory name "dubbo-parent-2.6.2”, 
“apache-dubbo-2.6.2” would be better.
- The code of conduct may need some small updates for instance I see 
"du...@googlegroups.com” mentioned.
- The README.md has links to information would be nice to include build 
instructions inside the README
- A few poms have some out of date information [2][3]
- The contributing document need a couple of minor updates (eg @author tags are 
not used at Apache)
- LICENSE includes " Copyright (c) 2001-2004 Caucho Technology, Inc” but some 
of the header have the date range 2001-2008
- Should these files be in the release? [7][8]
- Maven check style plugin is taking a long time when compiling (10+minutes) 
and runs out of memory on my machine. Disabling it (-Dcheckstyle.skip) reduced 
compile time to under a minute.

I’ve not checked if the compile source actually works (which is sort of 
important) so might be good if a few people check that when voting +1 :-)

Well done! It's not often I get to vote +1 on the first RC of a first release 
by a project.

Thanks,
Justin

1. https://www.apache.org/dev/release-distribution.html#sigs-and-sums
2. ./bom/pom.xml
3. ./dependencies-bom/pom.xml
4. ./dubbo-rpc/dubbo-rpc-rest/pom.xml
5. ./dubbo-common/src/test/resources/log4j.xml
6. 
dubbo-container/dubbo-container-api/src/main/resources/META-INF/assembly/bin/*.sh
7. dubbo-rpc/dubbo-rpc-default/dubbo.log
8. dubbo-rpc/dubbo-rpc-dubbo/dubbo.log
9. dubbo-test/dubbo-test-benchmark/src/main/resources/run.*
10. dubbo-test/dubbo-test-benchmark/src/test/resources/server/*.sh

Re: [Suggestion] Add maven wrapper

[Justin Mclean]

Hi,

Just be aware you can’t put maven-wrapper.jar in a source release as it’s 
compile code.

Thanks,
Justin

Re: Release notification of Apache Dubbo (Incubating) V2.6.2.

[Justin Mclean]

HI,

> One more thing to do: we need to using the Apache download link[1] for
> download. I am going to add it to website.

Yes that required.

> The current Github release note contains a download link [2], can we
> change that?


Basically you shouldn't use github releases, but it’s not IMO a big deal, it 
just not an official release even if it contents are identical.

Thanks,
Justin

Re: [Call for talks]: Dubbo Shanghai meetup

[Justin Mclean]

Hi,

> Please submit your ideas before June 13rd by sending email to
> priv...@dubbo.apache.org

I don't see that this would be private. Any reason for that suggestion?

Thanks,
Justin

Re: Planing to rename dubbo package to org.apache

[Justin Mclean]

Hi,

> I suggest that we have to freeze new comming PR after notification community.

Up to the PMC but I think this will cause more issues than it will solve. Lets 
see what other people say in this thread.

Thanks,
Justin

Re: Dubbo new logo and new website

[Justin Mclean]

Hi,

The "Alibaba folks" should be doing the work on this list as individuals in
the open. Doing the development off list then putting in a github repo once
done is not how Apache works. Ideally they should be making PRs against the
existing web site.

The community should also be involved in the development of the new site.
Perhaps first off ask for submissions from all committers on the new logo
and then vote on the one to use.

Thanks,
Justin

On Thu, Jun 7, 2018 at 4:16 PM, Huxing Zhang  wrote:

> Hi community,
>
> Just want to let the community to know that I am working with some of
> the Alibaba folks to create a new website and new logo.
>
> The new website/logo will have complete fresh design, including the
> following contents:
>
> * home page
> * documentation
> * blogs
> * community
> * events
>
> All of them will have English/Chinese versions.
>
> The implementation is still under way, and would be available in a
> separate Github repo once finished.
>
> The new repo is designed to be a combination of current
> incubator-dubbo-docs and incubator-dubbo-website.
>
> I have a quick question for this, if the community have decided to
> accept the new logo/website, can a  Software Grant or CLA cover it?
>
>
> --
> Best Regards！
> Huxing
>

Re: Dubbo new logo and new website

[Justin Mclean]

Hi,

> Designing a new logo requires skills which the committers might lack of.

They might they may not or they may know people who help, several projects I 
know have gotten a new logo this way.

Thanks,
Justin

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.3 [RC3]

[Justin Mclean]

Hi,

Having extra information in license or notice is unfortunate but IMO it's
just a documentation issue  rather than a licensing error. I think it can
be fixed in the next release.

Thanks,
Justin

On Wed., 8 Aug. 2018, 11:36 am jun liu,  wrote:

> > Each package MUST provide a LICENSE file and a NOTICE file which
> > account for the package's exact content. LICENSE and NOTICE MUST NOT
> > provide unnecessary information about materials which are not bundled
> > in the package, such as separately downloaded dependencies.
> >
> > So I suggest to fix this issue and redo the vote.
> >
> > [1]
> http://www.apache.org/legal/release-policy.html#licensing-documentation <
> http://www.apache.org/legal/release-policy.html#licensing-documentation>
> I am not sure if we need to redo the vote for this issue, I wonder what do
> other developers think?
>
> Best regards,
> Jun
>
> > On 7 Aug 2018, at 10:38, Huxing Zhang  wrote:
> >
> > Hi,
> >
> > Since we remove the hessian-lite, I suggest we remove the license info
> > in LICENSE.
> >
> > I checked ASF release policy[1], it says:
> >
> > Each package MUST provide a LICENSE file and a NOTICE file which
> > account for the package's exact content. LICENSE and NOTICE MUST NOT
> > provide unnecessary information about materials which are not bundled
> > in the package, such as separately downloaded dependencies.
> >
> > So I suggest to fix this issue and redo the vote.
> >
> > [1]
> http://www.apache.org/legal/release-policy.html#licensing-documentation
> >
> >
> >
> > On Mon, Aug 6, 2018 at 1:59 PM Jun Liu  wrote:
> >>> Hello Dubbo Community,
> >>
> >> This is a call for vote to release Apache Dubbo (Incubating) version
> 2.6.3.
> >>
> >> The release candidates (RC3):
> >> https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.3
> >>
> >> Git tag for the release (RC3):
> >> https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.3
> >>
> >> Hash for the release tag:
> >> 22899a4b395411496ebf03c514e7674e8073e0c3
> >>
> >> Release Notes:
> >> https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.3/CHANGES.md
> >>
> >> The artifacts have been signed with Key : 28681CB1, which can be found
> in the keys file:
> >> https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
> >>
> >> The vote will be open for at least 72 hours or until necessary number
> of votes are reached.
> >>
> >> Please vote accordingly:
> >>
> >> [ ] +1 approve
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove with the reason
> >>
> >> The previously RC2 vote thread:
> >>
> https://lists.apache.org/thread.html/39a25c905a46e7281b96f98a23f795c796616a9a20623c0bed8b90db@%3Cdev.dubbo.apache.org%3E
> >>
> >> Thanks,
> >> The Apache Dubbo (Incubating) Team
> >>
> >
> >
> > --
> > Best Regards！
> > Huxing
>
>

Re: [incubator-dubbo-website] branch asf-site updated: Google Analytics support

[Justin Mclean]

Hi,

I know of other Apache projects that also use google analytics, that’s not to 
say it right to do so, but currently we don’t really have any direction or 
policy on this so it’s hard to know what to do.

Thanks,
Justin 

Re: Use of "Team N" in issues and PRs

[Justin Mclean]

Hi,

Thanks Mark for the great advice here in this thread. Just about every time I 
see something I should respond to Mark gets there first and puts it way better 
than I could. :-)

> PS I see there is a Dubbo session at ApacheCon NA. I'd be more than
> happy to sit down with anyone that is interested and chat about any
> questions, concerns, etc. they may have about how the ASF works, why
> things are the way the are and any other ASF related questions.

I’m also at ApacheCon NA and can be involved in that. I will also be attending 
COSCon’18 in Shenzhen and another conference in Shanghai the week before that 
so if anyone wants to meet up please get in touch.

Thanks,
Justin

Re: [Help Wanted] A tricky issue when preparing for 2.6.3 Apache release vote.

[Justin Mclean]

Hi,

> We got a tricky problem when preparing for v2.6.3 release RC4, and we need 
> more inputs for what to do next. The problem is:
> While we are preparing for the RC4 Apache release vote, we found that the 
> binary maven release has been deployed to the central repository 

IMO I’d remove it right away. Apache project’s cannot release artefacts without 
having the PPMC/IPMC voting on them. [1][2]

Thanks,
Justin

1. http://www.apache.org/legal/release-policy.html#release-approval
2. http://www.apache.org/legal/release-policy.html#publication

Re: [Help Wanted] A tricky issue when preparing for 2.6.3 Apache release vote.

[Justin Mclean]

Hi,

Also what can do done to stop this happening accidentally in the future?

Thanks,
Justin

Re: [DRAFT] Dubbo incubator Report - September 2018

[Justin Mclean]

Hi,

> * The following projects has been added to Dubbo ecosystem:
>* dubbo-php-frmework
>* dubbo-serialiazation-avro
>* dubbo-sentinel-support
>* Intellij IDEA plugin
>* dubbo-rpc-native-thrift

I have some concerns with what is happening here. This is at 
https://github.com/dubbo correct? which is not part of the Apache repo.  First 
off why is it that this development is occurring (and in some cases moved to) 
outside of the project? Is the long term goal to bring that code back into the 
project, if so this may be difficult as contributor may not of signed ICLA and 
maybe hard to track down.

> * Dubbo has joined CNCF landscape

I assume you mean this? https://landscape.cncf.io

> * Mailing list stats:
>* June: 195 emails, 41 topics,  32 participants
>* July: 248 emails, 46 topics,  45 participants
>* August: 193 emails, 33 topics, 44, participants

Rather than just reporting stats, say some thing about if mailing list activity 
has increased or decreased and why you think that may be.

> * Github stats (since last report 2018-06-05):
>* 335 issues closed
>* 270 pr closed

Some here.

> When were the last committers or PPMC members elected?
> 2018-08-20

You should add the committer name as well.

Thanks,
Justin

Re: [DRAFT] Dubbo incubator Report - September 2018

[Justin Mclean]

HI,

Just a couple of questions below for people to ponder and I think it worth 
having a discussion on list about this. I don’t think having this external repo 
is a bad idea or against ASF policy but long term it could harm the project. 
For instance only contributions to the Apache project can be considered when 
voting committers or PMC members in. So contribution to the eco system doesn't 
accrue merit in the project eyes. You may run into licensing and other IP 
issues without ICLA to cover all contributions. Projects in the eco system may 
not follow the release or other ASF policies. I can see that several already 
don’t follow the ASF licensing policy, which is OK as they are not ASF 
projects, but if you want to use them with Dubbo that could cause issues. You 
see the sort of issues that could occur here?

What do other mentors think about this?

> Justin, this is dubbo eco system, including some artifacts built against
> dubbo extension machanism, polyglot support, samples, scaffold, etc., which
> are apparently not suitable to put in dubbo's main project.

Why is it not suitable? You can create multiple repos at Apache. The project 
can have multiple projects and release them on different schedules.

> It is a long term goal to build up eco system around dubbo as rich as
> possible, and it is a common practice to attract more developers and
> contributors,

Why wouldn’t that be done at Apache rather than external to it? By attracting 
developers and contributed to the eco systems you are removing  them as 
potential committers in Apache Dubbo.

> for example: https://github.com/grpc-ecosystem. Besides,
> right now GitHub doesn't support 2nd level group like
> github.com/apache/dubbo.

Why is that needed? Do you really need a two tier community model?

> If the only problem is ICLA, we could ask the corresponding contributor (in
> fact, a member in dubbo group) to sign it when the community see the
> necessity to move his/her works back into apache group.

No that not the only issue (see above) and you would probably need to get all 
contributors to sign and it can be hard to track them all down. Employment 
contracts may also become an issue regards who owns the IP. What if it turns 
out a contributor didn’t actually own their contributions?

Thanks,
Justin

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.3 [RC5]

[Justin Mclean]

Hi,

It’s best to keep votes open for a minimum of 72 hours before announcing the 
results.

Thanks,
Justin

Re: [DRAFT] Dubbo incubator Report - September 2018

[Justin Mclean]

Hi,

I note under "How has the community developed since the last report?”

you have.

* The following projects has been added to Dubbo ecosystem:
* dubbo-php-frmework
* dubbo-serialiazation-avro
* dubbo-sentinel-support
* Intellij IDEA plugin
* dubbo-rpc-native-thrift

As these are not part of the Apache project I would suggest that you make it 
clear in the report that these are not an official Apache repos.  The term 
"Dubbo ecosystem” could easily be confused as belonging to the Apache project 
(and this following it’s policies) perhaps it would be bette to refer to it as 
the “external Apache Dubbo ecosystem”?

Thanks,
Justin

Re: MODERATE for dev@dubbo.apache.org

[Justin Mclean]

Hi,

> I am not sure why this can't be sent to dev mailing list, even I've accepted 
> it.

Thanks for that. I can see the report has already been changed.

I sent it form the wrong address I’ll try not to do that in future.

Thanks,
Justin

Re: Meet Dubbo

[Justin Mclean]

Hi,

Nice article and I like the story you tell in going from user to contributor to 
committer and how developing open source code using the Apache Way involves the 
community. (I read it via google translate.)

Thanks,
Justin

Re: The chats must be public

[Justin Mclean]

Hi,

I suggest you don't use slack or any other instant message as doing will
exclude some people due to the platform used or time zone they are in or
language used. Also these conversations can be hard to search and may not
be archived.

All decisions need be made in publc on the mailing list and it should be
the primary firm of communication.

Thanks,
Justin

On Fri., 7 Sep. 2018, 2:17 pm Ian Luo,  wrote:

> I lean to use Slack for main means of chatting. Dingtalk is popular in
> China, but it is indeed inappropriate for public communication. I agree we
> should change.
>
> I tried the-asf workspace. It looks like it accepts subscriptions from
> apache committers only.
>
> What about one dedicated workspace for Dubbo? In this way, we could gather
> both dubbo user and dubbo developer in one single place, and more
> important, all discussions are public.
>
> What do you think?
>
> -Ian.
>
>
> On Fri, Sep 7, 2018 at 11:33 AM Jerrick Zhu  wrote:
>
> > hi, community
> >
> > Now, we have some chat groups, which are used to discuss about dubbo,
> such
> > as:
> >
> > * Dingtalk group, nearly 30 people, committers and contributors
> > * WeChat group, contains committers, contributors, and many users
> >
> > I think we need to public these chat groups, so that all people can join
> > us.
> >
> > Maybe Gitter? or Slack ?
> >
> > Or maybe we can drop the chat, just use the mailing list and github issue
> > for discuss.
> >
> > Any other suggestions?
> >
> > Sincerely.
> >
> > jerrick
> >
>

Re: The chats must be public

[Justin Mclean]

Hi,

> But it is a different story for Dubbo users.

You should be asking the users to use the mailing list as well. Users become 
contributors become committers.

> What I am worrying is where we could group them all together in one single 
> place.

If the user traffic gets too large for this list then you can make a seperate 
users@dubbo mailing list

> People need a place to know each other, to learn from each other, to talk 
> about Dubbo. Dubbo users
> keep asking us what WeChat group we are maintaining for Dubbo.

If they are just chatting about the project that fine but think of this 
scenario. A user asks a question and it gets a good answer, the answer could 
help out users who haven't asked it but are following the conversation, if it 
archived in the mailing list [1] it can help future users who can search for 
that answer. On some chat application that may not be open to everyone or not 
archives the answer is lost. Or worse the content placed on it may not be 
licensed in a way that is open for all to use.

Also being a mailing list people tend to think a little more about their 
replies and you get higher quality bandwidth, there’s a little less incidental 
chatter about pets and the weather.

> This is a dilemma we are facing today. I believe the fact of IM getting
> popular happens too in Western

Just because it popular doesn’t mean we use it at the ASF. It also has to fit 
in with our values of openness and transparency for instance.

> With regarding to Dubbo contributors, they have need of casual tech talk
> too. If there's no place allowed, then the tech talk will not happen at
> all. 

I think that sort of conversation should be happening on the mailing list. It 
not that it’s not allowed it just that if conversations are happening elsewhere 
the community isn’t going to grow and attract new committers as fast as it 
could.

> Last but not least, today's traffic in this mailing list is pretty low
> since Dubbo contributors contribute the vast majority.

Which I have listed as a (minor) concern in the current report to the board.

> I really interested to learn any success story to attract users into a 
> mailing list, especially
> for the peoples who are not native English speakers.

And the language barrier is a difficult issue. I think it find to not post in 
English with a google (or other) translation so everyone has some idea of what 
is being said. That being said a large number of Apache project have people who 
are not native English speakers and it generally works. We get commits from all 
over the world all the time. (There’s a web site showing commits by location I 
see if I can find it.)

Thanks,
Justin

Re: NOTICE file enhancement

[Justin Mclean]

Hi,

>>> This product contains code derived from Google Guava project, which is
>>> available under a "Apache License 2.0" license.
>>> (https://github.com/google/guava ).
>>> 
>>> This product contains code derived from the Netty Project, which is
>>> available under a "Apache License 2.0" license.
>>> (https://github.com/netty/netty )

First off license information should not be repeated in NOTICE [1], it belongs 
in LICENSE and there no need to add URLs in NOTICE to repo unless it is 
specified in the license conditions (so called required 3rd-party notices). [2]

The Guava project doesn’t have a NOTICE file so nothing needs to be added for 
it.

The Netty project has a long (and sadly IMO malformed) NOTICE file.

I would suggest you just add:

"This product contains code form the Netty Project:

The Netty Project
=
Please visit the Netty web site for more information:
  * http://netty.io/

Copyright 2014 The Netty Project”

Normally I would not add the URL but as they have it in their NOTICE file we 
should include it. [3]

Also double check if any of the code copies from Netty is from anything 
mentioned further down in Netty’s NOTICE file. If it is we would need to add 
more to the NOTICE file.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#mod-notice
2. https://www.apache.org/legal/resolved.html#required-third-party-notices
3. http://www.apache.org/dev/licensing-howto.html#alv2-dep

Re: [Discuss]Prepare for the next release v2.6.4

[Justin Mclean]

Hi,

> Yes, I think we need a new manager to do the next release, to get familiar 
> with and improve the release process.
> But I'm not sure if anyone has committer privilege is allowed to be the 
> release manager or only PMCs are allowed.

Anyone can be a release manager, but in practical term you need to be a 
committer or PMC member in order to get stuff done.

Thanks,
Justin

Re: [DISCUSS] A metric to measure the response time to issues/prs

[Justin Mclean]

HI,

> I'd suggest not worrying about the metric and concentrating on growing
> the community. Look for people who contribute and keep the bar low for
> committership.

+1 (again) to what Mark said.

I like metrics, and they can be useful for discover issues, or tracking X over 
time to see how things are going, but on their own without any action they 
don’t mean anything. You have a huge amount of activity going on and I’m sure 
there some committer worthy people in that.

Thanks,
Justin

Re: Podling Report Reminder - September 2018

[Justin Mclean]

Hi,

Sorry please ignore this, it was sent in error.

Thanks,
Justin

Re: NOTICE file enhancement

[Justin Mclean]

Hi,

The link provided is not that useful as  it doesn't take into consideration
ASF policy on licensed and notice files. I suggest you read [1].

IMO it does need to be included.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#mod-notice

Re: NOTICE file enhancement

[Justin Mclean]

Hi,

Btw the source bundle does include Netty code.
So it's not just the binary that needs it.

Thanks
Justin

Re: NOTICE file enhancement

[Justin Mclean]

Hi,

All mostly correct and I’ve clarified a few things where needed.

> Because the bundled Google Guava and Netty both contain no bundled
> subcomponents under other licenses

Well Netty does contain 3rd party bundled sub component but it incorrectly list 
then in NOTICE not LICENSE. I don't think you include any of these however.

> Because Netty does supply a NOTICE file, and it is Apache licensed, we
> should analyze whether we should modify NOTICE file.

Yes.

> According to "MODIFICATIONS TO NOTICE",  because Dubbo has relocated
> several classes from Netty, and these files contain copyright notice,
> we must modify NOTICE file to add Netty copyright notifications and
> then change the source file header to remove the copyright notice.

Relocated copyright are those where the copyright in the header has been 
removed with permission, usually as part of a software grant [1], that’s not 
the case here.

> That is my understanding of why we should add Netty's copyright notice
> to NOTICE file.

Close, but it's because it’s in the their NOTICE file and the contain of that 
NOTICE file (that are needed) need to be carried over.

> 1. The source file header of classes under
> org.apache.dubbo.common.threadlocal should be changed by removing the
> copyright Notice from Netty.

Please don’t. Never remove or modify headers from 3rd party files unless you 
have explicit permission from them to do so. [2]

Thanks,
Justin

1. https://www.apache.org/legal/src-headers.html#headers
2. https://www.apache.org/legal/src-headers.html#3party

Re: A little thought about the offline meetup

[Justin Mclean]

Hi,

> Yesterday Alibaba Group held a small offline meetup, I was fortunate to
> participate and did some communication with Justin.

I’m glad you found it helpful, if you have any other questions please ask them 
here.

> The discussion in the mailing list should not be limited to dubbo's issue
> list or pr list. The meaning of open source is not just open code.

+1 I’d also like to see more discussion on this list to help the community grow.

Thanks,
Justin

Re: Meetup in Hangzhou

[Justin Mclean]

Hi,

Actually I strongly suggest we should do it in a more open way next
> time, e.g. announce the meetup, and call for talks from the mailing list.
>

I strongly suggest you also do this.

Why is the "meetup management committee" not discussing this on list? and
why are they separate from the PPMC?

Thanks,
Justin

>

Re: Meetup in Hangzhou

[Justin Mclean]

Hi,

> For some private information, at least they should contact the
> @private list.

Why does any of this need to be private? Open transparent discussion that 
involves all of the community is the goal here.

If it’s the speaker selection that the issue then that could be done by the PMC 
on the private list.

> They are separated because some of the organizers are not in the Dubbo
> PPMC.

All the more reason to discuss this on the dev list.

> But some of the PPMC are involved.

Which means the whole PMC was not and that’s an issue.

Thanks,
Justin

Incubator Podling Report (Due 5th December)

[Justin Mclean]

Hi,

The incubator PMC would appreciated if you could complete the podling report on 
time it's due on 5th December in a few days. It takes time to prepare the 
incubator report, have your mentors sign off the report and for the board to 
review it, so it's best if you can get it in early.

Thanks,
Justin

Re: [DRAFT] Dubbo incubator Report - December 2018

[Justin Mclean]

Hi,

While the statistic are interesting it’s better to tell the story behind them 
and why they have changed. For instance the mail and GitHub stats don’t really 
mean much on their own, but it would be nice to know why there’s been an 
increase in closed PRs (I don’t know). Or why that their been a sudden influx 
of committers and PMC members (I can take a guess at this). You may also want 
to mention any meetups, conferences and similar events that have happened that 
have helped community growth since the last report.

Thanks,
Justin

Naming of non-ASF releases

[Justin Mclean]

HI,

From Mark:
> On a related topic, if this component is remaining outside the ASF it
> will need to change its name.

Looking up a couple of directories I can see a large number of releases using 
the dubbo name:
dubbo-bom/
dubbo-bootstrap/ 
dubbo-cluster/
dubbo-common/
dubbo-config/
dubbo-config-api/
dubbo-config-spring/
dubbo-container/
dubbo-container-api/  
dubbo-container-log4j/
dubbo-container-logback/ 
dubbo-container-spring/
dubbo-dependencies-bom/   
dubbo-filter/
dubbo-filter-cache/  
dubbo-filter-validation/   
dubbo-monitor/
dubbo-monitor-api/
dubbo-monitor-default/
dubbo-parent/  
dubbo-plugin/
dubbo-qos/
dubbo-registry/
dubbo-registry-api/
dubbo-registry-default/
dubbo-registry-multicast/
dubbo-registry-nacos/
dubbo-registry-redis/
dubbo-registry-zookeeper/
dubbo-remoting/
dubbo-remoting-api/
dubbo-remoting-grizzly/
dubbo-remoting-http/
dubbo-remoting-mina/
dubbo-remoting-netty/
dubbo-remoting-netty4/
dubbo-remoting-p2p/
dubbo-remoting-zookeeper/
dubbo-rpc/
dubbo-rpc-api/
dubbo-rpc-dubbo/
dubbo-rpc-hessian/
dubbo-rpc-http/
dubbo-rpc-injvm/
dubbo-rpc-memcached/
dubbo-rpc-redis/
dubbo-rpc-rest/
dubbo-rpc-rmi/
dubbo-rpc-thrift/
dubbo-rpc-webservice/
dubbo-serialization/
dubbo-serialization-api/
dubbo-serialization-fastjson/
dubbo-serialization-fst/
dubbo-serialization-hessian2/
dubbo-serialization-jdk/
dubbo-serialization-kryo/   

What are these projects are and is there any reason they are not part of Apache 
Dubbo?

Re naming, I think (as Mark said) this applies [1].

Thanks,
Justin

1. https://www.apache.org/foundation/marks/faq/#products

Re: Naming of non-ASF releases

[Justin Mclean]

Hi,

> Where did you get the list?

http://central.maven.org/maven2/com/alibaba/

> Most of them are Apache Dubbo modules.

I assumed some may be left over from the donation / old releases predating 
apache donation but not 100% sure if that accounts for all of them.

Thanks,
Justin

Re: Naming of non-ASF releases

[Justin Mclean]

Hi,

> I checked the list, excepted for the dubbo-registry-nacos, all of them are 
> Apache Dubbo modules.

Except that they are not still under Alibaba package and have been updated 
recently. I would understand if there has been no updates but that doesn't seem 
to the the case. If they are old artefacts then they shouldn’t be updated, if 
they are part of an official release they should only be updated when there is 
an official release, if they are not offical releases they can’t use the Dubbo 
name. Sorry but something doesn’t seem right here.

Thanks,
Justin

Re: Naming of non-ASF releases

[Justin Mclean]

Hi,

> @huxing, I think we should re-organize the ecosystem module release in Dubbo 
> community. @Justin, I also have a question, consider we have so many modules 
> in podling stage, everyone has its own release cycle, Is there a more 
> convenient way to do these releases, especially to push them to a central 
> repository :-)

In general all releases need to be voted on and approved by the PPMC before 
they can be pushed to a central repo. The binary connivance release needs to 
reflect what is in a source release so that usually done by voting on a release 
that contains many of these modules. If they do have different release cycles 
then that may before more difficult.

Thanks,
Justin

Re: Naming of non-ASF releases

[Justin Mclean]

Hi,

> First, all the artifacts, except dubbo-registry-nacos, are only
> updated when there is an official release. I didn't see any unexpected
> behavior there.

Taking one at random  [1] I see:

2.6.1 2018-03-15 
2.6.2 2018-06-05 
2.6.3 2018-08-05
2.6.4 2018-10-08 
2.6.5 2018-11-13

2.6.2 was released  2018-06-07, 2.6.3 was 2018-09-11, 2.6.4 was 2018-10-08 and 
2.6.5 was 2018-11-23. Why do the dates above in most cases pre-date the actual 
release date? Now I could be mistaken I but I would expect [1] to show publish 
dates and those should occur after the release has been voted on.

Also why are these still being released under com.alibaba and not 
org.apache.dubbo? Or is that to come in the 3.x branch?

> When you say something doesn't seem right, are you saying about 
> dubbo-registry-nacos? If the community agrees to transfer it to ASF, would 
> that solve this issue?

That’s would fix that issue yes.

Thanks,
Justin

1. http://central.maven.org/maven2/com/alibaba/dubbo-filter/
2. https://github.com/apache/incubator-dubbo/tree/2.6.x/dubbo-filter

Re: Naming of non-ASF releases

[Justin Mclean]

Hi,

> Regarding 2.6.3, it is due to some tricky issues described here[3].
> 
> Regarding 2.6.5, I am not quite sure but I suspect the same reason as 2.6.3.

Thanks for the explanation, that looks like something that needs to be kept an 
eye on. You don’t wan to making releases before the vote is over.

> Yes. 2.6.5 is a maintenance branch. 2.7.x branch will be released under 
> org.apache.dubbo.

Great!

Thanks,
Justin

Re: Donate dubbo-registry-nacos

[Justin Mclean]

Hi,

Out of interest have the 2 contributors signed ICLAs?

Thanks,
Justin

Re: Donate dubbo-registry-nacos

[Justin Mclean]

Hi,

> Yes, both of them are Dubbo ppmc member.cI think we need a software grant 
> here, shall we?

Give both people involved have signed ICLAs and the code in Apache licensed 
it’s probably not required. It may depend on who actually owns the code 
(usually the company those people work for but it depends on their employment 
conditions and contract).

Thanks,
Justin

Re: [Notification of V2.7.0] Status, TODOs, Possible Release Schedules.

[Justin Mclean]

Hi,

> You may need to update the NOTICE file.

There’s no need as it has no NOTICE file [1]. (It’s license file isn’t correct 
either but that’s not Dubbo’s issue).

Thanks,
Justin

1. https://github.com/alibaba/fastjson

Re: Junit5 source file, do I need to mark it in the LICENSE file?

[Justin Mclean]

Hi,

> I have a question :I ues junit-jupiter5.3.2, but for some test cases, I
> copied some source code from junit 5.4.0.M1 , the files are as follow :
>org.junit.jupiter.api.support.io.TempDirectory.java
> 
> org.junit.jupiter.api.MethodDescriptororg.junit.jupiter.api.TestMethodOrderorg.junit.jupiter.api.Orderorg.junit.jupiter.api.MethodOrdererorg.junit.jupiter.api.MethodOrdererContextorg.junit.jupiter.api.MethodDescriptor
> 
> the license is Eclipse Public License - v 2.0
> Do I need to mark it in the LICENSE file?

Sorry EPL is considered "Category B”  [1] and isn’t fully compatible with ALv2 
can’t be included in a source release. Is there another way of doing this?

if it was the connivance binary then yes you would need to put it in the 
LICENSE.

Thanks,
Justin

1. https://www.apache.org/legal/resolved.html#category-b

Re: Junit5 source file, do I need to mark it in the LICENSE file?

[Justin Mclean]

Hi,

> if it was the connivance binary then yes you would need to put it in the 
> LICENSE.

Sorry I mean “convenience binary” i.e. a binary made fro a source package for 
the convenience of users who don’t want to compile the source code.

Justin

Re: [VOTE]: Release Apache Dubbo Spring Boot Project (Incubating) 0.2.1 and 0.1.2 [RC1]

[Justin Mclean]

Hi,

> - I found .png file in source release, which is a binary file, it that
> allowed? Did not confirm with ASF release policy yet.

just confirming this is fine. It’s any binary that contains compiled code 
that's not allowed cos then it would not be open source.

Thanks,
Justin

Re: [VOTE]: Release Apache Dubbo OPS(Incubating) 0.1[RC2]

[Justin Mclean]

Hi,

> Regarding the NOTICE file, I found there is no NOTICE for google fonts
> roboto, but there is a COPYRIGHT.txt[1] file there, therefore I think
> it is better to include it in the NOTICE file. 

I’ve not looked in detail but in general license info goes in LICENSE not 
NOTICE. Please don’t put anything in NOTICE that’s not needed.

Thanks,
Justin

Re: [VOTE]: Release Apache Dubbo OPS(Incubating) 0.1[RC2]

[Justin Mclean]

Hi,

> Because what is included in the source release is several font files,
> font files can not have source headers. So I think the COPYRIGHT.txt
> is a variant of header-existing-copyright. According to [1], we should
> move it to NOTICE.

The copyright only get listed in NOTICE if it come from a software grant and 
the headers are changed to ASF headers in that software or it come from another 
ALv2 NOTICE file.

In this case it should not be listed in NOTICE.

Thanks,
Justin

Non-apache releases and old releases

[Justin Mclean]

HI,

i was looking at the releases here [1] and not there was two unapproved 
releases made after you entered incubation dubbo-2.6.1 and dubbo-2.5.10. 2.6.1 
has come up in conversion on this list before but not the previous release.

It not clear on the GitHub page what isn Apache release and what is not. I 
think it would be a good idea to changing the names of the pre Apache and 
unofficial releases to make that clear.

Thanks,
Justin

1. https://github.com/apache/incubator-dubbo/releases

Re: Non-apache releases and old releases

[Justin Mclean]

Hi,

> Just come back from Chinese Spring Festival. I have renamed all releases
> after 2.6.1 so now they have the prefix of apache-dubbo to distinguish from
> the previous releases, for example: from dubbo-2.7.0 to apache-dubbo-2.7.0.

That will cause less confusion with user of Apache Dubbo.

Thanks,
Justin

Re: Proposal for releasing hessian-lite 3.2.5

[Justin Mclean]

Hi,

> +1. It is not a ASF project, so I don't think it should follow the ASF
> release process.

How is that possible if it in a ASF repo?? [1]

Thanks,
Justin

1. https://github.com/dubbo/hessian-lite/ 

Re: Proposal for releasing hessian-lite 3.2.5

[Justin Mclean]

Hi,

> It is not in a ASF repo, what is your concern on this?\

I have no concerns, sorry for the noise.

Thanks,
Justin

Re: Fix dubbo ops binary license issue

[Justin Mclean]

Hi,

> 
> EPL v1.0 and LGPL 2.1
> 
> The following components are provided under the EPL v1.0 and LGPL 2.1.
> See project link for details.
> The text of each license is also included at licenses/LICENSE-[project].
> 
>qos-ch: logback 1.2.3
> https://github.com/qos-ch/logback/tree/v_1.2.3  EPL v1.0 and LGPL 2.1
> 
> 
> CDDL and GPL 2.0
> 
> The following components are provided under the CDDL and GPL 2.0. See
> project link for details.
> The text of each license is also included at licenses/LICENSE-[project].
> 
>javaee: javax.annotation 1.3.2
> https://github.com/javaee/javax.annotation/tree/1.3.2 CDDL and GPL 2.0


If something is dual license you take the more compatible license [2], and EPL 
and CDDL are Category B and can be included in a binary release. [1]

Thanks,
Justin

1. 
https://www.apache.org/legal/resolved.html#what-can-we-maybe-include-in-an-asf-project-category-b
2. https://www.apache.org/legal/resolved.html#mutually-exclusive

Re: Fix dubbo ops binary license issue

[Justin Mclean]

Hi,

> I think there are 2 things that need to be checked:
> a) ensure all the binary dependencies are listed in LICENSE, this
> includes jar files under BOOT-INF/lib, and javascript dependencies
> which can be found in package.json

Dependancies should not be listed just what in included in the releases, if 
it’s not in the release there's no need to list it even if it is a dependancy.

the other thing you may need to do is look inside each jar and see what it 
contains and it may bundle other 3rd party code inside that’s under different 
licenses, usually this is fairly obvious froth package name.

Thanks,
Justin

Re: Fix dubbo ops binary license issue

[Justin Mclean]

Hi,

> For javascript it is a bit more tricky, because all the javascript
> dependencies will be merged into one single and minimized javascript.

Yep JS causes all sort of issues, also that some JS file are not obviously 
licensed, and they are often missing license headers.

> I doubt this can be done in a practical way. If do it manually, it
> might be done for once, but check every jar for each release, that
> looks impossible to me.

In can be done in a piratical way, once you done it once you just need to check 
teh differences on future releases. BTW I usually just use vi for this as it 
understands comprised files so there no need to manually unpack the jars.

Thanks,
Justin