Hi Justin, Given today’s discussion regarding ShardingSphere and how pre-Apache releases came in I think we have everything available for the Mentors to deal with any issues with ECharts.
I respectfully request that you edit the following to make it less alarming and remove any implication that the IPMC cannot handle our duties. Three of the project Doris, Pinot and Sharding Sphere responded quickly and removed the releases. SDAP is addressing the issue. ECharts is a little reluctant to remove the releases due to the high use and popularity of the project and is trying to find another way of resolving the situation. The board may need to be involved. ECharts has a huge number of pre-Apache releases I have provided guidance today. ECharts latest attempt to release is in limbo in the VOTE thread on general@ - a discussion moved to legal-discuss which should have answered your concerns, but it is in limbo … Regards, Dave > On Feb 7, 2019, at 12:38 AM, Justin Mclean <jus...@classsoftware.com> wrote: > > Sorry I meant to send this to the list but only Dave got it. > >> Begin forwarded message: >> >> From: Justin Mclean <jus...@classsoftware.com> >> Subject: Re: Draft incubator report >> Date: 6 February 2019 at 8:48:46 am AEDT >> To: Dave Fisher <dave2w...@comcast.net> >> >> Hi, >> >>> Yes, that is better, but here is the next challenge. For distribution >>> channels like Maven, NPM, etc which some projects use to stage prospective >>> releases how do we recommend that projects stay within the available, but >>> not advertised rule? I think somewhere some guidance is needed. >> >> When this was dicusssed (see [1]) it was stated: >> "There are an unbounded number of such downstream channels, and there is no >> way we are going to formulate specific policies for all of them.” >> >> But it’s really not that hard and is covered by existing policy. [2][3] >> >> But some examples may help: >> - With GitHub I would not expect any releases that appear on the release >> page (https://github.com/apache/<apache project>/releases) to contain >> unreleased code or be compiled from such code. Only releases compiled from >> official approved source releases should be listed. >> - With npm if I go "npm install <apache project>” I only expect to get the >> latest official release based on an approved offical source release. To get >> a RC or nightly I’d need to "npm install <apache project>@sometag” >> - With docker hub, if I go "docker pull <apache project>” I’d only expect to >> get the latest official approved version and not contain any unapproved >> code. I’s expect RCs to be tagged in some way and nightly with their commit >> hash or something similar. >> - For PiPy I expect "pip install <apache project>” to install the lasted >> official approved release and no contain any unapproved code. And I not >> expect to see any releases on the release history page >> (https://pypi.org/project/<apache project>/#history) to contain unapproved >> code. >> >> I think with most platforms you can work out what to do so that you are not >> advising nightlys or release candidates to the general public. >> >> And of course your ASF project site shouldn't include any links to >> unapproved releases as mentioned in [2] "Do not include any links on the >> project website that might encourage non-developers to download and use >> nightly builds, snapshots, release candidates, or any other similar >> package”. Note it also says "If you find that the general public are >> downloading such test packages, then remove them.” so care still needs to be >> taken. >> >> Thanks, >> Justin >> >> 1. https://issues.apache.org/jira/browse/LEGAL-270 >> 2. http://www.apache.org/legal/release-policy.html#what >> 3. http://www.apache.org/legal/release-policy.html#release-types >
