Re: assimilation of mshadow into the MXNet codebase
Hi, > Here's the second update. At the moment we are only missing ICLAs from 20 > (out of 70) contributors, accounting for 31 (out of 913) commits left. IMO That's still a significant number of commits and people. > Regarding whether the contributors are employed by a company that requires > CCLA for contribution, I have no way of verifying the contributors' > employment status at the time of contribution, and not enough bandwidth to > verify the individual company policies on such contribution. As such, I will > solely rely on the ICLAs. The risk is that the IPMC may require more than that, I can’t predict how other IPMC members will vote in this case. Intel have supplied CCLAs in the past and there are people on that list not covered by a CCLA could be a concern along with the missing ICLAs. Thanks, Justin
Re: assimilation of mshadow into the MXNet codebase
Hi, In the case of Intel and other companies, it may be that their employee contracts do not allow employees to contribute to OS projects. It more likely that the contributor doesn’t own copyright of the code but their employer does. A CCLA give a clear indication that the contributors are intact allowed to contrive code and own the copyright of their contributions. We have CCLAs from Intel on file from other contributions so it would seem that Intel requires this. Thanks, Justin
Distribution of release candidates
Hi, I asked on the incubator vote but didn't get a reply. Can the PPMC please explain why release candidates are being released in this way, in particular by companies who employee MXnet PPMC members. What steps will the PPMC will take to stop this from happening in the future? Thanks, Justin
Re: assimilation of mshadow into the MXNet codebase
Hi, > Several peoples in below list are from Intel and I have added them into CC. Has Intel signed a CCLA? And if so does it list people who are allowed to contribute to this project? Are there any others on that list who employer’s may need to also sign CCLAs if we don’t have them? Thanks, Justin
Re: assimilation of mshadow into the MXNet codebase
Hi, > Thanks for clarifying. All contributors who made more than 10 commits to > msahdow before are committers of MXNet, so their ICLAs should already be on > file: tqchen, bingxu, eric.xie, sxjscience, mli, yajiedesign [1]. If you > think this is OK, one of the mentors or I can start the notification. What about the other 60 contributors? More than 10 commits is not a line I would feel comfortable with. You need to be able to account for the IP provenance of every line of code, just like in your initial code donation. It would probably be best to make a list all contributors and if they have an ICLA or not. Did the mshadow project use ICLAs? If so that may also help. Thanks, Justin
Re: assimilation of mshadow into the MXNet codebase
Hi, > Thank you, Justin. Though I’m still uncertain about what the definition of IP > clearance process is. The bit you quoted there is for an initial code base, it the second part of that document you need to look at. In short as well as the SGA you need to get signed ICLA from all of the contributors to the code base. It might be OK to just get the major ones depending on the type of contributions. You then need to notify the incubator of the IP clearance and see if they have any questions about it. Here’s an example: https://lists.apache.org/thread.html/r750880f7295c1a8c31c99e7a40f3466c177bd714254d0c98a506dede%40%3Cgeneral.incubator.apache.org%3E Thanks, Justin
Re: assimilation of mshadow into the MXNet codebase
Hi, See also: https://incubator.apache.org/guides/ip_clearance.html Thanks, Justin
Re: assimilation of mshadow into the MXNet codebase
HI, > Yes and yes. I filed the software grant and received confirmation from > secretary@. As well as the software grant the incline code base needs to go through IP clearance. See [1] option 2. IP clearance involves making sure all all contributors have signed ICLAs and there are no license or other IP issues and getting IP clearance from the incubator. [2] Thanks, Justin 1. https://www.apache.org/foundation/how-it-works/legal.html#incoming-code 2. https://incubator.apache.org/ip-clearance/
Re: assimilation of mshadow into the MXNet codebase
Hi, Has the IP clearance process been followed? I don't see it listed on this page [1] Does the current release being voted on contain this code? Thanks, Justin 1. https://incubator.apache.org/ip-clearance/
ApacheCon @Home 2020 call for papers closes in 2 days!
Hi, Only a couple of days to go before to call for papers closes for ApacheCon @Home 2020 on Monday. The Incubator will be running a track at this online conference, so if you're thinking of submitting something, please don't delay. We'll accept talks on the Apache incubator itself, and talks about projects in Incubator. If you have recently graduated (or may do shortly), you are still welcome to submit a talk. You can submit your talks here: https://acna2020.jamhosted.net/cfp.html And register to attend the conference here: https://hopin.to/events/apachecon-home So far (with a couple of months to go) more than 900 people have signed up for the conference. Thanks, Justin
Re: Update on non-compliant releases on repository.apache.org and how to obtain a compliant build
Hi, > On the question of building compliant CPU convenience binaries that can be > distributed under the name MXNet, ASF now agrees that the previous stance of > "libgfortran.so" is GPL and can't be distributed is incorrect based on the GCC > Runtime Library Exception [4]. I would wait until that legal JIRA is closed before assuming this is the case. I think you may of misinterpreted what Roman was saying. The currently policy is GPL with exceptions are are not allowed, either in a release or as a dependancy. [1] Thanks, Justin 1. https://www.apache.org/legal/resolved.html#category-x
Re: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: [MENTORS] PPMC case-by-case decision for major modifications of third-party work guidance
Hi, I also add that converting from one language to another is not considered a major modification. Thanks, Justin
Re: Issue with releases / feedback from ASF board
Hi,
> this page currently contains some links to third-party binary distributions of
> MXNet (for example at [1]). The question of what the PPMC should recommend
> those
> third-parties to avoid trademarking issues is currently being discussed on
> private@ and trademark@.
It’s quite clear they should not be linked to from an Apache page like this as
users will think these are Apache releases. Please remove them, after that
bring it up on the incubator general list and we can discuss what needs to be
done.
> Also I notice you referred to the Github Release page. Github will
> automatically
> provide a ZIP folder ("Source code (zip)") for the commit tagged as release.
> PPMC has further uploaded the ASF .tar.gz, .tar.gz.asc and .tar.gz.sha512. Is
> that what you mean with confusing mix of "Apache and non-Apache releases”?
You need to mark anything that is not an Apache release very clearly and if
that cannot be done them it needs to be removed.
Thanks,
Justin
Re: Issue with releases / feedback from ASF board
Hi, I don't see what has been done about this [1] which I mentioned above. What is the planned action here? Thanks, Justin 1. https://mxnet.apache.org/get_started?
Re: Issue with releases / feedback from ASF board
Hi, > - MXNet publishes only nightly pre-release builds to dist.mxnet.io for the > verification purpose for projects in the ecosystem and for developers who > work on the bleeding edge. IMO Something more needs to be done here, at the very least I would expect to se a very large disclaimer that these are not releases for use of the general public and for internal development use only and are not Apache Releases. A google search brings up that page and it is incorrectly titled "Apache MXNet Python Binary Distribution”. I see other download pages that just contain links and no information to what the files are. It also needs to be clear what a user is installed from this install page [1] which I assume is using the above? The GitHub download page [2] is also confusing as it contains a mix of Apache and non-Apache releases. > - PyPI releases are not the act of this PPMC, but are from individuals > acting as third-party for the convenience of the community. Currently this page isn’t in line with Apache trademark policy. > With my PPMC hat on, we will take the following actions: > > - We will try to take down problematic Maven releases immediately and > discuss in the community how to proceed with future Maven releases. Thanks for that. > - We will introduce source releases on PyPI and Maven using apache-mxnet > name to provide users with the option to have Apache distribution and allow > users to compile CUDA/cuDNN code as an option. I assume that mean you will two distribution on PyPI? Or is the intent to remove the other one? > Finally, we appreciate any lesson other projects can share on licensing and > distribution that involves CUDA code. Thanks. I’m not aware of any other project that uses CUDU code. Thanks, Justin 1. https://mxnet.apache.org/get_started/? 2. https://github.com/apache/incubator-mxnet/releases
Issue with releases / feedback from ASF board
Hi, The incubator report had the following feedback: Incubator needs to address the software distribution issues regarding MXNet (not reporting this month). The PPMC is effectively bypassing our software release policies by creating distribution packages that are combined with non-open-source platform libraries and publishing them on dist.mxnet.io, where they are picked up and distributed using the PyPi channel to all Python users. The resulting pages on PyPi mislead users into thinking they are installing an Apache License 2.0 package even though it contains software that we are not allowed to distribute under our license. https://issues.apache.org/jira/browse/LEGAL-515 https://dist.mxnet.io/python/cu102 https://pypi.org/project/mxnet-cu102/ I can see you have been discussing this here [1] so some progress has been made. It would be a good idea to keep the Incubator PMC in the loop on what actions the PMC is going to take to resolve this. Thanks, Justin 1. https://s.apache.org/5102c
Fwd: [RESTARTING][VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2
forgot to CC dev > Begin forwarded message: > > From: Justin Mclean > Subject: Re: [RESTARTING][VOTE] Release Apache MXNet (incubating) version > 1.4.0.rc2 > Date: 13 February 2019 at 6:43:48 pm AEDT > To: Michael Wall > > Hi, > >> Option 1: >> Do nothing. I don't know how a RESTARTED vote works. > > I don’t believe there is such a concept. > >> Option 2: >> Start another vote thread on general@incubator.a.o pointing to the original >> vote thread on dev@mxnet.a.o and the canceled vote thread. > > It may end up with the same outcome. > >> Option 3: >> 1 - Fix the header issues. > >> 3 - Start a vote thread on general@incubator.a.o pointing to the new vote >> thread from step 2. Will likely need to be open 72 hours. > > Just be aware it can take longer, sometime much longer, to get the 3 +1 IPMC > votes. > >> Tough position to be in with Horovod being released. > > Which show the risk of tying in your release cycle with a non Apache product. > IMO you need to be independent of 3rd party releases and not tied to their > milestones. If they wanted to include a particular unreleased version of ASF > software, you should started the release a long time ahead of time just in > case problems were encountered issues.This probably wouldn't be an issue if > you made more frequent releases, it’s easier to check compliance with > frequent releases so the 3rd party could just take the last good release and > go with that. > > Thanks, > Justin
Re: Julia Package Release Process
Hi, > 1) Reuse the old repo: https://github.com/dmlc/MXNet.jl > It's under DMLC. I have the committer bit of this repo. I'm not 100% sure that would be allowed from a branding/trademark perspective, any distribution owned by a 3rd party can't be called "Apache MXNet". > 2) A new repo under ASF's organization? That seems preferable I think. Thanks, Justin
Re: Julia Package Release Process
Hi, > I know there are some conditions under which Apache can distribute releases > downstream. Short version it's fine to distribute packages that consist of voted on ASF releases, but you are not allowed to create and distribute packages that contain un-released code. See also [1] Thanks, Justin 1. https://issues.apache.org/jira/browse/LEGAL-427
Re: Incubator Podling Report (Due 2nd January)
Hi, The report is due today. [1] If you cannot report this month, it will eb noted in teh board report and you'll be asked to report next month. Thanks, Justin 1. https://wiki.apache.org/incubator/January2019
Incubator Podling Report (Due 2nd January)
Hi, The incubator PMC would appreciated if you could complete the podling report on time it's due on 2nd January in a few days. It takes time to prepare the incubator report, have your mentors sign off the report and for the board to review it, so it's best if you can get it in early. Thanks, Justin
Re: MXNet Podling Report - October
Hi, I noticed you have edited the report after the due date and have broken the formatting a little after I formatted it. Each line must have a maximum of 76 characters, would you mind fixing your section of the report? Thanks, Justin
Re: ICLA?
Hi, Sorry if I'm mistaken (possible as I've not followed your project closely) but to me this sounds like more part of the initial IP Clearance process. Podlings can't make a release until that has been completed. [1] Thanks, Justin P.S please CC on any replies as I'm not subscribed to this list. 1. https://incubator.apache.org/guides/ip_clearance.html#establishing_provenance
