You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by sospartan <so...@apache.org> on 2017/05/02 05:49:21 UTC
[VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Hi all,
I'll calling a vote for Weex-incubating 0.12.0-RC3 release.
The PPMC vote for this release has passed:
https://lists.apache.org/thread.html/c5514c86433e3551cae00b21a77a1407ee20846f6565f9701d78c85b@%3Cdev.weex.apache.org%3E
The tag to be voted upon:
https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
;a=shortlog;h=refs/tags/0.12.0-rc3
The commit hash:
https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=702d04c4922105069f537afdb4688f808530994d
The source tarball can be found at:
https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.0-incubating/RC3/
The fingerprint of key to sign release artifacts:
97B9 6598 A6A3 B63C 53BD 77E9 44C5 2286 22B9 7784
Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
Release note about this version:
https://issues.apache.org/jira/browse/WEEX-26
This vote will remain open for at least 72 hours.
Please vote on releasing this RC.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
--
Best Regards!
------------------------------
sospartan
https://weex-project.io
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Niclas Hedhman <ni...@hedhman.org>.
+1
On Tue, May 2, 2017 at 1:49 PM, sospartan <so...@apache.org> wrote:
> Hi all,
> I'll calling a vote for Weex-incubating 0.12.0-RC3 release.
>
> The PPMC vote for this release has passed:
> https://lists.apache.org/thread.html/c5514c86433e3551cae00b21a77a14
> 07ee20846f6565f9701d78c85b@%3Cdev.weex.apache.org%3E
>
> The tag to be voted upon:
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
> ;a=shortlog;h=refs/tags/0.12.0-rc3
>
> The commit hash:
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> 702d04c4922105069f537afdb4688f808530994d
>
> The source tarball can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> 0-incubating/RC3/
>
> The fingerprint of key to sign release artifacts:
> 97B9 6598 A6A3 B63C 53BD 77E9 44C5 2286 22B9 7784
>
> Release artifacts are signed with the following key:
> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
>
> Release note about this version:
> https://issues.apache.org/jira/browse/WEEX-26
>
> This vote will remain open for at least 72 hours.
> Please vote on releasing this RC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> --
> Best Regards!
> ------------------------------
>
> sospartan
> https://weex-project.io
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Niclas Hedhman <ni...@hedhman.org>.
As for the Gradle Jar; I gave the go ahead for this release, as I am
pursuing to make Gradle have a single Java file instead of a Jar file, as
this will take some time.
This is known and not of legal concern, and up for interpretation of
policy, which we both agree is not definitive.
Since there is a projected path away from this, I ask you to reconsider.
Cheers
Niclas
On Wed, May 3, 2017 at 8:26 AM, John D. Ament <jo...@apache.org> wrote:
> Sorry but -1 due to binaries in the source release. I'm not sure if I
> missed these the last go around or what, but they should not be included
> (gradle-wrapper I know was called out before):
>
> ./apache-weex-incubating-0.12.0-src/android/playground/
> gradle/wrapper/gradle-wrapper.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/gradle/
> wrapper/gradle-wrapper.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/
> license-gradle-plugin-0.12.1.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/
> maven-license-plugin-1.10.b1.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/
> plexus-utils-3.0.24.jar
> ./apache-weex-incubating-0.12.0-src/android/weex_debug/
> gradle/wrapper/gradle-wrapper.jar
> ./apache-weex-incubating-0.12.0-src/android/weex_debug/libs/classes.jar
> ./apache-weex-incubating-0.12.0-src/scripts/apache-rat-0.12.jar
>
> Other things checked:
> - Has DISCLAIMER
> - File name includes incubating
> - NOTICE and LICENSE look right, especially like the name
> POSSIBLE-NOTICES-FOR-BIN-DIST
>
> I have no idea how to build from source, would be good to include that +
> how to run rat in your instructions. If it weren't for the binary files I
> would vote a +1.
>
> John
>
> On Tue, May 2, 2017 at 1:49 AM sospartan <so...@apache.org> wrote:
>
> > Hi all,
> > I'll calling a vote for Weex-incubating 0.12.0-RC3 release.
> >
> > The PPMC vote for this release has passed:
> >
> > https://lists.apache.org/thread.html/c5514c86433e3551cae00b21a77a14
> 07ee20846f6565f9701d78c85b@%3Cdev.weex.apache.org%3E
> >
> > The tag to be voted upon:
> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
> > ;a=shortlog;h=refs/tags/0.12.0-rc3
> >
> > The commit hash:
> >
> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> 702d04c4922105069f537afdb4688f808530994d
> >
> > The source tarball can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> 0-incubating/RC3/
> >
> > The fingerprint of key to sign release artifacts:
> > 97B9 6598 A6A3 B63C 53BD 77E9 44C5 2286 22B9 7784
> >
> > Release artifacts are signed with the following key:
> > https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
> >
> > Release note about this version:
> > https://issues.apache.org/jira/browse/WEEX-26
> >
> > This vote will remain open for at least 72 hours.
> > Please vote on releasing this RC.
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > --
> > Best Regards!
> > ------------------------------
> >
> > sospartan
> > https://weex-project.io
> >
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Craig Russell <ap...@gmail.com>.
> On May 6, 2017, at 10:04 AM, Craig Russell <ap...@gmail.com> wrote:
>
>>> 3. The java source files in android/commons/src are still in the
>>> com.alibaba name space. Assuming that these are actually weex source files,
>>> they must be repackaged to org.apache.
>>>
>> The ASF actually has no policy around this. There is no requirement for
>> any specific Java package name. We do however encourage the usage from a
>> branding standpoint. To this day, Groovy continues to use
>> org.codehaus.groovy to avoid backwards compatibility issues.
>
> Ok. I would be interested to see the user code that actually contains references to these package names. I thought from brief inspection that this was a set of tools used by gui developers not programmers.
>>
If the project intends to repackage all of the source files from the com.alibaba name space, then I have no problem with an incubator release.
But if the intent is to keep the com.alibaba name space, we need a discussion. The reference to org.codehaus.groovy is a good one. It refers to the existing non-commercial community-supported code base. But having a commercial entity with its name prominent in an Apache project is asking for trouble. It raises branding issues that I'm not comfortable with.
Craig
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Craig Russell <ap...@gmail.com>.
Hi John,
> On May 6, 2017, at 5:27 AM, John D. Ament <jo...@apache.org> wrote:
>
> Craig,
>
> To comment on a few of these notes.
>
> Many of these are valid issues with the release, but generally would not
> block an initial release. I would recommend we follow our rule of "point
> it out, pass it as it doesn't create a legal issue, and expect it to be
> fixed for next release."
I was (am) -1 due to the binaries: jars and shared objects. The other items are informational and I'm happy to discuss them. If we agree that they can be fixed for a future release, we can resolve them with "JIRA filed for next release".
>
> The only potential issues I see as legal impacting are the binaries and the
> com.google source code.
>
> On Wed, May 3, 2017 at 9:23 PM Craig Russell <ap...@gmail.com> wrote:
>
>> I also must vote -1 on this release.
>>
>> clr% find . -name "*.jar"
>> ./android/playground/gradle/wrapper/gradle-wrapper.jar
>> ./android/sdk/gradle/wrapper/gradle-wrapper.jar
>> ./android/sdk/license/license-gradle-plugin-0.12.1.jar
>> ./android/sdk/license/maven-license-plugin-1.10.b1.jar
>> ./android/sdk/license/plexus-utils-3.0.24.jar
>> ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar
>> ./android/weex_debug/libs/classes.jar
>> ./scripts/apache-rat-0.12.jar
>>
>> 1. These jar files are not source and must not appear in the source
>> release.
>>
>> 2. I appreciate the effort involved in compiling the
>> POSSIBLE-NOTICES-FOR-BIN-DIST. But looking into these dependencies I am
>> troubled by the difficulty actually finding the licenses of the projects.
>>
>> For example, the "possible notice" for animaitonjs (possible typo here)
>> refers to https://www.npmjs.com/package/animationjs from which it is
>> impossible (ok, perhaps possible but I could not find a link) to find the
>> actual project.
>>
>> References to npmjs in this entire file should be removed and replaced by
>> references to the home of the project. (Not relevant for this release
>> because the files are not actually being distributed.)
>>
>>
>
> The history behind this file is a bit jaded. As best as I can tell, Weex
> followed the path of RocketMQ and attempted to have a combined file. There
> are typically separate source and binary notices when the binary is an all
> inclusive application (standalone server that can just run).
My point is that a downstream user trying to perform due diligence will find it difficult or impossible to determine the license applied to the dependency if all they have is the npm reference. The user should be able to easily find the project where it lives. IIUC, npm is a binary distribution mechanism, not a source repository.
>
>
>> 3. The java source files in android/commons/src are still in the
>> com.alibaba name space. Assuming that these are actually weex source files,
>> they must be repackaged to org.apache.
>>
>>
> The ASF actually has no policy around this. There is no requirement for
> any specific Java package name. We do however encourage the usage from a
> branding standpoint. To this day, Groovy continues to use
> org.codehaus.groovy to avoid backwards compatibility issues.
Ok. I would be interested to see the user code that actually contains references to these package names. I thought from brief inspection that this was a set of tools used by gui developers not programmers.
>
>
>
>> 4. The javascript source files in playground/app/src are missing the
>> license header. They have a style that I do not recognize. Are these
>> generated files? The first several lines of storage-demo.js:
>>
>> /******/ (function(modules) { // webpackBootstrap
>> /******/ // The module cache
>> /******/ var installedModules = {};
>>
>> /******/ // The require function
>> /******/ function __webpack_require__(moduleId) {
>>
>> /******/ // Check if module is in cache
>> /******/ if(installedModules[moduleId])
>> /******/ return installedModules[moduleId].exports;
>>
>> 5. The java files in playground/app/src/main/java_zxing are in the
>> com.google name space. They have a google license header.
>>
>> 6. The packages/weex-html5 contains LICENSE and NOTICE files. These should
>> be in the top level directory of the release.
>>
>> 7. The scripts/rh contains LICENSE and NOTICE files. These should be in
>> the top level directory of the release.
>>
>> 8. There is an executable file that doesn't belong:
>>
>> clr% ls -l start
>> -rwxr-xr-x@ 1 clr staff 161 Apr 27 20:34 start
>>
>>
> Projects often times include executable files.I've never seen this as an
> issue before. We don't allow binary files.
My bad. I'm afraid I was confused by this one. It's not an issue. When I tried to examine it via MacOSX Finder, it didn't allow me to open it in a text viewer.
>
>
>> 9. There is an executable gradlew in sdk/gradle that doesn't belong in a
>> source release.
>>
>> 10. There are shared objects in sdk/libs that don't belong in a source
>> release.
>>
>> 11. There are NOTICE and LICENSE files in ios/sdk that seem to be unix
>> executable files.
Same thing here. The permissions need to be changed but it's not a blocker.
>>
>> clr% ls -l ios/sdk
>> total 40
>> -rwxr-xr-x@ 1 clr staff 11343 Apr 27 20:34 LICENSE
>> -rwxr-xr-x@ 1 clr staff 575 Apr 27 20:34 NOTICE
>>
>> 12. The README.md doesn't tell me how to build/use org.apache.weex. The
>> first several lines refer to third-party projects from Alibaba and
>> cocoapods. How do I use the Apache project?
Craig
>>
>> Craig
>>
>>> On May 2, 2017, at 5:26 PM, John D. Ament <jo...@apache.org> wrote:
>>>
>>> Sorry but -1 due to binaries in the source release. I'm not sure if I
>>> missed these the last go around or what, but they should not be included
>>> (gradle-wrapper I know was called out before):
>>>
>>>
>> ./apache-weex-incubating-0.12.0-src/android/playground/gradle/wrapper/gradle-wrapper.jar
>>>
>> ./apache-weex-incubating-0.12.0-src/android/sdk/gradle/wrapper/gradle-wrapper.jar
>>>
>> ./apache-weex-incubating-0.12.0-src/android/sdk/license/license-gradle-plugin-0.12.1.jar
>>>
>> ./apache-weex-incubating-0.12.0-src/android/sdk/license/maven-license-plugin-1.10.b1.jar
>>>
>> ./apache-weex-incubating-0.12.0-src/android/sdk/license/plexus-utils-3.0.24.jar
>>>
>> ./apache-weex-incubating-0.12.0-src/android/weex_debug/gradle/wrapper/gradle-wrapper.jar
>>> ./apache-weex-incubating-0.12.0-src/android/weex_debug/libs/classes.jar
>>> ./apache-weex-incubating-0.12.0-src/scripts/apache-rat-0.12.jar
>>>
>>> Other things checked:
>>> - Has DISCLAIMER
>>> - File name includes incubating
>>> - NOTICE and LICENSE look right, especially like the name
>>> POSSIBLE-NOTICES-FOR-BIN-DIST
>>>
>>> I have no idea how to build from source, would be good to include that +
>>> how to run rat in your instructions. If it weren't for the binary files
>> I
>>> would vote a +1.
>>>
>>> John
>>>
>>> On Tue, May 2, 2017 at 1:49 AM sospartan <so...@apache.org> wrote:
>>>
>>>> Hi all,
>>>> I'll calling a vote for Weex-incubating 0.12.0-RC3 release.
>>>>
>>>> The PPMC vote for this release has passed:
>>>>
>>>>
>> https://lists.apache.org/thread.html/c5514c86433e3551cae00b21a77a1407ee20846f6565f9701d78c85b@%3Cdev.weex.apache.org%3E
>>>>
>>>> The tag to be voted upon:
>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
>>>> ;a=shortlog;h=refs/tags/0.12.0-rc3
>>>>
>>>> The commit hash:
>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=702d04c4922105069f537afdb4688f808530994d
>>>>
>>>> The source tarball can be found at:
>>>>
>>>>
>> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.0-incubating/RC3/
>>>>
>>>> The fingerprint of key to sign release artifacts:
>>>> 97B9 6598 A6A3 B63C 53BD 77E9 44C5 2286 22B9 7784
>>>>
>>>> Release artifacts are signed with the following key:
>>>> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
>>>>
>>>> Release note about this version:
>>>> https://issues.apache.org/jira/browse/WEEX-26
>>>>
>>>> This vote will remain open for at least 72 hours.
>>>> Please vote on releasing this RC.
>>>>
>>>> [ ] +1 approve
>>>> [ ] +0 no opinion
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>> --
>>>> Best Regards!
>>>> ------------------------------
>>>>
>>>> sospartan
>>>> https://weex-project.io
>>>>
>>
>> Craig L Russell
>> clr@apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by "John D. Ament" <jo...@apache.org>.
Craig,
To comment on a few of these notes.
Many of these are valid issues with the release, but generally would not
block an initial release. I would recommend we follow our rule of "point
it out, pass it as it doesn't create a legal issue, and expect it to be
fixed for next release."
The only potential issues I see as legal impacting are the binaries and the
com.google source code.
On Wed, May 3, 2017 at 9:23 PM Craig Russell <ap...@gmail.com> wrote:
> I also must vote -1 on this release.
>
> clr% find . -name "*.jar"
> ./android/playground/gradle/wrapper/gradle-wrapper.jar
> ./android/sdk/gradle/wrapper/gradle-wrapper.jar
> ./android/sdk/license/license-gradle-plugin-0.12.1.jar
> ./android/sdk/license/maven-license-plugin-1.10.b1.jar
> ./android/sdk/license/plexus-utils-3.0.24.jar
> ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar
> ./android/weex_debug/libs/classes.jar
> ./scripts/apache-rat-0.12.jar
>
> 1. These jar files are not source and must not appear in the source
> release.
>
> 2. I appreciate the effort involved in compiling the
> POSSIBLE-NOTICES-FOR-BIN-DIST. But looking into these dependencies I am
> troubled by the difficulty actually finding the licenses of the projects.
>
> For example, the "possible notice" for animaitonjs (possible typo here)
> refers to https://www.npmjs.com/package/animationjs from which it is
> impossible (ok, perhaps possible but I could not find a link) to find the
> actual project.
>
> References to npmjs in this entire file should be removed and replaced by
> references to the home of the project. (Not relevant for this release
> because the files are not actually being distributed.)
>
>
The history behind this file is a bit jaded. As best as I can tell, Weex
followed the path of RocketMQ and attempted to have a combined file. There
are typically separate source and binary notices when the binary is an all
inclusive application (standalone server that can just run).
> 3. The java source files in android/commons/src are still in the
> com.alibaba name space. Assuming that these are actually weex source files,
> they must be repackaged to org.apache.
>
>
The ASF actually has no policy around this. There is no requirement for
any specific Java package name. We do however encourage the usage from a
branding standpoint. To this day, Groovy continues to use
org.codehaus.groovy to avoid backwards compatibility issues.
> 4. The javascript source files in playground/app/src are missing the
> license header. They have a style that I do not recognize. Are these
> generated files? The first several lines of storage-demo.js:
>
> /******/ (function(modules) { // webpackBootstrap
> /******/ // The module cache
> /******/ var installedModules = {};
>
> /******/ // The require function
> /******/ function __webpack_require__(moduleId) {
>
> /******/ // Check if module is in cache
> /******/ if(installedModules[moduleId])
> /******/ return installedModules[moduleId].exports;
>
> 5. The java files in playground/app/src/main/java_zxing are in the
> com.google name space. They have a google license header.
>
> 6. The packages/weex-html5 contains LICENSE and NOTICE files. These should
> be in the top level directory of the release.
>
> 7. The scripts/rh contains LICENSE and NOTICE files. These should be in
> the top level directory of the release.
>
> 8. There is an executable file that doesn't belong:
>
> clr% ls -l start
> -rwxr-xr-x@ 1 clr staff 161 Apr 27 20:34 start
>
>
Projects often times include executable files.I've never seen this as an
issue before. We don't allow binary files.
> 9. There is an executable gradlew in sdk/gradle that doesn't belong in a
> source release.
>
> 10. There are shared objects in sdk/libs that don't belong in a source
> release.
>
> 11. There are NOTICE and LICENSE files in ios/sdk that seem to be unix
> executable files.
>
> clr% ls -l ios/sdk
> total 40
> -rwxr-xr-x@ 1 clr staff 11343 Apr 27 20:34 LICENSE
> -rwxr-xr-x@ 1 clr staff 575 Apr 27 20:34 NOTICE
>
> 12. The README.md doesn't tell me how to build/use org.apache.weex. The
> first several lines refer to third-party projects from Alibaba and
> cocoapods. How do I use the Apache project?
>
> Craig
>
> > On May 2, 2017, at 5:26 PM, John D. Ament <jo...@apache.org> wrote:
> >
> > Sorry but -1 due to binaries in the source release. I'm not sure if I
> > missed these the last go around or what, but they should not be included
> > (gradle-wrapper I know was called out before):
> >
> >
> ./apache-weex-incubating-0.12.0-src/android/playground/gradle/wrapper/gradle-wrapper.jar
> >
> ./apache-weex-incubating-0.12.0-src/android/sdk/gradle/wrapper/gradle-wrapper.jar
> >
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/license-gradle-plugin-0.12.1.jar
> >
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/maven-license-plugin-1.10.b1.jar
> >
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/plexus-utils-3.0.24.jar
> >
> ./apache-weex-incubating-0.12.0-src/android/weex_debug/gradle/wrapper/gradle-wrapper.jar
> > ./apache-weex-incubating-0.12.0-src/android/weex_debug/libs/classes.jar
> > ./apache-weex-incubating-0.12.0-src/scripts/apache-rat-0.12.jar
> >
> > Other things checked:
> > - Has DISCLAIMER
> > - File name includes incubating
> > - NOTICE and LICENSE look right, especially like the name
> > POSSIBLE-NOTICES-FOR-BIN-DIST
> >
> > I have no idea how to build from source, would be good to include that +
> > how to run rat in your instructions. If it weren't for the binary files
> I
> > would vote a +1.
> >
> > John
> >
> > On Tue, May 2, 2017 at 1:49 AM sospartan <so...@apache.org> wrote:
> >
> >> Hi all,
> >> I'll calling a vote for Weex-incubating 0.12.0-RC3 release.
> >>
> >> The PPMC vote for this release has passed:
> >>
> >>
> https://lists.apache.org/thread.html/c5514c86433e3551cae00b21a77a1407ee20846f6565f9701d78c85b@%3Cdev.weex.apache.org%3E
> >>
> >> The tag to be voted upon:
> >> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
> >> ;a=shortlog;h=refs/tags/0.12.0-rc3
> >>
> >> The commit hash:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=702d04c4922105069f537afdb4688f808530994d
> >>
> >> The source tarball can be found at:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.0-incubating/RC3/
> >>
> >> The fingerprint of key to sign release artifacts:
> >> 97B9 6598 A6A3 B63C 53BD 77E9 44C5 2286 22B9 7784
> >>
> >> Release artifacts are signed with the following key:
> >> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
> >>
> >> Release note about this version:
> >> https://issues.apache.org/jira/browse/WEEX-26
> >>
> >> This vote will remain open for at least 72 hours.
> >> Please vote on releasing this RC.
> >>
> >> [ ] +1 approve
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> --
> >> Best Regards!
> >> ------------------------------
> >>
> >> sospartan
> >> https://weex-project.io
> >>
>
> Craig L Russell
> clr@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by sospartan <so...@gmail.com>.
> 4. The javascript source files in playground/app/src are missing the
license header. They have a style that I do not recognize. Are these
generated files? The first several lines of storage-demo.js:
>
> /******/ (function(modules) { // webpackBootstrap
> /******/ // The module cache
> /******/ var installedModules = {};
>
> /******/ // The require function
> /******/ function __webpack_require__(moduleId) {
>
> /******/ // Check if module is in cache
> /******/ if(installedModules[moduleId])
> /******/ return installedModules[moduleId].exports;
All js files under 'ios/' or 'android/' is generated files, which can be
removed from source tarball.
On Thu, May 4, 2017 at 10:24 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Thu, May 4, 2017 at 9:22 AM, Craig Russell <ap...@gmail.com>
> wrote:
> > clr% find . -name "*.jar"
> > ./android/playground/gradle/wrapper/gradle-wrapper.jar
> > ./android/sdk/gradle/wrapper/gradle-wrapper.jar
> > ./android/sdk/license/license-gradle-plugin-0.12.1.jar
> > ./android/sdk/license/maven-license-plugin-1.10.b1.jar
> > ./android/sdk/license/plexus-utils-3.0.24.jar
> > ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar
> > ./android/weex_debug/libs/classes.jar
> > ./scripts/apache-rat-0.12.jar
>
> > 1. These jar files are not source and must not appear in the source
> release.
>
> These are convenience for building the system. Those who are overly
> concerned and don't trust Apache project members, are free to build using
> tools downloaded by themselves. I have argued that this will be changed to
> a "only source code" approach in the future, but should not hinder a
> release now.
>
> > 2. I appreciate the effort involved in compiling the
> POSSIBLE-NOTICES-FOR-BIN-DIST. But looking into these dependencies I am
> troubled by the difficulty actually finding the licenses of the projects.
> >
> > For example, the "possible notice" for animaitonjs (possible typo here)
> refers to https://www.npmjs.com/package/animationjs from which it is
> impossible (ok, perhaps possible but I could not find a link) to find the
> actual project.
> >
> > References to npmjs in this entire file should be removed and replaced by
> references to the home of the project. (Not relevant for this release
> because the files are not actually being distributed.)
>
> And YET, the argument is that this file SHOULD NOT BE INCLUDED AT ALL, so
> that downstream packagers have to not only worry about what you are listing
> above, BUT ALSO figuring out what to start looking for. For fak sake,
> man.... Get a grip on reality!
>
> > 3. The java source files in android/commons/src are still in the
> com.alibaba name space. Assuming that these are actually weex source files,
> they must be repackaged to org.apache.
>
> YES, that is on purpose to avoid breaking compatibility with hundreds of
> people using Weex in their projects right now. org.apache.weex namespace is
> slated for a later release when compatibility is sacrificed.
>
> > 4. The javascript source files in playground/app/src are missing the
> license header. They have a style that I do not recognize. Are these
> generated files? The first several lines of storage-demo.js:
> >
> > /******/ (function(modules) { // webpackBootstrap
> > /******/ // The module cache
> > /******/ var installedModules = {};
> >
> > /******/ // The require function
> > /******/ function __webpack_require__(moduleId) {
> >
> > /******/ // Check if module is in cache
> > /******/ if(installedModules[moduleId])
> > /******/ return installedModules[moduleId].
> exports;
>
> I don't know about this one.
>
> > 5. The java files in playground/app/src/main/java_zxing are in the
> com.google name space. They have a google license header.
>
> I have missed that one. But it is bundled source code from elsewhere, and
> should be mentioned in top-level NOTICE, not only the localized one.
>
> Before you complain about the NOTICE and LICENSE in playground, that is due
> to the intent that the playground/ is expected to be copied elsewhere as a
> sample project that uses the Weex SDK. Hence its location there.
>
> > 6. The packages/weex-html5 contains LICENSE and NOTICE files. These
> should be in the top level directory of the release.
>
> This one is less than clear cut. The content in packages/ will be uploaded
> to npm registry, and the files in the directory will be moved there. There
> is relatively little information (compared to Maven Central uploads) how
> that is to be handled, since the content that is uploaded need to be part
> of a source release.
>
> > 7. The scripts/rh contains LICENSE and NOTICE files. These should be in
> the top level directory of the release.
>
> The scripts/ directory is mistakenly included in the dist.
>
> > 8. There is an executable file that doesn't belong:
> >
> > clr% ls -l start
> > -rwxr-xr-x@ 1 clr staff 161 Apr 27 20:34 start
>
> What's the problem with "executable file"? It is a shell script, and since
> when are we not allowed to ship that?
>
> Granted; lacking license header, but that is not your complaint.
>
> > 9. There is an executable gradlew in sdk/gradle that doesn't belong in a
> source release.
>
> Port of your point 1, and gradlew is another shell script. ARE YOU SAYING
> that shell scripts are not allowed in source distros?
>
> > 10. There are shared objects in sdk/libs that don't belong in a source
> release.
>
> Alright, this is a issue that I am not convinced either way. I agree that
> "doesn't belong", but on the other hand, the steps to set up (and get
> working) the Android Native Development Kit (not talking about the Android
> SDK) is substantial. By allowing these built binaries, we can avoid that
> for most users, who normally never touch the NDK. By demanding that these
> binaries are taken out, then you just condemned this project to produce a
> Binary Release as well, which was not planned for this release.
>
> > 11. There are NOTICE and LICENSE files in ios/sdk that seem to be unix
> executable files.
> > clr% ls -l ios/sdk
> > total 40
> > -rwxr-xr-x@ 1 clr staff 11343 Apr 27 20:34 LICENSE
> > -rwxr-xr-x@ 1 clr staff 575 Apr 27 20:34 NOTICE
>
> An honest mistake, and shouldn't stop a release.
>
> > 12. The README.md doesn't tell me how to build/use org.apache.weex. The
> first several lines refer to third-party projects from Alibaba and
> cocoapods. How do I use the Apache project?
>
> Well, you just introduced more complexity in "using the project" with your
> insistence on no binaries, and more so if your "no execute flag" is also
> now not allowed. AFAIK, there is no obligation that the source distribution
> must contain all details needed to build the project, only that it can be
> built. But for you convenience;
>
> 1. Install Gradle and learn how to use it.
> 2. Install Maven and learn how to use it.
> 3. Install Android NDK and learn how to use it.
> 4. Install Android SDK and learn how to use it.
> 5. Install Xcode and learn how to use it.
> 6. Install IOS SDK and learn how to use it.
> 7. Build each part with the tool needed.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
--
sospartan
Phone:13588488290
HangZhou
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Craig Russell <ap...@gmail.com>.
If your objective is to get me to change my vote, I'd suggest this is not a good way forward.
Craig
> On May 4, 2017, at 12:02 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> Sorry, but if you don't know the background on that file, then perhaps you
> think I am "not civil"... The fact is that NOTICE file doesn't require any
> inclusion of what the project depends on, since they are not bundled, but
> will be downloaded during build. In a previous round, we were told to take
> it out of NOTICE for that reason (not bundled) and I argued that we should
> keep it in to make it more reasonable for downstreams to get an idea of
> what a binary distro will actually contain. This file was the compromise of
> providing such details to downstream.
>
> Now you say, "Uhhh, it is unclear..." when in reality it would be even more
> unclear if we left it out, as some people on this very list pushed for on a
> previous RC.
>
> So, yes, I get pissed off as well. The incubator over time is getting more
> and more intolerant at podling's first release, and I think it is the wrong
> way to go. It is disheartening... truly...
>
>
> Niclas
>
> On Thu, May 4, 2017 at 1:57 PM, Craig Russell <ap...@gmail.com> wrote:
>
>> I'm going to call foul on this one.
>>
>> If you cannot be civil, then leave the discussion to others.
>>
>> Craig
>>
>>> On May 3, 2017, at 7:24 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>>>
>>> BUT ALSO figuring out what to start looking for. For fak sake,
>>> man.... Get a grip on reality!
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> clr@apache.org http://db.apache.org/jdo
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Niclas Hedhman <ni...@hedhman.org>.
Thanks Anthony,
so that's where the notion "gradlew doesn't work on Windows" comes from.
Makes more sense now. But I don't think that is just as practical for Weex
as it is for BigTop.
On Sat, May 6, 2017 at 3:10 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
> > On May 5, 2017, at 4:27 AM, sospartan <so...@gmail.com> wrote:
> >
> > I'll remove whole playground sample app from artifacts innext release. So
> > #7 would be a problem anymore.
> > As the gradle wrapper will be removed too. I'll suggest use installed
> > gradle to create that. These will be put in new "how to build from
> source"
> > doc in root folder.
> > Pierre Smits <pi...@gmail.com>于2017年5月5日 周五下午6:32写道：
> >
>
> You might want to consider using the Bigtop approach for gradlew [1] to
> avoid shipping a binary in the source release. The Geode project has been
> using this successfully (thanks to Roman for pointing us in this
> direction!).
>
> Anthony
>
> [1] https://github.com/apache/bigtop/blob/master/gradlew <
> https://github.com/apache/bigtop/blob/master/gradlew>
>
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Anthony Baker <ab...@pivotal.io>.
> On May 5, 2017, at 4:27 AM, sospartan <so...@gmail.com> wrote:
>
> I'll remove whole playground sample app from artifacts innext release. So
> #7 would be a problem anymore.
> As the gradle wrapper will be removed too. I'll suggest use installed
> gradle to create that. These will be put in new "how to build from source"
> doc in root folder.
> Pierre Smits <pi...@gmail.com>于2017年5月5日 周五下午6:32写道：
>
You might want to consider using the Bigtop approach for gradlew [1] to avoid shipping a binary in the source release. The Geode project has been using this successfully (thanks to Roman for pointing us in this direction!).
Anthony
[1] https://github.com/apache/bigtop/blob/master/gradlew <https://github.com/apache/bigtop/blob/master/gradlew>
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by sospartan <so...@gmail.com>.
I'll remove whole playground sample app from artifacts innext release. So
#7 would be a problem anymore.
As the gradle wrapper will be removed too. I'll suggest use installed
gradle to create that. These will be put in new "how to build from source"
doc in root folder.
Pierre Smits <pi...@gmail.com>于2017年5月5日 周五下午6:32写道：
> I forgot to address in my conclusion aspect #7 (classes.jar).
>
> This seems to be quite the issue, as I could not find a license associated
> with it when I did the cursory review. Nor could I find in the proposal
> anything more than a single reference. My question(s):
>
> - where does this originate from, and what is the license?
> - was this intended to be part of the Weex solution? And If so, does the
> ASF have an SGA for this?
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Fri, May 5, 2017 at 12:25 PM, Pierre Smits <pi...@gmail.com>
> wrote:
>
> > Hi All,
> >
> > To understand part of the problem correctly, in currently proposed
> release
> > there are many compiled components (jar files)that aren't allowed to be
> > included....
> > > clr% find . -name "*.jar"
> >
> > 1. > ./android/playground/gradle/wrapper/gradle-wrapper.jar
> > 2. > ./android/sdk/gradle/wrapper/gradle-wrapper.jar
> > 3. > ./android/sdk/license/license-gradle-plugin-0.12.1.jar
> > 4. > ./android/sdk/license/maven-license-plugin-1.10.b1.jar
> > 5. > ./android/sdk/license/plexus-utils-3.0.24.jar
> > 6. > ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar
> > 7. > ./android/weex_debug/libs/classes.jar
> > 8. > ./scripts/apache-rat-0.12.jar
> >
> >
> > So lets break this down:
> >
> > Re 1 & 2 and 6 : gradle-wrapper.jar
> > This is an 3rd party solution provided by the Gradle
> > community/organisation build through the 'gradle wrapper' task. Licensed
> > under AL2.0. This can be included in the source repo, however it can NOT
> > (per current conventions) be included in source releases. But it can be
> > included in convenience downloads based on source releases;
> >
> > Re 3: license-gradle-plugin-0.12.1.jar
> > This is apparently a 3rd party solution available through e.g.
> > mvnrepository.com. Licensed under AL2.0. This can be included in the
> > source repo, however it can NOT (per current conventions) be included in
> > source releases. But it can be included in convenience downloads based on
> > source releases;
> >
> > Re 4. maven-license-plugin-1.10.b1.jar
> > This is apparently a 3rd party solution available through e.g.
> > mvnrepository.com. Licensed under AL2.0. This can be included in the
> > source repo, however it can NOT (per current conventions) be included in
> > source releases. But it can be included in convenience downloads based on
> > source releases;
> >
> > Re 5: plexus-utils-3.0.24.jar
> > This is apparently a 3rd party solution available through e.g.
> > mvnrepository.com. Licensed under AL2.0. This can be included in the
> > source repo, however it can NOT (per current conventions) be included in
> > source releases. But it can be included in convenience downloads based on
> > source releases;
> >
> > Re 7: classes.jar
> > Cursory analysis of the jar shows that it stemming from com.taobao java
> > code, used in [1] and referenced in the Weex proposal (see [2]).
> >
> > Re 8: apache-rat-0.12.jar
> > This is an artefact produced by Apache Creadur project (see [3]). This
> can
> > be included in the source repo, and CAN be included in source releases
> (as
> > it is ASF own).And it can be included in convenience downloads based on
> > source releases;
> >
> > [1] https://github.com/apache/incubator-weex/tree/master/
> > android/weex_debug/src/main/java/com/taobao/weex
> > [2] https://wiki.apache.org/incubator/WeexProposal~)
> > [3] http://creadur.apache.org/rat/
> >
> > Conclusion(s):
> >
> > 1. Many of the 3rd party solutions (jar files) used in the Apache Weex
> > product are available in artefact repos like mvnrepository.com, and
> > need not be included in the code base, source releases and convenience
> > downloads as they can be retrieved through the dependency mgt
> solution used
> > by the project (gradle in this case);
> > 2. Convenience downloads (jar files) of ASF projects can be included
> > when downloaded from ASF sources. However, if these are not available
> > through ASF or 3rd party artefact repos ( e.g. mvnrepository.com) it
> > is advised that the project contacts the (appropriate) ASF project
> that
> > delivers such solutions and have them included in these artefact
> repos. The
> > project can then have such retrieved through the depency mgt solution
> used
> > by the project;
> > 3. gradle-wrapper.jar is generated by executing a gradle task
> > (./gradle wrapper), and is based on
> > 1. the gradle version used (by the person having downloaded the
> > source)
> > 2. potential gradle configuration elements included in the
> > project's source code (build.gradle, etc).
> >
> > No gradle-wrapper.jar artefact was found via mvnrepository.com. The
> ideal
> > situation (to resolve the major issue discussed in this thread) would be
> if
> > such convenience download would be made available through the various jar
> > repos (e.g. mvnrepository). This should (preferably) be done by the
> Gradle
> > community/organisation. However, in the short term, the project could
> > adjust the gradlew scripts in the codebase to have that invoke the
> > download from the project's repo ((in ./gradlew for linux initiate e.g.
> > wget), and in ./gradlew.bat initiate an equivalent))
> >
> >
> > I trust the above helps to clear the air.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Fri, May 5, 2017 at 3:57 AM, sospartan <so...@gmail.com> wrote:
> >
> >> Taylor,
> >> Can you point out which objections you are agreed exactly?
> >>
> >>
> >>
> >> On Fri, May 5, 2017 at 9:31 AM, P. Taylor Goetz <pt...@gmail.com>
> >> wrote:
> >>
> >> > Apologies for the auto correct.
> >> >
> >> > Please sub "Niclas" for "Nicolas".
> >> >
> >> > -Taylor
> >> >
> >> > > On May 4, 2017, at 8:43 PM, P. Taylor Goetz <pt...@gmail.com>
> >> wrote:
> >> > >
> >> > > Nicolas,
> >> > >
> >> > > I understand and appreciate your passion, but would respectfully ask
> >> > that you step down your tone a little bit. Craig and John have both
> >> taken
> >> > time to review the release candidate (which you should be appreciative
> >> of
> >> > -- getting IPMC members to review a release can be difficult). In my
> >> > opinion their reviews bring up some valid points that need to be
> >> considered.
> >> > >
> >> > > Weex, by its nature, has a complicated codebase with respect to
> >> > licensing and building from source. It is a far cry from a java
> project
> >> > with a Pom and a a "src" directory. It pulls in a lot of different
> code
> >> > that needs to be considered and evaluated. Going forward the (P)PMC
> will
> >> > need to understand that and as a TLP will need to be able to address
> >> issues
> >> > accordingly.
> >> > >
> >> > > What may seem like "Incubator hazing" right now, I would argue, is
> an
> >> > exercise in making sure the podling has what it takes to operate as a
> >> fully
> >> > functional TLP. No two podlings are the same, and some face certain
> >> burdens
> >> > that others do not.
> >> > >
> >> > > For now can we try to turn the thread toward a more constructive
> path
> >> > that benefits both the podling and the Incubator?
> >> > >
> >> > > For what it's worth, I agree with some (not all) of the objections
> >> that
> >> > have been raised. So I would be a -1 as well.
> >> > >
> >> > > -Taylor
> >> > >
> >> > >
> >> > >
> >> > >> On May 4, 2017, at 3:02 AM, Niclas Hedhman <ni...@hedhman.org>
> >> wrote:
> >> > >>
> >> > >> Sorry, but if you don't know the background on that file, then
> >> perhaps
> >> > you
> >> > >> think I am "not civil"... The fact is that NOTICE file doesn't
> >> require
> >> > any
> >> > >> inclusion of what the project depends on, since they are not
> bundled,
> >> > but
> >> > >> will be downloaded during build. In a previous round, we were told
> to
> >> > take
> >> > >> it out of NOTICE for that reason (not bundled) and I argued that we
> >> > should
> >> > >> keep it in to make it more reasonable for downstreams to get an
> idea
> >> of
> >> > >> what a binary distro will actually contain. This file was the
> >> > compromise of
> >> > >> providing such details to downstream.
> >> > >>
> >> > >> Now you say, "Uhhh, it is unclear..." when in reality it would be
> >> even
> >> > more
> >> > >> unclear if we left it out, as some people on this very list pushed
> >> for
> >> > on a
> >> > >> previous RC.
> >> > >>
> >> > >> So, yes, I get pissed off as well. The incubator over time is
> getting
> >> > more
> >> > >> and more intolerant at podling's first release, and I think it is
> the
> >> > wrong
> >> > >> way to go. It is disheartening... truly...
> >> > >>
> >> > >>
> >> > >> Niclas
> >> > >>
> >> > >>> On Thu, May 4, 2017 at 1:57 PM, Craig Russell <
> apache.clr@gmail.com
> >> >
> >> > wrote:
> >> > >>>
> >> > >>> I'm going to call foul on this one.
> >> > >>>
> >> > >>> If you cannot be civil, then leave the discussion to others.
> >> > >>>
> >> > >>> Craig
> >> > >>>
> >> > >>>> On May 3, 2017, at 7:24 PM, Niclas Hedhman <ni...@hedhman.org>
> >> > wrote:
> >> > >>>>
> >> > >>>> BUT ALSO figuring out what to start looking for. For fak sake,
> >> > >>>> man.... Get a grip on reality!
> >> > >>>
> >> > >>> Craig L Russell
> >> > >>> Secretary, Apache Software Foundation
> >> > >>> clr@apache.org http://db.apache.org/jdo
> >> > >>>
> >> > >>>
> >> > >>> ------------------------------------------------------------
> >> ---------
> >> > >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> > >>> For additional commands, e-mail:
> general-help@incubator.apache.org
> >> > >>>
> >> > >>>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Niclas Hedhman, Software Developer
> >> > >> http://polygene.apache.org - New Energy for Java
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: general-help@incubator.apache.org
> >> >
> >> >
> >>
> >>
> >> --
> >> sospartan
> >> Phone:13588488290
> >> HangZhou
> >>
> >
> >
>
--
sospartan
Phone:13588488290
HangZhou
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Pierre Smits <pi...@gmail.com>.
I forgot to address in my conclusion aspect #7 (classes.jar).
This seems to be quite the issue, as I could not find a license associated
with it when I did the cursory review. Nor could I find in the proposal
anything more than a single reference. My question(s):
- where does this originate from, and what is the license?
- was this intended to be part of the Weex solution? And If so, does the
ASF have an SGA for this?
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Fri, May 5, 2017 at 12:25 PM, Pierre Smits <pi...@gmail.com>
wrote:
> Hi All,
>
> To understand part of the problem correctly, in currently proposed release
> there are many compiled components (jar files)that aren't allowed to be
> included....
> > clr% find . -name "*.jar"
>
> 1. > ./android/playground/gradle/wrapper/gradle-wrapper.jar
> 2. > ./android/sdk/gradle/wrapper/gradle-wrapper.jar
> 3. > ./android/sdk/license/license-gradle-plugin-0.12.1.jar
> 4. > ./android/sdk/license/maven-license-plugin-1.10.b1.jar
> 5. > ./android/sdk/license/plexus-utils-3.0.24.jar
> 6. > ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar
> 7. > ./android/weex_debug/libs/classes.jar
> 8. > ./scripts/apache-rat-0.12.jar
>
>
> So lets break this down:
>
> Re 1 & 2 and 6 : gradle-wrapper.jar
> This is an 3rd party solution provided by the Gradle
> community/organisation build through the 'gradle wrapper' task. Licensed
> under AL2.0. This can be included in the source repo, however it can NOT
> (per current conventions) be included in source releases. But it can be
> included in convenience downloads based on source releases;
>
> Re 3: license-gradle-plugin-0.12.1.jar
> This is apparently a 3rd party solution available through e.g.
> mvnrepository.com. Licensed under AL2.0. This can be included in the
> source repo, however it can NOT (per current conventions) be included in
> source releases. But it can be included in convenience downloads based on
> source releases;
>
> Re 4. maven-license-plugin-1.10.b1.jar
> This is apparently a 3rd party solution available through e.g.
> mvnrepository.com. Licensed under AL2.0. This can be included in the
> source repo, however it can NOT (per current conventions) be included in
> source releases. But it can be included in convenience downloads based on
> source releases;
>
> Re 5: plexus-utils-3.0.24.jar
> This is apparently a 3rd party solution available through e.g.
> mvnrepository.com. Licensed under AL2.0. This can be included in the
> source repo, however it can NOT (per current conventions) be included in
> source releases. But it can be included in convenience downloads based on
> source releases;
>
> Re 7: classes.jar
> Cursory analysis of the jar shows that it stemming from com.taobao java
> code, used in [1] and referenced in the Weex proposal (see [2]).
>
> Re 8: apache-rat-0.12.jar
> This is an artefact produced by Apache Creadur project (see [3]). This can
> be included in the source repo, and CAN be included in source releases (as
> it is ASF own).And it can be included in convenience downloads based on
> source releases;
>
> [1] https://github.com/apache/incubator-weex/tree/master/
> android/weex_debug/src/main/java/com/taobao/weex
> [2] https://wiki.apache.org/incubator/WeexProposal~)
> [3] http://creadur.apache.org/rat/
>
> Conclusion(s):
>
> 1. Many of the 3rd party solutions (jar files) used in the Apache Weex
> product are available in artefact repos like mvnrepository.com, and
> need not be included in the code base, source releases and convenience
> downloads as they can be retrieved through the dependency mgt solution used
> by the project (gradle in this case);
> 2. Convenience downloads (jar files) of ASF projects can be included
> when downloaded from ASF sources. However, if these are not available
> through ASF or 3rd party artefact repos ( e.g. mvnrepository.com) it
> is advised that the project contacts the (appropriate) ASF project that
> delivers such solutions and have them included in these artefact repos. The
> project can then have such retrieved through the depency mgt solution used
> by the project;
> 3. gradle-wrapper.jar is generated by executing a gradle task
> (./gradle wrapper), and is based on
> 1. the gradle version used (by the person having downloaded the
> source)
> 2. potential gradle configuration elements included in the
> project's source code (build.gradle, etc).
>
> No gradle-wrapper.jar artefact was found via mvnrepository.com. The ideal
> situation (to resolve the major issue discussed in this thread) would be if
> such convenience download would be made available through the various jar
> repos (e.g. mvnrepository). This should (preferably) be done by the Gradle
> community/organisation. However, in the short term, the project could
> adjust the gradlew scripts in the codebase to have that invoke the
> download from the project's repo ((in ./gradlew for linux initiate e.g.
> wget), and in ./gradlew.bat initiate an equivalent))
>
>
> I trust the above helps to clear the air.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Fri, May 5, 2017 at 3:57 AM, sospartan <so...@gmail.com> wrote:
>
>> Taylor,
>> Can you point out which objections you are agreed exactly?
>>
>>
>>
>> On Fri, May 5, 2017 at 9:31 AM, P. Taylor Goetz <pt...@gmail.com>
>> wrote:
>>
>> > Apologies for the auto correct.
>> >
>> > Please sub "Niclas" for "Nicolas".
>> >
>> > -Taylor
>> >
>> > > On May 4, 2017, at 8:43 PM, P. Taylor Goetz <pt...@gmail.com>
>> wrote:
>> > >
>> > > Nicolas,
>> > >
>> > > I understand and appreciate your passion, but would respectfully ask
>> > that you step down your tone a little bit. Craig and John have both
>> taken
>> > time to review the release candidate (which you should be appreciative
>> of
>> > -- getting IPMC members to review a release can be difficult). In my
>> > opinion their reviews bring up some valid points that need to be
>> considered.
>> > >
>> > > Weex, by its nature, has a complicated codebase with respect to
>> > licensing and building from source. It is a far cry from a java project
>> > with a Pom and a a "src" directory. It pulls in a lot of different code
>> > that needs to be considered and evaluated. Going forward the (P)PMC will
>> > need to understand that and as a TLP will need to be able to address
>> issues
>> > accordingly.
>> > >
>> > > What may seem like "Incubator hazing" right now, I would argue, is an
>> > exercise in making sure the podling has what it takes to operate as a
>> fully
>> > functional TLP. No two podlings are the same, and some face certain
>> burdens
>> > that others do not.
>> > >
>> > > For now can we try to turn the thread toward a more constructive path
>> > that benefits both the podling and the Incubator?
>> > >
>> > > For what it's worth, I agree with some (not all) of the objections
>> that
>> > have been raised. So I would be a -1 as well.
>> > >
>> > > -Taylor
>> > >
>> > >
>> > >
>> > >> On May 4, 2017, at 3:02 AM, Niclas Hedhman <ni...@hedhman.org>
>> wrote:
>> > >>
>> > >> Sorry, but if you don't know the background on that file, then
>> perhaps
>> > you
>> > >> think I am "not civil"... The fact is that NOTICE file doesn't
>> require
>> > any
>> > >> inclusion of what the project depends on, since they are not bundled,
>> > but
>> > >> will be downloaded during build. In a previous round, we were told to
>> > take
>> > >> it out of NOTICE for that reason (not bundled) and I argued that we
>> > should
>> > >> keep it in to make it more reasonable for downstreams to get an idea
>> of
>> > >> what a binary distro will actually contain. This file was the
>> > compromise of
>> > >> providing such details to downstream.
>> > >>
>> > >> Now you say, "Uhhh, it is unclear..." when in reality it would be
>> even
>> > more
>> > >> unclear if we left it out, as some people on this very list pushed
>> for
>> > on a
>> > >> previous RC.
>> > >>
>> > >> So, yes, I get pissed off as well. The incubator over time is getting
>> > more
>> > >> and more intolerant at podling's first release, and I think it is the
>> > wrong
>> > >> way to go. It is disheartening... truly...
>> > >>
>> > >>
>> > >> Niclas
>> > >>
>> > >>> On Thu, May 4, 2017 at 1:57 PM, Craig Russell <apache.clr@gmail.com
>> >
>> > wrote:
>> > >>>
>> > >>> I'm going to call foul on this one.
>> > >>>
>> > >>> If you cannot be civil, then leave the discussion to others.
>> > >>>
>> > >>> Craig
>> > >>>
>> > >>>> On May 3, 2017, at 7:24 PM, Niclas Hedhman <ni...@hedhman.org>
>> > wrote:
>> > >>>>
>> > >>>> BUT ALSO figuring out what to start looking for. For fak sake,
>> > >>>> man.... Get a grip on reality!
>> > >>>
>> > >>> Craig L Russell
>> > >>> Secretary, Apache Software Foundation
>> > >>> clr@apache.org http://db.apache.org/jdo
>> > >>>
>> > >>>
>> > >>> ------------------------------------------------------------
>> ---------
>> > >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > >>> For additional commands, e-mail: general-help@incubator.apache.org
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >> --
>> > >> Niclas Hedhman, Software Developer
>> > >> http://polygene.apache.org - New Energy for Java
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> >
>>
>>
>> --
>> sospartan
>> Phone:13588488290
>> HangZhou
>>
>
>
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Pierre Smits <pi...@gmail.com>.
Hi All,
To understand part of the problem correctly, in currently proposed release
there are many compiled components (jar files)that aren't allowed to be
included....
> clr% find . -name "*.jar"
1. > ./android/playground/gradle/wrapper/gradle-wrapper.jar
2. > ./android/sdk/gradle/wrapper/gradle-wrapper.jar
3. > ./android/sdk/license/license-gradle-plugin-0.12.1.jar
4. > ./android/sdk/license/maven-license-plugin-1.10.b1.jar
5. > ./android/sdk/license/plexus-utils-3.0.24.jar
6. > ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar
7. > ./android/weex_debug/libs/classes.jar
8. > ./scripts/apache-rat-0.12.jar
So lets break this down:
Re 1 & 2 and 6 : gradle-wrapper.jar
This is an 3rd party solution provided by the Gradle community/organisation
build through the 'gradle wrapper' task. Licensed under AL2.0. This can be
included in the source repo, however it can NOT (per current conventions)
be included in source releases. But it can be included in convenience
downloads based on source releases;
Re 3: license-gradle-plugin-0.12.1.jar
This is apparently a 3rd party solution available through e.g.
mvnrepository.com. Licensed under AL2.0. This can be included in the source
repo, however it can NOT (per current conventions) be included in source
releases. But it can be included in convenience downloads based on source
releases;
Re 4. maven-license-plugin-1.10.b1.jar
This is apparently a 3rd party solution available through e.g.
mvnrepository.com. Licensed under AL2.0. This can be included in the source
repo, however it can NOT (per current conventions) be included in source
releases. But it can be included in convenience downloads based on source
releases;
Re 5: plexus-utils-3.0.24.jar
This is apparently a 3rd party solution available through e.g.
mvnrepository.com. Licensed under AL2.0. This can be included in the source
repo, however it can NOT (per current conventions) be included in source
releases. But it can be included in convenience downloads based on source
releases;
Re 7: classes.jar
Cursory analysis of the jar shows that it stemming from com.taobao java
code, used in [1] and referenced in the Weex proposal (see [2]).
Re 8: apache-rat-0.12.jar
This is an artefact produced by Apache Creadur project (see [3]). This can
be included in the source repo, and CAN be included in source releases (as
it is ASF own).And it can be included in convenience downloads based on
source releases;
[1]
https://github.com/apache/incubator-weex/tree/master/android/weex_debug/src/main/java/com/taobao/weex
[2] https://wiki.apache.org/incubator/WeexProposal~)
[3] http://creadur.apache.org/rat/
Conclusion(s):
1. Many of the 3rd party solutions (jar files) used in the Apache Weex
product are available in artefact repos like mvnrepository.com, and need
not be included in the code base, source releases and convenience downloads
as they can be retrieved through the dependency mgt solution used by the
project (gradle in this case);
2. Convenience downloads (jar files) of ASF projects can be included
when downloaded from ASF sources. However, if these are not available
through ASF or 3rd party artefact repos ( e.g. mvnrepository.com) it is
advised that the project contacts the (appropriate) ASF project that
delivers such solutions and have them included in these artefact repos. The
project can then have such retrieved through the depency mgt solution used
by the project;
3. gradle-wrapper.jar is generated by executing a gradle task (./gradle
wrapper), and is based on
1. the gradle version used (by the person having downloaded the
source)
2. potential gradle configuration elements included in the project's
source code (build.gradle, etc).
No gradle-wrapper.jar artefact was found via mvnrepository.com. The ideal
situation (to resolve the major issue discussed in this thread) would be if
such convenience download would be made available through the various jar
repos (e.g. mvnrepository). This should (preferably) be done by the Gradle
community/organisation. However, in the short term, the project could
adjust the gradlew scripts in the codebase to have that invoke the
download from the project's repo ((in ./gradlew for linux initiate e.g.
wget), and in ./gradlew.bat initiate an equivalent))
I trust the above helps to clear the air.
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Fri, May 5, 2017 at 3:57 AM, sospartan <so...@gmail.com> wrote:
> Taylor,
> Can you point out which objections you are agreed exactly?
>
>
>
> On Fri, May 5, 2017 at 9:31 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
>
> > Apologies for the auto correct.
> >
> > Please sub "Niclas" for "Nicolas".
> >
> > -Taylor
> >
> > > On May 4, 2017, at 8:43 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
> > >
> > > Nicolas,
> > >
> > > I understand and appreciate your passion, but would respectfully ask
> > that you step down your tone a little bit. Craig and John have both taken
> > time to review the release candidate (which you should be appreciative of
> > -- getting IPMC members to review a release can be difficult). In my
> > opinion their reviews bring up some valid points that need to be
> considered.
> > >
> > > Weex, by its nature, has a complicated codebase with respect to
> > licensing and building from source. It is a far cry from a java project
> > with a Pom and a a "src" directory. It pulls in a lot of different code
> > that needs to be considered and evaluated. Going forward the (P)PMC will
> > need to understand that and as a TLP will need to be able to address
> issues
> > accordingly.
> > >
> > > What may seem like "Incubator hazing" right now, I would argue, is an
> > exercise in making sure the podling has what it takes to operate as a
> fully
> > functional TLP. No two podlings are the same, and some face certain
> burdens
> > that others do not.
> > >
> > > For now can we try to turn the thread toward a more constructive path
> > that benefits both the podling and the Incubator?
> > >
> > > For what it's worth, I agree with some (not all) of the objections that
> > have been raised. So I would be a -1 as well.
> > >
> > > -Taylor
> > >
> > >
> > >
> > >> On May 4, 2017, at 3:02 AM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
> > >>
> > >> Sorry, but if you don't know the background on that file, then perhaps
> > you
> > >> think I am "not civil"... The fact is that NOTICE file doesn't require
> > any
> > >> inclusion of what the project depends on, since they are not bundled,
> > but
> > >> will be downloaded during build. In a previous round, we were told to
> > take
> > >> it out of NOTICE for that reason (not bundled) and I argued that we
> > should
> > >> keep it in to make it more reasonable for downstreams to get an idea
> of
> > >> what a binary distro will actually contain. This file was the
> > compromise of
> > >> providing such details to downstream.
> > >>
> > >> Now you say, "Uhhh, it is unclear..." when in reality it would be even
> > more
> > >> unclear if we left it out, as some people on this very list pushed for
> > on a
> > >> previous RC.
> > >>
> > >> So, yes, I get pissed off as well. The incubator over time is getting
> > more
> > >> and more intolerant at podling's first release, and I think it is the
> > wrong
> > >> way to go. It is disheartening... truly...
> > >>
> > >>
> > >> Niclas
> > >>
> > >>> On Thu, May 4, 2017 at 1:57 PM, Craig Russell <ap...@gmail.com>
> > wrote:
> > >>>
> > >>> I'm going to call foul on this one.
> > >>>
> > >>> If you cannot be civil, then leave the discussion to others.
> > >>>
> > >>> Craig
> > >>>
> > >>>> On May 3, 2017, at 7:24 PM, Niclas Hedhman <ni...@hedhman.org>
> > wrote:
> > >>>>
> > >>>> BUT ALSO figuring out what to start looking for. For fak sake,
> > >>>> man.... Get a grip on reality!
> > >>>
> > >>> Craig L Russell
> > >>> Secretary, Apache Software Foundation
> > >>> clr@apache.org http://db.apache.org/jdo
> > >>>
> > >>>
> > >>> ------------------------------------------------------------
> ---------
> > >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >>> For additional commands, e-mail: general-help@incubator.apache.org
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Niclas Hedhman, Software Developer
> > >> http://polygene.apache.org - New Energy for Java
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> sospartan
> Phone:13588488290
> HangZhou
>
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by sospartan <so...@gmail.com>.
Taylor,
Can you point out which objections you are agreed exactly?
On Fri, May 5, 2017 at 9:31 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
> Apologies for the auto correct.
>
> Please sub "Niclas" for "Nicolas".
>
> -Taylor
>
> > On May 4, 2017, at 8:43 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
> >
> > Nicolas,
> >
> > I understand and appreciate your passion, but would respectfully ask
> that you step down your tone a little bit. Craig and John have both taken
> time to review the release candidate (which you should be appreciative of
> -- getting IPMC members to review a release can be difficult). In my
> opinion their reviews bring up some valid points that need to be considered.
> >
> > Weex, by its nature, has a complicated codebase with respect to
> licensing and building from source. It is a far cry from a java project
> with a Pom and a a "src" directory. It pulls in a lot of different code
> that needs to be considered and evaluated. Going forward the (P)PMC will
> need to understand that and as a TLP will need to be able to address issues
> accordingly.
> >
> > What may seem like "Incubator hazing" right now, I would argue, is an
> exercise in making sure the podling has what it takes to operate as a fully
> functional TLP. No two podlings are the same, and some face certain burdens
> that others do not.
> >
> > For now can we try to turn the thread toward a more constructive path
> that benefits both the podling and the Incubator?
> >
> > For what it's worth, I agree with some (not all) of the objections that
> have been raised. So I would be a -1 as well.
> >
> > -Taylor
> >
> >
> >
> >> On May 4, 2017, at 3:02 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> >>
> >> Sorry, but if you don't know the background on that file, then perhaps
> you
> >> think I am "not civil"... The fact is that NOTICE file doesn't require
> any
> >> inclusion of what the project depends on, since they are not bundled,
> but
> >> will be downloaded during build. In a previous round, we were told to
> take
> >> it out of NOTICE for that reason (not bundled) and I argued that we
> should
> >> keep it in to make it more reasonable for downstreams to get an idea of
> >> what a binary distro will actually contain. This file was the
> compromise of
> >> providing such details to downstream.
> >>
> >> Now you say, "Uhhh, it is unclear..." when in reality it would be even
> more
> >> unclear if we left it out, as some people on this very list pushed for
> on a
> >> previous RC.
> >>
> >> So, yes, I get pissed off as well. The incubator over time is getting
> more
> >> and more intolerant at podling's first release, and I think it is the
> wrong
> >> way to go. It is disheartening... truly...
> >>
> >>
> >> Niclas
> >>
> >>> On Thu, May 4, 2017 at 1:57 PM, Craig Russell <ap...@gmail.com>
> wrote:
> >>>
> >>> I'm going to call foul on this one.
> >>>
> >>> If you cannot be civil, then leave the discussion to others.
> >>>
> >>> Craig
> >>>
> >>>> On May 3, 2017, at 7:24 PM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
> >>>>
> >>>> BUT ALSO figuring out what to start looking for. For fak sake,
> >>>> man.... Get a grip on reality!
> >>>
> >>> Craig L Russell
> >>> Secretary, Apache Software Foundation
> >>> clr@apache.org http://db.apache.org/jdo
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Niclas Hedhman, Software Developer
> >> http://polygene.apache.org - New Energy for Java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
sospartan
Phone:13588488290
HangZhou
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Apologies for the auto correct.
Please sub "Niclas" for "Nicolas".
-Taylor
> On May 4, 2017, at 8:43 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
>
> Nicolas,
>
> I understand and appreciate your passion, but would respectfully ask that you step down your tone a little bit. Craig and John have both taken time to review the release candidate (which you should be appreciative of -- getting IPMC members to review a release can be difficult). In my opinion their reviews bring up some valid points that need to be considered.
>
> Weex, by its nature, has a complicated codebase with respect to licensing and building from source. It is a far cry from a java project with a Pom and a a "src" directory. It pulls in a lot of different code that needs to be considered and evaluated. Going forward the (P)PMC will need to understand that and as a TLP will need to be able to address issues accordingly.
>
> What may seem like "Incubator hazing" right now, I would argue, is an exercise in making sure the podling has what it takes to operate as a fully functional TLP. No two podlings are the same, and some face certain burdens that others do not.
>
> For now can we try to turn the thread toward a more constructive path that benefits both the podling and the Incubator?
>
> For what it's worth, I agree with some (not all) of the objections that have been raised. So I would be a -1 as well.
>
> -Taylor
>
>
>
>> On May 4, 2017, at 3:02 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>>
>> Sorry, but if you don't know the background on that file, then perhaps you
>> think I am "not civil"... The fact is that NOTICE file doesn't require any
>> inclusion of what the project depends on, since they are not bundled, but
>> will be downloaded during build. In a previous round, we were told to take
>> it out of NOTICE for that reason (not bundled) and I argued that we should
>> keep it in to make it more reasonable for downstreams to get an idea of
>> what a binary distro will actually contain. This file was the compromise of
>> providing such details to downstream.
>>
>> Now you say, "Uhhh, it is unclear..." when in reality it would be even more
>> unclear if we left it out, as some people on this very list pushed for on a
>> previous RC.
>>
>> So, yes, I get pissed off as well. The incubator over time is getting more
>> and more intolerant at podling's first release, and I think it is the wrong
>> way to go. It is disheartening... truly...
>>
>>
>> Niclas
>>
>>> On Thu, May 4, 2017 at 1:57 PM, Craig Russell <ap...@gmail.com> wrote:
>>>
>>> I'm going to call foul on this one.
>>>
>>> If you cannot be civil, then leave the discussion to others.
>>>
>>> Craig
>>>
>>>> On May 3, 2017, at 7:24 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>>>>
>>>> BUT ALSO figuring out what to start looking for. For fak sake,
>>>> man.... Get a grip on reality!
>>>
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> clr@apache.org http://db.apache.org/jdo
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>> --
>> Niclas Hedhman, Software Developer
>> http://polygene.apache.org - New Energy for Java
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Nicolas,
I understand and appreciate your passion, but would respectfully ask that you step down your tone a little bit. Craig and John have both taken time to review the release candidate (which you should be appreciative of -- getting IPMC members to review a release can be difficult). In my opinion their reviews bring up some valid points that need to be considered.
Weex, by its nature, has a complicated codebase with respect to licensing and building from source. It is a far cry from a java project with a Pom and a a "src" directory. It pulls in a lot of different code that needs to be considered and evaluated. Going forward the (P)PMC will need to understand that and as a TLP will need to be able to address issues accordingly.
What may seem like "Incubator hazing" right now, I would argue, is an exercise in making sure the podling has what it takes to operate as a fully functional TLP. No two podlings are the same, and some face certain burdens that others do not.
For now can we try to turn the thread toward a more constructive path that benefits both the podling and the Incubator?
For what it's worth, I agree with some (not all) of the objections that have been raised. So I would be a -1 as well.
-Taylor
> On May 4, 2017, at 3:02 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> Sorry, but if you don't know the background on that file, then perhaps you
> think I am "not civil"... The fact is that NOTICE file doesn't require any
> inclusion of what the project depends on, since they are not bundled, but
> will be downloaded during build. In a previous round, we were told to take
> it out of NOTICE for that reason (not bundled) and I argued that we should
> keep it in to make it more reasonable for downstreams to get an idea of
> what a binary distro will actually contain. This file was the compromise of
> providing such details to downstream.
>
> Now you say, "Uhhh, it is unclear..." when in reality it would be even more
> unclear if we left it out, as some people on this very list pushed for on a
> previous RC.
>
> So, yes, I get pissed off as well. The incubator over time is getting more
> and more intolerant at podling's first release, and I think it is the wrong
> way to go. It is disheartening... truly...
>
>
> Niclas
>
>> On Thu, May 4, 2017 at 1:57 PM, Craig Russell <ap...@gmail.com> wrote:
>>
>> I'm going to call foul on this one.
>>
>> If you cannot be civil, then leave the discussion to others.
>>
>> Craig
>>
>>> On May 3, 2017, at 7:24 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>>>
>>> BUT ALSO figuring out what to start looking for. For fak sake,
>>> man.... Get a grip on reality!
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> clr@apache.org http://db.apache.org/jdo
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Niclas Hedhman <ni...@hedhman.org>.
Sorry, but if you don't know the background on that file, then perhaps you
think I am "not civil"... The fact is that NOTICE file doesn't require any
inclusion of what the project depends on, since they are not bundled, but
will be downloaded during build. In a previous round, we were told to take
it out of NOTICE for that reason (not bundled) and I argued that we should
keep it in to make it more reasonable for downstreams to get an idea of
what a binary distro will actually contain. This file was the compromise of
providing such details to downstream.
Now you say, "Uhhh, it is unclear..." when in reality it would be even more
unclear if we left it out, as some people on this very list pushed for on a
previous RC.
So, yes, I get pissed off as well. The incubator over time is getting more
and more intolerant at podling's first release, and I think it is the wrong
way to go. It is disheartening... truly...
Niclas
On Thu, May 4, 2017 at 1:57 PM, Craig Russell <ap...@gmail.com> wrote:
> I'm going to call foul on this one.
>
> If you cannot be civil, then leave the discussion to others.
>
> Craig
>
> > On May 3, 2017, at 7:24 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> >
> > BUT ALSO figuring out what to start looking for. For fak sake,
> > man.... Get a grip on reality!
>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org http://db.apache.org/jdo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Craig Russell <ap...@gmail.com>.
I'm going to call foul on this one.
If you cannot be civil, then leave the discussion to others.
Craig
> On May 3, 2017, at 7:24 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> BUT ALSO figuring out what to start looking for. For fak sake,
> man.... Get a grip on reality!
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, May 4, 2017 at 9:22 AM, Craig Russell <ap...@gmail.com> wrote:
> clr% find . -name "*.jar"
> ./android/playground/gradle/wrapper/gradle-wrapper.jar
> ./android/sdk/gradle/wrapper/gradle-wrapper.jar
> ./android/sdk/license/license-gradle-plugin-0.12.1.jar
> ./android/sdk/license/maven-license-plugin-1.10.b1.jar
> ./android/sdk/license/plexus-utils-3.0.24.jar
> ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar
> ./android/weex_debug/libs/classes.jar
> ./scripts/apache-rat-0.12.jar
> 1. These jar files are not source and must not appear in the source
release.
These are convenience for building the system. Those who are overly
concerned and don't trust Apache project members, are free to build using
tools downloaded by themselves. I have argued that this will be changed to
a "only source code" approach in the future, but should not hinder a
release now.
> 2. I appreciate the effort involved in compiling the
POSSIBLE-NOTICES-FOR-BIN-DIST. But looking into these dependencies I am
troubled by the difficulty actually finding the licenses of the projects.
>
> For example, the "possible notice" for animaitonjs (possible typo here)
refers to https://www.npmjs.com/package/animationjs from which it is
impossible (ok, perhaps possible but I could not find a link) to find the
actual project.
>
> References to npmjs in this entire file should be removed and replaced by
references to the home of the project. (Not relevant for this release
because the files are not actually being distributed.)
And YET, the argument is that this file SHOULD NOT BE INCLUDED AT ALL, so
that downstream packagers have to not only worry about what you are listing
above, BUT ALSO figuring out what to start looking for. For fak sake,
man.... Get a grip on reality!
> 3. The java source files in android/commons/src are still in the
com.alibaba name space. Assuming that these are actually weex source files,
they must be repackaged to org.apache.
YES, that is on purpose to avoid breaking compatibility with hundreds of
people using Weex in their projects right now. org.apache.weex namespace is
slated for a later release when compatibility is sacrificed.
> 4. The javascript source files in playground/app/src are missing the
license header. They have a style that I do not recognize. Are these
generated files? The first several lines of storage-demo.js:
>
> /******/ (function(modules) { // webpackBootstrap
> /******/ // The module cache
> /******/ var installedModules = {};
>
> /******/ // The require function
> /******/ function __webpack_require__(moduleId) {
>
> /******/ // Check if module is in cache
> /******/ if(installedModules[moduleId])
> /******/ return installedModules[moduleId].exports;
I don't know about this one.
> 5. The java files in playground/app/src/main/java_zxing are in the
com.google name space. They have a google license header.
I have missed that one. But it is bundled source code from elsewhere, and
should be mentioned in top-level NOTICE, not only the localized one.
Before you complain about the NOTICE and LICENSE in playground, that is due
to the intent that the playground/ is expected to be copied elsewhere as a
sample project that uses the Weex SDK. Hence its location there.
> 6. The packages/weex-html5 contains LICENSE and NOTICE files. These
should be in the top level directory of the release.
This one is less than clear cut. The content in packages/ will be uploaded
to npm registry, and the files in the directory will be moved there. There
is relatively little information (compared to Maven Central uploads) how
that is to be handled, since the content that is uploaded need to be part
of a source release.
> 7. The scripts/rh contains LICENSE and NOTICE files. These should be in
the top level directory of the release.
The scripts/ directory is mistakenly included in the dist.
> 8. There is an executable file that doesn't belong:
>
> clr% ls -l start
> -rwxr-xr-x@ 1 clr staff 161 Apr 27 20:34 start
What's the problem with "executable file"? It is a shell script, and since
when are we not allowed to ship that?
Granted; lacking license header, but that is not your complaint.
> 9. There is an executable gradlew in sdk/gradle that doesn't belong in a
source release.
Port of your point 1, and gradlew is another shell script. ARE YOU SAYING
that shell scripts are not allowed in source distros?
> 10. There are shared objects in sdk/libs that don't belong in a source
release.
Alright, this is a issue that I am not convinced either way. I agree that
"doesn't belong", but on the other hand, the steps to set up (and get
working) the Android Native Development Kit (not talking about the Android
SDK) is substantial. By allowing these built binaries, we can avoid that
for most users, who normally never touch the NDK. By demanding that these
binaries are taken out, then you just condemned this project to produce a
Binary Release as well, which was not planned for this release.
> 11. There are NOTICE and LICENSE files in ios/sdk that seem to be unix
executable files.
> clr% ls -l ios/sdk
> total 40
> -rwxr-xr-x@ 1 clr staff 11343 Apr 27 20:34 LICENSE
> -rwxr-xr-x@ 1 clr staff 575 Apr 27 20:34 NOTICE
An honest mistake, and shouldn't stop a release.
> 12. The README.md doesn't tell me how to build/use org.apache.weex. The
first several lines refer to third-party projects from Alibaba and
cocoapods. How do I use the Apache project?
Well, you just introduced more complexity in "using the project" with your
insistence on no binaries, and more so if your "no execute flag" is also
now not allowed. AFAIK, there is no obligation that the source distribution
must contain all details needed to build the project, only that it can be
built. But for you convenience;
1. Install Gradle and learn how to use it.
2. Install Maven and learn how to use it.
3. Install Android NDK and learn how to use it.
4. Install Android SDK and learn how to use it.
5. Install Xcode and learn how to use it.
6. Install IOS SDK and learn how to use it.
7. Build each part with the tool needed.
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by Craig Russell <ap...@gmail.com>.
I also must vote -1 on this release.
clr% find . -name "*.jar"
./android/playground/gradle/wrapper/gradle-wrapper.jar
./android/sdk/gradle/wrapper/gradle-wrapper.jar
./android/sdk/license/license-gradle-plugin-0.12.1.jar
./android/sdk/license/maven-license-plugin-1.10.b1.jar
./android/sdk/license/plexus-utils-3.0.24.jar
./android/weex_debug/gradle/wrapper/gradle-wrapper.jar
./android/weex_debug/libs/classes.jar
./scripts/apache-rat-0.12.jar
1. These jar files are not source and must not appear in the source release.
2. I appreciate the effort involved in compiling the POSSIBLE-NOTICES-FOR-BIN-DIST. But looking into these dependencies I am troubled by the difficulty actually finding the licenses of the projects.
For example, the "possible notice" for animaitonjs (possible typo here) refers to https://www.npmjs.com/package/animationjs from which it is impossible (ok, perhaps possible but I could not find a link) to find the actual project.
References to npmjs in this entire file should be removed and replaced by references to the home of the project. (Not relevant for this release because the files are not actually being distributed.)
3. The java source files in android/commons/src are still in the com.alibaba name space. Assuming that these are actually weex source files, they must be repackaged to org.apache.
4. The javascript source files in playground/app/src are missing the license header. They have a style that I do not recognize. Are these generated files? The first several lines of storage-demo.js:
/******/ (function(modules) { // webpackBootstrap
/******/ // The module cache
/******/ var installedModules = {};
/******/ // The require function
/******/ function __webpack_require__(moduleId) {
/******/ // Check if module is in cache
/******/ if(installedModules[moduleId])
/******/ return installedModules[moduleId].exports;
5. The java files in playground/app/src/main/java_zxing are in the com.google name space. They have a google license header.
6. The packages/weex-html5 contains LICENSE and NOTICE files. These should be in the top level directory of the release.
7. The scripts/rh contains LICENSE and NOTICE files. These should be in the top level directory of the release.
8. There is an executable file that doesn't belong:
clr% ls -l start
-rwxr-xr-x@ 1 clr staff 161 Apr 27 20:34 start
9. There is an executable gradlew in sdk/gradle that doesn't belong in a source release.
10. There are shared objects in sdk/libs that don't belong in a source release.
11. There are NOTICE and LICENSE files in ios/sdk that seem to be unix executable files.
clr% ls -l ios/sdk
total 40
-rwxr-xr-x@ 1 clr staff 11343 Apr 27 20:34 LICENSE
-rwxr-xr-x@ 1 clr staff 575 Apr 27 20:34 NOTICE
12. The README.md doesn't tell me how to build/use org.apache.weex. The first several lines refer to third-party projects from Alibaba and cocoapods. How do I use the Apache project?
Craig
> On May 2, 2017, at 5:26 PM, John D. Ament <jo...@apache.org> wrote:
>
> Sorry but -1 due to binaries in the source release. I'm not sure if I
> missed these the last go around or what, but they should not be included
> (gradle-wrapper I know was called out before):
>
> ./apache-weex-incubating-0.12.0-src/android/playground/gradle/wrapper/gradle-wrapper.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/gradle/wrapper/gradle-wrapper.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/license-gradle-plugin-0.12.1.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/maven-license-plugin-1.10.b1.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/plexus-utils-3.0.24.jar
> ./apache-weex-incubating-0.12.0-src/android/weex_debug/gradle/wrapper/gradle-wrapper.jar
> ./apache-weex-incubating-0.12.0-src/android/weex_debug/libs/classes.jar
> ./apache-weex-incubating-0.12.0-src/scripts/apache-rat-0.12.jar
>
> Other things checked:
> - Has DISCLAIMER
> - File name includes incubating
> - NOTICE and LICENSE look right, especially like the name
> POSSIBLE-NOTICES-FOR-BIN-DIST
>
> I have no idea how to build from source, would be good to include that +
> how to run rat in your instructions. If it weren't for the binary files I
> would vote a +1.
>
> John
>
> On Tue, May 2, 2017 at 1:49 AM sospartan <so...@apache.org> wrote:
>
>> Hi all,
>> I'll calling a vote for Weex-incubating 0.12.0-RC3 release.
>>
>> The PPMC vote for this release has passed:
>>
>> https://lists.apache.org/thread.html/c5514c86433e3551cae00b21a77a1407ee20846f6565f9701d78c85b@%3Cdev.weex.apache.org%3E
>>
>> The tag to be voted upon:
>> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
>> ;a=shortlog;h=refs/tags/0.12.0-rc3
>>
>> The commit hash:
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=702d04c4922105069f537afdb4688f808530994d
>>
>> The source tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.0-incubating/RC3/
>>
>> The fingerprint of key to sign release artifacts:
>> 97B9 6598 A6A3 B63C 53BD 77E9 44C5 2286 22B9 7784
>>
>> Release artifacts are signed with the following key:
>> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
>>
>> Release note about this version:
>> https://issues.apache.org/jira/browse/WEEX-26
>>
>> This vote will remain open for at least 72 hours.
>> Please vote on releasing this RC.
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> --
>> Best Regards!
>> ------------------------------
>>
>> sospartan
>> https://weex-project.io
>>
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Posted by "John D. Ament" <jo...@apache.org>.
Sorry but -1 due to binaries in the source release. I'm not sure if I
missed these the last go around or what, but they should not be included
(gradle-wrapper I know was called out before):
./apache-weex-incubating-0.12.0-src/android/playground/gradle/wrapper/gradle-wrapper.jar
./apache-weex-incubating-0.12.0-src/android/sdk/gradle/wrapper/gradle-wrapper.jar
./apache-weex-incubating-0.12.0-src/android/sdk/license/license-gradle-plugin-0.12.1.jar
./apache-weex-incubating-0.12.0-src/android/sdk/license/maven-license-plugin-1.10.b1.jar
./apache-weex-incubating-0.12.0-src/android/sdk/license/plexus-utils-3.0.24.jar
./apache-weex-incubating-0.12.0-src/android/weex_debug/gradle/wrapper/gradle-wrapper.jar
./apache-weex-incubating-0.12.0-src/android/weex_debug/libs/classes.jar
./apache-weex-incubating-0.12.0-src/scripts/apache-rat-0.12.jar
Other things checked:
- Has DISCLAIMER
- File name includes incubating
- NOTICE and LICENSE look right, especially like the name
POSSIBLE-NOTICES-FOR-BIN-DIST
I have no idea how to build from source, would be good to include that +
how to run rat in your instructions. If it weren't for the binary files I
would vote a +1.
John
On Tue, May 2, 2017 at 1:49 AM sospartan <so...@apache.org> wrote:
> Hi all,
> I'll calling a vote for Weex-incubating 0.12.0-RC3 release.
>
> The PPMC vote for this release has passed:
>
> https://lists.apache.org/thread.html/c5514c86433e3551cae00b21a77a1407ee20846f6565f9701d78c85b@%3Cdev.weex.apache.org%3E
>
> The tag to be voted upon:
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
> ;a=shortlog;h=refs/tags/0.12.0-rc3
>
> The commit hash:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=702d04c4922105069f537afdb4688f808530994d
>
> The source tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.0-incubating/RC3/
>
> The fingerprint of key to sign release artifacts:
> 97B9 6598 A6A3 B63C 53BD 77E9 44C5 2286 22B9 7784
>
> Release artifacts are signed with the following key:
> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
>
> Release note about this version:
> https://issues.apache.org/jira/browse/WEEX-26
>
> This vote will remain open for at least 72 hours.
> Please vote on releasing this RC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> --
> Best Regards!
> ------------------------------
>
> sospartan
> https://weex-project.io
>