Re: [Cava] Suitable name search - choosing a name

[Pierre Smits]

+1 for 'Jal'

Nice sounding, different, short.
.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Fri, Feb 22, 2019 at 11:47 PM Antoine Toulme  wrote:

> Hi all,
>
> I have opened a thread to vote the Cava proposal into the incubator [0].
>
> At the same time, I have engaged with the list on searching a better name
> for the project [1].
>
> Out of this initial thread, we have singled out a list of names.
>
> Here are the names:
> - Rainbow (after the name of my kid’s favorite toy, and in line with the
> crypto community unicorn punk theme [2].
> - Winch (a mechanical device used to wind up or wind out wires (Wikipedia)
> , in the chain theme)
> - Sprocket (a profiled wheel with teeth, or cogs, that mesh with a chain,
> track or other perforated or indented material. (Wikipedia), in the chain
> theme as well)
> - “Jal”, in reference to Indra’s net (or Indra jal) (with a quote from
> [3]: "Imagine a multidimensional spider's web in the early morning covered
> with dew drops. And every dew drop contains the reflection of all the other
> dew drops.
> And, in each reflected dew drop, the reflections of all the other dew
> drops in that reflection. And so ad infinitum. That is the Buddhist
> conception of the universe in an image." –Alan Watts)
>
> In this thread, please indicate the one name you like most. Please feel
> free to justify your choice.
> Based on your input, the project will adopt the name. In absence of a
> strong contender, I'll work with the Champion (Jim Jagielski) to pick a
> name.
>
> I'll keep the thread open for 72 hours - that gives us until Tuesday
> afternoon PST time.
>
> Cheers,
>
> Antoine
>
> [0]:
> https://lists.apache.org/thread.html/5634b8f24cf552da4cba12ab4b59647bfa6800b7380833d8131331e9@%3Cgeneral.incubator.apache.org%3E
> [1]:
> https://lists.apache.org/thread.html/8d8014f53f140a3ccdd517c3c303de1d45cc04afdaee5961ac43e7fc@%3Cgeneral.incubator.apache.org%3E
> [2]: https://www.urbandictionary.com/define.php?term=unicorn%20punk
> [3]: https://en.wikipedia.org/wiki/Indra%27s_net
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[PROPOSAL] Apache DataSketches

[leerho]

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Apache DataSketches

[Justin Mclean]

Hi,

> === Nominated Mentors ===
> (Recommended to me: )
> 
> Liang Chen, Vice President of Apache CarbonData, [chenliang613 at apache
> dot org]
> Jean-Baptiste Onofré, jb at nanthrax dot net
> Gil Yehuda, gyehuda at verizonmedia dot com

Currently only IPMC members can be official mentors, of the 3 people listed 
here I believe only Jean-Baptiste Onofré is an IPMC member.

Thanks,
Justin 
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Apache DataSketches

[Furkan KAMACI]

Hi,

If possible, I would like to contribute DataSketches as mentor too.

Kind Regards,
Furkan KAMACI

23 Şub 2019 Cmt, saat 14:59 tarihinde Justin Mclean <
jus...@classsoftware.com> şunu yazdı:

> Hi,
>
> > === Nominated Mentors ===
> > (Recommended to me: )
> >
> > Liang Chen, Vice President of Apache CarbonData, [chenliang613 at apache
> > dot org]
> > Jean-Baptiste Onofré, jb at nanthrax dot net
> > Gil Yehuda, gyehuda at verizonmedia dot com
>
> Currently only IPMC members can be official mentors, of the 3 people
> listed here I believe only Jean-Baptiste Onofré is an IPMC member.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Apache DataSketches

[Justin Mclean]

Hi,

> Currently only IPMC members can be official mentors, of the 3 people listed 
> here I believe only Jean-Baptiste Onofré is an IPMC member.

Sorry, my apologies, Liang Chen is also an IPMC member, (Chen Liang, and 
presumedly a different person, is a committer but not an IPMC member) but I 
cannot find Gil Yehuda, do you mind provide a link to the roster for them or 
their Apache id?

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Daffodil (incubating) 2.3.0-rc1

[Steve Lawrence]

That's for all the response from everyone so far. We'll make sure to fix
the KEYS issue for the next release. DAFFODIL-2070 [1] was created to
track that issue, and we plan to fix it in the next release. Other
comments inline.

On 2/22/19 3:45 PM, Christofer Dutz wrote:
> Hi all,
> 
> I have started verifying this release ... however this is the first time I am 
> validating a project I'm not directly involved in. 
> So I found some things that are different than with the other projects (Not 
> sure if this is bad or good though)
> 
> So here goes:
> 1) No KEYS file (Think this has been reported)

Ticket mentioned above, we plan to fix this for the next release.

> 2) No README and RELEASE_NOTES in the RC directory

We have a REAMDE.md in the root directory of the source release and the
convenience binaries. And we've been maintaining releases notes on our
website. For example, the release for this are at
https://daffodil.apache.org/releases/2.3.0/

Looking at a few other random incubator release candidates, I don't see
a README or RELEASE_NOTES in their directories, so maybe this isn't
required, and the readme in the source and release notes on the webpage
is sufficient?

> 3) There are sha256 and 512 files ... is it OK to have the sha256 ones? I 
> remember us having to remove less "save" signature files

We've recently removed md5 and sha1 for this reason. I haven't yet heard
the need to remove sha256, but I'm fine doing that if that's the right
thing to do.

> 4) Is there a reason, why the "RPM" file is "2.3.0.incubating" instead of 
> "2.3.0-incubating" (dot instead of a dash).

The tool we use to build RPMs is very particular about versios and
filenames RPM standards. Those standards require the dot instead of the
dash. It also requires the -1 at the end as well.

> 5) It was impossible to import the GPG Key from pgp.mit.edu or any of my 
> known key servers (did it manually)

I've had a lot of troubles getting keys from pgp.mit.edu, always seems
to be down for me. I have uploaded it in the past for previous releases,
so it should be up there when the server works. But I'm unable to
confirm right now--I get "service temporarily unavailable" errors.

> 6) The PGP key used to sign doesn't have a valid trust chain (but the 
> signatures check out and refer to an apache email address)

I haven't been able to attended any key signings or anything to get
someone to sign my key. Something on my TODO list to get done.

> Formal download, hash and signature checks: All OK (see GPG remark)
> - I was able to download all artifacts
> - All 256sha hashes are valid
> - All 512sha hashes are valid
> - The signatures in the ASC files check-out (no trust chain though)
> 
> Now to the source-bundle checks:
> - Was able to unpack the zip
> - Zip name contained "incubating"
> - Archive contains: DISCLAIMER, LICENSE, NOTICE, README(.md)
> - There is no RELEASE_NOTES (Think this is required)

As mentioned above, we maintain this on our website and in the release
files. I'd prefer to not have to maintain two separate versions if
having it there is sufficient.

> - Content of the README.md:
>   - I it states the user list to be: u...@daffodil.apache.org, however 
> I'm subscribed to us...@daffodil.apache.org
>   - I think the ASF HipChat was replaced with Slack (Don't know if it's 
> still active)

Good catch. I've opened DAFFODIL-2073 to resolve these issues. I'd
prefer to fix these in our next release if these aren't considered
blockers. Our website does mention the correct email address.

> 
> Building
> - Mac 10.14.3, SBT 1.2.8, Java Oracle 1.8.0_141-b15: 
>   - sbt compile (success)
>   - sbt test (got out of memory errors, did a 'export 
> SBT_OPTS="-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=2G -Xmx2G"' first to 
> make it run) 
>   [error] Failed: Total 3311, Failed 35, Errors 0, Passed 3276
>   - sbt it:test (all tests passed)
> 
> - Windows 10, SBT 1.2.7, Java Oracle 1.8.0_101:
>   - sbt compile (success)
>   - sbt test (got out of memory errors, did a 'export 
> SBT_OPTS="-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=2G -Xmx2G"' first to 
> make it run)
>   [error] Failed: Total 3311, Failed 35, Errors 0, Passed 3276
>   - sbt it:test 
>   Failed: 4

These failures are very interesting. All of our tests pass in TravisCI
[3] and pass on my machine, so I'm guessing these are some sort of
environment issue. I assume you're in Germany based on the .de email? I
know we've had some issues in the past related to timezones or default
encodings, so might be related to that. It would be really helpful if
you could capture the output of sbt test and send it to dev@daffodil.a.o
or create a Jira ticket for it. We can try to determine what the issue
might be and see if they should be blockers.

> ... I'll continue testing on Sunday evening ...
> 
> So far I'll vote with a
> 
> +0 (binding) as I don't quite know how bad the things I found are.
> 
> Chris
> 
>

Re: [PROPOSAL] Apache DataSketches

[leerho]

Forgive me I am a newbie, but there has got to be a better way to post a
document that everyone can see and allow it to be updated without having to
resend it as raw text.  I have an easier to read version of the proposal as
a Google doc where I could post the link, but I sense that that is a no-no
in this community.  Any suggestions?

Lee.

On Sat, Feb 23, 2019 at 4:07 AM Justin Mclean 
wrote:

> Hi,
>
> > Currently only IPMC members can be official mentors, of the 3 people
> listed here I believe only Jean-Baptiste Onofré is an IPMC member.
>
> Sorry, my apologies, Liang Chen is also an IPMC member, (Chen Liang, and
> presumedly a different person, is a committer but not an IPMC member) but I
> cannot find Gil Yehuda, do you mind provide a link to the roster for them
> or their Apache id?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Add to Wiki ContributorsGroup

[leerho]

Lee Rhodes

Re: [PROPOSAL] Apache DataSketches

[leerho]

On 2019/02/23 18:54:57, leerho  wrote: 
> Forgive me I am a newbie, but there has got to be a better way to post a
> document that everyone can see and allow it to be updated without having to
> resend it as raw text.  I have an easier to read version of the proposal as
> a Google doc where I could post the link, but I sense that that is a no-no
> in this community.  Any suggestions?
> 
> Lee.
> 
> On Sat, Feb 23, 2019 at 4:07 AM Justin Mclean 
> wrote:
> 
> > Hi,
> >
> > > Currently only IPMC members can be official mentors, of the 3 people
> > listed here I believe only Jean-Baptiste Onofré is an IPMC member.
> >
> > Sorry, my apologies, Liang Chen is also an IPMC member, (Chen Liang, and
> > presumedly a different person, is a committer but not an IPMC member) but I
> > cannot find Gil Yehuda, do you mind provide a link to the roster for them
> > or their Apache id?
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
> I got it.  It is the Incubator Wiki.  Now trying to get this proposal posted 
> there. 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Daffodil (incubating) 2.3.0-rc1

[Dave Fisher]

Hi Craig,

Sent from my iPhone

On Feb 22, 2019, at 4:12 PM, Craig Russell  wrote:

>> On Feb 19, 2019, at 1:18 PM, Dave Fisher  wrote:
>> 
>> Hi -
>> 
>> (1) To be fixed on the next release:
>>(a) Please do not include the KEYS file in the source release zip. Refer 
>> the users back to the location: 
>> https://dist.apache.org/repos/dist/release/incubator/daffodil/KEYS 
>> 
> 
> Yes the KEYS must not be distributed in the source release. But the canonical 
> location for KEYS is https://www.apache.org/dist/incubator/daffodil/KEYS 
> 
> 
> The dist.apache.org url is not for public use.

Thanks for the friendly reminder. I’ll need to flag for follow up with some 
podlings where I may have given incorrect advice.

Cheers,
Dave


> 
> Craig
> 
>>(b) Discuss vendor specific tests that are name *ibm* and *tresys* on 
>> dev@daffodil. I think it would help community building to have something 
>> more feature specific, but I could be wrong.
>> (2) Rat Check passes.
>> (3) All Signatures pass.
>> (4) All Checksums pass.
>> (5) LICENSE, NOTICE and DISCLAIMER look good. (MSI was not checked. I do not 
>> have a windows machine available.)
>> (6) Compiles
>> (7) sbt test “runs”. I did have a large number of OOM and other errors and 
>> they took over 3 hours to run on a MacBook Pro with the latest macOS.
>> (8) sbt it:test worked well.
>> 
>> +1 to all packages except for MSI.
>> +0 on MSI binary convenience package - I cannot check it.
>> 
>> Regards,
>> Dave
>> 
>>> On Feb 19, 2019, at 5:21 AM, Steve Lawrence  wrote:
>>> 
>>> Hi all,
>>> 
>>> The Apache Daffodil community has voted and approved the proposed
>>> release of Apache Daffodil (incubating) 2.3.0-rc1.
>>> 
>>> We now kindly request the Incubator PMC members review and vote on this
>>> incubator release.
>>> 
>>> Daffodil is an open source implementation of the DFDL specification that
>>> uses DFDL schemas to parse fixed format data into an infoset, which is
>>> most commonly represented as either XML or JSON. This allows the use of
>>> well-established XML or JSON technologies and libraries to consume,
>>> inspect, and manipulate fixed format data in existing solutions.
>>> Daffodil is also capable of the reverse by serializing or "unparsing" an
>>> XML or JSON infoset back to the original data format.
>>> 
>>> Vote thread:
>>> https://lists.apache.org/thread.html/0ec1161ad296aebda54e86c219e3f1c4498a7de640c6342e6888aea1@%3Cdev.daffodil.apache.org%3E
>>> 
>>> Result thread:
>>> 
>>> https://lists.apache.org/thread.html/a195a77640235501109bdea5ec7fb9a34c6f50644c7173fb8a919989@%3Cdev.daffodil.apache.org%3E
>>> 
>>> All distribution packages, including signatures, digests, etc. can be
>>> found at:
>>> 
>>> https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.3.0-rc1/
>>> 
>>> Staging artifacts can be found at:
>>> 
>>> https://repository.apache.org/content/repositories/orgapachedaffodil-1008/
>>> 
>>> This release has been signed with PGP key 36F3494B033AE661,
>>> corresponding to slawre...@apache.org, which is included in the
>>> repository's KEYS file. This key can be found on keyservers, such as:
>>> 
>>> http://pgp.mit.edu/pks/lookup?op=get&search=0x36F3494B033AE661
>>> 
>>> It is also listed here:
>>> 
>>> https://people.apache.org/keys/committer/slawrence.asc
>>> 
>>> The release candidate has been tagged in git with v2.3.0-rc1 on commit
>>> hash 193c84690401debd93c1f48e39e564fec09e9337.
>>> 
>>> For reference, here is a list of all closed JIRAs tagged with 2.3.0:
>>> 
>>> https://issues.apache.org/jira/browse/DAFFODIL-2067?jql=project%20%3D%20DAFFODIL%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20%3D%202.3.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>> 
>>> For a summary of the changes in this release, see:
>>> 
>>> https://daffodil.apache.org/releases/2.3.0/
>>> 
>>> Please review and vote. The vote will be open for at least 72 hours.
>>> 
>>> [ ] +1 approve
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove (and reason why)
>>> 
>>> Thanks,
>>> - Steve
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>> 
> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org  http://db.apache.org/jdo 
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Apache DataSketches

[Ted Dunning]

Actually, I find that early drafts are easier to work on using gdocs. Once
things settle down, the wiki is a very good place.


On Sat, Feb 23, 2019 at 12:35 PM lee...@gmail.com  wrote:

>
>
> On 2019/02/23 18:54:57, leerho  wrote:
> > Forgive me I am a newbie, but there has got to be a better way to post a
> > document that everyone can see and allow it to be updated without having
> to
> > resend it as raw text.  I have an easier to read version of the proposal
> as
> > a Google doc where I could post the link, but I sense that that is a
> no-no
> > in this community.  Any suggestions?
>
>

Re: Binary jars in the source release which are only for testing

[Willem Jiang]

Hi

Thanks Justin for the clarification.  I guess the policy imply the
source materials cannot have any binary.
But what if the binary is only for testing, which cannot be part of
the released software.
>From my point of view, we don't need to modify the source materials
testing binary to do the software release as it is not a part of the
binary release of the software.

Any thoughts?

Regards,

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean  wrote:
>
> Hi,
>
> > [1]http://www.apache.org/legal/release-policy.html#what
>
> It’s explained in that link there i.e.  "The Apache Software Foundation 
> produces open source software. All releases are in the form of the source 
> materials needed to make changes to the software being released”.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary jars in the source release which are only for testing

[Ted Dunning]

Willem,

This issue of embedded binaries for testing purposes has come up before.
Examples include network intercepts for testing malware detection or class
files for a byte code manipulator. The network files can't easily be
recreated since they were observed in the wild and the class files might
have been produced by a specific (possibly broken) compiler version that
isn't widely available.

The key question is whether these binaries are derived from some source
that could be compiled instead of distributing the binary objects. Failing
that, can the provenance and justification for the binary object be
described?




On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang  wrote:

> Hi
>
> Thanks Justin for the clarification.  I guess the policy imply the
> source materials cannot have any binary.
> But what if the binary is only for testing, which cannot be part of
> the released software.
> From my point of view, we don't need to modify the source materials
> testing binary to do the software release as it is not a part of the
> binary release of the software.
>
> Any thoughts?
>
> Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > > [1]http://www.apache.org/legal/release-policy.html#what
> >
> > It’s explained in that link there i.e.  "The Apache Software Foundation
> produces open source software. All releases are in the form of the source
> materials needed to make changes to the software being released”.
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Zipkin Brave (incubating) for Apache Karaf version 0.1.2

[Willem Jiang]

Hi,

Just forwarding my +1 bind from dev list.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem


On Sat, Feb 23, 2019 at 8:54 AM Adrian Cole  wrote:
>
> Hello All,
>
> This is a call for vote to release Apache Zipkin Brave (incubating)
> for Apache Karaf version 0.1.2
>
> The Apache Zipkin community has voted on and approved a proposal to
> release Apache Zipkin Brave (incubating) for Apache Karaf version
> 0.1.2.
>
> We now kindly request the Incubator PMC members review and vote on
> this incubator release.
>
> Apache Zipkin Brave (incubating) for Apache Karaf sets up tracing
> components such that tools built Karaf needn't configure these
> explicitly.
>
> Zipkin community vote and result thread:
> https://lists.apache.org/thread.html/32baf4b4b65644dd1dd8e2bf0cb360c94f8f939d61c5444b8f4ef45b@%3Cdev.zipkin.apache.org%3E
>
> The release candidates:
> https://dist.apache.org/repos/dist/dev/incubator/zipkin/brave-karaf/0.1.2/
>
> Git tag for the release:
> https://github.com/apache/incubator-zipkin-brave-karaf/tree/v0.1.2
>
> Hash for the release tag:
> 3cf4ac6577eb0d4775d20f24814e7a0852fa1635
>
> Release Notes:
> https://github.com/apache/incubator-zipkin-brave-karaf/releases/tag/v0.1.2
>
> The artifacts have been signed with Key : BB67A050, which can be found
> in the keys file:
> https://dist.apache.org/repos/dist/dev/incubator/zipkin/KEYS
>
> Verification Hints:
> For your convenience, the below includes detailed how-to on verifying
> a source release. Please note that this document is a work-in-progress
> https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+Release
>
> The vote will be open for at least 72 hours or until necessary number
> of votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> Thanks,
> The Apache Zipkin (Incubating) Team
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Zipkin Brave (incubating) for Apache Karafversion 0.1.2

[???? Sheng Wu]

+1 binding


Checked
1. LICENSE, DISCLAIMER, NOTICE exist.
2. Apache rat check passed.
3. asc checked.
4. Maven compile passed.
5. No wrapper jar (recheck because of last release failure)
6. sha512 exists and checked.


--
Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin
Twitter, wusheng1108


 




-- Original --
From:  "willem.jiang";
Date:  Sun, Feb 24, 2019 11:31 AM
To:  "general";

Subject:  Re: [VOTE] Release Apache Zipkin Brave (incubating) for Apache 
Karafversion 0.1.2



Hi,

Just forwarding my +1 bind from dev list.

Willem Jiang

Twitter: willemjiang
Weibo: willem


On Sat, Feb 23, 2019 at 8:54 AM Adrian Cole  wrote:
>
> Hello All,
>
> This is a call for vote to release Apache Zipkin Brave (incubating)
> for Apache Karaf version 0.1.2
>
> The Apache Zipkin community has voted on and approved a proposal to
> release Apache Zipkin Brave (incubating) for Apache Karaf version
> 0.1.2.
>
> We now kindly request the Incubator PMC members review and vote on
> this incubator release.
>
> Apache Zipkin Brave (incubating) for Apache Karaf sets up tracing
> components such that tools built Karaf needn't configure these
> explicitly.
>
> Zipkin community vote and result thread:
> https://lists.apache.org/thread.html/32baf4b4b65644dd1dd8e2bf0cb360c94f8f939d61c5444b8f4ef45b@%3Cdev.zipkin.apache.org%3E
>
> The release candidates:
> https://dist.apache.org/repos/dist/dev/incubator/zipkin/brave-karaf/0.1.2/
>
> Git tag for the release:
> https://github.com/apache/incubator-zipkin-brave-karaf/tree/v0.1.2
>
> Hash for the release tag:
> 3cf4ac6577eb0d4775d20f24814e7a0852fa1635
>
> Release Notes:
> https://github.com/apache/incubator-zipkin-brave-karaf/releases/tag/v0.1.2
>
> The artifacts have been signed with Key : BB67A050, which can be found
> in the keys file:
> https://dist.apache.org/repos/dist/dev/incubator/zipkin/KEYS
>
> Verification Hints:
> For your convenience, the below includes detailed how-to on verifying
> a source release. Please note that this document is a work-in-progress
> https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+Release
>
> The vote will be open for at least 72 hours or until necessary number
> of votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> Thanks,
> The Apache Zipkin (Incubating) Team
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary jars in the source release which are only for testing

[Alex Harui]

Or, can you change your build script to download the jar instead of packaging 
it in the source release?

On 2/23/19, 6:02 PM, "Ted Dunning"  wrote:

Willem,

This issue of embedded binaries for testing purposes has come up before.
Examples include network intercepts for testing malware detection or class
files for a byte code manipulator. The network files can't easily be
recreated since they were observed in the wild and the class files might
have been produced by a specific (possibly broken) compiler version that
isn't widely available.

The key question is whether these binaries are derived from some source
that could be compiled instead of distributing the binary objects. Failing
that, can the provenance and justification for the binary object be
described?




On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang  wrote:

> Hi
>
> Thanks Justin for the clarification.  I guess the policy imply the
> source materials cannot have any binary.
> But what if the binary is only for testing, which cannot be part of
> the released software.
> From my point of view, we don't need to modify the source materials
> testing binary to do the software release as it is not a part of the
> binary release of the software.
>
> Any thoughts?
>
> Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > > 
[1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23what&data=02%7C01%7Caharui%40adobe.com%7Cf5a610c610a847bf492408d699fc1ad8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636865705492422828&sdata=aLOPz6UB1Fz4oNJYUYf6LZKwNeTkGhfNC1Q9Nmq6vok%3D&reserved=0
> >
> > It’s explained in that link there i.e.  "The Apache Software Foundation
> produces open source software. All releases are in the form of the source
> materials needed to make changes to the software being released”.
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Binary jars in the source release which are only for testing

[Willem Jiang]

Normally we don't distribute the test jar outside, I'm not sure if I
can find a good place to host these jars.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Feb 24, 2019 at 2:47 PM Alex Harui  wrote:
>
> Or, can you change your build script to download the jar instead of packaging 
> it in the source release?
>
> On 2/23/19, 6:02 PM, "Ted Dunning"  wrote:
>
> Willem,
>
> This issue of embedded binaries for testing purposes has come up before.
> Examples include network intercepts for testing malware detection or class
> files for a byte code manipulator. The network files can't easily be
> recreated since they were observed in the wild and the class files might
> have been produced by a specific (possibly broken) compiler version that
> isn't widely available.
>
> The key question is whether these binaries are derived from some source
> that could be compiled instead of distributing the binary objects. Failing
> that, can the provenance and justification for the binary object be
> described?
>
>
>
>
> On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang  
> wrote:
>
> > Hi
> >
> > Thanks Justin for the clarification.  I guess the policy imply the
> > source materials cannot have any binary.
> > But what if the binary is only for testing, which cannot be part of
> > the released software.
> > From my point of view, we don't need to modify the source materials
> > testing binary to do the software release as it is not a part of the
> > binary release of the software.
> >
> > Any thoughts?
> >
> > Regards,
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean 
> > wrote:
> > >
> > > Hi,
> > >
> > > > 
> [1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23what&data=02%7C01%7Caharui%40adobe.com%7Cf5a610c610a847bf492408d699fc1ad8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636865705492422828&sdata=aLOPz6UB1Fz4oNJYUYf6LZKwNeTkGhfNC1Q9Nmq6vok%3D&reserved=0
> > >
> > > It’s explained in that link there i.e.  "The Apache Software 
> Foundation
> > produces open source software. All releases are in the form of the 
> source
> > materials needed to make changes to the software being released”.
> > >
> > > Thanks,
> > > Justin
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary jars in the source release which are only for testing

[Willem Jiang]

Hi Ted,

You made a good point,  I think my solution could be building the jars
from source and then using it for testing.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Feb 24, 2019 at 10:02 AM Ted Dunning  wrote:
>
> Willem,
>
> This issue of embedded binaries for testing purposes has come up before.
> Examples include network intercepts for testing malware detection or class
> files for a byte code manipulator. The network files can't easily be
> recreated since they were observed in the wild and the class files might
> have been produced by a specific (possibly broken) compiler version that
> isn't widely available.
>
> The key question is whether these binaries are derived from some source
> that could be compiled instead of distributing the binary objects. Failing
> that, can the provenance and justification for the binary object be
> described?
>
>
>
>
> On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang  wrote:
>
> > Hi
> >
> > Thanks Justin for the clarification.  I guess the policy imply the
> > source materials cannot have any binary.
> > But what if the binary is only for testing, which cannot be part of
> > the released software.
> > From my point of view, we don't need to modify the source materials
> > testing binary to do the software release as it is not a part of the
> > binary release of the software.
> >
> > Any thoughts?
> >
> > Regards,
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean 
> > wrote:
> > >
> > > Hi,
> > >
> > > > [1]http://www.apache.org/legal/release-policy.html#what
> > >
> > > It’s explained in that link there i.e.  "The Apache Software Foundation
> > produces open source software. All releases are in the form of the source
> > materials needed to make changes to the software being released”.
> > >
> > > Thanks,
> > > Justin
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary jars in the source release which are only for testing

[Vinayakumar B]

Hi,

For testing purpose.. why cant provide bin artifacts in a separate
convenience binary package as its being done in many other projects.. why
it should be part of source package.?

For the easy detection.. bin artifacts can have same version number as
source.

Again.. Official voting is on source package as per policy.

-Vinay

On Sun, 24 Feb 2019, 12:44 pm Willem Jiang,  wrote:

> Hi Ted,
>
> You made a good point,  I think my solution could be building the jars
> from source and then using it for testing.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sun, Feb 24, 2019 at 10:02 AM Ted Dunning 
> wrote:
> >
> > Willem,
> >
> > This issue of embedded binaries for testing purposes has come up before.
> > Examples include network intercepts for testing malware detection or
> class
> > files for a byte code manipulator. The network files can't easily be
> > recreated since they were observed in the wild and the class files might
> > have been produced by a specific (possibly broken) compiler version that
> > isn't widely available.
> >
> > The key question is whether these binaries are derived from some source
> > that could be compiled instead of distributing the binary objects.
> Failing
> > that, can the provenance and justification for the binary object be
> > described?
> >
> >
> >
> >
> > On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang 
> wrote:
> >
> > > Hi
> > >
> > > Thanks Justin for the clarification.  I guess the policy imply the
> > > source materials cannot have any binary.
> > > But what if the binary is only for testing, which cannot be part of
> > > the released software.
> > > From my point of view, we don't need to modify the source materials
> > > testing binary to do the software release as it is not a part of the
> > > binary release of the software.
> > >
> > > Any thoughts?
> > >
> > > Regards,
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <
> jus...@classsoftware.com>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > > [1]http://www.apache.org/legal/release-policy.html#what
> > > >
> > > > It’s explained in that link there i.e.  "The Apache Software
> Foundation
> > > produces open source software. All releases are in the form of the
> source
> > > materials needed to make changes to the software being released”.
> > > >
> > > > Thanks,
> > > > Justin
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Accept Cava into the Apache Incubator

[Vinayakumar B]

+1

-Vinay



On Fri, 22 Feb 2019, 7:22 am Huxing Zhang,  wrote:

> +1 (non-binding)
>
> On Thu, Feb 21, 2019 at 3:50 AM Antoine Toulme 
> wrote:
> >
> > Hi everyone,
> >
> > we've discussed the proposal for the Cava project in [1] and [2]. The
> > proposal itself can be found on the wiki[3].
> >
> > We discussed how to go about finding a suitable name for the project in
> [2].
> > I will kick off a vote to pick a name based on the proposals made there.
> >
> > According to the Incubator rules[4] I'd like to call a vote to accept the
> > new "Cava" project as a podling in the Apache Incubator.
> >
> > A vote for accepting a new Apache Incubator podling is a majority vote.
> > Everyone is welcome to vote, only Incubator PMC member votes are binding.
> > It would be helpful (but not required) if you could add a comment stating
> > whether your vote is binding or non-binding.
> >
> > This vote will run for at least 72 hours (but I expect to keep it open
> for
> > longer). Please VOTE as follows:
> >
> > [ ] +1 Accept Cava into the Apache Incubator
> > [ ] +0 Abstain
> > [ ] -1 Do not accept Cava into the Apache Incubator because ...
> >
> > Thank you for everyone who decided to join in in the past discussions!
> > Antoine
> >
> > [1]:
> https://lists.apache.org/thread.html/5a7f6a218b11a1cac61fbd53f4c995fd7716f8ad3751cf9f171ebd57@%3Cgeneral.incubator.apache.org%3E
> > [2]:
> https://lists.apache.org/thread.html/8d8014f53f140a3ccdd517c3c303de1d45cc04afdaee5961ac43e7fc@%3Cgeneral.incubator.apache.org%3E
> > [3]: https://wiki.apache.org/incubator/CavaProposal?action=recall&rev=14
> > [4]: https://incubator.apache.org/guides/proposal.html#the_vote
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> --
> Best Regards！
> Huxing
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>