Re: ASF hosted binaries collecting user data without an explicit opt-in

[Konstantin Boudnik]

While I am completely agree with your point, and the Ignite graduation
is the water under the bridge, this is in an important point for the
current podlings to consider. Perhaps it could be done elsewhere as
well, but I am not sure where would be the best place for it.
Thoughts?

Thanks,
  Cos
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  wrote:
> While these are all great discussion points, I don't believe they're
> relevant to incubator only and probably should have remained on the
> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
> doesn't have an opinion about this, but it's good to know that the policy
> may change (and I do personally have an opinion on said types of software).
>
> John
>
> On Mon, Jun 5, 2017 at 11:16 PM Roman Shaposhnik 
> wrote:
>
>> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  wrote:
>> > Thanks for the explanation, Roman. I had no idea that policies for
>> hosted binaries
>> > were stricter than for source code (other than the obvious effect on
>> licensing when you bundle in dependencies).
>>
>> Btw, this one is serious enough that I'd like us to update our release
>> policy based on the
>> learnings here.
>>
>> So far it seems that there's an agreement on that having this type of
>> capability...
>>1 ... in the source code disabled by default -- totally OK
>>2 ... in the source code enabled by default -- questionable, but OK
>>3 ... in the binary hosted by ASF disabled by default -- OK
>>4 ... in the binary hosted by ASF enabled by default -- NOT OK
>>
>> #4 can get nuanced if we want to invest in ASF managed infrastructure that
>> is
>> responsible for update tracking and user data collection. With my ASF hat
>> on,
>> I'd say that INFRA should probably stay away from user data
>> collection/retention.
>>
>> That still leaves a possibility of a a ping/pong API that only
>> consumes a name of ASF
>> project and its version and returns a JSON object of some kind as per
>> PMC choice.
>>
>>
>> Thanks,
>> Roman.
>>
>> -
>> 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: ASF hosted binaries collecting user data without an explicit opt-in

[Alex Harui]

Is the use of Google Analytics also prohibited by #4?

-Alex

On 6/5/17, 8:16 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
 wrote:

>On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  wrote:
>> Thanks for the explanation, Roman. I had no idea that policies for
>>hosted binaries
>> were stricter than for source code (other than the obvious effect on
>>licensing when you bundle in dependencies).
>
>Btw, this one is serious enough that I'd like us to update our release
>policy based on the
>learnings here.
>
>So far it seems that there's an agreement on that having this type of
>capability...
>   1 ... in the source code disabled by default -- totally OK
>   2 ... in the source code enabled by default -- questionable, but OK
>   3 ... in the binary hosted by ASF disabled by default -- OK
>   4 ... in the binary hosted by ASF enabled by default -- NOT OK
>
>#4 can get nuanced if we want to invest in ASF managed infrastructure
>that is
>responsible for update tracking and user data collection. With my ASF hat
>on,
>I'd say that INFRA should probably stay away from user data
>collection/retention.
>
>That still leaves a possibility of a a ping/pong API that only
>consumes a name of ASF
>project and its version and returns a JSON object of some kind as per
>PMC choice.
>
>
>Thanks,
>Roman.
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: ASF hosted binaries collecting user data without an explicit opt-in

[John D. Ament]

While these are all great discussion points, I don't believe they're
relevant to incubator only and probably should have remained on the
legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
doesn't have an opinion about this, but it's good to know that the policy
may change (and I do personally have an opinion on said types of software).

John

On Mon, Jun 5, 2017 at 11:16 PM Roman Shaposhnik 
wrote:

> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  wrote:
> > Thanks for the explanation, Roman. I had no idea that policies for
> hosted binaries
> > were stricter than for source code (other than the obvious effect on
> licensing when you bundle in dependencies).
>
> Btw, this one is serious enough that I'd like us to update our release
> policy based on the
> learnings here.
>
> So far it seems that there's an agreement on that having this type of
> capability...
>1 ... in the source code disabled by default -- totally OK
>2 ... in the source code enabled by default -- questionable, but OK
>3 ... in the binary hosted by ASF disabled by default -- OK
>4 ... in the binary hosted by ASF enabled by default -- NOT OK
>
> #4 can get nuanced if we want to invest in ASF managed infrastructure that
> is
> responsible for update tracking and user data collection. With my ASF hat
> on,
> I'd say that INFRA should probably stay away from user data
> collection/retention.
>
> That still leaves a possibility of a a ping/pong API that only
> consumes a name of ASF
> project and its version and returns a JSON object of some kind as per
> PMC choice.
>
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Contents of Podling Status Tracking

[John D. Ament]

As a follow up to my prior question, (
https://lists.apache.org/thread.html/31119aafbc4260720d222666f3efd01f2fe2975e424039ea539c9cb6@%3Cgeneral.incubator.apache.org%3E
).
Looking at our current tracking file for podlings, I wonder how much of the
information is useful.  Let's use Traffic Control as a for instance here:
http://incubator.apache.org/projects/trafficcontrol.html (its nothing
they're doing bad, I just happened to grab them)

- The committer list is fully replaced by the Whimsy Roster Tool
- Do we care about News? Shouldn't this be captured in the quarterly
reports?
- I see a lot of usefulness in tracking the Podling Name Search request
- The first few questions have to do with the actual vote.  I think these
can best be captured by two fields - "Sponsor" and "Date Accepted into
Incubator"
- Infra section - I think all of these are important, we may want to expand
some of the options to include gitbox and other tools that are managed
outside our hosted infrastructure.
- Mentor section - I'm not sure how useful this is, but I want to get
others opinions.  Mentors being on the IPMC is a pre-req for votes, so this
is hopefully less of an issue.
- Copyright - I believe this can be replaced by a single field "Date SGA
Received".  Copyright headers are subjective.
- Add a new field "Date of IP Clearance" for projects using IP Clearance
instead of SGA (e.g. already Apache v2)
- Verify Distribution Rights - I think this can be rewritten to instead say
"Date of Release with no Source Licensing Issues" (listing out the bullet
points mentioned here) and a new field "Date of Release with no Binary
Licensing Issues" (indicating some of the Cat-B/Optional Cat-X stuff)
- I don't think we need the committers section at the bottom, since the
roster would be controlled from Whimsy itself.

Is there more information that we could leverage to make this easier to
watch?  I figure that once a podling has filled out all of these (except
for one of SGA/IP Clearance) we can tell them they're close to graduation.

John

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  wrote:
> Thanks for the explanation, Roman. I had no idea that policies for hosted 
> binaries
> were stricter than for source code (other than the obvious effect on 
> licensing when you bundle in dependencies).

Btw, this one is serious enough that I'd like us to update our release
policy based on the
learnings here.

So far it seems that there's an agreement on that having this type of
capability...
   1 ... in the source code disabled by default -- totally OK
   2 ... in the source code enabled by default -- questionable, but OK
   3 ... in the binary hosted by ASF disabled by default -- OK
   4 ... in the binary hosted by ASF enabled by default -- NOT OK

#4 can get nuanced if we want to invest in ASF managed infrastructure that is
responsible for update tracking and user data collection. With my ASF hat on,
I'd say that INFRA should probably stay away from user data
collection/retention.

That still leaves a possibility of a a ping/pong API that only
consumes a name of ASF
project and its version and returns a JSON object of some kind as per
PMC choice.


Thanks,
Roman.

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

Re: [VOTE] Release Apache Traffic Control 1.8.1-incubating (RC0)

[John D. Ament]

I generally agree with Sebb's sentiments.  Its confusing that you list a
downloads page, but it's not listed (though I feel its better that its not
shown based on last release's issues).

For next release, I would like the output artifact to be
"apache-trafficcontrol-VERSION-incubating" (think back to my
presentation).  This better aligns with your overall branding.

You're mentioning the font licenses in NOTICE, but they better apply to the
LICENSE file.

Here's my +1 as your release is better.  Please try to address these for
next release.

John

On Mon, Jun 5, 2017 at 6:52 PM sebb  wrote:

> On 5 June 2017 at 23:20, Dan Kirkwood  wrote:
> > Thanks for that feedback -- I'll make sure our release instructions
> > are clear on those points and remove users@ from any future votes.
> >
> >> The draft release notes (along with links to artifacts,
> >> signatures/checksums, and updated documentation) can be found here:
> >>
> >> http://trafficcontrol.incubator.apache.org/downloads/
> >
> > To clarify,  this is misstated: the artifacts for this release are not
> > there -- they will be placed at that location once the release is
> > approved and not before.  The previous (approved) release artifacts
> > are at that location.
>
> OK, that's a relief.
>
> Is there a copy of the proposed download page?
> It would be useful to link to that.
>
> > -dan
> >
> >
> > On Mon, Jun 5, 2017 at 3:49 PM, sebb  wrote:
> >> On 5 June 2017 at 22:12, Dan Kirkwood  wrote:
> >>
> >> DROPPED user@ list - see below.
> >>
> >>> Hello Incubator PMC,
> >>>
> >>> The Apache Traffic Control community has voted on and approved a
> >>> proposal to release Apache Traffic Control 1.8.1-incubating. We now
> >>> kindly request that the Incubator PMC members review and vote on this
> >>> incubator release.
> >>>
> >>> The VOTE RESULT is here:
> >>>
> >>>
> https://lists.apache.org/thread.html/c43fe387586c44e2ecbac1f968a146f9a402a328be0f6e9b296fc3c9@%3Cusers.trafficcontrol.apache.org%3E
> >>>
> >>> The draft release notes (along with links to artifacts,
> >>> signatures/checksums, and updated documentation) can be found here:
> >>>
> >>> http://trafficcontrol.incubator.apache.org/downloads/
> >>
> >> This is a *public* URL.
> >> However the release has not yet been approved, so it must *not* be
> published.
> >> For the same reason, the email regarding the RC should not be sent to
> >> the user list.
> >>
> >> Also the download page points to
> >>
> >> https://dist.apache.org/repos/dist/
> >>
> >> The dist repo is a staging repo only, and must not be used for public
> URLs.
> >>
> >>> The git tag for the repository is "RELEASE-1.8.1-RC0":
> >>>
> https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.1-RC0
> >>>
> >>> The source distribution (also linked in the release notes) is here:
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0/
> >>
> >> That URL is fine for RC vote mails
> >>
> >>> Build instructions are included in the BUILD.md file which is included
> >>> in the source artifact.
> >>>
> >>> Artifacts have been signed with the "dang...@apache.org" key listed
> in:
> >>>
> >>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
> >>
> >> That URL is fine for RC vote mails
> >>
> >>> Please review and vote:
> >>>
> >>> [ ] +1 Approve the release
> >>> [ ] -1 Don't approve the release (please provide specific comments)
> >>>
> >>> This vote will be open for at least 72 hours.
> >>>
> >>> Thanks,
> >>>
> >>>  Dan Kirkwood 
> >>>
> >>> -
> >>> 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
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Julian Hyde]

Thanks for the explanation, Roman. I had no idea that policies for hosted 
binaries were stricter than for source code (other than the obvious effect on 
licensing when you bundle in dependencies).

Julian

> On Jun 5, 2017, at 7:47 PM, Roman Shaposhnik  wrote:
> 
> On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde  wrote:
>> If the binaries are built from the released source code I don’t think we 
>> should restrict what the binaries do.
> 
> Well, but that's not how we treat licensing for example. For example
> -- there's plenty of ASF project that
> allow GPL licensed extension to be pulled into the build. That
> mechanics is part of the source code. However,
> as per our policy, we will not allow this kind of a convenience binary
> (containing GPL bits) to be hosted by
> ASF infrastructure.
> 
> Now, there's nothing wrong with those kinds of binaries -- and 3d
> parties host them all the time -- its just that
> WE at ASF decided that it wouldn't be aligned with what we do.
> 
> What I'm concerned about is that a combination of binaries hosted by
> ASF and a lack of opt-in AND an unsecure
> nature of the communication AND unclear data handling policies can
> potential make ASF liable if this kind of
> data ends up containing sensitive information and gets exploited.
> 
> IANAL, but I could see EU being especially strict here.
> 
>> The question is whether the community is aware of what the code is doing, 
>> and considers it to be in the best interests of the project.
>> 
>> The answer seems to be yes, and yes. I saw that the issue was discussed on 
>> dev@ignite[1], and had a corresponding JIRA case[2],
> 
> As for the discussion on JIRA, I expected the podling to listen to the
> advice given by one of the mentors:
>   
> https://issues.apache.org/jira/browse/IGNITE-775?focusedCommentId=14512075=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512075
> but apparently that never happened.
> 
> Thanks,
> Roman.
> 
> -
> 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: ASF hosted binaries collecting user data without an explicit opt-in

[Raphael Bircher]

Hi all,

Am .06.2017, 04:47 Uhr, schrieb Roman Shaposhnik :


On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde  wrote:
If the binaries are built from the released source code I don’t think  
we should restrict what the binaries do.


Well, but that's not how we treat licensing for example. For example
-- there's plenty of ASF project that
allow GPL licensed extension to be pulled into the build. That
mechanics is part of the source code. However,
as per our policy, we will not allow this kind of a convenience binary
(containing GPL bits) to be hosted by
ASF infrastructure.

Now, there's nothing wrong with those kinds of binaries -- and 3d
parties host them all the time -- its just that
WE at ASF decided that it wouldn't be aligned with what we do.

What I'm concerned about is that a combination of binaries hosted by
ASF and a lack of opt-in AND an unsecure
nature of the communication AND unclear data handling policies can
potential make ASF liable if this kind of
data ends up containing sensitive information and gets exploited.

IANAL, but I could see EU being especially strict here.
Absolutely, for me the described behavior is a no go. The binaries should  
not be distributed over ASF Mirrors.


Regards, Raphael

--
My introduction https://youtu.be/Ln4vly5sxYU

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Konstantin Boudnik]

Thanks Greg. I have already started the conversation on private@ignite
and opened IGNITE-5413
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Mon, Jun 5, 2017 at 7:36 PM, Greg Stein  wrote:
> The Infrastructure team is taking this to the Apache Ignite PMC. This is
> completely improper.
>
> On Mon, Jun 5, 2017 at 9:34 PM, Julian Hyde  wrote:
>
>> If the binaries are built from the released source code I don’t think we
>> should restrict what the binaries do. The question is whether the community
>> is aware of what the code is doing, and considers it to be in the best
>> interests of the project.
>>
>> The answer seems to be yes, and yes. I saw that the issue was discussed on
>> dev@ignite[1], and had a corresponding JIRA case[2], and no objections
>> were raised. If anyone has problems with that behavior (including security
>> bugs) they should raise it with Ignite's PMC.
>>
>> Julian
>>
>> [1] https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
>> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%3E <
>> https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
>> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%3E>
>>
>> [2] https://issues.apache.org/jira/browse/IGNITE-775 <
>> https://issues.apache.org/jira/browse/IGNITE-775>
>>
>>
>>
>> > On Jun 5, 2017, at 6:48 PM, Roman Shaposhnik 
>> wrote:
>> >
>> > Hi!
>> >
>> > after seeing this thread on legal-discuss:
>> >https://mail-archives.apache.org/mod_mbox/www-legal-
>> discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_
>> V1REQ9hUERCFog%40mail.gmail.com%3E
>> >
>> > I'd like to ask a policy related question.
>> >
>> > What we currently have is a whole bunch of binaries hosted
>> > by ASF: https://ignite.apache.org/download.cgi#binaries that
>> > collect user data and ship it away to a host currently not
>> > associated with ASF (nor does it seem to be associated with
>> > Ignite's PMC). The host name is ignite.run (and, as a side note,
>> > as it turns out the connection to that host in Ignite releases prior
>> > to 1.9 is unsecure:
>> >   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
>> > )
>> >
>> > Is this something ASF should be concerned with from a standpoint
>> > of the policy that we have for binary convenience artifacts that are
>> > hosted on our end?
>> >
>> > Would it make it different if ignite.run and the data collected
>> > by it was managed by an Ignite PMC as opposed to an unidentified
>> > 3d party?
>> >
>> > Thanks,
>> > Roman.
>> >
>> > -
>> > 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: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde  wrote:
> If the binaries are built from the released source code I don’t think we 
> should restrict what the binaries do.

Well, but that's not how we treat licensing for example. For example
-- there's plenty of ASF project that
allow GPL licensed extension to be pulled into the build. That
mechanics is part of the source code. However,
as per our policy, we will not allow this kind of a convenience binary
(containing GPL bits) to be hosted by
ASF infrastructure.

Now, there's nothing wrong with those kinds of binaries -- and 3d
parties host them all the time -- its just that
WE at ASF decided that it wouldn't be aligned with what we do.

What I'm concerned about is that a combination of binaries hosted by
ASF and a lack of opt-in AND an unsecure
nature of the communication AND unclear data handling policies can
potential make ASF liable if this kind of
data ends up containing sensitive information and gets exploited.

IANAL, but I could see EU being especially strict here.

> The question is whether the community is aware of what the code is doing, and 
> considers it to be in the best interests of the project.
>
> The answer seems to be yes, and yes. I saw that the issue was discussed on 
> dev@ignite[1], and had a corresponding JIRA case[2],

As for the discussion on JIRA, I expected the podling to listen to the
advice given by one of the mentors:
   
https://issues.apache.org/jira/browse/IGNITE-775?focusedCommentId=14512075=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512075
but apparently that never happened.

Thanks,
Roman.

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Greg Stein]

The Infrastructure team is taking this to the Apache Ignite PMC. This is
completely improper.

On Mon, Jun 5, 2017 at 9:34 PM, Julian Hyde  wrote:

> If the binaries are built from the released source code I don’t think we
> should restrict what the binaries do. The question is whether the community
> is aware of what the code is doing, and considers it to be in the best
> interests of the project.
>
> The answer seems to be yes, and yes. I saw that the issue was discussed on
> dev@ignite[1], and had a corresponding JIRA case[2], and no objections
> were raised. If anyone has problems with that behavior (including security
> bugs) they should raise it with Ignite's PMC.
>
> Julian
>
> [1] https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%3E <
> https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%3E>
>
> [2] https://issues.apache.org/jira/browse/IGNITE-775 <
> https://issues.apache.org/jira/browse/IGNITE-775>
>
>
>
> > On Jun 5, 2017, at 6:48 PM, Roman Shaposhnik 
> wrote:
> >
> > Hi!
> >
> > after seeing this thread on legal-discuss:
> >https://mail-archives.apache.org/mod_mbox/www-legal-
> discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_
> V1REQ9hUERCFog%40mail.gmail.com%3E
> >
> > I'd like to ask a policy related question.
> >
> > What we currently have is a whole bunch of binaries hosted
> > by ASF: https://ignite.apache.org/download.cgi#binaries that
> > collect user data and ship it away to a host currently not
> > associated with ASF (nor does it seem to be associated with
> > Ignite's PMC). The host name is ignite.run (and, as a side note,
> > as it turns out the connection to that host in Ignite releases prior
> > to 1.9 is unsecure:
> >   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
> > )
> >
> > Is this something ASF should be concerned with from a standpoint
> > of the policy that we have for binary convenience artifacts that are
> > hosted on our end?
> >
> > Would it make it different if ignite.run and the data collected
> > by it was managed by an Ignite PMC as opposed to an unidentified
> > 3d party?
> >
> > Thanks,
> > Roman.
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Julian Hyde]

If the binaries are built from the released source code I don’t think we should 
restrict what the binaries do. The question is whether the community is aware 
of what the code is doing, and considers it to be in the best interests of the 
project.

The answer seems to be yes, and yes. I saw that the issue was discussed on 
dev@ignite[1], and had a corresponding JIRA case[2], and no objections were 
raised. If anyone has problems with that behavior (including security bugs) 
they should raise it with Ignite's PMC.

Julian

[1] 
https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%3E
 


[2] https://issues.apache.org/jira/browse/IGNITE-775 




> On Jun 5, 2017, at 6:48 PM, Roman Shaposhnik  wrote:
> 
> Hi!
> 
> after seeing this thread on legal-discuss:
>
> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_V1REQ9hUERCFog%40mail.gmail.com%3E
> 
> I'd like to ask a policy related question.
> 
> What we currently have is a whole bunch of binaries hosted
> by ASF: https://ignite.apache.org/download.cgi#binaries that
> collect user data and ship it away to a host currently not
> associated with ASF (nor does it seem to be associated with
> Ignite's PMC). The host name is ignite.run (and, as a side note,
> as it turns out the connection to that host in Ignite releases prior
> to 1.9 is unsecure:
>   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
> )
> 
> Is this something ASF should be concerned with from a standpoint
> of the policy that we have for binary convenience artifacts that are
> hosted on our end?
> 
> Would it make it different if ignite.run and the data collected
> by it was managed by an Ignite PMC as opposed to an unidentified
> 3d party?
> 
> Thanks,
> Roman.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

Hi!

after seeing this thread on legal-discuss:

https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_V1REQ9hUERCFog%40mail.gmail.com%3E

I'd like to ask a policy related question.

What we currently have is a whole bunch of binaries hosted
by ASF: https://ignite.apache.org/download.cgi#binaries that
collect user data and ship it away to a host currently not
associated with ASF (nor does it seem to be associated with
Ignite's PMC). The host name is ignite.run (and, as a side note,
as it turns out the connection to that host in Ignite releases prior
to 1.9 is unsecure:
   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
)

Is this something ASF should be concerned with from a standpoint
of the policy that we have for binary convenience artifacts that are
hosted on our end?

Would it make it different if ignite.run and the data collected
by it was managed by an Ignite PMC as opposed to an unidentified
3d party?

Thanks,
Roman.

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

Re: [NOTICE] Community Vote for Apache Atlas Graduation to TLP

[John D. Ament]

Suma,

One more thing.  I cannot find a podling name search on file for Atlas.
Has this been done?  See also [1]

John

[1]: http://incubator.apache.org/guides/names.html#name-search

On Thu, May 25, 2017 at 8:45 PM John D. Ament  wrote:

> Hi Suma,
>
> Thanks for the heads up.  There is actually no requirement for the podling
> community to vote on graduation, but its a good sign.
>
> I'm a little concerned, can you double check your status file at [1] ?
> Most of the items are marked N/A which is weird, most of these should
> actually have dates.
>
> In addition, can you provide a list of committers you have added since
> starting at Apache?  The podling status report shows none, but it may be
> that your status file is not up to date.
>
> [1]: http://incubator.apache.org/projects/atlas.html
>
>
> On Thu, May 25, 2017 at 8:33 PM Suma Shivaprasad 
> wrote:
>
>> Dear Incubator members,
>>
>> Please note that the community vote for graduating Apache Atlas to TLP has
>> commenced and has so far received a very positive response from the Atlas
>> community. You can find the vote thread at https://s.apache.org/94xI.
>>
>> Thanks
>> Suma
>>
>

Re: [VOTE] Release Apache Traffic Control 1.8.1-incubating (RC0)

[sebb]

On 5 June 2017 at 23:20, Dan Kirkwood  wrote:
> Thanks for that feedback -- I'll make sure our release instructions
> are clear on those points and remove users@ from any future votes.
>
>> The draft release notes (along with links to artifacts,
>> signatures/checksums, and updated documentation) can be found here:
>>
>> http://trafficcontrol.incubator.apache.org/downloads/
>
> To clarify,  this is misstated: the artifacts for this release are not
> there -- they will be placed at that location once the release is
> approved and not before.  The previous (approved) release artifacts
> are at that location.

OK, that's a relief.

Is there a copy of the proposed download page?
It would be useful to link to that.

> -dan
>
>
> On Mon, Jun 5, 2017 at 3:49 PM, sebb  wrote:
>> On 5 June 2017 at 22:12, Dan Kirkwood  wrote:
>>
>> DROPPED user@ list - see below.
>>
>>> Hello Incubator PMC,
>>>
>>> The Apache Traffic Control community has voted on and approved a
>>> proposal to release Apache Traffic Control 1.8.1-incubating. We now
>>> kindly request that the Incubator PMC members review and vote on this
>>> incubator release.
>>>
>>> The VOTE RESULT is here:
>>>
>>> https://lists.apache.org/thread.html/c43fe387586c44e2ecbac1f968a146f9a402a328be0f6e9b296fc3c9@%3Cusers.trafficcontrol.apache.org%3E
>>>
>>> The draft release notes (along with links to artifacts,
>>> signatures/checksums, and updated documentation) can be found here:
>>>
>>> http://trafficcontrol.incubator.apache.org/downloads/
>>
>> This is a *public* URL.
>> However the release has not yet been approved, so it must *not* be published.
>> For the same reason, the email regarding the RC should not be sent to
>> the user list.
>>
>> Also the download page points to
>>
>> https://dist.apache.org/repos/dist/
>>
>> The dist repo is a staging repo only, and must not be used for public URLs.
>>
>>> The git tag for the repository is "RELEASE-1.8.1-RC0":
>>> https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.1-RC0
>>>
>>> The source distribution (also linked in the release notes) is here:
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0/
>>
>> That URL is fine for RC vote mails
>>
>>> Build instructions are included in the BUILD.md file which is included
>>> in the source artifact.
>>>
>>> Artifacts have been signed with the "dang...@apache.org" key listed in:
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>>
>> That URL is fine for RC vote mails
>>
>>> Please review and vote:
>>>
>>> [ ] +1 Approve the release
>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>
>>> This vote will be open for at least 72 hours.
>>>
>>> Thanks,
>>>
>>>  Dan Kirkwood 
>>>
>>> -
>>> 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
>

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

Re: [VOTE] Release Apache Traffic Control 1.8.1-incubating (RC0)

[Dan Kirkwood]

Thanks for that feedback -- I'll make sure our release instructions
are clear on those points and remove users@ from any future votes.

> The draft release notes (along with links to artifacts,
> signatures/checksums, and updated documentation) can be found here:
>
> http://trafficcontrol.incubator.apache.org/downloads/

To clarify,  this is misstated: the artifacts for this release are not
there -- they will be placed at that location once the release is
approved and not before.  The previous (approved) release artifacts
are at that location.

-dan


On Mon, Jun 5, 2017 at 3:49 PM, sebb  wrote:
> On 5 June 2017 at 22:12, Dan Kirkwood  wrote:
>
> DROPPED user@ list - see below.
>
>> Hello Incubator PMC,
>>
>> The Apache Traffic Control community has voted on and approved a
>> proposal to release Apache Traffic Control 1.8.1-incubating. We now
>> kindly request that the Incubator PMC members review and vote on this
>> incubator release.
>>
>> The VOTE RESULT is here:
>>
>> https://lists.apache.org/thread.html/c43fe387586c44e2ecbac1f968a146f9a402a328be0f6e9b296fc3c9@%3Cusers.trafficcontrol.apache.org%3E
>>
>> The draft release notes (along with links to artifacts,
>> signatures/checksums, and updated documentation) can be found here:
>>
>> http://trafficcontrol.incubator.apache.org/downloads/
>
> This is a *public* URL.
> However the release has not yet been approved, so it must *not* be published.
> For the same reason, the email regarding the RC should not be sent to
> the user list.
>
> Also the download page points to
>
> https://dist.apache.org/repos/dist/
>
> The dist repo is a staging repo only, and must not be used for public URLs.
>
>> The git tag for the repository is "RELEASE-1.8.1-RC0":
>> https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.1-RC0
>>
>> The source distribution (also linked in the release notes) is here:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0/
>
> That URL is fine for RC vote mails
>
>> Build instructions are included in the BUILD.md file which is included
>> in the source artifact.
>>
>> Artifacts have been signed with the "dang...@apache.org" key listed in:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>
> That URL is fine for RC vote mails
>
>> Please review and vote:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>>
>> This vote will be open for at least 72 hours.
>>
>> Thanks,
>>
>>  Dan Kirkwood 
>>
>> -
>> 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] Release Apache Traffic Control 1.8.1-incubating (RC0)

[sebb]

On 5 June 2017 at 22:12, Dan Kirkwood  wrote:

DROPPED user@ list - see below.

> Hello Incubator PMC,
>
> The Apache Traffic Control community has voted on and approved a
> proposal to release Apache Traffic Control 1.8.1-incubating. We now
> kindly request that the Incubator PMC members review and vote on this
> incubator release.
>
> The VOTE RESULT is here:
>
> https://lists.apache.org/thread.html/c43fe387586c44e2ecbac1f968a146f9a402a328be0f6e9b296fc3c9@%3Cusers.trafficcontrol.apache.org%3E
>
> The draft release notes (along with links to artifacts,
> signatures/checksums, and updated documentation) can be found here:
>
> http://trafficcontrol.incubator.apache.org/downloads/

This is a *public* URL.
However the release has not yet been approved, so it must *not* be published.
For the same reason, the email regarding the RC should not be sent to
the user list.

Also the download page points to

https://dist.apache.org/repos/dist/

The dist repo is a staging repo only, and must not be used for public URLs.

> The git tag for the repository is "RELEASE-1.8.1-RC0":
> https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.1-RC0
>
> The source distribution (also linked in the release notes) is here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0/

That URL is fine for RC vote mails

> Build instructions are included in the BUILD.md file which is included
> in the source artifact.
>
> Artifacts have been signed with the "dang...@apache.org" key listed in:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS

That URL is fine for RC vote mails

> Please review and vote:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
>
>  Dan Kirkwood 
>
> -
> 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] - Approve the release of Apache Joshua incubating 6.1 (rc4)

[lewis john mcgibbney]

Please see the following issue folks
https://github.com/redpony/cdec/issues/94
Thanks
Lewis

On Fri, Jun 2, 2017 at 9:46 AM, lewis john mcgibbney 
wrote:

> Hi Justin,
> Excellent catch. Thank you for rebiewing the RC... it is really helping us
> out.
> To answer your question, I had to look back to the Joshua Tag for 6.0.4
> (prior to it's entry into the Incubator as a podling) I managed to find the
> commit history for the file(s) in question...
> https://github.com/joshua-decoder/joshua/commit/
> aeaed01deb0688b0af5adcd01a0be0b9d4d51789
> You will see that they were added to Joshua (at that time) in one commit,
> the commit message would indicate that they came from the source you've
> provided. e.g. "...Added parallelization files from cdec"
> Where does this leave us now? The file(s) have bee altered since then,
> please see
> https://github.com/joshua-decoder/joshua/commit/
> 0bee12805426fc5ac61b3fdb702a5a059404d64f
> The copyright has been retained but the Apache Licence v2.0 header has
> also been added.
> Lewis
>
> On Fri, Jun 2, 2017 at 8:59 AM, 
> wrote:
>
>>
>> From: Justin Mclean 
>> To: general@incubator.apache.org
>> Cc:
>> Bcc:
>> Date: Fri, 2 Jun 2017 18:29:14 +1000
>> Subject: Re: [VOTE] - Approve the release of Apache Joshua incubating 6.1
>> (rc4)
>> Hi,
>>
>> Just wondering if the "All rights reserved” may imply that it's not
>> licensed under a permissive license?
>>
>>  I’m unaware of the history / providence of that file so was enquiring if
>> anyone on the project had any more info where it come from.
>>
>> Thanks,
>> Justin
>>
>
>
>
> --
> http://home.apache.org/~lewismc/
> @hectorMcSpector
> http://www.linkedin.com/in/lmcgibbney
>



-- 
http://home.apache.org/~lewismc/
@hectorMcSpector
http://www.linkedin.com/in/lmcgibbney

Re: [VOTE] - Approve the release of Apache Joshua incubating 6.1 (rc4)

[lewis john mcgibbney]

Hi Justin and Tommaso,
I'll register and issue over on the cdec repository and ping the
contributors over there. I'll cross-reference the outcome here and
hopefully we can move forward.
Lewis

On Fri, Jun 2, 2017 at 9:46 AM, lewis john mcgibbney 
wrote:

> Hi Justin,
> Excellent catch. Thank you for rebiewing the RC... it is really helping us
> out.
> To answer your question, I had to look back to the Joshua Tag for 6.0.4
> (prior to it's entry into the Incubator as a podling) I managed to find the
> commit history for the file(s) in question...
> https://github.com/joshua-decoder/joshua/commit/
> aeaed01deb0688b0af5adcd01a0be0b9d4d51789
> You will see that they were added to Joshua (at that time) in one commit,
> the commit message would indicate that they came from the source you've
> provided. e.g. "...Added parallelization files from cdec"
> Where does this leave us now? The file(s) have bee altered since then,
> please see
> https://github.com/joshua-decoder/joshua/commit/
> 0bee12805426fc5ac61b3fdb702a5a059404d64f
> The copyright has been retained but the Apache Licence v2.0 header has
> also been added.
> Lewis
>
> On Fri, Jun 2, 2017 at 8:59 AM, 
> wrote:
>
>>
>> From: Justin Mclean 
>> To: general@incubator.apache.org
>> Cc:
>> Bcc:
>> Date: Fri, 2 Jun 2017 18:29:14 +1000
>> Subject: Re: [VOTE] - Approve the release of Apache Joshua incubating 6.1
>> (rc4)
>> Hi,
>>
>> Just wondering if the "All rights reserved” may imply that it's not
>> licensed under a permissive license?
>>
>>  I’m unaware of the history / providence of that file so was enquiring if
>> anyone on the project had any more info where it come from.
>>
>> Thanks,
>> Justin
>>
>
>
>
> --
> http://home.apache.org/~lewismc/
> @hectorMcSpector
> http://www.linkedin.com/in/lmcgibbney
>



-- 
http://home.apache.org/~lewismc/
@hectorMcSpector
http://www.linkedin.com/in/lmcgibbney

[VOTE] Release Apache Traffic Control 1.8.1-incubating (RC0)

[Dan Kirkwood]

Hello Incubator PMC,

The Apache Traffic Control community has voted on and approved a
proposal to release Apache Traffic Control 1.8.1-incubating. We now
kindly request that the Incubator PMC members review and vote on this
incubator release.

The VOTE RESULT is here:

https://lists.apache.org/thread.html/c43fe387586c44e2ecbac1f968a146f9a402a328be0f6e9b296fc3c9@%3Cusers.trafficcontrol.apache.org%3E

The draft release notes (along with links to artifacts,
signatures/checksums, and updated documentation) can be found here:

http://trafficcontrol.incubator.apache.org/downloads/

The git tag for the repository is "RELEASE-1.8.1-RC0":
https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.1-RC0

The source distribution (also linked in the release notes) is here:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0/

Build instructions are included in the BUILD.md file which is included
in the source artifact.

Artifacts have been signed with the "dang...@apache.org" key listed in:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS

Please review and vote:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,

 Dan Kirkwood 

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

Re: [RESULT] Re: [VOTE] Livy to enter Apache Incubator

[Bikas Saha]

Hi,

I am sorry I was off email when all of this happened. Would like to add my post 
result +1 to join everyone in supporting this effort!

Thanks!
Bikas


From: Sean Busbey 
Sent: Monday, June 5, 2017 10:34:45 AM
To: general@incubator.apache.org
Subject: [RESULT] Re: [VOTE] Livy to enter Apache Incubator

With 7 binding +1 votes (and 14 non-binding +1 votes), this vote passes.

Thanks for everyone who took the time to vote!

I'll coordinate with the mentors to start the initial paperwork today. (And 
we'd be thrilled for the 4th mentor JB!)

binding:
Larry McCay
Jean-Baptiste Onofré
Luciano Resende
Andrew Purtell
Brock Noland
Raphael Bircher
Hitesh Shah

non-binding:
Sean Busbey
Ismaël Mejía
Marcelo Vanzin
Neelesh Salian
Phillip Rhodes
Kostas Sakellis
Jeff Zhang
Saisai Shao
tim shea
Pierre Smits
Arpit Agarwal
Madhawa Kasun Gunasekara
Bruno Mahé
Felix Cheung

-busbey

On 2017-05-31 08:03 (-0500), "Sean Busbey" wrote:
> Hi folks!
>
> I'm calling a vote to accept "Livy" into the Apache Incubator.
>
> The full proposal is available below, and is also available in the wiki:
>
> https://wiki.apache.org/incubator/LivyProposal
>
> For additional context, please see the discussion thread:
>
> https://s.apache.org/incubator-livy-proposal-thread
>
> Please cast your vote:
>
> [ ]  1, bring Livy into Incubator
> [ ] -1, do not bring Livy into Incubator, because...
>
> The vote will open at least for 72 hours and only votes from the Incubator
> PMC are binding.
>
> I start with my vote:
>  1
>


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

Re: Request for write access to Apache Incubator Wiki

[Vinod Kumar Vavilapalli]

Thanks a bunch, Nick!

+Vinod

> On Jun 3, 2017, at 1:37 AM, Nick Burch  wrote:
> 
> On Fri, 2 Jun 2017, Vinod Kumar Vavilapalli wrote:
>> I just volunteered to be a mentor for the Apache Slider incubator project. 
>> Please grant me write access to Apache Incubator Wiki.
> 
> Karma granted, happy mentoring!
> 
> Nick
> 
> -
> 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: [NOTICE] Community Vote for Apache Atlas Graduation to TLP

[Sam Ruby]

On Mon, Jun 5, 2017 at 3:17 PM, Suma Shivaprasad
 wrote:
> Thanks Sam. Have added the rest of the PPMC/committers.

Cool!

For future reference, you can click on + multiple times to queue up
additions, and then add them all at once.

Also, take a look at the "Draft graduation resolution" at the bottom
of the page.  It can help you draft a resolution that contains correct
names and IDs, etc.

> Suma

- Sam Ruby

> On Thu, Jun 1, 2017 at 7:46 PM, Sam Ruby  wrote:
>
>> On Thu, Jun 1, 2017 at 6:25 PM, Suma Shivaprasad
>>  wrote:
>>
>> >
>> > Once the issues are rectified, will work with one of the mentors to
>> update
>> > https://whimsy.apache.org/roster/ppmc/atlas
>>
>> I've added you; you should now be able to add the rest.  The PPMC will
>> be notified of your changes.
>>
>> > Thanks
>> > Suma
>>
>> - Sam Ruby
>>
>> -
>> 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: [NOTICE] Community Vote for Apache Atlas Graduation to TLP

[Suma Shivaprasad]

Thanks Sam. Have added the rest of the PPMC/committers.

Suma

On Thu, Jun 1, 2017 at 7:46 PM, Sam Ruby  wrote:

> On Thu, Jun 1, 2017 at 6:25 PM, Suma Shivaprasad
>  wrote:
>
> >
> > Once the issues are rectified, will work with one of the mentors to
> update
> > https://whimsy.apache.org/roster/ppmc/atlas
>
> I've added you; you should now be able to add the rest.  The PPMC will
> be notified of your changes.
>
> > Thanks
> > Suma
>
> - Sam Ruby
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[RESULT] Re: [VOTE] Livy to enter Apache Incubator

[Sean Busbey]

With 7 binding +1 votes (and 14 non-binding +1 votes), this vote passes.

Thanks for everyone who took the time to vote!

I'll coordinate with the mentors to start the initial paperwork today. (And 
we'd be thrilled for the 4th mentor JB!)

binding:
Larry McCay
Jean-Baptiste Onofré
Luciano Resende
Andrew Purtell
Brock Noland
Raphael Bircher
Hitesh Shah

non-binding:
Sean Busbey
Ismaël Mejía
Marcelo Vanzin
Neelesh Salian
Phillip Rhodes
Kostas Sakellis
Jeff Zhang
Saisai Shao
tim shea
Pierre Smits
Arpit Agarwal
Madhawa Kasun Gunasekara
Bruno Mahé
Felix Cheung

-busbey

On 2017-05-31 08:03 (-0500), "Sean Busbey" wrote: 
> Hi folks!
> 
> I'm calling a vote to accept "Livy" into the Apache Incubator.
> 
> The full proposal is available below, and is also available in the wiki:
> 
> https://wiki.apache.org/incubator/LivyProposal
> 
> For additional context, please see the discussion thread:
> 
> https://s.apache.org/incubator-livy-proposal-thread
> 
> Please cast your vote:
> 
> [ ]  1, bring Livy into Incubator
> [ ] -1, do not bring Livy into Incubator, because...
> 
> The vote will open at least for 72 hours and only votes from the Incubator
> PMC are binding.
> 
> I start with my vote:
>  1
> 


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

Re: [VOTE] Apache HTrace 4.3.0 incubating release (rc3)

[Billie Rinaldi]

+1 binding, though the license and notice have room for improvement
signature and checksums are good
tarball matches the git tag
disclaimer is good
builds from git tag
unit tests pass
overall the license and notice appear to reflect the contents of the source
release, with the following notes that I'd like to see addressed in the
future

for the source tarball:
* htrace-c/pom.xml has the wrong license header
* htrace-c/src/test/temp_dir.c appears to be an ASLv2 licensed file with
"Copyright 2011-2012 the Redfish authors" and this isn't mentioned in the
NOTICE
* htrace-hbase/src/main/webapps/htrace/bootstrap-theme.min.css and
htrace-hbase/src/main/webapps/htrace/bootstrap.min.css appear to have an
older version of bootstrap (3.0.0 instead of 3.3.1) with ASLv2 license
"Copyright 2013 Twitter, Inc" and this isn't mentioned in the NOTICE

for the jars and war distributed in the maven repository:
* distributed jars and wars should have their own LICENSE and NOTICE files
reflecting what is included in them -- there are some BSD, MIT, and CDDL
licensed classes included in the shaded jars that are not mentioned
* htrace-zipkin-4.3.0-incubating.jar contains a confusing license file,
META-INF/license/LICENSE.jboss-logging.txt, that states jboss logging is
LGPL. jboss logging does not appear to be included in the jar, but I
suspect the license file is present because jboss logging is an optional
dependency of netty, which is included in the jar

On Fri, 2 Jun 2017 15:11:19 -0500, Mike Drob  wrote:
> Hi IPMC,
>
> Please consider the release of Apache HTrace 4.3.0 Incubating
>
>
>
> Project [VOTE]:
>
>
https://lists.apache.org/thread.html/6e60ba2574a853da59c3a150f18cd9bbd52051785380a7cc837b583e@%3Cdev.htrace.apache.org%3E
>
> Project [RESULT][VOTE]:
>
>
https://lists.apache.org/thread.html/fb2a68fcd9c80d9db4a483794112aecde486ca263384dec0bad38c34@%3Cdev.htrace.apache.org%3E
>
> Artifacts staged at:
>
> http://people.apache.org/~mdrob/htrace-4.3.0-incubating-rc3/
>
> Staging maven repository at:
>
> https://repository.apache.org/content/repositories/orgapachehtrace-1029
>
> Source tree:
>
>
https://git-wip-us.apache.org/repos/asf?p=incubator-htrace.git;a=tree;h=2ca8767b38c83f0d2f46ce7f91373d9df69f7fb8;hb=a47398aea8d65fb544faba150beb49bb7654cb49
>
>
> Please download and evaluate the release candidate.
>
> This vote will remain open for minimum 5 days
>
> [ ] +1 Approve the release
>
> [ ] +0 No opinion
>
> [ ] -1 Do not approve the release because ...
>
>
> Thanks,
>
> Mike

Re: [DISCUSS] Migration of Podling Maintenance Tooling to Whimsy

[Julian Hyde]

+1

It moves us towards a self-service (dare I say “github-like”) experience for 
podlings, and that is always good.

Furthermore, if there are choices to be made (e.g. svnpubsub vs. CMS) I think 
the tooling should strongly encourage them to take the “standard” option. Maybe 
it doesn’t even present the other option(s) at all. When my project was going 
through incubation I was forever worried about stepping on some infrastructure 
landmine and as a result did nothing for several months.

Julian


> On Jun 4, 2017, at 7:33 PM, John D. Ament  wrote:
> 
> All,
> 
> I want to bring up this discussion to see others opinions.  I would like to
> move forward on migrating podling status maintenance into Whimsy.  Some of
> the key things I want to improve upon is the overall experience around
> managing the podling.  Sam's done a great job with rosters, but we can
> start to track other things in whimsy, which mirrors what's in the status
> file.  This can include IP Clearance/SGAs, Podling Name Searches, the
> various dates we track.
> 
> Ultimately, I want to simplify how podlings are managed and make it a bit
> easier on an end user.  Rather than needing to svn checkout to get files,
> they simply go to a webpage, and assuming they're on that podling's roster
> they would have access to update the status.  We could even automate
> certain events so that when the board passes a resolution to graduate the
> podling, the status file is updated along side any other record the podling
> may have.
> 
> This does mean that the status file format is likely to change.  It also
> means we're likely to move away from the java based build tool that has to
> parse the XML templates into web pages and instead rely on a more
> structured format for the status.
> 
> It doesn't mean you have to change.  If you like using SVN to edit this
> stuff that's fine, you would still be able to.  Just what you're editing is
> likely to be different.
> 
> Thoughts? Opinions?
> 
> John


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

Re: Images in source code.

[Bertrand Delacretaz]

On Sat, Jun 3, 2017 at 6:12 PM, James Bognar
 wrote:
> ...The reason I asked is because we've previously been asked about ownership
> of image files during release votes, so I wasn't sure if we were supposed
> to mark them somehow...

You could create a ticket in your issue tracker to indicate the
provenance of those images, and mention the ticket ID in the commit
messages when adding those images. Or maybe just add "created by
myself" to the commit messages for clarity.

-Bertrand

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

Re: [DISCUSS] Migration of Podling Maintenance Tooling to Whimsy

[Jim Jagielski]

+1

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

[VOTE]: Apache Weex-incubating Release 0.12.0-RC5

[sospartan]

Hi all,

I'm calling a vote for Weex-incubating 0.12.0-RC5 release.
The changes fix problems pointed out by John D. Ament and Justin Mclean in
RC4 voting thread[1].
Thanks to these guys. And thanks to people who vote +1 too. Hope this RC
would finally passed.

The PPMC vote for this release has passed:
*https://lists.apache.org/thread.html/866a707deea418ff5374d38783f5591d0cda6fa09515766fec101d3e@%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-rc5

The commit hash:
https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
dcf9a83360b4403ffbdbfb3e168a68d1ff7a2b38

The source tarball can be found at:
https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.0-incubating/RC5/

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)


1.
https://lists.apache.org/thread.html/9e9308203feb3e9651644e7bef6578a50cf21a4a0513bd6175e1fb53@%3Cgeneral.incubator.apache.org%3E

-- 
Best Regards!

sospartan
http://weex.apache.org/ 

Re: [VOTE] - Approve the release of Apache Joshua incubating 6.1 (rc4)

[Justin Mclean]

Hi,

Not to be a pain but I still don't think that quite explains the "All rights 
reserved” comment.

Just because these files were added to a repo that is under an Apache license 
(by someone other than the author I would note) doesn't automatically mean the 
original files were Apache licensed.

Perhaps the best thing to do is to reach to the author and ask for permission 
to use the files / clarify the license they are under?

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