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/04/20 08:10:55 UTC
[VOTE]: Apache Weex-incubating Release 0.12.0-RC2
Hi all,
I'll calling a vote for Weex-incubating 0.12.0-RC2 release.
The PPMC vote for this release has passed:
https://lists.apache.org/thread.html/d544a60a4038f9d053f7ea1eca0d162b9aef392551a02a0401041e8f@%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-rc1
The commit hash:
https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907
The source tarball can be found at:
https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.0-incubating/RC1/
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-RC2
Posted by Niclas Hedhman <ni...@hedhman.org>.
+1 binding
On Thu, Apr 20, 2017 at 4:10 PM, sospartan <so...@apache.org> wrote:
> Hi all,
> I'll calling a vote for Weex-incubating 0.12.0-RC2 release.
>
> The PPMC vote for this release has passed:
> https://lists.apache.org/thread.html/d544a60a4038f9d053f7ea1eca0d16
> 2b9aef392551a02a0401041e8f@%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-rc1
>
> The commit hash:
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> 9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907
>
> The source tarball can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> 0-incubating/RC1/
>
> 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-RC2
Posted by Daniel Dekany <dd...@freemail.hu>.
Saturday, April 22, 2017, 12:41:23 PM, Niclas Hedhman wrote:
> Note on gradle-wrapper.jar,
> For source releases, we expect the project to be buildable by the user. The
> Gradle wrapper is the easiest way to make that happen. It (together with
> the gradlew and gradlew.bat scripts) ensures that that the build will be
> the same, and not suffer from different Gradle versions being used,
> potentially incompatible. Now, you could write a document on how to achieve
> this in other ways, and deal with the fall-out. But just like the
> gradle-wrapper.jar is committed to the source repository, I stand by that
> the gradle-wrapper belongs in the source distro, as a defacto standard for
> projects using Gradle to build. You will find similar 'bundling' of build
> systems in other languages as well, are they also banned? Or it just
> because they are in human-readable format that it is considered ok?
I'm also interested in the answer for this. Committing
gradle-wrapper.jar into the VCN is a quite common practice (and is
also the subject of some "religious" disputes, because some just can't
bear the idea of committing jar-s). We have run into yet another
problem with gradle-wrapper.jar; there's no license information for
it, or at least we couldn't find it. I guess that will be the real
blocker when it comes to including it. (Or perhaps ASF could make an
exception with gradle-wrapper.jar, as it's commonly known what it is
and where it comes from.)
> Note on LICENSE;
> IIUIC, the source distribution doesn't ship any dependencies (except Gradle
> above), and there is only Apache License to be considered.
>
> As for NOTICE, the ASF documentation you point to, basically says that a)
> don't put in anything that is not bundled (i.e. just about nothing in the
> source release), b) no burden on downstream users. HOWEVER, by excluding
> the list of dependencies that will be in the resulting product, we would
> actually increase the burden of downstream users as they would need to
> figure out what licensing requirements will come out of it all, if they
> choose to distribute.
> Therefor, I would argue that documentation is in this case arguing against
> itself in a single sentence, and think that the approach taken by Weex is
> appropriate.
We do have a different NOTICE and LICENSE for the source distribution
and for the binary distribution, plus one more variation that's
included in the jar artifact (which is distributed in itself via the
Maven Central Repository). That's because each form of distributor
carries different files. I'm not saying that's the correct way (I
don't know... but I hope so), but such releases have passed voting
here for 3 times so far.
> (all subject to that my understanding of that there is no third-party in
> the source distribution)
>
>
> Package name; yeah, I completely forgot that, as I saw it in the directory
> name.
>
>
> On Sat, Apr 22, 2017 at 6:10 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>> Sorry but -1 due to misnamed package and binary content.
>>
>> - No "incubating" / "incubator" in package name
>> - JAR files are present in the source release (gradle-wrapper.jar)
>> - Ideally the expanded package would include "apache" in the folder, not a
>> big deal.
>> - DISCLAIMER present
>>
>> Your NOTICE seems way too big. Do you actually bundle all of these
>> dependencies? I can't find them if you do. Most of what's being called out
>> in NOTICE should actually be in LICENSE. For instance, only Apache
>> licensed code would normally call out NOTICE entries, and those entries are
>> meant to be copied verbatim from the source package. In this case, fastjson
>> is referenced (though I don't see it anywhere), but it has no NOTICE so
>> nothing to declare.
>>
>> Meanwhile, your LICENSE is too short. Each project that you do bundle, if
>> its not Apache licensed, you must copy its license text or provide a
>> pointer to the license. We have a full guide on how to assemble these -
>> http://www.apache.org/dev/licensing-howto.html - please reach out if you
>> need help.
>>
>> The critical piece to fix is your package name. If you're re-rolling to
>> fix that, I would recommend going through your NOTICE/LICENSE and see what
>> does and doesn't belong. The second piece to fix is the JAR files. You
>> must not include them (I've tried fighting the fight, and can't get
>> anywhere on it - source releases are for source code only).
>>
>> John
>>
>> On Thu, Apr 20, 2017 at 4:11 AM sospartan <so...@apache.org> wrote:
>>
>> > Hi all,
>> > I'll calling a vote for Weex-incubating 0.12.0-RC2 release.
>> >
>> > The PPMC vote for this release has passed:
>> >
>> > https://lists.apache.org/thread.html/d544a60a4038f9d053f7ea1eca0d16
>> 2b9aef392551a02a0401041e8f@%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-rc1
>> >
>> > The commit hash:
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
>> > 9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907
>> > <https://git-wip-us.apache.org/repos/asf?p=incubator-
>> weex.git;a=commit;h=9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907>
>> >
>> > The source tarball can be found at:
>> >
>> > https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
>> 0-incubating/RC1/
>> >
>> > 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
>> >
>>
>
>
>
--
Thanks,
Daniel Dekany
---------------------------------------------------------------------
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-RC2
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sun, Apr 23, 2017 at 7:26 PM, John D. Ament <jo...@apache.org>
wrote:
> Sure - but there's still issues with it. And you still need a NOTICE file
> in your source distribution.
>
True. But it would be a single "from Apache..." note, as we are not
bundling anything else.
> I thought about your points a bit more last night, and conversely I want to
> explain why its actually more of a burdon. Suppose that for some reason I
> found the contents of this class to be useful and wanted to use it alone in
> my work:
> https://github.com/apache/incubator-weex/blob/master/
> android/commons/src/main/java/com/alibaba/weex/commons/
> SimpleWeexActivity.java
> .
> By having an extremely verbose NOTICE, as a user of this file alone, I have
> to carry all of that along with me.
>
I think you will get more than one answer if asking 3 lawyers on this,
because if you single out that class file, then the discussion is quickly
whether the "work" is that class file, or all the stuff around it.
Example; say that I use something that was licensed to me under a BSD
license, but is not otherwise published elsewhere, or maybe hard to locate.
I use that work in a larger work which I release under GPL. So, you come
along and find this file and say "hey, exactly what I have been looking
for"... Is that file now GPL, even though the file header may say
otherwise, and no matter whether I intended that? This is analogous of your
case above, but perhaps spelled out a bit more dramatically.
And honestly, hand on heart, how often is picking individual source files
done, compared to the endless number of binary dependencies that are
resolved by the hour? And most business software that I have ended up
working on places those dependencies in the mid-to-high hundreds, even
beyond thousand, where IF built from source, YOU would have to go figure
each one out manually. Can you honestly claim that is less "burden", even
IF all 100 lines of notice needs to percolate downstream ad nauseum, which
in reality is a "cat his/NOTICE her/NOTICE >my/NOITCE"?
I also just noticed that <strike-through>your</strike-through>
> <inserted>the</inserted> files are including the full license text of
the apache license in each file. We typically use the abbreviated version.
>
Yeah, I know that. I thought to tackle that with a package name change that
I would also like to see soon.
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2
Posted by sospartan <so...@gmail.com>.
john,
I'll take the work and make NOTICE and LICENSE(s) right.
Thanks for this discussion, which will be a good lesson for our newbies.
The full-licensed file(SimpleWeexActivity.java) is in old branch, we have
fix that in dev. I'll push to master after we have our first RC.
On Sun, Apr 23, 2017 at 7:26 PM, John D. Ament <jo...@apache.org>
wrote:
> On Sat, Apr 22, 2017 at 9:43 PM Niclas Hedhman <ni...@hedhman.org> wrote:
>
> > John,
> > thanks for pointing me to the issue. I argue against Marvin on it, based
> on
> > "this is a tool" that is made conveniently available for those who are
> not
> > paranoid.
> >
> > NOTICE; Ok, let's rename the file.
> > NOTICES-POSSIBLY-NEEDED-FOR-BINARY-DISTRIBUTION
> >
> >
> Sure - but there's still issues with it. And you still need a NOTICE file
> in your source distribution.
>
> Here's an example: fastjson is listed in the NOTICE file. If I look at
> fastjson's repository, and build artifacts, there's no NOTICE file
> included. As a result, there should be no entry in the NOTICE file for
> this dependency. https://github.com/alibaba/fastjson
>
> Likewise, for each MIT licensed artifact, an entry in LICENSE should be
> made pointing to the MIT license for that product. Same applies to each
> BSD-3-Clause licensed work included in the binary. Same applies to other
> non-Apache-2 licensed products (Apache 2 is already included, so you're
> good). Apache 2 products are meant to carry NOTICE files for copyright to
> avoid repeating licenses.
>
> At the same time, dexposed has a ridiculously long NOTICE file - completely
> incorrectly build, but its all in there. This may technically mean the
> entire contents have to be included in your binary NOTICE file:
> https://github.com/alibaba/dexposed/blob/master/NOTICE
>
> If you need me to, I can go into each of your dependencies and give a heads
> up, but would recommend that the PPMC does this, based on the assembling
> guide I've linked to already.
>
>
> > Ok?
> >
> >
> I thought about your points a bit more last night, and conversely I want to
> explain why its actually more of a burdon. Suppose that for some reason I
> found the contents of this class to be useful and wanted to use it alone in
> my work:
> https://github.com/apache/incubator-weex/blob/master/
> android/commons/src/main/java/com/alibaba/weex/commons/
> SimpleWeexActivity.java
> .
> By having an extremely verbose NOTICE, as a user of this file alone, I have
> to carry all of that along with me.
>
> I also just noticed that your files are including the full license text of
> the apache license in each file. We typically use the abbreviated version.
>
>
> >
> > On Sun, Apr 23, 2017 at 8:01 AM, John D. Ament <jo...@apache.org>
> > wrote:
> >
> > > On Sat, Apr 22, 2017 at 7:57 AM Niclas Hedhman <ni...@hedhman.org>
> > wrote:
> > >
> > > > On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <
> johndament@apache.org>
> > > > wrote:
> > > > >
> > > > > On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <niclas@hedhman.org
> >
> > > > wrote:
> > > > >
> > > > > > Note on gradle-wrapper.jar,
> > > >
> > > > > Agreed, and this is mostly my argument as well. However, in *nix
> the
> > > JAR
> > > > > will get downloaded automatically if not present. On windows, you
> > need
> > > > to
> > > > > pre-install gradle.
> > > >
> > > > Where did you get this idea? The gradlew launches the Java program
> > inside
> > > > the gradle-wrapper.jar which in turn downloads the full Gradle distro
> > if
> > > > not present already. I have not heard neither that the gradlew would
> > > > download the wrapper jar, nor that the gradle-wrapper does not work
> on
> > > > Windows.
> > > >
> > > >
> > > I must have seen a custom built version of gradlew then.
> > >
> > >
> > > >
> > > > > The argument I've seen from present VP Legal is that the JARs may
> > have
> > > > > viruses in them, or contain other malware.
> > > >
> > > > That was the silliest reason I have heard in a long time. With that
> > > > argument, we only allow source distributions, only allow to use tools
> > > that
> > > > are built from source recursively back through time... Yeah! Right...
> > > now,
> > > > there are a few projects that needs that, such as the Bitcoin
> > blockchain
> > > > toolchain, as they distrust everything, and settled on some binary
> from
> > > > decades ago with a known hash as the starting point. In any event,
> ASF
> > > > would collapse under the "they may contain malware" banner of
> paranoia.
> > > >
> > > > I don't buy it, since I trust my fellow folks at ASF rather than
> assume
> > > > malevolence from everyone.
> > > >
> > > >
> > > I don't disagree with you. And now may be a good time to bring this
> back
> > > up. But for now, its not allowable in the release. See also
> > > https://issues.apache.org/jira/browse/LEGAL-288
> > >
> > >
> > >
> > > > In this particular case, I don't think that gradle-wrapper.jar ever
> > > > changes, so committing a new version would set off red flags, at
> least
> > > with
> > > > me (used Gradle for about 7 years now). A small script that traverse
> > all
> > > of
> > > > Apache GitHub and compares them all??
> > > >
> > > > >
> > > > > > Note on LICENSE;
> > > > > > IIUIC, the source distribution doesn't ship any dependencies
> > (except
> > > > Gradle
> > > > > > above), and there is only Apache License to be considered.
> > > > > >
> > > > > > As for NOTICE, the ASF documentation you point to, basically says
> > > that
> > > > a)
> > > > > > don't put in anything that is not bundled (i.e. just about
> nothing
> > in
> > > > the
> > > > > > source release), b) no burden on downstream users. HOWEVER, by
> > > > excluding
> > > > > > the list of dependencies that will be in the resulting product,
> we
> > > > would
> > > > > > actually increase the burden of downstream users as they would
> need
> > > to
> > > > > > figure out what licensing requirements will come out of it all,
> if
> > > they
> > > > > > choose to distribute.
> > > > > > Therefor, I would argue that documentation is in this case
> arguing
> > > > against
> > > > > > itself in a single sentence, and think that the approach taken by
> > > Weex
> > > > is
> > > > > > appropriate.
> > > > > >
> > > > >
> > > > > I disagree. I think you're thinking of source release vs binary
> > > release.
> > > > > Weex has only presented a source release.
> > > >
> > > > I am aware of that, but the documentation says "make it easier for
> the
> > > > downstream" and by "excluding all non-bundled, but required,
> > dependencies
> > > > from NOTICE" we actually make it harder for the downstream. And
> sorry,
> > I
> > > > place "common sense" and "tribal knowledge" way over someone writing
> a
> > > > documentation and perhaps didn't realize the consequences. I never
> stop
> > > > thinking, just because I read something somewhere.
> > > >
> > > >
> > > I'm not sure what a valid response to this would be. I don't believe
> we
> > > should be taking into account ease of use for downstream consumers,
> > however
> > > at the end of the day those downstream consumers of a source release
> > > eventually get a binary and that binary should include proper data.
> > What I
> > > am trying to say is that these contents look more appropriate for the
> > > binary release, which would be a satisfactory use case for downstream
> > > consumers.
> > >
> > >
> > >
> > > >
> > > > Cheers
> > > > --
> > > > Niclas Hedhman, Software Developer
> > > > http://polygene.apache.org - New Energy for Java
> > > >
> > >
> >
> >
> >
> > --
> > 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-RC2
Posted by "John D. Ament" <jo...@apache.org>.
On Sat, Apr 22, 2017 at 9:43 PM Niclas Hedhman <ni...@hedhman.org> wrote:
> John,
> thanks for pointing me to the issue. I argue against Marvin on it, based on
> "this is a tool" that is made conveniently available for those who are not
> paranoid.
>
> NOTICE; Ok, let's rename the file.
> NOTICES-POSSIBLY-NEEDED-FOR-BINARY-DISTRIBUTION
>
>
Sure - but there's still issues with it. And you still need a NOTICE file
in your source distribution.
Here's an example: fastjson is listed in the NOTICE file. If I look at
fastjson's repository, and build artifacts, there's no NOTICE file
included. As a result, there should be no entry in the NOTICE file for
this dependency. https://github.com/alibaba/fastjson
Likewise, for each MIT licensed artifact, an entry in LICENSE should be
made pointing to the MIT license for that product. Same applies to each
BSD-3-Clause licensed work included in the binary. Same applies to other
non-Apache-2 licensed products (Apache 2 is already included, so you're
good). Apache 2 products are meant to carry NOTICE files for copyright to
avoid repeating licenses.
At the same time, dexposed has a ridiculously long NOTICE file - completely
incorrectly build, but its all in there. This may technically mean the
entire contents have to be included in your binary NOTICE file:
https://github.com/alibaba/dexposed/blob/master/NOTICE
If you need me to, I can go into each of your dependencies and give a heads
up, but would recommend that the PPMC does this, based on the assembling
guide I've linked to already.
> Ok?
>
>
I thought about your points a bit more last night, and conversely I want to
explain why its actually more of a burdon. Suppose that for some reason I
found the contents of this class to be useful and wanted to use it alone in
my work:
https://github.com/apache/incubator-weex/blob/master/android/commons/src/main/java/com/alibaba/weex/commons/SimpleWeexActivity.java
.
By having an extremely verbose NOTICE, as a user of this file alone, I have
to carry all of that along with me.
I also just noticed that your files are including the full license text of
the apache license in each file. We typically use the abbreviated version.
>
> On Sun, Apr 23, 2017 at 8:01 AM, John D. Ament <jo...@apache.org>
> wrote:
>
> > On Sat, Apr 22, 2017 at 7:57 AM Niclas Hedhman <ni...@hedhman.org>
> wrote:
> >
> > > On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <jo...@apache.org>
> > > wrote:
> > > >
> > > > On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <ni...@hedhman.org>
> > > wrote:
> > > >
> > > > > Note on gradle-wrapper.jar,
> > >
> > > > Agreed, and this is mostly my argument as well. However, in *nix the
> > JAR
> > > > will get downloaded automatically if not present. On windows, you
> need
> > > to
> > > > pre-install gradle.
> > >
> > > Where did you get this idea? The gradlew launches the Java program
> inside
> > > the gradle-wrapper.jar which in turn downloads the full Gradle distro
> if
> > > not present already. I have not heard neither that the gradlew would
> > > download the wrapper jar, nor that the gradle-wrapper does not work on
> > > Windows.
> > >
> > >
> > I must have seen a custom built version of gradlew then.
> >
> >
> > >
> > > > The argument I've seen from present VP Legal is that the JARs may
> have
> > > > viruses in them, or contain other malware.
> > >
> > > That was the silliest reason I have heard in a long time. With that
> > > argument, we only allow source distributions, only allow to use tools
> > that
> > > are built from source recursively back through time... Yeah! Right...
> > now,
> > > there are a few projects that needs that, such as the Bitcoin
> blockchain
> > > toolchain, as they distrust everything, and settled on some binary from
> > > decades ago with a known hash as the starting point. In any event, ASF
> > > would collapse under the "they may contain malware" banner of paranoia.
> > >
> > > I don't buy it, since I trust my fellow folks at ASF rather than assume
> > > malevolence from everyone.
> > >
> > >
> > I don't disagree with you. And now may be a good time to bring this back
> > up. But for now, its not allowable in the release. See also
> > https://issues.apache.org/jira/browse/LEGAL-288
> >
> >
> >
> > > In this particular case, I don't think that gradle-wrapper.jar ever
> > > changes, so committing a new version would set off red flags, at least
> > with
> > > me (used Gradle for about 7 years now). A small script that traverse
> all
> > of
> > > Apache GitHub and compares them all??
> > >
> > > >
> > > > > Note on LICENSE;
> > > > > IIUIC, the source distribution doesn't ship any dependencies
> (except
> > > Gradle
> > > > > above), and there is only Apache License to be considered.
> > > > >
> > > > > As for NOTICE, the ASF documentation you point to, basically says
> > that
> > > a)
> > > > > don't put in anything that is not bundled (i.e. just about nothing
> in
> > > the
> > > > > source release), b) no burden on downstream users. HOWEVER, by
> > > excluding
> > > > > the list of dependencies that will be in the resulting product, we
> > > would
> > > > > actually increase the burden of downstream users as they would need
> > to
> > > > > figure out what licensing requirements will come out of it all, if
> > they
> > > > > choose to distribute.
> > > > > Therefor, I would argue that documentation is in this case arguing
> > > against
> > > > > itself in a single sentence, and think that the approach taken by
> > Weex
> > > is
> > > > > appropriate.
> > > > >
> > > >
> > > > I disagree. I think you're thinking of source release vs binary
> > release.
> > > > Weex has only presented a source release.
> > >
> > > I am aware of that, but the documentation says "make it easier for the
> > > downstream" and by "excluding all non-bundled, but required,
> dependencies
> > > from NOTICE" we actually make it harder for the downstream. And sorry,
> I
> > > place "common sense" and "tribal knowledge" way over someone writing a
> > > documentation and perhaps didn't realize the consequences. I never stop
> > > thinking, just because I read something somewhere.
> > >
> > >
> > I'm not sure what a valid response to this would be. I don't believe we
> > should be taking into account ease of use for downstream consumers,
> however
> > at the end of the day those downstream consumers of a source release
> > eventually get a binary and that binary should include proper data.
> What I
> > am trying to say is that these contents look more appropriate for the
> > binary release, which would be a satisfactory use case for downstream
> > consumers.
> >
> >
> >
> > >
> > > Cheers
> > > --
> > > Niclas Hedhman, Software Developer
> > > http://polygene.apache.org - New Energy for Java
> > >
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2
Posted by Niclas Hedhman <ni...@hedhman.org>.
John,
thanks for pointing me to the issue. I argue against Marvin on it, based on
"this is a tool" that is made conveniently available for those who are not
paranoid.
NOTICE; Ok, let's rename the file.
NOTICES-POSSIBLY-NEEDED-FOR-BINARY-DISTRIBUTION
Ok?
On Sun, Apr 23, 2017 at 8:01 AM, John D. Ament <jo...@apache.org>
wrote:
> On Sat, Apr 22, 2017 at 7:57 AM Niclas Hedhman <ni...@hedhman.org> wrote:
>
> > On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <jo...@apache.org>
> > wrote:
> > >
> > > On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <ni...@hedhman.org>
> > wrote:
> > >
> > > > Note on gradle-wrapper.jar,
> >
> > > Agreed, and this is mostly my argument as well. However, in *nix the
> JAR
> > > will get downloaded automatically if not present. On windows, you need
> > to
> > > pre-install gradle.
> >
> > Where did you get this idea? The gradlew launches the Java program inside
> > the gradle-wrapper.jar which in turn downloads the full Gradle distro if
> > not present already. I have not heard neither that the gradlew would
> > download the wrapper jar, nor that the gradle-wrapper does not work on
> > Windows.
> >
> >
> I must have seen a custom built version of gradlew then.
>
>
> >
> > > The argument I've seen from present VP Legal is that the JARs may have
> > > viruses in them, or contain other malware.
> >
> > That was the silliest reason I have heard in a long time. With that
> > argument, we only allow source distributions, only allow to use tools
> that
> > are built from source recursively back through time... Yeah! Right...
> now,
> > there are a few projects that needs that, such as the Bitcoin blockchain
> > toolchain, as they distrust everything, and settled on some binary from
> > decades ago with a known hash as the starting point. In any event, ASF
> > would collapse under the "they may contain malware" banner of paranoia.
> >
> > I don't buy it, since I trust my fellow folks at ASF rather than assume
> > malevolence from everyone.
> >
> >
> I don't disagree with you. And now may be a good time to bring this back
> up. But for now, its not allowable in the release. See also
> https://issues.apache.org/jira/browse/LEGAL-288
>
>
>
> > In this particular case, I don't think that gradle-wrapper.jar ever
> > changes, so committing a new version would set off red flags, at least
> with
> > me (used Gradle for about 7 years now). A small script that traverse all
> of
> > Apache GitHub and compares them all??
> >
> > >
> > > > Note on LICENSE;
> > > > IIUIC, the source distribution doesn't ship any dependencies (except
> > Gradle
> > > > above), and there is only Apache License to be considered.
> > > >
> > > > As for NOTICE, the ASF documentation you point to, basically says
> that
> > a)
> > > > don't put in anything that is not bundled (i.e. just about nothing in
> > the
> > > > source release), b) no burden on downstream users. HOWEVER, by
> > excluding
> > > > the list of dependencies that will be in the resulting product, we
> > would
> > > > actually increase the burden of downstream users as they would need
> to
> > > > figure out what licensing requirements will come out of it all, if
> they
> > > > choose to distribute.
> > > > Therefor, I would argue that documentation is in this case arguing
> > against
> > > > itself in a single sentence, and think that the approach taken by
> Weex
> > is
> > > > appropriate.
> > > >
> > >
> > > I disagree. I think you're thinking of source release vs binary
> release.
> > > Weex has only presented a source release.
> >
> > I am aware of that, but the documentation says "make it easier for the
> > downstream" and by "excluding all non-bundled, but required, dependencies
> > from NOTICE" we actually make it harder for the downstream. And sorry, I
> > place "common sense" and "tribal knowledge" way over someone writing a
> > documentation and perhaps didn't realize the consequences. I never stop
> > thinking, just because I read something somewhere.
> >
> >
> I'm not sure what a valid response to this would be. I don't believe we
> should be taking into account ease of use for downstream consumers, however
> at the end of the day those downstream consumers of a source release
> eventually get a binary and that binary should include proper data. What I
> am trying to say is that these contents look more appropriate for the
> binary release, which would be a satisfactory use case for downstream
> consumers.
>
>
>
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
> >
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2
Posted by "John D. Ament" <jo...@apache.org>.
On Sat, Apr 22, 2017 at 7:57 AM Niclas Hedhman <ni...@hedhman.org> wrote:
> On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <jo...@apache.org>
> wrote:
> >
> > On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <ni...@hedhman.org>
> wrote:
> >
> > > Note on gradle-wrapper.jar,
>
> > Agreed, and this is mostly my argument as well. However, in *nix the JAR
> > will get downloaded automatically if not present. On windows, you need
> to
> > pre-install gradle.
>
> Where did you get this idea? The gradlew launches the Java program inside
> the gradle-wrapper.jar which in turn downloads the full Gradle distro if
> not present already. I have not heard neither that the gradlew would
> download the wrapper jar, nor that the gradle-wrapper does not work on
> Windows.
>
>
I must have seen a custom built version of gradlew then.
>
> > The argument I've seen from present VP Legal is that the JARs may have
> > viruses in them, or contain other malware.
>
> That was the silliest reason I have heard in a long time. With that
> argument, we only allow source distributions, only allow to use tools that
> are built from source recursively back through time... Yeah! Right... now,
> there are a few projects that needs that, such as the Bitcoin blockchain
> toolchain, as they distrust everything, and settled on some binary from
> decades ago with a known hash as the starting point. In any event, ASF
> would collapse under the "they may contain malware" banner of paranoia.
>
> I don't buy it, since I trust my fellow folks at ASF rather than assume
> malevolence from everyone.
>
>
I don't disagree with you. And now may be a good time to bring this back
up. But for now, its not allowable in the release. See also
https://issues.apache.org/jira/browse/LEGAL-288
> In this particular case, I don't think that gradle-wrapper.jar ever
> changes, so committing a new version would set off red flags, at least with
> me (used Gradle for about 7 years now). A small script that traverse all of
> Apache GitHub and compares them all??
>
> >
> > > Note on LICENSE;
> > > IIUIC, the source distribution doesn't ship any dependencies (except
> Gradle
> > > above), and there is only Apache License to be considered.
> > >
> > > As for NOTICE, the ASF documentation you point to, basically says that
> a)
> > > don't put in anything that is not bundled (i.e. just about nothing in
> the
> > > source release), b) no burden on downstream users. HOWEVER, by
> excluding
> > > the list of dependencies that will be in the resulting product, we
> would
> > > actually increase the burden of downstream users as they would need to
> > > figure out what licensing requirements will come out of it all, if they
> > > choose to distribute.
> > > Therefor, I would argue that documentation is in this case arguing
> against
> > > itself in a single sentence, and think that the approach taken by Weex
> is
> > > appropriate.
> > >
> >
> > I disagree. I think you're thinking of source release vs binary release.
> > Weex has only presented a source release.
>
> I am aware of that, but the documentation says "make it easier for the
> downstream" and by "excluding all non-bundled, but required, dependencies
> from NOTICE" we actually make it harder for the downstream. And sorry, I
> place "common sense" and "tribal knowledge" way over someone writing a
> documentation and perhaps didn't realize the consequences. I never stop
> thinking, just because I read something somewhere.
>
>
I'm not sure what a valid response to this would be. I don't believe we
should be taking into account ease of use for downstream consumers, however
at the end of the day those downstream consumers of a source release
eventually get a binary and that binary should include proper data. What I
am trying to say is that these contents look more appropriate for the
binary release, which would be a satisfactory use case for downstream
consumers.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <jo...@apache.org>
wrote:
>
> On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <ni...@hedhman.org> wrote:
>
> > Note on gradle-wrapper.jar,
> Agreed, and this is mostly my argument as well. However, in *nix the JAR
> will get downloaded automatically if not present. On windows, you need to
> pre-install gradle.
Where did you get this idea? The gradlew launches the Java program inside
the gradle-wrapper.jar which in turn downloads the full Gradle distro if
not present already. I have not heard neither that the gradlew would
download the wrapper jar, nor that the gradle-wrapper does not work on
Windows.
> The argument I've seen from present VP Legal is that the JARs may have
> viruses in them, or contain other malware.
That was the silliest reason I have heard in a long time. With that
argument, we only allow source distributions, only allow to use tools that
are built from source recursively back through time... Yeah! Right... now,
there are a few projects that needs that, such as the Bitcoin blockchain
toolchain, as they distrust everything, and settled on some binary from
decades ago with a known hash as the starting point. In any event, ASF
would collapse under the "they may contain malware" banner of paranoia.
I don't buy it, since I trust my fellow folks at ASF rather than assume
malevolence from everyone.
In this particular case, I don't think that gradle-wrapper.jar ever
changes, so committing a new version would set off red flags, at least with
me (used Gradle for about 7 years now). A small script that traverse all of
Apache GitHub and compares them all??
>
> > Note on LICENSE;
> > IIUIC, the source distribution doesn't ship any dependencies (except
Gradle
> > above), and there is only Apache License to be considered.
> >
> > As for NOTICE, the ASF documentation you point to, basically says that
a)
> > don't put in anything that is not bundled (i.e. just about nothing in
the
> > source release), b) no burden on downstream users. HOWEVER, by excluding
> > the list of dependencies that will be in the resulting product, we would
> > actually increase the burden of downstream users as they would need to
> > figure out what licensing requirements will come out of it all, if they
> > choose to distribute.
> > Therefor, I would argue that documentation is in this case arguing
against
> > itself in a single sentence, and think that the approach taken by Weex
is
> > appropriate.
> >
>
> I disagree. I think you're thinking of source release vs binary release.
> Weex has only presented a source release.
I am aware of that, but the documentation says "make it easier for the
downstream" and by "excluding all non-bundled, but required, dependencies
from NOTICE" we actually make it harder for the downstream. And sorry, I
place "common sense" and "tribal knowledge" way over someone writing a
documentation and perhaps didn't realize the consequences. I never stop
thinking, just because I read something somewhere.
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2
Posted by "John D. Ament" <jo...@apache.org>.
On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <ni...@hedhman.org> wrote:
> Note on gradle-wrapper.jar,
> For source releases, we expect the project to be buildable by the user. The
> Gradle wrapper is the easiest way to make that happen. It (together with
> the gradlew and gradlew.bat scripts) ensures that that the build will be
> the same, and not suffer from different Gradle versions being used,
> potentially incompatible. Now, you could write a document on how to achieve
> this in other ways, and deal with the fall-out. But just like the
> gradle-wrapper.jar is committed to the source repository, I stand by that
> the gradle-wrapper belongs in the source distro, as a defacto standard for
> projects using Gradle to build. You will find similar 'bundling' of build
> systems in other languages as well, are they also banned? Or it just
> because they are in human-readable format that it is considered ok?
>
>
Agreed, and this is mostly my argument as well. However, in *nix the JAR
will get downloaded automatically if not present. On windows, you need to
pre-install gradle.
The argument I've seen from present VP Legal is that the JARs may have
viruses in them, or contain other malware.
> Note on LICENSE;
> IIUIC, the source distribution doesn't ship any dependencies (except Gradle
> above), and there is only Apache License to be considered.
>
> As for NOTICE, the ASF documentation you point to, basically says that a)
> don't put in anything that is not bundled (i.e. just about nothing in the
> source release), b) no burden on downstream users. HOWEVER, by excluding
> the list of dependencies that will be in the resulting product, we would
> actually increase the burden of downstream users as they would need to
> figure out what licensing requirements will come out of it all, if they
> choose to distribute.
> Therefor, I would argue that documentation is in this case arguing against
> itself in a single sentence, and think that the approach taken by Weex is
> appropriate.
>
I disagree. I think you're thinking of source release vs binary release.
Weex has only presented a source release. The binary release LICENSE and
NOTICE may be different, due to bundled dependencies. Transitive
dependencies should never be included in these files.
I suspect that Weex based its release on RocketMQ's recent release. I'll
point out that in RocketMQ's case the binary distribution includes all of
its transitive dependencies (its a server, not a library) so the binary
NOTICE contents make sense to list out everything. IN the case of a
library type tool, you wouldn't include things coming in transitively,
they're not part of your packages. RocketMQ leveraged different source and
binary NOTICE/LICENSE files to account for these nuances. In Justin's
initial review of their release, some of these items came up on their dev
list.
I suspect that the binary version of Weex falls more in line with RocketMQ
though, where the whole thing gets installed somewhere, in which case what
you're describing is accurate, but only for the binary distribution (which
I suspect most of these NOTICE entries are coming from).
>
> (all subject to that my understanding of that there is no third-party in
> the source distribution)
>
>
This is my understanding as well, since I don't see anything, other than
the gradle wrapper.
>
> Package name; yeah, I completely forgot that, as I saw it in the directory
> name.
>
>
> On Sat, Apr 22, 2017 at 6:10 PM, John D. Ament <jo...@apache.org>
> wrote:
>
> > Sorry but -1 due to misnamed package and binary content.
> >
> > - No "incubating" / "incubator" in package name
> > - JAR files are present in the source release (gradle-wrapper.jar)
> > - Ideally the expanded package would include "apache" in the folder, not
> a
> > big deal.
> > - DISCLAIMER present
> >
> > Your NOTICE seems way too big. Do you actually bundle all of these
> > dependencies? I can't find them if you do. Most of what's being called
> out
> > in NOTICE should actually be in LICENSE. For instance, only Apache
> > licensed code would normally call out NOTICE entries, and those entries
> are
> > meant to be copied verbatim from the source package. In this case,
> fastjson
> > is referenced (though I don't see it anywhere), but it has no NOTICE so
> > nothing to declare.
> >
> > Meanwhile, your LICENSE is too short. Each project that you do bundle,
> if
> > its not Apache licensed, you must copy its license text or provide a
> > pointer to the license. We have a full guide on how to assemble these -
> > http://www.apache.org/dev/licensing-howto.html - please reach out if you
> > need help.
> >
> > The critical piece to fix is your package name. If you're re-rolling to
> > fix that, I would recommend going through your NOTICE/LICENSE and see
> what
> > does and doesn't belong. The second piece to fix is the JAR files. You
> > must not include them (I've tried fighting the fight, and can't get
> > anywhere on it - source releases are for source code only).
> >
> > John
> >
> > On Thu, Apr 20, 2017 at 4:11 AM sospartan <so...@apache.org> wrote:
> >
> > > Hi all,
> > > I'll calling a vote for Weex-incubating 0.12.0-RC2 release.
> > >
> > > The PPMC vote for this release has passed:
> > >
> > > https://lists.apache.org/thread.html/d544a60a4038f9d053f7ea1eca0d16
> > 2b9aef392551a02a0401041e8f@%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-rc1
> > >
> > > The commit hash:
> > >
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> > > 9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907
> > > <https://git-wip-us.apache.org/repos/asf?p=incubator-
> > weex.git;a=commit;h=9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907>
> > >
> > > The source tarball can be found at:
> > >
> > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> > 0-incubating/RC1/
> > >
> > > 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-RC2
Posted by Niclas Hedhman <ni...@hedhman.org>.
Note on gradle-wrapper.jar,
For source releases, we expect the project to be buildable by the user. The
Gradle wrapper is the easiest way to make that happen. It (together with
the gradlew and gradlew.bat scripts) ensures that that the build will be
the same, and not suffer from different Gradle versions being used,
potentially incompatible. Now, you could write a document on how to achieve
this in other ways, and deal with the fall-out. But just like the
gradle-wrapper.jar is committed to the source repository, I stand by that
the gradle-wrapper belongs in the source distro, as a defacto standard for
projects using Gradle to build. You will find similar 'bundling' of build
systems in other languages as well, are they also banned? Or it just
because they are in human-readable format that it is considered ok?
Note on LICENSE;
IIUIC, the source distribution doesn't ship any dependencies (except Gradle
above), and there is only Apache License to be considered.
As for NOTICE, the ASF documentation you point to, basically says that a)
don't put in anything that is not bundled (i.e. just about nothing in the
source release), b) no burden on downstream users. HOWEVER, by excluding
the list of dependencies that will be in the resulting product, we would
actually increase the burden of downstream users as they would need to
figure out what licensing requirements will come out of it all, if they
choose to distribute.
Therefor, I would argue that documentation is in this case arguing against
itself in a single sentence, and think that the approach taken by Weex is
appropriate.
(all subject to that my understanding of that there is no third-party in
the source distribution)
Package name; yeah, I completely forgot that, as I saw it in the directory
name.
On Sat, Apr 22, 2017 at 6:10 PM, John D. Ament <jo...@apache.org>
wrote:
> Sorry but -1 due to misnamed package and binary content.
>
> - No "incubating" / "incubator" in package name
> - JAR files are present in the source release (gradle-wrapper.jar)
> - Ideally the expanded package would include "apache" in the folder, not a
> big deal.
> - DISCLAIMER present
>
> Your NOTICE seems way too big. Do you actually bundle all of these
> dependencies? I can't find them if you do. Most of what's being called out
> in NOTICE should actually be in LICENSE. For instance, only Apache
> licensed code would normally call out NOTICE entries, and those entries are
> meant to be copied verbatim from the source package. In this case, fastjson
> is referenced (though I don't see it anywhere), but it has no NOTICE so
> nothing to declare.
>
> Meanwhile, your LICENSE is too short. Each project that you do bundle, if
> its not Apache licensed, you must copy its license text or provide a
> pointer to the license. We have a full guide on how to assemble these -
> http://www.apache.org/dev/licensing-howto.html - please reach out if you
> need help.
>
> The critical piece to fix is your package name. If you're re-rolling to
> fix that, I would recommend going through your NOTICE/LICENSE and see what
> does and doesn't belong. The second piece to fix is the JAR files. You
> must not include them (I've tried fighting the fight, and can't get
> anywhere on it - source releases are for source code only).
>
> John
>
> On Thu, Apr 20, 2017 at 4:11 AM sospartan <so...@apache.org> wrote:
>
> > Hi all,
> > I'll calling a vote for Weex-incubating 0.12.0-RC2 release.
> >
> > The PPMC vote for this release has passed:
> >
> > https://lists.apache.org/thread.html/d544a60a4038f9d053f7ea1eca0d16
> 2b9aef392551a02a0401041e8f@%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-rc1
> >
> > The commit hash:
> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> > 9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907
> > <https://git-wip-us.apache.org/repos/asf?p=incubator-
> weex.git;a=commit;h=9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907>
> >
> > The source tarball can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> 0-incubating/RC1/
> >
> > 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-RC2
Posted by "John D. Ament" <jo...@apache.org>.
Sorry but -1 due to misnamed package and binary content.
- No "incubating" / "incubator" in package name
- JAR files are present in the source release (gradle-wrapper.jar)
- Ideally the expanded package would include "apache" in the folder, not a
big deal.
- DISCLAIMER present
Your NOTICE seems way too big. Do you actually bundle all of these
dependencies? I can't find them if you do. Most of what's being called out
in NOTICE should actually be in LICENSE. For instance, only Apache
licensed code would normally call out NOTICE entries, and those entries are
meant to be copied verbatim from the source package. In this case, fastjson
is referenced (though I don't see it anywhere), but it has no NOTICE so
nothing to declare.
Meanwhile, your LICENSE is too short. Each project that you do bundle, if
its not Apache licensed, you must copy its license text or provide a
pointer to the license. We have a full guide on how to assemble these -
http://www.apache.org/dev/licensing-howto.html - please reach out if you
need help.
The critical piece to fix is your package name. If you're re-rolling to
fix that, I would recommend going through your NOTICE/LICENSE and see what
does and doesn't belong. The second piece to fix is the JAR files. You
must not include them (I've tried fighting the fight, and can't get
anywhere on it - source releases are for source code only).
John
On Thu, Apr 20, 2017 at 4:11 AM sospartan <so...@apache.org> wrote:
> Hi all,
> I'll calling a vote for Weex-incubating 0.12.0-RC2 release.
>
> The PPMC vote for this release has passed:
>
> https://lists.apache.org/thread.html/d544a60a4038f9d053f7ea1eca0d162b9aef392551a02a0401041e8f@%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-rc1
>
> The commit hash:
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> 9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907
> <https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907>
>
> The source tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.0-incubating/RC1/
>
> 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
>