incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Draft incubator report
Date Thu, 07 Feb 2019 23:20:51 GMT
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 <justin@classsoftware.com> wrote:
> 
> Sorry I meant to send this to the list but only Dave got it.
> 
>> Begin forwarded message:
>> 
>> From: Justin Mclean <justin@classsoftware.com>
>> Subject: Re: Draft incubator report
>> Date: 6 February 2019 at 8:48:46 am AEDT
>> To: Dave Fisher <dave2wave@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
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message