Re: LGPL dependency

[Hen]

Assuming Weex requires Webkit and is unable to work with an alternative,
the issue here is that users of Weex would seem to have to permit reverse
engineering in their legal terms. Our position has been that that goes
beyond the scope of the Apache 2.0 license and would be an unpleasant
surprise for users.

(seem to have to  =>  this is how we've discussed the license; an actual
court may decide something completely different)

Looking at Weex's website's description, it does not seem to be that a user
of Weex will already have agreed to the terms of Webkit; thus I believe
they would be unpleasantly surprised.

Hen

On Fri, Jun 14, 2019 at 12:49 AM 申远  wrote:

> Hi,
>
> I am a PPMC member of Apache Weex. After serious reviewing of our
> dependencies, I found there some of the source code we copied from Webkit
> is actually under LGPL license(Category X) and our license format tools
> changed the license header of these files to Apache v2 incorrectly. I'd
> like to hear advice from incubator that whether our actions below would fix
> the Category X issue.
>
> First of all, License for Webkit is complicated, as it's said that  "WebKit
> is open source software with portions licensed under the LGPL and BSD
> licenses available here." [1].
>
> Now, Weex includes 1500 header files( .h files) from Webkit at compiling
> stage and around 150 of the are under BSD License. At runtime, Weex will
> dynamic links to the shared library of Webkit.
>
> After some major change, Weex could just include around 50 headers(.h
> files) at compiling stage and all of them are under BSD license. At
> runtime, Weex still needs to dynamic links to the shared library of Webkit
> as before.
>
> As Webkit is under dual license, and it's almost impossible for us to
> figure out whether there is an function call chain like
> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd like to
> know our proposed change is enough to fix the Category X dependency.
>
> [1] https://webkit.org/licensing-webkit/
>
> Best Regards,
> YorkShen
>
> 申远
>

Re: [IMPORTANT] Board proposal on podling releases

[Hen]

On Thu, Jun 13, 2019 at 02:53 Justin Mclean 
wrote:

> HI,
>
> > I think that serious = release blocker;
>
> That would also be my meaning. People / podlings have requested that
> release blockers be allowed in podling releases.
>
> > I'd love to hear some examples. I suspect they are all legal.
>
> Sure some recent examples (without mentioning any pooling name, but I can
> supply links if you want):
> - Including code license under a category B license


Boring imo. You have to try hard to screw up Cat B (though I’ve seen it
done).


> - Including code under an unknown license


Case by case.  Many would be (temporarily) okay imo under a “well it’s
clearly published for folk to use”.


> - including code under a permissive license, which required you to include
> the copyright and license text, but not including that text anywhere
> (LICENSE file or file header)


Put it on website/release announcements.

That partly argues to the disclaimer being partially I dependent of the
release


>
> The last one is probably the most common, especially with Javascript when
> license headers seem to be optional.


IMO those projects are inducing users to not comply by failing to
self-attribute.

Any project including jQuery or Bootstrap immediately encounters this as
> they have embedded 3rd party code without license headers.
>
> We’ve allowed all of these situations, although I can also point to
> Category B inclusions where we have not allowed them.
>
> We’ve also allowed GPL dependancy and I think GPL inclusion (would need to
> check) with VP legal/VP incubator OK on a once off basis a while back. The
> provision being that it was fixed next release.
>
> All of those would be against the terms of the license, which I assume you
> mean by legal? Or do you mean something else by that term?


I mean clearly against the terms and intention. i.e. I’m less cut up if a
3rd party project did a crap job of their attribution such that we had to
fix their problems in obeying their license. GPL, MPL can happily be
included; it breaks our policy not their license.


>
> > I'd definitely like to see change. My feeling is that there's a lot we
> can
> > make that falls comfortably within the scope of the Incubator PMC.
>
> As Roman also suggested, we should discuss this with the legal committee
> and come up with a list to give podlings clearer guidance.
>
> > IIRC the release policies came out of the Incubator; I don't recall
> there being a
> > request for the board to ratify them, but I might be failing to remember
> > something a decade+ ago :)
>
> From several discussion it been made clear that we don’t own them, the
> board does. Interesting enough this say legal affairs does [1] when we’ve
> also been told they don’t. :-) In some cases there's been a nice triangle,
> where legal, infra and the board all say it someone else responsibility but
> not the incubators :-)


I’ll agree on that :) personally I speculate that the incubator went
over-bureaucracy on the topic a decade ago and there was a unofficial
“slowdown” push back that should have been more clearly owned.


>
> > By that are you suggesting that the text implies a guarantee that those
> are
> > the only issues?
>
>  Issues can be found in the IPMC vote not the podling vote, so some of
> these serious issues won’t be listed in the disclaimer when the IPMC votes
> on it.
>

We should decouple (a copy of) the disclaimer. Put it next you KEYS
perhaps. Our desire for atomic artifacts causes a lot of our pain.


> Thanks,
> Justin
>
> 1. http://www.apache.org/legal/release-policy.html#administration
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [IMPORTANT] Board proposal on podling releases

[Hen]

On Thu, Jun 13, 2019 at 01:15 Greg Stein  wrote:

> On Thu, Jun 13, 2019, 02:47 Alex Harui  wrote:
>
> > Maybe the next question is: Are all release policy violations
> > showstoppers?  I suspect the answer is no.  And thus, if any TLP can punt
> > release policy violations to a future release,
>
>
> What are you talking about?
>
> Nobody has suggested any modifications to TLP's policy.



I hearby suggest we modify TLP policy :) Alex is right.

>
>
> -g
>
> [deleting entire rest of irrelevant goo]


Ever the diplomat ;)

>
>

Re: [IMPORTANT] Board proposal on podling releases

[Hen]

On Sun, Jun 9, 2019 at 4:11 PM Justin Mclean 
wrote:

> Hi,
>
> > I agree with other respondents that 'serious' seems bad here. To me the
> > serious ones are the only ones they can't release with.
>
> So we just continue as is then? You have any suggests to what we change?
>

I don't think we're using the same word meanings.

I think that serious = release blocker; but I equally think there are very
few items that are serious.


>
> > ReleaseBlocking:  Has a LICENSE.  Legally permitted to release and
> complies
> > with the license via some mechanism.
>
> We currently allow releases that are not strictly legal. This would be a
> step backwards.
>
>
I'd love to hear some examples. I suspect they are all legal.

Speculating hypothetically:

* We should never make a release that we know there is some content in that
we explicitly do not have permission to publish.
* We should never make a release that we know contains content that is
criminal (for whatever that would mean).

Other than that... I'm not sure what else would come under 'all legal'
label.


> > GraduationBlocking:  Everything else; including complying with the
> license
> > via our preferred mechanism (i.e. we might want the MIT license text in
> our
> > LICENSE file, but would accept it being in the source header of the files
> > themselves).
>
> We currently allow podlings to graduate with some issues as longs as the
> PPMC is dealing with them. This would be a step backwards.
>
>
Yeah. We need a third category for "MehNotBlockingPleaseFix".


> > I don't see a need to go to the board on this :)
>
> If we don’t want to change anything - sure there's no need to go to the
> board.
>

I'd definitely like to see change. My feeling is that there's a lot we can
make that falls comfortably within the scope of the Incubator PMC. IIRC the
release policies came out of the Incubator; I don't recall there being a
request for the board to ratify them, but I might be failing to remember
something a decade+ ago :)


>
> >> issues have been fixed. The IPMC will add additional information to the
> > incubator DISCLAIMER to cover that podling release may not abide by all
> >
> > The IPMC? That sounds like a people scaling problem. The podling
> committee
> > should handle it.
>
> I mean just changing this page [1] , podlings can update their own
> disclaimers.
>

Gotya :)


>
> > "This release still has the following issues that will need to be
> resolved
> > before the Foo Project can graduate to an Apache vetted Top Level
> Project”
>
> What about unknown issues?
>

By that are you suggesting that the text implies a guarantee that those are
the only issues? (Otherwise I'm off into philosophy of whether the unknown
can exist when the only test makes it known :) ).

"The Foo Project have currently identified the following issues that will
need to be resolved before the project can graduate to an Apache vetted Top
Level Project”

Any better?


> > Are the board lawyers? :) Until you have a well-defined list, I doubt
> > anything could be confirmed. I'd go with:  "Conceptually what you
> describe
> > could lead to a situation where a PPMC releases a project fully compliant
> > with the ASF's expectations. “
>
> I assume you mean “not fully compliant”?
>

Nope.

I was being defensive in my broad statements. For the given question; sure,
someone might manage a perfect release someday :)

Hen

Re: [IMPORTANT] Board proposal on podling releases

[Hen]

Copying the proposal in so I have something to respond to :)

> Proposal
>
> That the IPMC can allow releases with serious issues in them to be
released and distributed without IPMC or legal VP approval. When this
occurs

I agree with other respondents that 'serious' seems bad here. To me the
serious ones are the only ones they can't release with.

ReleaseBlocking:  Has a LICENSE.  Legally permitted to release and complies
with the license via some mechanism.
GraduationBlocking:  Everything else; including complying with the license
via our preferred mechanism (i.e. we might want the MIT license text in our
LICENSE file, but would accept it being in the source header of the files
themselves).

I don't see a need to go to the board on this :)

> podling will documents the issue as one blocking graduation and carry on
incubating. They will not be allowed to graduate until all serious release

+1 to documenting it as BlocksGraduation :)  Noting the 'serious' here
again.

> issues have been fixed. The IPMC will add additional information to the
incubator DISCLAIMER to cover that podling release may not abide by all

The IPMC? That sounds like a people scaling problem. The podling committee
should handle it.

> terms of the ALv2 and may contain code under an incompatible license.

Incompatible is such a vague word. It's also very specific to one type of
GraduationBlocking issue. I would stick to:

"This release still has the following issues that will need to be resolved
before the Foo Project can graduate to an Apache vetted Top Level Project"
(or some such; I really want to say Apache-Certified Community, but that's
a different argument.

> All releases and podling web sites will be updated to include this where
> required.

This is a given.

>
> Notes
>
> The IPMC will come up with a well-defined list of those serious issues
and distribute to mentors, IPMC members and podlings so that everyone's
> expectations are clear. This proposal does not change the need for an
IPMC vote on podling releases.

Redefining "serious issues" to mean ones that block a release; they should
be writeable on the back of a couple of business cards. Taking serious
issues as ones that are not actually serious and only graduation blockers;
then +1. It should still be short, but a piece of paper seems good :)

> Can the board also confirm that the ASF's legal shield would cover people
making releases under this proposal?

Are the board lawyers? :) Until you have a well-defined list, I doubt
anything could be confirmed. I'd go with:  "Conceptually what you describe
could lead to a situation where a PPMC releases a project fully compliant
with the ASF's expectations. "

Hen




On Thu, Jun 6, 2019 at 11:45 PM Justin Mclean 
wrote:

> Hi,
>
> As suggested I’ve collated information from several threads and turned it
> into a proposal for the board. Any edits, feedback, agreement, disagreement
> etc etc is welcome. In particular it would be nice  to hear some feedback
> from people who are in favour of this.
>
> Note that this is important as it probably changes the advice mentors will
> give their podlings on releases and change in a positive way how we vote on
> releases with serious issues in them. If you are a mentor or vote on
> releases please read it. Again feedback welcome.
>
> If the board agrees with the proposal I think we'll need to update the
> incubator DISCLAIMER. I’ve suggested what we might add in the proposal but
> the exact changes can to be discussed here. If the board disagrees with the
> proposal I suggest we discuss and come up with a list of serious issues
> that the IPMC recommends voting -1 vote on a release. This is just
> guidance, not rules, and there may of course be exceptions. (For instance
> you could ask VP legal for an exception as has been done in the past.)
> That way mentors and podlings have clear expectations on releases must
> contain.
>
> The proposal can be found in the draft board report. [1]
>
> Thanks,
> Justin
>
> 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podling releases and release policy

[Hen]

On Sun, Jun 2, 2019 at 11:53 Greg Stein  wrote:

> On Sun, Jun 2, 2019 at 1:22 PM Hen  wrote:
> >...
>
> > * Incubating releases are Apache releases.
> >
>
> That is demonstrably not true, as (historically) the Incubator has made
> releases with GPL'd code in them (eg. Hibernate).


I don’t understand the choice of words :(

To me that is an Apache release which did not adhere, or had an exception,
to foundation policy. I assume it was offered from an Apache url.

If it wasn’t from an Apache url, then it wasn’t an Incubating release.

Hen



>

Re: Podling releases and release policy

[Hen]

Wrote a long thing... decided it wasn't useful :)

The tldr;

* Incubating releases are Apache releases. No user cares if they are
endorsed or official (for whatever they may mean). Perhaps if we said GA we
might be clearer.
* We end up having an argument about easiness of release vs
reproducible/provable releases.
** We too easily -1 a release because of something that could be easily
fixed by a human. We don't think about that human element when we stack on
more requirements.
** But we want perfection of the process. If I miss a DISCLAIMER; I can't
just fix it and publish, there is a whole rigmarole and revote I have to
do.

I'm thinking that should be solved with a standard source release. Press a
button and a tar.gz will be created, checking for a few standard files and
using the private key you supply. Have it require the PMC Chair to moderate
the release to confirm that the Apache Way was followed (and PPMCs need
chairs).

(and we need an entire conference to figure out binary releases)

Hen

On Sun, Jun 2, 2019 at 10:10 AM Kevin A. McGrail 
wrote:

> I think the fact that incubating releases are not official ASF releases
> covers this issue.  The full effect of the shield is more a risk for the
> programmers in the limbo state of incubating from my perspective.
>
> On 6/1/2019 11:27 PM, Justin Mclean wrote:
> > Hi,
> >
> > The other though that occurred to me is if we do this, are the people
> involved covered by ASF’s legal shield? i.e Does it pass the clean line
> mentioned in [1].
> >
> > "Deviations from this policy may have an adverse effect on the legal
> shield's effectiveness, or the insurance premiums Apache pays to protect
> officers and directors, so are strongly discouraged without prior, explicit
> board approval. "
> >
> > Thanks,
> > Justin
> >
> > 1. http://www.apache.org/legal/release-policy.html#why
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> --
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.1.rc0

[Hen]

+1 to the release.

I compared to the previous release and shared, on dev@mxnet, a note
regarding licensing of datasets (not included in the release but linked
from a script). I've suggested that a note on the origin and license be
added.

Hen

On Sun, May 5, 2019 at 8:14 AM Junru Shao  wrote:

> Dear community,
>
> This is a call for a releasing Apache MXNet (incubating) 1.4.1, release
> candidate 0. Apache MXNet (incubating) community has voted and approved the
> release.
>
> Vote thread:
>
> https://lists.apache.org/thread.html/6c140f4c180c259dd1b7f4ecf36f2d083ed810cd68b37d7f635f5614@%3Cdev.mxnet.apache.org%3E
>  .
>
> Result thread:
>
> https://lists.apache.org/thread.html/8b11c43fdafa3b9174fe7fa2344ed3cf468eaf7fffa0afded722cdb2@%3Cdev.mxnet.apache.org%3E
>  .
>
> The source tarball, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.1.rc0/   .
>
> The tag to be voted upon is 1.4.1.rc0:
> https://github.com/apache/incubator-mxnet/releases/tag/1.4.1.rc0/   .
>
> The release hash is 1a71996:
>
> https://github.com/apache/incubator-mxnet/tree/1a7199691f5cbc6012bb53eecbf884bed5ae6590/
>  .
>
> KEYS file available:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS/   .
>
> For information about the contents of this release, see:
>
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.1+Release+Notes
>  .
>
> The vote will be open for 72 hours, from May 3 2019, 23:59:59 PST to May 07
> 2019, 23:59:59 PST. (Weekends are counted as half day)
>
> [ ] +1 release this package as ...
> [ ] +0 no opinion
> [ ] -1 do not release this package because...
>
> Best regards,
> Junru Shao
>

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc3

[Hen]

+1.

I reviewed the diff with the RC2 that I approved, no concerns with anything
added.

Cc'ing other mentors.

Hen


On Wed, Feb 20, 2019 at 10:45 AM Piyush Ghai  wrote:

> Dear community,
>
> This is a call for releasing Apache MXNet (incubating) 1.4.0, release
> candidate RC3.
>
> Apache MXNet (incubating) community has voted and approved the release.
>
> Vote thread :
>
> https://lists.apache.org/thread.html/618ad28580e838254f998deb71373467374a05228401dae0323a6d0f@%3Cdev.mxnet.apache.org%3E
> <
> https://lists.apache.org/thread.html/618ad28580e838254f998deb71373467374a05228401dae0323a6d0f@%3Cdev.mxnet.apache.org%3E
> >
>
>
> Results thread :
>
>
> https://lists.apache.org/thread.html/68373b7be4a12e90f136aab2d55a334fad021bec7b796174d357f4b7@%3Cdev.mxnet.apache.org%3E
> <
> https://lists.apache.org/thread.html/68373b7be4a12e90f136aab2d55a334fad021bec7b796174d357f4b7@%3Cdev.mxnet.apache.org%3E>
>
>
> The community raised the following issues which are not considered as
> release stopper :
>
> 1. NOTICE year is wrong (2018): Not considered a stopping issue as release
> was started in 2018.
>
>
> The source tar ball, including signature, digests etc can be found at :
>
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc3/ <
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc3/>
>
> The tag to be voted upon :
> https://github.com/apache/incubator-mxnet/releases/tag/1.4.0.rc3 <
> https://github.com/apache/incubator-mxnet/releases/tag/1.4.0.rc3>
>
> The release hash is a03d59e
> <
> https://github.com/apache/incubator-mxnet/commit/a03d59ed867ba334d78d61246a1090cd1868f5da
> <
> https://github.com/apache/incubator-mxnet/commit/a03d59ed867ba334d78d61246a1090cd1868f5da>>
> :
>
>
> https://github.com/apache/incubator-mxnet/commit/a03d59ed867ba334d78d61246a1090cd1868f5da
> <
> https://github.com/apache/incubator-mxnet/commit/a03d59ed867ba334d78d61246a1090cd1868f5da
> >
>
> Release artifacts are signed with the following key :
>
> 0812 9523 58B1 2DC3 0536 E7E0 C069 16C3 AB88 ABFE
>
> KEYS file available :
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS <
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS>
>
> The vote will end on Monday, February 25th, 4:00 PM PDT or until the
> sufficient number of votes is reached.
>
> [ ] +1 Release this package as 1.4.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
>
> Thanks,
> Piyush

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2

[Hen]

Did you mean:

"The rat-exclude configuration on the project _must_ be less permissive."

?

(your text suggests it's an option, whereas your vote says it's required)

On Sun, Feb 10, 2019 at 8:08 PM Luciano Resende 
wrote:

> I ran RAT, and while I understand that a lot of the failures are
> coming from the 3rdparty directory, some of those are from files that
> should have the ASF license header such as pom files, docker files,
> project documentation (yes, MD files do accept apache license
> headers),  Maybe the rat-exclude configuration on the project should
> be less permissive.
>
> Based on this I am -1 (binding)
>
> On Wed, Feb 6, 2019 at 1:59 PM Steffen Rochel 
> wrote:
> >
> > Dear community,
> >
> > This is a call for releasing Apache MXNet (incubating) 1.4.0, release
> > candidate 2
> >
> > Apache MXNet (incubating) community has voted and approved the release.
> >
> > Vote thread:
> >
> >
> https://lists.apache.org/thread.html/4b445460d36d098be1c1e60e29869cf243e2bc37bd2b84ca7b1daab3@%3Cdev.mxnet.apache.org%3E
> >
> >
> > Result thread:
> >
> >
> https://lists.apache.org/thread.html/60e3272326cf93100370fa5b01a54a4b2f18f95462553b5a1acfd456@%3Cdev.mxnet.apache.org%3E
> >
> > The community raised the following issues which are not considered as
> > release stopper:
> >
> > 1. NOTICE year is wrong (2018): Not considered a stopping issue as
> release
> > was started in 2018.
> > 2. TVM NOTICE missing - TVM NOTICE file was added post the commit ID used
> > in MXNet v1.4.0.rc2 release, not considered a stopping issue
> > 3. build with make passes, but build with cmake failed in
> > 3rdparty/dmlc-core/test/unittest
> > 4. Recent MKLDNN upgrade prevents us from offering binary distribution
> for
> > earlier versions before OSX 10.13.
> >
> >
> > The source tarball, including signatures, digests, etc. can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc2/
> >
> > The tag to be voted upon:
> > https://github.com/apache/incubator-mxnet/releases/tag/1.4.0.rc2
> >
> > The release hash is e999a46
> > <
> https://github.com/apache/incubator-mxnet/commit/e999a46a8ca1383e78a9178dc65fa91e6e656c26
> >
> > :
> >
> >
> https://github.com/apache/incubator-mxnet/commit/e999a46a8ca1383e78a9178dc65fa91e6e656c26
> >
> > KEYS file available:
> > https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
> >
> > For information about the contents of this release, see:
> >
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.0+Release+Notes
> >
> > The vote will be open at least 72 hours (Sunday February 10th 4pm PST)
> and
> > until sufficient votes are received.
> >
> > [ ] +1 release this package as 1.4.0
> > [ ] +0 no opinion
> > [ ] -1 do not release this package because...
> >
> > Best regards,
> > Steffen
>
>
>
> --
> Luciano Resende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2

[Hen]

+1.

On Wed, Feb 6, 2019 at 1:59 PM Steffen Rochel 
wrote:

> Dear community,
>
> This is a call for releasing Apache MXNet (incubating) 1.4.0, release
> candidate 2
>
> Apache MXNet (incubating) community has voted and approved the release.
>
> Vote thread:
>
>
> https://lists.apache.org/thread.html/4b445460d36d098be1c1e60e29869cf243e2bc37bd2b84ca7b1daab3@%3Cdev.mxnet.apache.org%3E
>
>
> Result thread:
>
>
> https://lists.apache.org/thread.html/60e3272326cf93100370fa5b01a54a4b2f18f95462553b5a1acfd456@%3Cdev.mxnet.apache.org%3E
>
> The community raised the following issues which are not considered as
> release stopper:
>
> 1. NOTICE year is wrong (2018): Not considered a stopping issue as release
> was started in 2018.
> 2. TVM NOTICE missing - TVM NOTICE file was added post the commit ID used
> in MXNet v1.4.0.rc2 release, not considered a stopping issue
> 3. build with make passes, but build with cmake failed in
> 3rdparty/dmlc-core/test/unittest
> 4. Recent MKLDNN upgrade prevents us from offering binary distribution for
> earlier versions before OSX 10.13.
>
>
> The source tarball, including signatures, digests, etc. can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc2/
>
> The tag to be voted upon:
> https://github.com/apache/incubator-mxnet/releases/tag/1.4.0.rc2
>
> The release hash is e999a46
> <
> https://github.com/apache/incubator-mxnet/commit/e999a46a8ca1383e78a9178dc65fa91e6e656c26
> >
> :
>
>
> https://github.com/apache/incubator-mxnet/commit/e999a46a8ca1383e78a9178dc65fa91e6e656c26
>
> KEYS file available:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
>
> For information about the contents of this release, see:
>
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.0+Release+Notes
>
> The vote will be open at least 72 hours (Sunday February 10th 4pm PST) and
> until sufficient votes are received.
>
> [ ] +1 release this package as 1.4.0
> [ ] +0 no opinion
> [ ] -1 do not release this package because...
>
> Best regards,
> Steffen
>

Re: Tying Dockerhub into development and release management

[Hen]

On Thu, Feb 7, 2019 at 4:43 PM Hen  wrote:

>
>
> On Thu, Feb 7, 2019 at 1:49 PM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> > 2. The PPMC should not publish software outside of Apache controlled
>> locations.
>>
>> I’m trying to find where the above has come from as I can find anything
>> in the release or distribution policies. [1] says “It is appropriate to
>> distribute official releases through downstream channels, but inappropriate
>> to distribute unreleased materials through them.”, [4] say this is OK "In
>> all such cases, the binary/bytecode package must have the same version
>> number as the source release and may only add binary/bytecode files that
>> are the result of compiling that version of the source code release.”
>>
>> So everything there  to me is saying it’s OK to distribute versions of
>> release software on platforms like docker and I not sure where the "Apache
>> controlled locations only” restriction has come from.
>>
>
> I'm trying to understand from the thread on legal-discuss on the subject.
> Which frankly I think I'm failing to do.
>
> I see these DockerHub accounts:
>
> https://hub.docker.com/_/httpd   (HTTP Server from Docker?)
> https://hub.docker.com/r/bitnami/apache/  (HTTP Server from Bitnami)
> https://hub.docker.com/u/apache (various images from the ASF)
>
> I assume that "https://hub.docker.com/u/apache; is an Apache controlled
> location, so publishing Apache images from there is fine provided they obey
> our policies (release policy, website policy etc).
>
> On the other hand, Docker and Bitnami do not have to obey our release
> policy for their publishing locations, just our license/trademark-policy.
>
> Assuming the ASF control /apache, which I think believe do, Docker works.
> Though "_/httpd" is confusing as to who that's coming from.
>
> I get more confused in other areas (PyPI, npm) where we don't have a clear
> namespace for acts of the foundation. Is
> https://pypi.org/project/apache-beam/ an act of the PMC or an act of some
> random folk who may or may not overlap with the PMC. It seems it's the
> latter (ie: Pypi packages are not an act of the PMC and therefore don't
> have to obey our release policy, just our license and trademark policy - I
> think that's nuts btw).
>
>
Tried to re-read the thread on legal-discuss and I'm more confused now than
before (though I did note that /u/apache is Apache controlled by Infra).

Ignore me on this thread. I'll take my ignorance off to a special corner
and let it beat me up a bit more.

Hen

Re: Tying Dockerhub into development and release management

[Hen]

On Thu, Feb 7, 2019 at 1:49 PM Justin Mclean 
wrote:

> Hi,
>
> > 2. The PPMC should not publish software outside of Apache controlled
> locations.
>
> I’m trying to find where the above has come from as I can find anything in
> the release or distribution policies. [1] says “It is appropriate to
> distribute official releases through downstream channels, but inappropriate
> to distribute unreleased materials through them.”, [4] say this is OK "In
> all such cases, the binary/bytecode package must have the same version
> number as the source release and may only add binary/bytecode files that
> are the result of compiling that version of the source code release.”
>
> So everything there  to me is saying it’s OK to distribute versions of
> release software on platforms like docker and I not sure where the "Apache
> controlled locations only” restriction has come from.
>

I'm trying to understand from the thread on legal-discuss on the subject.
Which frankly I think I'm failing to do.

I see these DockerHub accounts:

https://hub.docker.com/_/httpd   (HTTP Server from Docker?)
https://hub.docker.com/r/bitnami/apache/  (HTTP Server from Bitnami)
https://hub.docker.com/u/apache (various images from the ASF)

I assume that "https://hub.docker.com/u/apache; is an Apache controlled
location, so publishing Apache images from there is fine provided they obey
our policies (release policy, website policy etc).

On the other hand, Docker and Bitnami do not have to obey our release
policy for their publishing locations, just our license/trademark-policy.

Assuming the ASF control /apache, which I think believe do, Docker works.
Though "_/httpd" is confusing as to who that's coming from.

I get more confused in other areas (PyPI, npm) where we don't have a clear
namespace for acts of the foundation. Is
https://pypi.org/project/apache-beam/ an act of the PMC or an act of some
random folk who may or may not overlap with the PMC. It seems it's the
latter (ie: Pypi packages are not an act of the PMC and therefore don't
have to obey our release policy, just our license and trademark policy - I
think that's nuts btw).

Hen

Re: Tying Dockerhub into development and release management

[Hen]

On Wed, Feb 6, 2019 at 8:34 PM Justin Mclean 
wrote:

> HI,
>
> > 2. The PPMC should not publish software outside of Apache controlled
> > locations.
>
> We have TLP / PMCs doing that already
>
> > 3. Third parties may publish software based on Apache's, but they must
> not
> > cause user confusion (i.e. respect trademarks).
>
> And we have this as well (see docker links).
>
> All a bit of a mess really.
>
> Justin



Agreed :)

I think PMCs are trying to do the right thing for the public and we need to
come up with structure for how PMCs should publish installables on 3p
locations.

Hen

>

Re: Tying Dockerhub into development and release management

[Hen]

On Tue, Feb 5, 2019 at 6:45 AM Roman Shaposhnik 
wrote:

> On Tue, Feb 5, 2019 at 2:48 PM Dave  wrote:
>
> > I totally agree with you that Docker images should be built from official
> > source releases, unless they are clearly marked as unofficial SNAPSHOT
> > releases and intended for testing. I'm just repeating what I've heard
> over
> > and over again from various ASF members that the only official release is
> > the source release; I'd don't agree with that point of view.
> >
> > I'm curious what "built from the official source releases". Does that
> mean
> > that you must create Docker images by downloading the official source
> > release, verifying it's hash and then building image?  Or, are you
> allowed
> > to build your Docker images from the same SCM tag as was used to create
> the
> > source release?
> >
>
> I think an acceptable solution could be:
>* make sure that your :latest tag either points to a Docker scratch
> container
>  or a container that simply prints Incubator disclaimer and exists
>* introduce a tagging scheme for nightly builds (personally I'm quite
> fond
>  of tagging nightly docker builds with SHAs from your git tree from
> which
>  you build the image)
>* introduce :snapshot tag that points at the latest tag from previous
> item
>
> I feel that this could be passable for IPMC.
>
>
I remain confused on this topic.

The legal-discuss thread leads me to think the current state is:

1. The PPMC release some source code. They may release convenience binaries
on the Apache distribution urls, or in Maven Central (via Infra's support),
and those binaries must be built from the release soruce.
2. The PPMC should not publish software outside of Apache controlled
locations.
3. Third parties may publish software based on Apache's, but they must not
cause user confusion (i.e. respect trademarks).
4. The PPMC may link to the software (including binaries) published by a
third party, but they should flag that it does not come from Apache and
should not treat it as the default user experience.

All of which means PPMCs must not use PyPI, NuGet, NPM, DockerHub, etc.
unless Infra actively support a mechanism of doing so (which they
definitely do for Maven).

(Though I'm confused as to whether #2 is a must not, should not, or can if
they wish to)

Hen

Re: Policy for podling committers on graduation

[Hen]

+1 to automatically carried forward which I suspect is how it’s been
handled up to now.

On Sat, Jul 14, 2018 at 4:15 AM sebb  wrote:

> When a podling graduates, all the people listed on the board
> resolution become both PMC members and committers.
>
> What is the policy for podling committers?
>
> Are they all automatically carried forward as committers?
>
> Or does the podling need to specifically need to re-appoint the
> committers that are not mentioned in the graduation resolution?
>
> S.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache MXNet (incubating) 1.2.1 release RC0

[Hen]

+1.

I reviewed the diff between this release and the last.

Hen



On Fri, Jun 22, 2018 at 12:15 PM, Anirudh  wrote:

> Hi all,
>
> This is a call for releasing Apache MXNet (incubating) 1.2.1, release
> candidate RC0.
>
> Apache MXNet (incubating) community has voted and approved the release.
>
> Vote thread:
>
> https://lists.apache.org/thread.html/52a6487bc1389d8865ccc0e42ade49
> edde02c061090389616c8088d5@%3Cdev.mxnet.apache.org%3E
>
> Results thread:
>
> https://lists.apache.org/thread.html/1d833bc94897132590950668eaff7d
> 7e253894e2c274b1223ef733e1@%3Cdev.mxnet.apache.org%3E
>
> The source tarball, including signatures, digests etc. can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.2.1.rc0/
>
> The release tag can be found here:
>
> https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc0
>
> <https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc0>
> The release hash is daa957c9c811b1abd09b98e8fb5ff2c06cad9ad8 and can be
> found here:
>
> https://github.com/apache/incubator-mxnet/commit/
> daa957c9c811b1abd09b98e8fb5ff2c06cad9ad8
>
> Release artifacts are signed with the following key:
>
>
> 0D04 3D0F 92CA 7333 22A8  D131 9067 CC8E AF55 CD6D
>
>
> KEYS file available:
>
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
>
> The vote will end at Tuesday June 26th, 12:15 PDT.
>
> [ ] +1 Release this package as 1.2.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
> Anirudh
>

Re: Committer/PPMC votes

[Hen]

Interesting.

Foundation-wise, all our votes are Majority Voting (new member vote, board
vote (ish), votes by the board themselves, omnibus voting). There's little
expectation/requirement of consensus.

Jakarta/Commons wise new committer votes felt that way (Majority); however
both of those were large PMCs. Disagreement was more likely than on a
smaller PMC so the reality was that we needed Majority instead of
Consensus. The mantra was always "votes on code (technical) had veto,
everything else was majority". But it was also, to your point, a strong
culture to avoid relying on majority-overrule of a veto. Thus new release
votes always felt like Consensus voting even if the rule says Majority
voting.

I think the release voting (
https://www.apache.org/foundation/voting.html#ReleaseVotes ) is similar to
new committer votes. It's Majority Voting, but the Release Manager does
hold a veto. I'd expect a PMC Chair to have a similar role in a new
committer vote. "As Chair I consider the -1 from Alice to be a blocking
veto; we need to discuss more". That doesn't work with Podlings though as
there's no (local) buck-stops-here chair.

It feels like there's an inconsistency between
https://www.apache.org/foundation/voting.html and
https://community.apache.org/newcommitter.html . Either we update
newcommitter.html to explain that it's a Majority vote, but explain how
unusual it should be to see -1 after discussion; or voting.html needs
updating to explain that most (or all?) projects use Consensus voting to
add committers (and presumably PMC members too).

On most projects using consensus voting for committers/pmc; it feels that
it's hard to tell the difference. If there are no -1s, a consensus and
majority vote look the same. :)

Hen




On Thu, Jun 21, 2018 at 5:48 PM, Justin Mclean 
wrote:

>
> Hi,
>
> Way back when each project having a set of bylaws/guidelines was
> fashionable I looked through them and there is some variation but a -1 on a
> committer or PMC member is generally treated as a veto. That being said any
> objections should really come up in the discussion stage (and hopefully
> mitigated) before a vote is called so a -1 vote should be rare. If you look
> at [1] [2] you see that consensus voting allows for a veto (with a reason)
> and AFAIK most projects use consensus approval when adding committers/PMC
> members. It may be some don’t realise this as a -1 has never come up.
>
> Thanks,
> Justin
>
> 1. https://www.apache.org/foundation/voting.html
> 2. https://www.apache.org/foundation/glossary.html#ConsensusApproval
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Committer/PPMC votes

[Hen]

I’m wondering what a -1 means on a committer vote.

https://community.apache.org/newcommitter.html says “and no vetoes”, while
https://www.apache.org/foundation/voting.html does not list a new committer
vote as a “technical” vote.

My assumption is that the rules for voting for an Apache member are the
same as for voting for a PMC member or a committer. Ideally there are no
-1s, but at the end of the day it’s a majority vote.

ie: I think newcommitter.html is buggy.

Thoughts?

Hen

Re: Retiring legacy git repositories from podling?

[Hen]

+1 to a transfer rather than Attic.

On Fri, Jun 15, 2018 at 2:05 AM, Stian Soiland-Reyes 
wrote:

> Hi,
>
> The Taverna podling has its code in multiple git repositories
> https://taverna.incubator.apache.org/code/
> Most of these were imported from the initial Software Grant
>
>
> The Taverna PPMC has voted to retire two legacy git repositories that
> will stay behind when/if we graduate.
>
> > https://github.com/apache/incubator-taverna-plugin-component
> > https://github.com/apache/incubator-taverna-plugin-bioinformatics
>
> VOTE Result:
>
> https://lists.apache.org/thread.html/547b87fa93601d42ef77a778f80bf5
> 9fe9a300fffd7d3a6bcb7a7d81@%3Cdev.taverna.apache.org%3E
>
>
> These code bases have NOT fully completed the IP clearance/license
> checks (there would be a couple of files that have unknown authorship
> or the odd GPL dependency), but have already got the Apache License
> headers for the rest (majority) of the codebase, that was covered by
> the Software Grant.  Would we need to remove/change those headers?
>
> Do the IPMC need to vote on such 'retiring' of a code case?
>
>
> Our plan is to do a GitHub owner transfer to our affiliated
> https://github.com/taverna-extras/ --  but do let me know if you think
> Apache Attic would be better (we could delete the files that miss the
> headers).
>
> Do IPMC think that it's OK that we do such a GitHub transfer
> (effectively giving a HTTP redirect) rather than just
> forking+deleting?
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)

[Hen]

On Mon, May 21, 2018 at 4:22 PM, Ted Dunning <ted.dunn...@gmail.com> wrote:

> On Mon, May 21, 2018, 21:12 Justin Mclean <jus...@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > > Why does this need to be included at all? Why not just provide a
> pointer
> > to
> > > the canonical minified version?
> >
> > Most common occurrence (off the top of my head) is a minified version of
> > bootstrap for project site / documentations. So your view is that that
> > shouldn’t be included in a source release?
> >
>
> Sure. D3 and jQuery will wind up in the same boat.
>
> I would not go so far as to emphatically say not to include them, but I
> don't see the real need to include them given that they are so easily
> downloadable. A URL and a checksum keeps the distro clean.
>

Point to a CDN instead of copying into the distro?

On the one hand, one can argue a CDN is bad if someone wants to read
offline. On the other, I don't like being added to the security update
chain if there is an issue in D3/jQuery/bootstrap etc.

Hen

Re: [VOTE] Retire the Slider podling

[Hen]

+1.

Kudos to the podling for voting for retirement. The JIRA gives hope that
there is user activity, but if the lack of commits and existence of a
technical alternative in Hadoop suggests this is a good decision.

Hen


On Sun, May 20, 2018 at 10:59 AM, Billie Rinaldi <bil...@apache.org> wrote:

> After a long period of low activity, the Slider PPMC has recently decided
> upon retirement [1]. Please vote on whether we should retire the Slider
> podling. Here is my +1 (binding).
>
> [ ] +1 Retire Slider
> [ ] +0 No opinion
> [ ] -1 Do not retire Slider because ...
>
> This vote will remain open for 72 hours.
>
> [1]: https://s.apache.org/V8SB
>

Re: [VOTE] Apache MXNet (incubating) 1.2.0 release RC3

[Hen]

I am only reviewing the "diff -r" between RC2 and RC3.

Confirmed that the DevGuide.md is removed.

There is a fix ( https://github.com/apache/incubator-mxnet/issues/10837 )
to Dockerfiles, and a pom.xml fix adding a parent tag to the scala-package.

These seem fine and rectifies the blocking item in the previous vote.

+1.

Hen


On Tue, May 15, 2018 at 12:16 PM, Anirudh Subramanian <
anirudh2...@apache.org> wrote:

> Hi all,
>
> This is a call for releasing Apache MXNet (incubating) 1.2.0, release
> candidate RC3.
> As suggested by Justin and Henri, we have removed the two category b
> license files: DevGuide.md from the release source tarball.
>
> Apache MXNet (incubating) community has voted and approved the release.
>
> Vote thread:
> https://lists.apache.org/thread.html/fee7800da4b701cb62d6dd7c1b43ef
> d44c94a3a386f3adb48f343d6e@%3Cdev.mxnet.apache.org%3E
>
> Results thread:
> https://lists.apache.org/thread.html/0a43205e47a02a528873e16fe0e578
> 9dfcfebc8a8539f17bbcde2062@%3Cdev.mxnet.apache.org%3E
>
> The source tarball, including signatures, digests etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.2.0.rc3/
>
> The release tag can be found here:
> https://github.com/apache/incubator-mxnet/releases/tag/1.2.0.rc3
>
> <https://github.com/apache/incubator-mxnet/releases/tag/1.2.0.rc3>
> The release hash is 297c64fd2ee404612aa3ecc880b940fb2538039c and can be
> found here:
> https://github.com/apache/incubator-mxnet/commit/
> 297c64fd2ee404612aa3ecc880b940fb2538039c
>
> <https://github.com/apache/incubator-mxnet/commit/
> 297c64fd2ee404612aa3ecc880b940fb2538039c>
> Release artifacts are signed with the following key:
> 0D04 3D0F 92CA 7333 22A8  D131 9067 CC8E AF55 CD6D
>
> KEYS file available:
>
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
>
> For information on the contents of the release see:
>
> https://cwiki.apache.org/confluence/display/MXNET/
> Apache+MXNet+%28incubating%29+1.2.0+Release+Notes
>
> The vote will end at 1:00 PM on Friday, May 18th, PDT.
>
> [ ] +1 Release this package as 1.2.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
>
> Anirudh
>

Re: [VOTE] Apache MXNet (incubating) 1.2.0 release RC2

[Hen]

I'll poke the legal-discuss thread; however why can't we have the build
script for the tar.gz start by removing the .md file?

On Fri, May 11, 2018 at 5:35 PM, Anirudh  wrote:

> Hi Justin,
>
> We cannot just remove the documentation without modifying the original
> repo, since it is a submodule.
> I have opened an issue to googletest to see if it can be relicensed:
> https://github.com/google/googletest/issues/1604
> Is this acceptable for the release?
>
> For issue 1 and 2, is the information being in README and API docs enough
> or do we need to add a
> warning for Creative commons license when script is launched ?
>
> Anirudh
>
>
> On Fri, May 11, 2018 at 5:03 PM, Justin Mclean 
> wrote:
>
> > Hi,
> > My reading of that is the documentation is under a CC license and the
> code
> > under a different one. That's quite common. You could just not include
> the
> > documentation.
> > Thanks,
> > Justin
> >
> > On Sat., 12 May 2018, 9:48 am Anirudh,  wrote:
> >
> > > On Fri, May 11, 2018 at 3:57 PM, Justin Mclean <
> jus...@classsoftware.com
> > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > > For 1 and 2, Considering that the Creative Commons License files
> > aren't
> > > > > part of the release source itself but downloaded when user calls
> some
> > > > > specific api or runs some script, would these be blocking issues ?
> > > >
> > > > No but this need to explicitly pointed out to the user that they are
> > > > downloading something that is not compatable with the ALv2
> > > >
> > >
> > > The information regarding the license is currently added both to the
> > README
> > > of the example for 1, and also on the docs for the API call for 2.
> > > Are you suggesting that some kind of warning be provided during
> download
> > of
> > > these datasets?
> > >
> > >
> > > >
> > > > > For 3, I have added it to known issues and I look forward to any
> > other
> > > > > suggestions you have related to this.
> > > >
> > > > Ask the owner for it to be relicensed under another license?
> > > >
> > >
> > > The link (
> > >
> > > https://github.com/google/googletest/blob/
> ec44c6c1675c25b9827aacd08c0243
> > 3cccde7780/googlemock/docs/DevGuide.md
> > > )
> > > states the following at the bottom :
> > >
> > > "This page is based on the Making GWT Better
> > >  guide from
> the
> > > Google
> > > Web Toolkit  project. Except as
> > > otherwise noted ,
> the
> > > content of this page is licensed under the Creative Commons Attribution
> > 2.5
> > > License ."
> > >
> > > At the top it states the following ::
> > >
> > > "All Google Mock source and pre-built packages are provided under the
> New
> > > BSD License ."
> > >
> > > Since the CC-BY license states "except as otherwise noted", does this
> > mean
> > > that the CC-BY-2.5 license at the bottom is void ?
> > >
> > > > Thanks,
> > > > Justin
> > > > 
> -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Apache MXNet (incubating) 1.2.0 release RC2

[Hen]

+1.

Reviewed diff between 1.1.0 and 1.2.0 source releases for anything unusual.
Sampled new files in 1.2.0 for source headers.
Happy to see the dmlc code folded into 3rd-party so it's clearer for
users/reviewers.

Good patient release-managering btw with all those side-issues on the vote
thread regarding flaky tests/CI fails.

Hen

On Tue, May 8, 2018 at 10:36 AM, Anirudh <anirudh2...@gmail.com> wrote:

> Hi all,
>
> This is a call for releasing Apache MXNet (incubating) 1.2.0, release
> candidate RC2.
>
> Apache MXNet (incubating) community has voted and approved the release.
>
> Vote thread:
> https://lists.apache.org/thread.html/ddc088a21aac179144350ea97353a7
> ea885b2765ccb98db08a03ba2d@%3Cdev.mxnet.apache.org%3E
>
> Results thread:
> https://lists.apache.org/thread.html/4c55ab75f6781e835d4b3e564904a4
> 3680c760e619d741ce00c55962@%3Cdev.mxnet.apache.org%3E
>
> The source tarball, including signatures, digests etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.2.0.rc2/
>
> The release tag can be found here:
> https://github.com/apache/incubator-mxnet/releases/tag/1.2.0.rc2
>
> The release hash is 60641ef1183bb4584c9356e84b6ca6d5fce58d6d and can be
> found here:
> https://github.com/apache/incubator-mxnet/commit/
> 60641ef1183bb4584c9356e84b6ca6d5fce58d6d
>
> Release artifacts are signed with the following key:
> 6E67 8509 715E 3B63 CDB2  234F F8F3 3A11 7CC1 8E95
>
> KEYS file available:
>
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
>
> <https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS>
> For information on the contents of the release see:
>
> https://cwiki.apache.org/confluence/display/MXNET/
> Apache+MXNet+%28incubating%29+1.2.0+Release+Notes
>
> The vote will end at 10:30 AM on Friday, May 11th, PDT.
>
> [ ] +1 Release this package as 1.2.0
> [ ] +0 no opinion
> [ ]  -1 Do not release this package because ...
>
> Anirudh
>

Re: The role of a mentor

[Hen]

I liked Julian's description too.

Yours worries me though - specifically the "but in fact they are reading
every thread, watching every process being developed, thinking through
every decision. Very occasionally (in an ideal world) they are saying
nothing".

My first concern is because that's not in the meaning of mentor. If you
think of someone you view as a mentor, they didn't spend all their time
looking over your shoulder. Instead you met with them from time to time and
discussed a topic that you were looking to find clarity on; and your mentor
successfully helped you find clarity on that. Your description sounds more
like a coach, be it sports coach or another type. Always watching, ideally
doesn't have to nudge, but does when needed. Or Roz from Monster's Inc
"Always Watching". I know there's no reason why the definition of
Incubator Mentor has to equal other concepts of the word, but it helps.

The second concern is on available time. If we assume that all of us are
maxed out in our available time to volunteer for an activity, mentoring a
podling means giving up a substantial existing volunteer activity. In
essence to mentor a podling you have to stop tracking the communication on
another project, which means stopping contributing to another project.
That's a heavy hit and while having coaches (my word) for every podling
would be awesome, I don't see that we have that number of volunteer with
idle cycles waiting to do something.

Which takes us full circle - if what we want are coaches, absent (burnt
out?) mentors are no surprise at all.

Hen

On Tue, Apr 10, 2018 at 9:35 AM, <r...@gardler.org> wrote:

> +1000
>
> I've not been very active in the incubator for some time. I've
> participated in these "role of the mentor" conversations many times over
> the years. I wish I'd been able to make my contribution as clear and
> accurate as Julian's contribution below... (applause)
>
> A good mentor *looks* like they are doing nothing, but in fact they are
> reading every thread, watching every process being developed, thinking
> through every decision. Very occasionally (in an ideal world) they are
> saying nothing.
>
> When they do choose to speak it's because something is happening that is
> in conflict with "the Apache Way". The goal is not to teach the community
> specific and rigid processes, the goal is to teach the community how to use
> the Apache Way to create communities that create software. The precise
> processes will evolve over time in a way that suits the project community.
>
> In most cases, as the podling community matures the mentor will start to
> learn improvements to their own processes. This has certainly been true in
> every single project I've mentored over the years and why I occasionally
> come back and mentor a new project. It's a learning experience, it is NOT a
> teaching experience.
>
> Ross
>
> -Original Message-
> From: Jim Jagielski <j...@jagunet.com>
> Sent: Tuesday, April 10, 2018 7:32 AM
> To: general <general@incubator.apache.org>
> Subject: Re: The role of a mentor
>
> +1
>
> > On Apr 9, 2018, at 12:45 PM, Julian Hyde <jh...@apache.org> wrote:
> >
> > Has anyone here taught someone how to fish? (Or how to make cookies,
> > or ski?)
> >
> > Mostly you just stand off, watching what they do. If you see them
> > about to screw up in a big way, step in. Occasionally, offer them
> > hints for how they might do what they’re doing a little bit better.
> > (Not too often, because they’ll start to resent the advice.)
> >
> > It’s a time-intensive process, and most of the time the person being
> taught thinks you’re doing nothing.
> >
> > Sometimes they ask for help, and very occasionally they ask for guidance
> (but only if you have not given them more unsolicited advice than they
> think they need, see above).
> >
> > Julian
> >
> >
> >> On Apr 9, 2018, at 5:52 AM, Liang Chen <chenliang6...@gmail.com
> <mailto:chenliang6...@gmail.com>> wrote:
> >>
> >> Hi
> >>
> >> +1, agree with JB points.
> >> Mentor mostly just focus on ASF policy and rules, then is ok.
> >> "Teach him how to fish", it is more important, so it would be better
> >> if mentors could provide some good example cases(role model) for them
> >> to learn, tell them how to find the solution from ASF website.
> >>
> >> Regards
> >> Liang
> >>
> >> Jean-Baptiste Onofré wrote
> >>> Hi John,
> >>>
> >>> IMHO, a mentor is not necessary involved in the project
> >>> technics/codebase (it's actually a bonus).
> >>>
> &

Re: [DISCUSS] Absent mentors

[Hen]

On Mon, Apr 2, 2018 at 1:09 AM, Justin Mclean <jus...@classsoftware.com>
wrote:

> Hi,
>
> > Justin's two metrics are interesting to me as I (kinda) don't view either
> > of those as mentor responsibilities.
>
> Interesting how do you projects you mentor get to work out release profile
> and what need to done re license and notice? Or are they simple boiler
> plate license and notice releases and/or already involve ASF people who
> have those skills and know what to look for?
>

I subsequently proviso'd it with: "once a general cadence has been set".


>
> > For me a mentor is: 
>
> For sure it not just helping out with releases, but some of those things
> you mentioned are hard to measure in any real way.
>
> > I'd also have an urge for us to define more specific milestones within
> > incubation, with more expectation on mentor activity for podlings at
> > earlier milestones.
>
> What would those milestones be? One of them I assume would be a podling
> first release and vote on the IPMC?
>

Yeah. Half-arsed guess (and these start to feel more like badges in that
they can be in parallel, but I think there is a typical/ideal order):

* Minimum Infrastructure Setup complete
* All ICLAs signed/IPMC setup
* Licensing Sorted
* First (no major issue) Release Complete
* X% new contributors converted to IPMC
* Graduation delta identified (a thread in which general@ agrees on the
remaining items before graduation)

Tempted to throw in these, though feeling more badge-like:

* Website complete (brand, security note, link to Foundation etc)
* Apache Blogged
* Conference presentation
* Board report complete, no comments/concerns

Hen

Re: apache at bintray

[Hen]

Given there's an asfinfra user there, it seems official. I doubt the infra
team would be involved otherwise :)

Maybe they have instructions on how to interact with the account?

Hen

On Sun, Apr 1, 2018 at 5:27 AM, Jochen Theodorou <blackd...@gmx.org> wrote:

> Hi all,
>
> I was pointed at https://bintray.com/apache. Is that an "official"
> bintray account for apache? Are projects publishing convenience artifacts
> on bintray supposed to use that?
>
> bye Jochen
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Absent mentors

[Hen]

+1 to flagging mentor absence; and I like making it automated otherwise
it's not going to happen (or rather, it'll be up to a podling to flag it
and they're unlikely to feel comfortable doing so).

Justin's two metrics are interesting to me as I (kinda) don't view either
of those as mentor responsibilities.

For me a mentor is:

1) Someone who prods the podling to move along to the next step in its path
in the incubator.
2) Someone who monitors the list for general 'flow'. Is dev happening, does
it seem to be moving along nicely etc.
3) Someone who joins in on exceptional/abnormal threads (ie: when #2 hits
bumps).
4) Someone who deep dives early on in the podlings life to get things
moving.
5) Someone who is reviewing the podling's board report.

For me a mentor is not required to be:

1) Someone who is a coder on the project, or deep in the technology in
question.
2) Someone who votes on how the project chooses to develop, or
3) Someone who votes on the technical choices in the project,
4) Or, someone who is deep diving into release votes once a general cadence
has been set (beyond that need for IPMC +1s).

When a project is ready to graduate, the mentors of the project should be
doing practically nothing with their mentor hat on.

--

Given all that, I would definitely lean towards automated flagging for
mentors when not reviewing the podling's board report.

I'd also have an urge for us to define more specific milestones within
incubation, with more expectation on mentor activity for podlings at
earlier milestones.

Hen


On Sat, Mar 31, 2018 at 4:24 PM, Justin Mclean <jus...@classsoftware.com>
wrote:

> Hi,
>
> > As for the metric -- I really think that using mentor turnout on release
> > voting threads will serve us well.
>
> My concern with using that as a metric is people will just vote +1 without
> doing a thorough check and we may end up with more releases with issues.
>
> Possibly a better metric is how many mentors voted something other than +1
> on a RC, most releases (other than very simple ones) go through a couple of
> RCs before coming to the IPMC.
>
> Another metric is which project releases get a -1 in the IPMC as those
> issue should of been caught by the projects mentors.
>
> Thanks,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: 404 issues

[Hen]

Thanks John. I'll go ask some "I used to know this honest" questions on
HipChat tomorrow :)

On Wed, Mar 7, 2018 at 8:06 AM, John D. Ament <john.d.am...@gmail.com>
wrote:

> Infra would be the best to get these questions asked.
>
> On Wed, Mar 7, 2018 at 9:52 AM Aaron Markham <aaron.s.mark...@gmail.com>
> wrote:
>
> > Ah ok thanks! We will try it out.
> > Regarding log access or reporting on logs, is that available? Would like
> > some more capability on spotting 404s, and doing reverse dns reporting so
> > we can track organization level traffic.
> >
> > Cheers,
> > Aaron
> >
> > On Mar 7, 2018 04:13, "John D. Ament" <johndam...@apache.org> wrote:
> >
> >> .htaccess support should still work.  I would recommend following up
> with
> >> infra if you're seeing something not quite right.
> >>
> >> John
> >>
> >> On Wed, Mar 7, 2018 at 1:54 AM Hen <bay...@apache.org> wrote:
> >>
> >>> Apologies for my rustiness :(
> >>>
> >>> Are we still able to manage a mod_rewrite configuration per project, or
> >>> did
> >>> that go away?
> >>>
> >>> Thanks,
> >>>
> >>> Hen
> >>>
> >>> -- Forwarded message --
> >>> From: Aaron Markham <aaron.s.mark...@gmail.com>
> >>> Date: Mon, Mar 5, 2018 at 3:54 PM
> >>> Subject: 404 issues
> >>> To: d...@mxnet.incubator.apache.org
> >>>
> >>>
> >>> I've been notified by several parties about 404s for files that are
> >>> now longer available on the site.
> >>> https://github.com/apache/incubator-mxnet/issues/9917
> >>>
> >>> This page returns 404:
> >>> https://mxnet.incubator.apache.org/api/python/module.html
> >>>
> >>> It was moved here:
> >>> https://mxnet.incubator.apache.org/api/python/module/module.html
> >>>
> >>> There are many other examples of moved content. Some are temporarily
> >>> "fixed" via adding a meta-refresh tag in the html source for the old
> >>> pages. For example the meta tag is being used to redirect to faq, the
> >>> new location for the how_to docs.
> >>>
> >>> It would seem a better solution for us is to use htaccess files and
> >>> publish persistent redirects for the new location(s) of content.
> >>>
> >>> Do we have a way of pushing a config to the Apache infra to facilitate
> >>> this? I think we'd need config access if we're to put up some custom
> >>> 404 pages too (which would be nicer than what we have now.)
> >>>
> >>> Also, is there a good way to access the log files to get a better idea
> >>> of the 404 situation?
> >>>
> >>> Cheers,
> >>> Aaron
> >>>
> >>
>

Fwd: 404 issues

[Hen]

Apologies for my rustiness :(

Are we still able to manage a mod_rewrite configuration per project, or did
that go away?

Thanks,

Hen

-- Forwarded message --
From: Aaron Markham <aaron.s.mark...@gmail.com>
Date: Mon, Mar 5, 2018 at 3:54 PM
Subject: 404 issues
To: d...@mxnet.incubator.apache.org


I've been notified by several parties about 404s for files that are
now longer available on the site.
https://github.com/apache/incubator-mxnet/issues/9917

This page returns 404:
https://mxnet.incubator.apache.org/api/python/module.html

It was moved here:
https://mxnet.incubator.apache.org/api/python/module/module.html

There are many other examples of moved content. Some are temporarily
"fixed" via adding a meta-refresh tag in the html source for the old
pages. For example the meta tag is being used to redirect to faq, the
new location for the how_to docs.

It would seem a better solution for us is to use htaccess files and
publish persistent redirects for the new location(s) of content.

Do we have a way of pushing a config to the Apache infra to facilitate
this? I think we'd need config access if we're to put up some custom
404 pages too (which would be nicer than what we have now.)

Also, is there a good way to access the log files to get a better idea
of the 404 situation?

Cheers,
Aaron

Re: [VOTE] Apache MXNet (incubating) 1.1.0 release RC1

[Hen]

+1. License change looks good to me.

On Thu, Feb 15, 2018 at 10:28 AM, YiZhi Liu  wrote:

> Just remind that the voting is ongoing. Please help to verify whether
> the release candidate meets the standard and vote accordingly.
>
> 2018-02-13 23:37 GMT-08:00 YiZhi Liu :
> > Hi all,
> >
> > As we have updated the LICENSE file which caused the failure vote for
> > Apache MXNet (incubating) 1.1.0.RC0, this is a call for a releasing
> > Apache MXNet (incubating) 1.1.0, release candidate 1.
> >
> > Apache MXNet (incubating) community has voted and approved the release.
> >
> > Vote thread:
> > https://lists.apache.org/thread.html/500fb648e8629249b904d9fc56e773
> 7c5312dfe54c17d4d5d06468a8@%3Cdev.mxnet.apache.org%3E
> >
> > Result thread:
> > https://lists.apache.org/thread.html/afaf45dda45da60692476c56a268b9
> 5dd0663bb193f8c77ac372631a@%3Cdev.mxnet.apache.org%3E
> >
> > PR which fixes the license:
> > https://github.com/apache/incubator-mxnet/pull/9701
> >
> > The source tarball, including signatures, digests, etc. can be found at:
> > https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.1.0.rc1/
> >
> > The tag to be voted upon is 1.1.0.rc0:
> > https://github.com/apache/incubator-mxnet/releases/tag/1.1.0.rc1
> >
> > The release hash is 07a83a0325a3d782513a04f47d711710972cb144:
> > https://github.com/apache/incubator-mxnet/commit/
> 07a83a0325a3d782513a04f47d711710972cb144
> >
> > Release artifacts are signed with the following key:
> > F42C 1A6E 634C 105E 8D98  5105 CA75 1254 E97B 9FE4
> >
> > KEYS file available:
> > https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
> >
> > For information about the contents of this release, see:
> > https://cwiki.apache.org/confluence/display/MXNET/
> Apache+MXNet+%28incubating%29+1.1.0+Release+Notes
> >
> > The vote will end at 11:35 pm on Friday, Feb 16th, PST.
> >
> > [ ] +1 Release this package as 1.1.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
> >
> > --
> > Yizhi Liu
> > DMLC member
> > Amazon Web Services
> > Vancouver, Canada
>
>
>
> --
> Yizhi Liu
> DMLC member
> Amazon Web Services
> Vancouver, Canada
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache MXNet (incubating) 1.1.0 release RC0

[Hen]

On Mon, Feb 5, 2018 at 2:58 PM, Justin Mclean <jus...@classsoftware.com>
wrote:

> Hi,
>
> > Are there any files apart from these excluded ones where you see missing
> licenses?
>
> You don’t need to exclude files that are under a different licensesI would
> rather see them in the rat report so I know what 3rd party software is
> there. And yes I noticed a couple (which would not be a blocker) for
> instance some zlib licensed code and code under non 2 clause BSD, but
> without 3rd party software listed in LICENSE it’s a little hard to tell
> what has been included or not :-)
>

Still need to move the DMLC code into a dmlc or third-party directory so
it's clearer which files are outside of the project's ability to control.
ie) excluding files because we can't fix without forking seems fine to me.
Unless we just say "The rat report will fail on these directories" and it
doesn't affect a vote, but that seems weak.


>
> > The changes to the top Level LICENSE file was a recommendation from the
> > previous release to make this file easier to maintain. However, I do
> > understand your concern (specially about the BSD license). I can make the
> > required change and put this fix onto the master branch, but do you think
> > this is a blocker for this release?
>
> Yes which is why I've voted -1. Other IPMC members may vote differently.
> <general-h...@incubator.apache.org>
>

Agreed. -1 on my part. The LICENSE file is critical and shouldn't get worse.

Hen

Re: [VOTE] Apache MXNet (incubating) 1.0.0 release RC1

[Hen]

+1.

Items I note should happen post release are:

* Move the various git submodules into third-party/ or similar so it's
simpler to see what is Apache original source when we review a release.
* Deal with the Copyright statements in perl-package (copyright holder has
approved doing this)
* Lots of whitespace on end of NOTICE
* Comment added to CODEOWNERS to explain the file so we don't cause
community problems
* There was a suggestion to simplify the LICENSE to not explicitly list
which packages are under each license. Something to consider.

Hen



On Thu, Nov 30, 2017 at 4:45 PM, Chris Olivier <cjolivie...@apache.org>
wrote:

> Hello All,
>
>
> This is a call for releasing Apache MXNet (incubating) 1.0.0, release
> candidate 1.
>
>
> Apache MXNet community has voted and approved the release.
>
>
> *Vote thread:*
>
> https://lists.apache.org/thread.html/568bf0c9960f14640b753a5fb6766c
> 7b0074339d286f405c04ffec96@%3Cdev.mxnet.apache.org%3E
>
>
> *Result thread:*
>
> https://lists.apache.org/thread.html/558a60f4d0c16b0311c96afd059082
> ebde0f773c56a03cb9e00bc19f@%3Cdev.mxnet.apache.org%3E
>
>
> *The source tarball, including signatures, digests, etc. can be found at:*
>
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.0.0.rc1/
>
>
>
> *The release tag can be found here: *
>
> https://github.com/apache/incubator-mxnet/tree/1.0.0.rc1
>
>
>
> *The release hash is *25720d0e3c29232a37e2650f3ba3a2454f9367bb* and can be
> found here:*
>
> <https://github.com/apache/incubator-mxnet/commit/
> 25720d0e3c29232a37e2650f3ba3a2454f9367bb>
>
>
>
> *Release artifacts are signed with the following key:*
>
> 16DD B2E2 FE0C 3925 CB13  38D7 21F3 F9AB C622 DF82
>
>
>
> *KEY files are available here:*
>
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
>
>
>
> *For information about the contents of this release, see:*
>
> <https://cwiki.apache.org/confluence/display/MXNET/
> Apache+MXNet+%28incubating%29+1.0+Release+Notes>
>
>
>
> The vote will be open for at least 72 hours.
>
>
> [ ] +1 Release this package as 1.0.0
>
> [ ] +0 no opinion
>
> [ ] -1 Do not release this package because...
>
>
> Thanks,
>
>
> -Chris Olivier
>
> cjolivie...@apache.org
>

Re: [VOTE] Apache MXNet (incubating) 1.0.0 release RC0

[Hen]

On Wed, Nov 29, 2017 at 3:18 PM, Justin Mclean <justinmcl...@me.com> wrote:

> Hi,
>
> >> - A number of source file are missing license headers e.g. [15][16] [18]
> >> [19] and many others
> >>
> >
> > Many of these are not Apache MXNet files but from dependencies. I'll
> > suggest on dev@ that these submodules be moved into a third-party/
> > directory.
>
> Having that clearly identified would certainly make the release a lot
> easier to review.
>
> > Why would it be? We only have to include the LICENSE from TVM, we don't
> > need to name them.
>
> In general all bundled software need to be added. [1]
>
> > If TVM want to be identified, they should add a NOTICE file.
>
> Licenses of permissively bundled software go in LICENSE with a few
> exceptions. [2] Apache licensed (v2) doesn't have to me listed [3] but is
> useful to list and you're listing other Apache licensed software in LICENSE
> so it seemed odd to omit it.
>
> Again I suggest you run rat over the release and see if you can fix up
> what it finds. An annotated rat exclusion file would also be a lot of help.
> Just try not to make the exclusions too wide as you may miss something.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
> 2. http://www.apache.org/dev/licensing-howto.html#permissive-deps
> 3. http://www.apache.org/dev/licensing-howto.html#alv2-dep


Fair enough.

My argument would be that it's Apache v2, so its LICENSE is in the MXNet
package already, but if it's out of sorts with other items already being
listed then that's a weak argument :)

Hen

Re: [VOTE] Apache MXNet (incubating) 1.0.0 release RC0

[Hen]

Thanks Justin.

Some comments inline on ones I don't think need fixing; but afaict from
MXNet dev@ activity the plan is to produce a new release and restart the
vote.

On Tue, Nov 28, 2017 at 3:54 PM, Justin Mclean 
wrote:

> Hi,
>
> -1 binding due to license, header issues and having a compiled jar in a
> source release.
>
> I checked:
> - incubating in name
> - signatures and hashes correct
> - DISCLAIMER exists
> - LICENSE has issues (see below) I also note that license issues brought
> up last time have not all been addressed. [22]
> - NOTICE seem rather brief considering the number of Apache licensed
> inclusion do any of them have NOTICE files?
>

We can double check, but I know the ones I've looked at didn't use NOTICE
files (the various dmlc/ projects). Plus as these are GitHub submodules, if
they did the NOTICE would automatically come over.


> - A number of source file are missing license headers e.g. [15][16] [18]
> [19] and many others
>

Many of these are not Apache MXNet files but from dependencies. I'll
suggest on dev@ that these submodules be moved into a third-party/
directory. Given the impact of that to builds etc, I'm hoping that can go
in a subsequent release.



> - A number of source look to have had the ASF header incorrectly added.
> - Binary included in source release [20] Note there’s an unresolved legal
> issue about this [21]
>
> Have you run rat on this release it would of help pick up most of these
> issues?
>
> In this file [1] there’s a copyright notice but it also has an ASF header
> which is a little odd. This also occurs in a number of other places.
>

This came up in the previous release (but the opposite way).

When the code came in from MXNet, it had "Copyright Contributors". We
removed that because 'what a useless statement' :), however as there are
400+ contributors and not everyone has signed a CLA, the previous release
vote asked the project to put it back in again, so they did. It's an
eyesore, but we're a bit stuck unless we're prepared to move away from our
rules of "Never remove or move a Copyright statement without approval" and
"Never edit a copyright statement".

We could (I guess) put a comment above it of "# Original MXNet copyright
statement" or some such.


>
> This file [2] also look to incorrectly have an ASF header and it’s unclear
> how the original code is licensed. From a quick like their seems to be many
> files that incorrectly have ASF headers on them e.g. [5][6][7]
> [10][12][13][14] and others.
>
> This file [3] (and others) looks to come from the TVM project which is not
> mentioned in license.
>

Why would it be? We only have to include the LICENSE from TVM, we don't
need to name them.  If TVM want to be identified, they should add a NOTICE
file.


>
> The license for this file [4] is missing from license.
>
> The link for JQuery [8] is missing from the license. Also missing license
> for these files [9][11][17] and probably others.
>
> At this point I gave up so there may be other issues.
>

Understood. A lot of these are systematic characteristics of the project
rather than flat out issues, but definitely some good finds here too.


>
> It also a good idea to publish your keys:
> gpg: assuming signed data in 'apache-mxnet-src-1.0.0.rc0-in
> cubating.tar.gz'
> gpg: Signature made Sat 25 Nov 07:48:02 2017 AEDT
> gpg:using RSA key 80FD81D7703DF31B
> gpg: requesting key 80FD81D7703DF31B from hkps server
> hkps.pool.sks-keyservers.net
> gpg: Can't check signature: No public key
>
> It’s also a good idea to sign with an apache email address rather than a
> gmail one.
>
> I’m also curious about “CODEOWNERS” file as that doesn’t seem to fit with
> any Apache model I’m aware of.
>

This is a GitHub feature. The name is unfortunate and perhaps we could add
a comment explaining what it is. It allows for automatic addition of
reviewers to a pull request. Kind of like a watch on the code.

The important thing is that a project should never tell a committer they
can't put their name in as a codeowner nee automatic-reviewer.


>
> In “CONTRIBUTORS” there’s a long list of contributors - are their plan to
> make any of these people committers?
>
> Thanks,
> Justin
>
> 1. ./apache-mxnet-src-1.0.0.rc0-incubating/perl-package/AI-MXNe
> t/lib/AI/MXNet.pm
> 2. ./apache-mxnet-src-1.0.0.rc0-incubating/example/image-classi
> fication/predict-cpp/image-classification-predict.cc
> 3. ./apache-mxnet-src-1.0.0.rc0-incubating/nnvm/tvm/src/op/op_util.cc
> 4. ./apache-mxnet-src-1.0.0.rc0-incubating/docs/_static/searcht
> ools_custom.js
> 5. ./apache-mxnet-src-1.0.0.rc0-incubating/src/operator/nn/pool.h
> 6. ./apache-mxnet-src-1.0.0.rc0-incubating/src/operator/contrib
> /nn/deformable_im2col.h
> 7. ./apache-mxnet-src-1.0.0.rc0-incubating/src/operator/contrib
> /psroi_pooling-inl.h
> 8. ./apache-mxnet-src-1.0.0.rc0-incubating/docs/_static/jquery-1.11.1.js
> 9. ./apache-mxnet-src-1.0.0.rc0-incubating/cub/test/mersenne.h
> 10. 

Re: [VOTE] Apache MXNet (incubating) 1.0.0 release RC0

[Hen]

Thank you for the review Sergio :)

On Mon, Nov 27, 2017 at 7:37 PM, Sergio Fernández <wik...@apache.org> wrote:

> Hi,
>
> * Incubator DISCLAIMER included.
> * LICENSE file contains information that should go in the NOTICE.
>

Interested in which you think should be in there. The license file is
pointing to licenses lower in the tree that contain their various items.
One could argue the Copyright for the BSD etc should either be in LICENSE
or NOTICE, but it is in those lower directories.


> * Build worked fine on my desktop (Ubuntu 17.10, GCC 7.2.0).
>
> * I'd put the install instruction somewhere more prominent
> than docs/install/index.md, and probably more CLI-friendly text document.
> Actually I was confused by the very different instruction from
> http://mxnet.apache.org/install/index.html So always take into account
> usability of your source release.
>

This one always bothers me too. I get why there are lots of .md files,
that's how life on GitHub works, but it makes life difficult when reviewing
the source tarball.


> * The KEYS file are not correctly linked in the VOTE email. They weren't
> that hard to find at https://dist.apache.org/repos/dist/dev/incubator/
> mxnet/KEYS, but should be properly linked..
>
> Event thoughmy vote for this RC1 is -1 (binding), because:
>
> * Binary nnvm/tvm/apps/android_rpc/gradle/wrapper/gradle-wrapper.jar is
> distributed without NOTICE.
>

Noting that nnvm is a third party app (though one that some of the MXNet
committers work on). Perhaps a bug report/patch could be submitted there.

However, the gradle wrapper is under Apache 2.0, and does not have a NOTICE
file (uppercase NOTICE). NNVM has an Apache 2.0 license in its root. It's
not as user friendly as it could be, but I believe it is being distributed
with license notice (lower case notice), which is all the license requires.

(While Gradle does have additional licensing in their LICENSE file, I don't
see any of that in the gradle-wrapper.jar).


> * Files' header contain, after the normative ASF license header, confusing
> copyright information that should be cleaned to avoid confusions.
>

If you mean:

 *  Copyright (c) 2017 by Contributors

Then that was reintroduced by specific request of a previous Incubator
vote/Incubator PMC feedback. Not all the code is covered by a CLA/grant (I
counted 400 contributors), so the original Copyright statement is
maintained (the enormously ugly 'Copyright Contributors').

Thanks,

Hen

Re: [VOTE] Apache MXNet (incubating) 0.12.1 release RC0

[Hen]

Sorry for my slowness.

+1 from me.

On Sun, Nov 12, 2017 at 12:51 AM, Sebastian  wrote:

> +1 binding
>
>
> On 11.11.2017 07:44, Suneel Marthi wrote:
>
>> +1 binding
>>
>> On Sat, Nov 11, 2017 at 4:07 AM, Meghna Baijal <
>> meghnabaijal2...@gmail.com>
>> wrote:
>>
>> Hello All,
>>>
>>>
>>> This is a call for releasing Apache MXNet (incubating) 0.12.1, release
>>> candidate 0.
>>>
>>>
>>> Apache MXNet community has voted and approved the release.
>>>
>>>
>>> *Vote thread:*
>>>
>>> https://lists.apache.org/thread.html/254d533bf9b2df9ac2de960ba6303d
>>> 89d5d39a783573b4c6e47e4e08@%3Cdev.mxnet.apache.org%3E
>>>
>>>
>>> *Result thread:*
>>>
>>> https://lists.apache.org/thread.html/2027f372ebff981ea2e585f6215d8a
>>> 6a844058e7628a1f16ebd351c9@%3Cdev.mxnet.apache.org%3E
>>>
>>>
>>> *The source tarball, including signatures, digests, etc. can be found
>>> at:*
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.1.rc0/
>>>
>>>
>>>
>>> *The release tag can be found here: *
>>>
>>> https://github.com/apache/incubator-mxnet/tree/0.12.1.rc0
>>>
>>>
>>>
>>> *The release hash is *e0c7906693f0c79b0ce34a4d777c26a6bf1903c1* and can
>>> be
>>> found here:*
>>>
>>> https://github.com/apache/incubator-mxnet/commit/
>>> e0c7906693f0c79b0ce34a4d777c26a6bf1903c1
>>>
>>>
>>>
>>> *Release artifacts are signed with the following key:*
>>>
>>> 69FF E8D6 1051 FFE7 E61B 02C2 80FD 81D7 703D F31B
>>>
>>>
>>>
>>> *KEY files are available here:*
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.1.rc0/
>>>
>>>
>>>
>>> *For information about the contents of this release, see:*
>>>
>>> https://cwiki.apache.org/confluence/display/MXNET/
>>> MXNet+0.12.1+Release+Notes
>>>
>>>
>>>
>>> The vote will be open for at least 72 hours.
>>>
>>>
>>> [ ] +1 Release this package as 0.12.1
>>>
>>> [ ] +0 no opinion
>>>
>>> [ ] -1 Do not release this package because...
>>>
>>>
>>> Thanks,
>>>
>>> Meghna Baijal
>>>
>>>
>>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Update README for retired podlings?

[Hen]

On Fri, Nov 3, 2017 at 4:29 AM, Shane Curcuru <a...@shanecurcuru.org> wrote:

> Dave Fisher wrote on 11/2/17 11:13 PM:
> >> On Nov 2, 2017, at 7:06 PM, John D. Ament <johndam...@apache.org>
> wrote:
> >>> On Thu, Nov 2, 2017 at 6:17 PM Dave Fisher <dave2w...@comcast.net>
> wrote:
> >>>>> On Nov 2, 2017, at 3:08 PM, sebb <seb...@gmail.com> wrote:
>
> >>>>> On 2 November 2017 at 21:07, Dave Fisher <dave2w...@comcast.net>
> wrote:
> ...snip...
> >> I'm not even sure I agree with deleting the websites.  It was a project.
> >> Now it's not.  That doesn't mean the information should no longer be
> >> available.  But not sure the resources need to be covered.
> >
> > Either the IPMC should review the policy or we should ask the board to
> set/confirm the policy for “retired” podlings.
>
> Podlings in incubation are not Apache projects - by definition.  They
> are podlings effectively managed within the incubator.  So it would be
> best for the IPMC to come up with a specific policy or plan for this,
> vote on it, and then just let the board know "Hey, here's how we're
> going to formally handle retiring podling assets".
>
> Personally, I think it depends on how long the podling was around (i.e.
> how many likely other people were attempting to use the project) and
> what the state of it's IP clearance is.  In particular, if IP clearance
> weren't complete, I would vote for deleting the repos, just to ensure
> that we're not distributing (even via source control) IP that the ASF
> isn't assured of having under our license.
>
>
I'd argue that being under our license is not important.

If we have code in our source control that can't be distributed, it should
be deleted (regardless of project). If we have a retired Incubator podling
with code that didn't get sufficiently relicensed from another open source
license, no big deal (provided that's clear).

My vote (unsurprisingly) would be for treating a retired podling the same
way a retired project is treated.

Hen

Re: PPMC voting new committers

[Hen]

Scratching my head as I assumed it was a normal non-tech vote conducted on
the PPMC private list, majority wins, must be at least 3 votes. The one
'additional' rule I assumed was that the same must be true of PMC members
voting; effectively the PPMC vote needs to include 3 mentor +1s. If a vote
concludes with less than 3 PMC votes, it goes to the Incubator PMC private
list to fill in the necessary votes. As the project moves closer to
graduation, those mentor votes become more and more whackamole.

Guessing I'm out of date :) I didn't know we had PMCs that were adding
people via lazy consensus.

Hen


On Fri, Nov 3, 2017 at 10:34 AM, Craig Russell <apache@gmail.com> wrote:

> I'd like to see a change in incubator policy w.r.t. voting new committers.
>
> While there are no Foundation policies on how to vote new committers, we
> do have best practices documented in http://community.apache.org/
> newcommitter.html that explicitly calls for consensus approval of at
> least three positive votes and no vetoes.
>
> Applying this to the incubator, it makes sense to me to change the
> incubator policy to require a vote (no lazy consensus) and at least three
> PPMC votes in favor. I'd also add a requirement for at least one Mentor
> vote in favor.
>
> After graduation, communities might feel that they know better and can
> adopt bylaws that are different from the community best practices. But
> while in incubation I think that we should enforce best practice.
>
> Craig
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache MXNet (incubating) 0.12.0 release RC0

[Hen]

+1.

Noting that Suneel was +1 in the original thread (ie: you have 3
mentor/Incubator-PMC  +1s).

Hen

On Tue, Oct 24, 2017 at 11:06 PM, Sebastian <ssc.o...@googlemail.com> wrote:

> +1 (binding)
>
> Successfully built and validated the RC from source.
>
> Best,
> Sebastian
>
>
> On 25.10.2017 03:38, Meghna Baijal wrote:
>
>> Hello All,
>>
>> This is a call for releasing Apache MXNet (incubating) 0.12.0, release
>> candidate 0.
>>
>> Apache MXNet community has voted and approved the release.
>>
>> *Vote thread:*
>> https://lists.apache.org/thread.html/800402860be8a1b4055ede0
>> 75ab465af48b7f8d041b42217372a63b9@%3Cdev.mxnet.apache.org%3E
>>
>> *Result thread:*
>> https://lists.apache.org/thread.html/83ab3763f0bb84685112692
>> 66bf0c26bdc786509d2cb38a2aafe30a3@%3Cdev.mxnet.apache.org%3E
>>
>>
>> *The source tarball, including signatures, digests, etc. can be found at:*
>> https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.0.rc0/
>>
>>
>> *The release tag can be found here: *
>> https://github.com/apache/incubator-mxnet/tree/0.12.0.rc0
>>
>>
>> *The release hash is 4f2af2d2e5216ab3a1faadcc117709b6836029dc and can be
>> found here:*
>> https://github.com/apache/incubator-mxnet/commit/4f2af2d2e52
>> 16ab3a1faadcc117709b6836029dc
>>
>>
>> *Release artifacts are signed with the following key:*
>> 69FF E8D6 1051 FFE7 E61B 02C2 80FD 81D7 703D F31B
>>
>>
>> *KEY files are available here:*
>> https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.0.rc0/
>>
>>
>> *For information about the contents of this release, see:*
>> https://cwiki.apache.org/confluence/display/MXNET/MXNet+0.
>> 12.0+Release+Notes
>>
>>
>> The vote will be open for at least 72 hours.
>>
>> [ ] +1 Release this package as 0.12.0
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because...
>>
>> Thanks,
>> Meghna Baijal
>>
>>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [LAZY] Letting anyone invite on Slack

[Hen]

Done. Anyone on TheAsf slack workspace can invite someone to the workspace.

On Sat, Oct 14, 2017 at 03:28 Greg Stein <gst...@gmail.com> wrote:

> Fair enough... then open it up. Not even sure why that's a question :-)
>
> On Sat, Oct 14, 2017 at 1:52 AM, Hen <bay...@apache.org> wrote:
>
> > While I lean to the 'not seeing the value of Slack', we have many
> channels
> > on Slack now (mostly driven by Incubator projects I think; John seems to
> > have taken the lead on the workspace), so this isn't a thread for getting
> > rid of slack :)
> >
> > Hen
> >
> > On Fri, Oct 13, 2017 at 11:06 PM, Craig Russell <apache@gmail.com>
> > wrote:
> >
> > > Hi Henri,
> > >
> > > We tried to use slack with the Juneau project and never got it to work
> > > "the Apache Way". Inviting people instead of self-service, no ability
> to
> > > monitor discussions, no archive of discussions.
> > >
> > > We gave up and now use the wiki whenever mail doesn't serve. Common
> > > editing of documents, diagrams, etc. are all easily done on confluence
> > > where email doesn't allow sharing documents.
> > >
> > > I frankly do not see slack filling a need here.
> > >
> > > Craig
> > >
> > > > On Oct 13, 2017, at 9:51 PM, Henri Yandell <bay...@apache.org>
> wrote:
> > > >
> > > > Currently only 'admins' can invite people to the ASF Slack:
> > > >
> > > >  https://the-asf.slack.com/
> > > >
> > > > If we view it as an IRC equivalent, having to invite people at all is
> > > > weird. We can, via a checkbox, change it so anyone on the ASF Slack
> > > (except
> > > > 'guests') can invite someone to the Slack workspace:
> > > >
> > > > 
> > > >
> > > > Invitations
> > > >
> > > > Choose whether to allow non-admins to invite new people to *ASF*.
> > > >
> > > > Allow everyone (except guests) to invite new members.
> > > > 
> > > >
> > > > I can't see why we'd have an issue there, so I'm planning to turn
> that
> > > > checkbox on at the end of next week (Thursday or whenever I remember
> to
> > > > after that :) ).
> > > >
> > > > If this is a bad idea, please object and let me know why :)
> > > >
> > > > Hen
> > >
> > > Craig L Russell
> > > c...@apache.org
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>

Re: [LAZY] Letting anyone invite on Slack

[Hen]

While I lean to the 'not seeing the value of Slack', we have many channels
on Slack now (mostly driven by Incubator projects I think; John seems to
have taken the lead on the workspace), so this isn't a thread for getting
rid of slack :)

Hen

On Fri, Oct 13, 2017 at 11:06 PM, Craig Russell <apache@gmail.com>
wrote:

> Hi Henri,
>
> We tried to use slack with the Juneau project and never got it to work
> "the Apache Way". Inviting people instead of self-service, no ability to
> monitor discussions, no archive of discussions.
>
> We gave up and now use the wiki whenever mail doesn't serve. Common
> editing of documents, diagrams, etc. are all easily done on confluence
> where email doesn't allow sharing documents.
>
> I frankly do not see slack filling a need here.
>
> Craig
>
> > On Oct 13, 2017, at 9:51 PM, Henri Yandell <bay...@apache.org> wrote:
> >
> > Currently only 'admins' can invite people to the ASF Slack:
> >
> >  https://the-asf.slack.com/
> >
> > If we view it as an IRC equivalent, having to invite people at all is
> > weird. We can, via a checkbox, change it so anyone on the ASF Slack
> (except
> > 'guests') can invite someone to the Slack workspace:
> >
> > 
> >
> > Invitations
> >
> > Choose whether to allow non-admins to invite new people to *ASF*.
> >
> > Allow everyone (except guests) to invite new members.
> > 
> >
> > I can't see why we'd have an issue there, so I'm planning to turn that
> > checkbox on at the end of next week (Thursday or whenever I remember to
> > after that :) ).
> >
> > If this is a bad idea, please object and let me know why :)
> >
> > Hen
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>