[DISCUSS] Guidelines for distribution of incubating artefacts on other platforms

[Justin Mclean]

Hi,

Feedback welcome. If you think anything here is not in line with the ASF 
release and distribution policy please speak up. Currently it’s not clear to me 
if RCs, snapshots or nightlys would be allowed on these platforms so some 
changes may need to be made.

If you want to add another platform please do so, but these are one we’ve 
recently had issues with that I’m aware of.

Currently not many projects would be complying with this, for instance most 
likely missing the incubator disclaimer, which I think is importtant.

Does the IPMC think we need to have a vote on approving this?

I've added a harsh non-compliance to hopefully smart how important this is and 
to reduce the risk to the ASF. If you think it is too harsh or not needed speak 
up.

--
Guidelines to help you comply with the ASF release and distribution policies

In addition to the Apache mirror system incubating projects may distribute 
artefacts on other platforms as long as they follow these general guidelines:
- Unofficial releases need to be made from approved voted on approved ASF 
releases.
- An incubating disclaimer must be clearly be displayed where the artefacts are 
made available.
- Release candidates, nightlys and snapshots must not be advertised to the 
general public.
- Apache project branding and naming needs to be respected.
- It should be clear that the artefact in under the ALv2 license.
- Where possible these artefacts should not be referred to as releases.

If any podling is found not to comply they will be asked to fix it, if a fix 
doesn’t happen with a week they will be asked to remove the offending 
artefact(s), if a podling commits serial offences or fails to remove artefacts 
when asked to within a week they will be banned from using that distribution 
mechanism altogether.

GitHub

Artifacts show up on https://github.com/apache/incubator-/releases

To comply with ASF release and distributions please ensue the following:
- Any releases need to include the text of the incubation disclaimer.
- The release page must not contain release candidates, nightly or snapshots 
releases.
- Any releases that exist before coming into incubation need to be clearly 
described and tagged as such on 
https://github.com/apache/incubator-/tags.
- Release candidates, nightly or snapshots releases can be tagged and appear on 
https://github.com/apache/incubator-/tags.

Docker

Artefacts need to be placed in https://hub.docker.com/r/apache/ or 
https://hub.docker.com/u/apache/

To comply with ASF release and distributions please ensue the following:
- The overview should include the incubator disclaimer.
- The docker file should include an ASF header.
- The docker file should include the incubator disclaimer.
- "docker pull apache/" should not install an artefact containing 
unapproved code.
- Release candidates, nightly or snapshots need to be clearly tagged.
- The latest tag should not point to an artefact containing unapproved code 
e.g. to master or dev branches or to a RC or snapshot.

NPM

Artefacts  show up on https://www.npmjs.com/package/apache version page

To comply with ASF release and distributions please ensue the following:
- The readme tab needs to include the text of the incubation disclaimer.
- “npm install apache” should not install an artefact containing 
unapproved code.
- The latest release should not point to an artefact containing unapproved code 
e.g. a release candidate or snapshot.
- Release candidates, nightly or snapshots need to be clearly tagged.
- The license field should display the ALv2 license.

PiPy

Artefacts need to be placed in https://pypi.org/project/apache/

To comply with ASF release and distributions please ensue the following:
- The project description should include the incubator disclaimer.
- “pip install apache" should not install an artefact containing 
unapproved code.
- Release candidates, nightly or snapshots need to be clearly tagged as 
pre-release on https://pypi.org/project/apaceh/#history
- The latest version should not point to an artefact containing unapproved code 
e.g. to a release candidate or snapshot
- The meta license field should display the ALv2 license.
—

Once the discussion has died down I'll run this past infra and legal and see if 
they are fine with it and then bring it to the boards attention.

Thanks,
Justin


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

Re: [DISCUSS] Training (incubating) Proposal

[Justin Mclean]

Hi,

> discussion seems to have died down. Before moving on I'd really like to
> hear the opinions of the interested contributors on which direction to go.
> Otherwise we might have to put it to a vote?

Perhaps I biased, but I think going via the incubator is alway helpful. :-) The 
big question is would the board support the project going straight to TLP? I 
really don’t know, it’s approved them in the past and not rejected any that I 
know of. What could the project do to show the board that going straight to TLP 
is justifiable? Perhaps start by list out how many ASF members you have on the 
project and and give an idea of how long they been around, how many projects 
they gone through incubation with and how active they are in the incubator and 
may help you decide which path to go and give the board some reassurance.

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

Re: [DISCUSS] Training (incubating) Proposal

[Lars Francke]

Hello everyone,

discussion seems to have died down. Before moving on I'd really like to
hear the opinions of the interested contributors on which direction to go.
Otherwise we might have to put it to a vote?

Cheers,
Lars

On Mon, Feb 4, 2019 at 11:52 AM Lars Francke  wrote:

> Dmitry,
>
> I agree that there are lots of technical things to discuss and I won't
> stop anyone doing that but I'd like to keep this thread about the proposal
> and the project itself knowing that technical stuff is what most of us do
> and like to do and it's also more interesting but let's get the "boring"
> part out of the way :)
>
> I assume (that's actually part of the proposal text) that the first few
> weeks/months of the new project will be spent discussing (and probably
> testing) a lot of these technical issues.
>
> Cheers,
> Lars
>
> On Mon, Feb 4, 2019 at 11:47 AM Dmitriy Pavlov  wrote:
>
>> Hi Lars,
>>
>> About the project: I've got only one thing to say here: Apache Incubator
>> is
>> intended to be a place where a community is build up and everybody (mostly
>> newcomers) learn guides and policies. So straight-to-TLP is also a
>> possible
>> option, but some incubation process isn't bad at all. But still, it is up
>> to board to decide if we go to TLP without incubation.
>>
>> I'm now interested in more technical aspects of contributing to Apache
>> Training: source code for labs, presentations.
>>
>> For example, I can start working on Apache Ignite training, so I will need
>> to contribute 2 types of presentations (source and prepared for students),
>> project code for labs, solved labs, publish it using some website or wiki.
>> Are there any VCS compatible presentation development tools? Can we use,
>> for example, Google Docs for presentations?
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> пн, 4 февр. 2019 г. в 12:56, Hans-Peter Zorn :
>>
>> > Hi all,
>> >
>> > I have been creating training material for various big data apache
>> > projects (mostly Apache Spark) for the last five years and we would
>> like to
>> > contribute those. I for myself have not been directly involved with the
>> ASF
>> > directly, however I have been contributing to some open source projects
>> in
>> > the past.  We have been in discussion about this with Lars Francke and
>> > Sören Liebau the last weeks.  Currently most of the material we have is
>> > powerpoint and zeppelin notebooks at the moment but learning on how to
>> make
>> > this more collaboration friendly format-wise would be one thing we would
>> > like to see in this project.
>> >
>> >
>> > Kind regards,
>> > Hans-Peter
>> >
>> >
>> >
>> > > Am 25.01.2019 um 13:49 schrieb Lars Francke :
>> > >
>> > > Hello everyone,
>> > >
>> > > this is the result of the discussion I started in December 2018[1].
>> > >
>> > > I would like to start this thread to get feedback on a proposal we've
>> > been
>> > > working on for a project focused on developing training material for
>> > Apache
>> > > & 3rd party projects.
>> > >
>> > > The full proposal can be found here <
>> > > https://wiki.apache.org/incubator/TrainingProposal>
>> > >
>> > > Disclaimer: It is a bit different than most other proposals as it
>> > basically
>> > > starts at zero.
>> > >
>> > > Our main goals for this discussion are:
>> > > * Finding mentors and interested contributors
>> > > * Discuss whether this should be a Incubator project, straight to TLP
>> or
>> > a
>> > > Central Service
>> > > * Sharpen the scope of the project
>> > >
>> > > While I personally have a relatively long history as a contributor,
>> > > committer etc. at Apache I've never been a mentor before so we would
>> love
>> > > for some experienced people to help us out.
>> > >
>> > > We're looking forward to all kinds of feedback.
>> > >
>> > > Cheers,
>> > > Lars
>> > >
>> > > [1] <
>> > >
>> >
>> https://lists.apache.org/thread.html/9cb4d7eef73e0d526e0124944c3d37325aa892675351a1eed0a25de3@%3Cgeneral.incubator.apache.org%3E
>> > >>
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>> >
>>
>

Re: Tying Dockerhub into development and release management

[Dave Fisher]

Sent from my iPhone

> On Feb 7, 2019, at 7:51 PM, Chris Lambertus  wrote:
> 
> 
> 
>> On Feb 7, 2019, at 6:47 PM, Justin Mclean  wrote:
>> 
>> Hi,
>> 
>>> Infra does not police what projects deploy on their dockerhub repos. Do we 
>>> need to?
>> 
>> Well from a casual glance I can see several projects that seem to be putting 
>> releases constructed from unapproved source code up there. I’ve not looked 
>> in detail so may be mistaken. I guess sit depends if that concerns you or 
>> not.
> 
> I hear you loud and clear. It’s not a question of if it concerns “me” i.e. 
> Infra, but more if it concerns Legal. Based on 
> www.apache.org/legal/release-policy.html it seems like Infra may need to 
> clamp down on what’s going on with the dockerhub repos and builds. As I 
> alluded to before, we’ve generally left this to the good will of the project. 
> If it’s being abused and the project is “releasing” artifacts via dockerhub 
> that have not been vetted through the ASF release policy, then we do need to 
> take action. Thanks for bringing this to our attention. Could you please send 
> a list of any “offenders” that you’ve found to private@infra?

Does DockerHub provide a way to limit some containers from public view? If so 
then such unapproved artifacts should be hidden first. A general announcement 
could then be made.

Regards,
Dave

> 
> Thanks,
> 
> 
> -Chris
> ASF Infra
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: Tying Dockerhub into development and release management

[Chris Lambertus]

> On Feb 7, 2019, at 6:47 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Infra does not police what projects deploy on their dockerhub repos. Do we 
>> need to?
> 
> Well from a casual glance I can see several projects that seem to be putting 
> releases constructed from unapproved source code up there. I’ve not looked in 
> detail so may be mistaken. I guess sit depends if that concerns you or not.

I hear you loud and clear. It’s not a question of if it concerns “me” i.e. 
Infra, but more if it concerns Legal. Based on 
www.apache.org/legal/release-policy.html it seems like Infra may need to clamp 
down on what’s going on with the dockerhub repos and builds. As I alluded to 
before, we’ve generally left this to the good will of the project. If it’s 
being abused and the project is “releasing” artifacts via dockerhub that have 
not been vetted through the ASF release policy, then we do need to take action. 
Thanks for bringing this to our attention. Could you please send a list of any 
“offenders” that you’ve found to private@infra?

Thanks,


-Chris
ASF Infra


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

Re: Draft incubator report

[Justin Mclean]

Hi,

> If the non-approved artifact is not advertised on the download page and is 
> made available to the development community on request then we are good.

Well I think so, but I’m sure that release policy does and infra doesn’t seem 
to allow it on docker hub, but perhaps they do “unofficial” can cover a lot of 
ground. So far on Roman has spoken up to support that idea which probably 
counts for something.

I think we’ll need to come up with some guidelines for docker and run them 
relevant parties to see if they agree it’s in line with policy.

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

Re: Draft incubator report

[Dave Fisher]

Sent from my iPhone

> On Feb 7, 2019, at 6:51 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> Give the response from intro on use of docker. it would seem that this is not 
> actually allowed.
> 
>> Nightly builds for project-internal use clearly marked as "snapshot" or
>> "prerelease" (or similar) can be made available to project contributors. If
>> in doubt please ask your mentors or on the incubator general list.
> 
> I really wish this wasn’t the case.

Go back and focus on the docker question.

If the non-approved artifact is not advertised on the download page and is made 
available to the development community on request then we are good.

GitHub provides a way to hide Drafts and mark prerelease. Does DockerHub do 
similar?

Regards,
Dave

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


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

Re: Draft incubator report

[Justin Mclean]

Hi,

> Give the response from intro on use of docker. it would seem that this is not 
> actually allowed.

"response from INFRA" sorry.

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

Re: Draft incubator report

[Justin Mclean]

Hi,

Give the response from intro on use of docker. it would seem that this is not 
actually allowed.

> Nightly builds for project-internal use clearly marked as "snapshot" or
> "prerelease" (or similar) can be made available to project contributors. If
> in doubt please ask your mentors or on the incubator general list.

I really wish this wasn’t the case.

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

Re: Tying Dockerhub into development and release management

[Justin Mclean]

Hi,

> Infra does not police what projects deploy on their dockerhub repos. Do we 
> need to?

Well from a casual glance I can see several projects that seem to be putting 
releases constructed from unapproved source code up there. I’ve not looked in 
detail so may be mistaken. I guess sit depends if that concerns you or not.

> Most projects historically have played by the rules. This touches a bit on 
> what it really means to be an Apache Project. My thought here is that the 
> Incubator needs to be a bit more circumspect with regards to onboarding 
> projects before they fully understand the Apache Way. We’ve seen this play 
> out with a significant percentage of projects over the last few years. I 
> don’t know what the solution here is, but the gap between “old school” 
> projects that fall into the Apache Way fairly easily, and the “new school” 
> github-based projects that fly fast and loose seems to be growing by the day.

The incubator does need to do a better job of making the GitHub (and other 
platform)  limitations clear before the project joins. Quite often we’re not 
even aware of how the project was using GitHub, Docker or other channels before 
it joined, it only that after they join that these things become issues and 
then it’s too late.

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

Re: Tying Dockerhub into development and release management

[Chris Lambertus]

> On Feb 7, 2019, at 5:53 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Infra manages the u/apache dockerhub org. We provide this service with the 
>> express caveat that projects note that these are UNOFFICIAL releases, and 
>> CONVENIENCE BINARIES ONLY.
> 
> By that I assume you mean only connivance binaries only created from an 
> official approved/voted on ASF releases. Does that also suggest that release 
> candidates, snapshot and nightlys (even if tagged and/or clearly described) 
> would not be allowed there

Infra has little control over what the project publishes. We expect their good 
will and knowledge of the Apache Release Policy will guide them. As these 
releases are UNOFFICIAL, they could have dockerhub packages built for any 
branch or tag on their repo. This is a social construct, not a technical one, 
but that of course means absolutely nothing to the end user consumer of these 
packages. 

Infra does not police what projects deploy on their dockerhub repos. Do we need 
to?

Most projects historically have played by the rules. This touches a bit on what 
it really means to be an Apache Project. My thought here is that the Incubator 
needs to be a bit more circumspect with regards to onboarding projects before 
they fully understand the Apache Way. We’ve seen this play out with a 
significant percentage of projects over the last few years. I don’t know what 
the solution here is, but the gap between “old school” projects that fall into 
the Apache Way fairly easily, and the “new school” github-based projects that 
fly fast and loose seems to be growing by the day.

> If so doesn’t that just encourage podlings to go make their own 
> https://hub.docker.com/r/apache/ and put them there? And if 
> they do what do we do about it? If a TLP project or podling is found to be 
> using u/apache and placing unapproved releases there what should be done? 
> (Would you like to be informed for starters?)  

I don’t see how this “encourages” any action one way or the other. Many new 
podlings find the restrictions imposed by joining the ASF to be extremely 
detrimental to their community, and are often very surprised to find that 
things that “used to work” on github are now verboten due to our legal policies.


>> Until that juxtaposition is well and truly addressed, these discussions will 
>> continue to happen ad nauseam.
> 
> Well that is problematic.

I agree. This is a topic that comes up frequently, but has yet to be really 
addressed as far as I know.

> Thanks,
> Justin

-Chris
ASF Infra


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

Re: Tying Dockerhub into development and release management

[Justin Mclean]

Hi,

> Infra manages the u/apache dockerhub org. We provide this service with the 
> express caveat that projects note that these are UNOFFICIAL releases, and 
> CONVENIENCE BINARIES ONLY.

By that I assume you mean only connivance binaries only created from an 
official approved/voted on ASF releases. Does that also suggest that release 
candidates, snapshot and nightlys (even if tagged and/or clearly described) 
would not be allowed there

 If so doesn’t that just encourage podlings to go make their own 
https://hub.docker.com/r/apache/ and put them there? And if 
they do what do we do about it? If a TLP project or podling is found to be 
using u/apache and placing unapproved releases there what should be done? 
(Would you like to be informed for starters?)   

> Until that juxtaposition is well and truly addressed, these discussions will 
> continue to happen ad nauseam.

Well that is problematic.

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

Re: Tying Dockerhub into development and release management

[Chris Lambertus]

> On Feb 7, 2019, at 4:54 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> 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).
> 
> I believe INFA has something to do with setting that up, but I think we 
> should extend what be consider “official" to anything with apache in it’s 
> user name, like apachepulsar.


Hi, 

Infra manages the u/apache dockerhub org. We provide this service with the 
express caveat that projects note that these are UNOFFICIAL releases, and 
CONVENIENCE BINARIES ONLY. How much projects comply with this is unknown to me. 
It is a common thread in discussions of this nature because the party line is 
“the ASF releases code” but the reality is that “people consume binaries.”

Until that juxtaposition is well and truly addressed, these discussions will 
continue to happen ad nauseam. I have not reviewed the threads on legal, I just 
popped in over here because Dave Fisher pointed it out to me. 

We (Infra) always point out http://www.apache.org/legal/release-policy.html as 
the defining document that describes official release channels. 

-Chris
ASF Infra



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

Re: Tying Dockerhub into development and release management

[Justin Mclean]

Hi,

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

The podlings are already there waiting for you :-)

So what can we offer on guidance to podlings around:
1) Making official releases available on docker (or other platforms)?
2) Want to provide nightly or snapshots on those platforms?

Thanks,
Justin

Re: Tying Dockerhub into development and release management

[Justin Mclean]

Hi,

> 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).

I believe INFA has something to do with setting that up, but I think we should 
extend what be consider “official" to anything with apache in it’s user name, 
like apachepulsar.

> 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.

Given the confusion, perhaps only allow project names with apache in them to be 
controlled by PMCs and/or assume they are? Much like the domain name policy we 
have. If so they would need to follow ASF release policy. If it’s named apache 
there a good chance users think it official and it probably is run by the PMC 
so policy applies?

Thanks,
Justin

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: Draft incubator report

[Dave Fisher]

Hi -

> On Feb 7, 2019, at 3:41 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> I respectfully request that you edit the following to make it less alarming 
>> and remove any implication that the IPMC cannot handle our duties.
> 
> I don’t read that implication there, this is quite factual all of the project 
> had issues with unapproved releases that had gone unnoticed. I’ll see what I 
> can do as all of the situations are being dealt with I’ll remove “The bard 
> may need to be involved”. Usually the report only covers the period up to the 
> last day of the month, anything beyond that really belongs in the next report.

Thanks.

> 
>> ECharts has a huge number of pre-Apache releases I have provided guidance 
>> today.
> 
> And they also have a number of RCs still listed and versions 4.0.4 and 4.03 
> and 4.0.2 and perhaps 4.0.0 added after then entered incubation that I can’t 
> find a vote for.

Well. I provided the guidance an hour or two ago and it just now morning in 
China during their New Years holiday. …. we will see the response.

Regards,
Dave

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


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

Re: Draft incubator report

[Justin Mclean]

Hi,

> I respectfully request that you edit the following to make it less alarming 
> and remove any implication that the IPMC cannot handle our duties.

I don’t read that implication there, this is quite factual all of the project 
had issues with unapproved releases that had gone unnoticed. I’ll see what I 
can do as all of the situations are being dealt with I’ll remove “The bard may 
need to be involved”. Usually the report only covers the period up to the last 
day of the month, anything beyond that really belongs in the next report.

> ECharts has a huge number of pre-Apache releases I have provided guidance 
> today.

And they also have a number of RCs still listed and versions 4.0.4 and 4.03 and 
4.0.2 and perhaps 4.0.0 added after then entered incubation that I can’t find a 
vote for.

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

Re: Draft incubator report

[Dave Fisher]

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  wrote:
> 
> Sorry I meant to send this to the list but only Dave got it.
> 
>> Begin forwarded message:
>> 
>> From: Justin Mclean 
>> Subject: Re: Draft incubator report
>> Date: 6 February 2019 at 8:48:46 am AEDT
>> To: Dave Fisher 
>> 
>> 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//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 ” 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 @sometag”
>> - With docker hub, if I go "docker pull ” 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 ” 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//#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
> 

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 1:55 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Do we recommend that the Title be changed to add “Non-Apache release from 
>> prior to Incubation” or would it be sufficient for that text to be added to 
>> the Description?
> 
> IMO however the PPMC want to handle it as long as it’s clear it’s not an 
> Apache release and came before the incubation date. I’ve given such advice to 
> several incubating projects. e.g. [1]

Appending “  (non-apache release)” or “ (pre-apache release)” to the title is a 
reasonable recommendation for current and future podlings.

Also the pre-release checkbox and draft tags may also be used.

Regards,
Dave

> 
> Thanks,
> Justin
> 
> 1. https://github.com/apache/incubator-doris/releases
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: Unapproved Sharding Sphere releases

[Justin Mclean]

Hi,

> Do we recommend that the Title be changed to add “Non-Apache release from 
> prior to Incubation” or would it be sufficient for that text to be added to 
> the Description?

IMO however the PPMC want to handle it as long as it’s clear it’s not an Apache 
release and came before the incubation date. I’ve given such advice to several 
incubating projects. e.g. [1]

Thanks,
Justin

1. https://github.com/apache/incubator-doris/releases
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 1:44 PM, Craig Russell  wrote:
> 
>> On Feb 7, 2019, at 11:02 AM, Dave Fisher  wrote:
>> 
>>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 
>>>  
>> 
>> The old repository was moved to the ASF and logically that should also have 
>> moved the legacy releases.
> 
> Doh! I learn something new about git every day. My assumption all along was 
> that the contents of the repository were to be copied, leaving the old 
> repository/web-pages/releases intact.
> 
> Larger discussion: Is there a reason for projects coming into incubation to 
> have the old repository moved (i.e. renamed) instead of being copied? I 
> cannot think of a good use case for moving versus copying. Seems like any 
> project that had releases and a community outside Apache would want to copy, 
> not move.

If the project is moved then all of the thousands of forks and stars are still 
associated with the original project. If copied then all of these will be 
associated with the now abandoned repository and most of those will never come 
along with the moving project.

For the Chinese projects this can mean losing thousands of users and sometime 
contributors to the project.

So, I am a MOVE and not COPY.

ShardingSphere has 6,633 stars and 2,363 forks plus 842 watches.

> 
> Smaller discussion: Should the JIRA have been written to request 
> copying/forking the project? Or is this something that is supposed to be 
> self-serve. I could not find a definitive answer to this.

Ask Infra. ASICT they move by default.

Regards,
Dave


> 
> Craig
>> 
>> There are tradeoffs between moving / renaming and cloning. What moving the 
>> repository means is that technically there is no old repository or project.
>> 
>> Prior “Non-Apache Releases” are attached to the repository and come along. 
>> What to do? I think we have to accept these, but mark them appropriately as 
>> deleting them would be for the project community during transition.
>> 
>> Regards,
>> Dave
> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org  http://db.apache.org/jdo 
> 


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

Re: Tying Dockerhub into development and release management

[Justin Mclean]

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.

Now the main issue with snapshots and nightly is this [2] "Projects SHALL 
publish official releases and SHALL NOT publish unreleased materials outside 
the development community.”, [3] explains it’s about legal protection of (P)PMC 
members, and [4] prohibits links to such releases. The distribution policy [5] 
also states that unreleased material "MAY be distributed to consenting members 
of a development community.”

So I believe  the question here with docker is:  Is using a tag enough to 
satisfy that the PPMC is only distributing to consenting members of a 
development community?

Thanks,
Justin


1, https://issues.apache.org/jira/browse/LEGAL-270
2. http://www.apache.org/legal/release-policy.html#publication
3. http://www.apache.org/legal/release-policy.html#why
4. http://www.apache.org/legal/release-policy.html#what
5. https://www.apache.org/dev/release-distribution.html#unreleased
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 1:24 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Prior “Non-Apache Releases” are attached to the repository and come along. 
>> What to do? I think we have to accept these, but mark them appropriately as 
>> deleting them would be for the project community during transition.
> 
> +1 Clearly labelling any non-apache releases prior to the the data of 
> incubation is fine. It makes it clear that they were not made while the 
> project was at the ASF.

Since we are working to inform podlings how to fix an oversight I think we 
should be prescriptive.

To fix this the PPMC would go to each pre-Apache release and edit the release: 
https://help.github.com/articles/editing-and-deleting-releases/ 


Do we recommend that the Title be changed to add “Non-Apache release from prior 
to Incubation” or would it be sufficient for that text to be added to the 
Description?

Thanks,
Dave

> 
> Thanks,
> Justin

Re: Unapproved Sharding Sphere releases

[Craig Russell]

> On Feb 7, 2019, at 11:02 AM, Dave Fisher  wrote:
> 
>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 
>>  
> 
> The old repository was moved to the ASF and logically that should also have 
> moved the legacy releases.

Doh! I learn something new about git every day. My assumption all along was 
that the contents of the repository were to be copied, leaving the old 
repository/web-pages/releases intact.

Larger discussion: Is there a reason for projects coming into incubation to 
have the old repository moved (i.e. renamed) instead of being copied? I cannot 
think of a good use case for moving versus copying. Seems like any project that 
had releases and a community outside Apache would want to copy, not move.

Smaller discussion: Should the JIRA have been written to request 
copying/forking the project? Or is this something that is supposed to be 
self-serve. I could not find a definitive answer to this.

Craig
> 
> There are tradeoffs between moving / renaming and cloning. What moving the 
> repository means is that technically there is no old repository or project.
> 
> Prior “Non-Apache Releases” are attached to the repository and come along. 
> What to do? I think we have to accept these, but mark them appropriately as 
> deleting them would be for the project community during transition.
> 
> Regards,
> Dave

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Unapproved Sharding Sphere releases

[Justin Mclean]

Hi,

> Prior “Non-Apache Releases” are attached to the repository and come along. 
> What to do? I think we have to accept these, but mark them appropriately as 
> deleting them would be for the project community during transition.

+1 Clearly labelling any non-apache releases prior to the the data of 
incubation is fine. It makes it clear that they were not made while the project 
was at the ASF.

Thanks,
Justin

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 10:46 AM, Craig Russell  wrote:
> 
> Hi Dave,
> 
>> On Feb 7, 2019, at 9:12 AM, Dave Fisher  wrote:
>> 
>> 
>> 
>>> On Feb 7, 2019, at 8:31 AM, Craig Russell  wrote:
>>> 
>>> 
>>> 
 On Feb 6, 2019, at 10:31 PM, Justin Mclean  
 wrote:
 
 HI,
 
> This was done. The issue is that the "3.0.0 outside Apache" release 
> should not be associated with Apache but with the previous project.
 
 They also made a 3.1.0 release as well and it was on the Apache github 
 site (both 3.0 and 3.1 have now been removed from there).
 
> It looks like the original repositories have been changed to redirect to 
> Apache. I'd suggest restoring the original 
> https://github.com/sharding-sphere/ 
> * repositories so 
> they don't automatically redirect to the Apache podling git repositories. 
 
 I’m not so sure that's OK. It’s probably not right for a PPMC to be 
 releasing software anywhere advertised to the general public that hasn’t 
 been approved for release. Could a 3rd party do it sure, could they call 
 it Sharding Sphere probably not.
>>> 
>>> To be clear, the ShardingSphere PPMC did not release anything. The group of 
>>> people who managed the project before it became the ShardingSphere PPMC did 
>>> the release.
>>> 
>>> The unfortunate thing is that the ShardingSphere PPMC then made the release 
>>> available on the PPMC-managed site. This is the wrong thing that needs to 
>>> be fixed. Removing the 3.x releases from the Apache site is part of the 
>>> fix. Restoring the github project that existed prior to the creation of the 
>>> podling is the other part.
>>> 
>>> I hope we can agree that there are two separate projects. One of them will 
>>> be obsolete and will disappear once Apache ShardingSphere graduates. The 
>>> old ShardingSphere will no longer have rights to the name. 
>> 
>> Was the ASF Git for ShardingSphere created by cloning the legacy project, or 
>> was the repo transferred under an SGA?
>> 
> I believe this INFRA ticket has the relevant information: 
> 
> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 
> 

The old repository was moved to the ASF and logically that should also have 
moved the legacy releases.

There are tradeoffs between moving / renaming and cloning. What moving the 
repository means is that technically there is no old repository or project.

Prior “Non-Apache Releases” are attached to the repository and come along. What 
to do? I think we have to accept these, but mark them appropriately as deleting 
them would be for the project community during transition.

Regards,
Dave

> 
> More details on provenance:
> 
> https://wiki.apache.org/incubator/ShardingSphereProposal
> 
> The code base was granted by Dangdang:
> 
> https://svn.apache.org/repos/private/documents/grants/dangdang-sharding-sphere.pdf
> 
> Craig
> 
>> Regards,
>> Dave
>> 
>>> 
>>> Regards,
>>> 
>>> Craig
 
 Thanks,
 Justin
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
 
 For additional commands, e-mail: general-h...@incubator.apache.org 
 
 
>>> 
>>> 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 
>>> 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
>> 
>> For additional commands, e-mail: general-h...@incubator.apache.org 
>> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org  http://db.apache.org/jdo 
> 

Re: Unapproved Sharding Sphere releases

[Craig Russell]

Hi Dave,

> On Feb 7, 2019, at 9:12 AM, Dave Fisher  wrote:
> 
> 
> 
>> On Feb 7, 2019, at 8:31 AM, Craig Russell  wrote:
>> 
>> 
>> 
>>> On Feb 6, 2019, at 10:31 PM, Justin Mclean  wrote:
>>> 
>>> HI,
>>> 
 This was done. The issue is that the "3.0.0 outside Apache" release should 
 not be associated with Apache but with the previous project.
>>> 
>>> They also made a 3.1.0 release as well and it was on the Apache github site 
>>> (both 3.0 and 3.1 have now been removed from there).
>>> 
 It looks like the original repositories have been changed to redirect to 
 Apache. I'd suggest restoring the original 
 https://github.com/sharding-sphere/ 
 * repositories so 
 they don't automatically redirect to the Apache podling git repositories. 
>>> 
>>> I’m not so sure that's OK. It’s probably not right for a PPMC to be 
>>> releasing software anywhere advertised to the general public that hasn’t 
>>> been approved for release. Could a 3rd party do it sure, could they call it 
>>> Sharding Sphere probably not.
>> 
>> To be clear, the ShardingSphere PPMC did not release anything. The group of 
>> people who managed the project before it became the ShardingSphere PPMC did 
>> the release.
>> 
>> The unfortunate thing is that the ShardingSphere PPMC then made the release 
>> available on the PPMC-managed site. This is the wrong thing that needs to be 
>> fixed. Removing the 3.x releases from the Apache site is part of the fix. 
>> Restoring the github project that existed prior to the creation of the 
>> podling is the other part.
>> 
>> I hope we can agree that there are two separate projects. One of them will 
>> be obsolete and will disappear once Apache ShardingSphere graduates. The old 
>> ShardingSphere will no longer have rights to the name. 
> 
> Was the ASF Git for ShardingSphere created by cloning the legacy project, or 
> was the repo transferred under an SGA?
> 
I believe this INFRA ticket has the relevant information: 

https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289

More details on provenance:

https://wiki.apache.org/incubator/ShardingSphereProposal

The code base was granted by Dangdang:

https://svn.apache.org/repos/private/documents/grants/dangdang-sharding-sphere.pdf

Craig

> Regards,
> Dave
> 
>> 
>> Regards,
>> 
>> Craig
>>> 
>>> Thanks,
>>> Justin
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
>>> 
>>> For additional commands, e-mail: general-h...@incubator.apache.org 
>>> 
>>> 
>> 
>> 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 
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
> 
> For additional commands, e-mail: general-h...@incubator.apache.org 
> 
Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 8:31 AM, Craig Russell  wrote:
> 
> 
> 
>> On Feb 6, 2019, at 10:31 PM, Justin Mclean  wrote:
>> 
>> HI,
>> 
>>> This was done. The issue is that the "3.0.0 outside Apache" release should 
>>> not be associated with Apache but with the previous project.
>> 
>> They also made a 3.1.0 release as well and it was on the Apache github site 
>> (both 3.0 and 3.1 have now been removed from there).
>> 
>>> It looks like the original repositories have been changed to redirect to 
>>> Apache. I'd suggest restoring the original 
>>> https://github.com/sharding-sphere/ 
>>> * repositories so 
>>> they don't automatically redirect to the Apache podling git repositories. 
>> 
>> I’m not so sure that's OK. It’s probably not right for a PPMC to be 
>> releasing software anywhere advertised to the general public that hasn’t 
>> been approved for release. Could a 3rd party do it sure, could they call it 
>> Sharding Sphere probably not.
> 
> To be clear, the ShardingSphere PPMC did not release anything. The group of 
> people who managed the project before it became the ShardingSphere PPMC did 
> the release.
> 
> The unfortunate thing is that the ShardingSphere PPMC then made the release 
> available on the PPMC-managed site. This is the wrong thing that needs to be 
> fixed. Removing the 3.x releases from the Apache site is part of the fix. 
> Restoring the github project that existed prior to the creation of the 
> podling is the other part.
> 
> I hope we can agree that there are two separate projects. One of them will be 
> obsolete and will disappear once Apache ShardingSphere graduates. The old 
> ShardingSphere will no longer have rights to the name. 

Was the ASF Git for ShardingSphere created by cloning the legacy project, or 
was the repo transferred under an SGA?

Regards,
Dave

> 
> Regards,
> 
> Craig
>> 
>> Thanks,
>> Justin
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> 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
> 


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

Re: Unapproved Sharding Sphere releases

[Craig Russell]

> On Feb 6, 2019, at 10:31 PM, Justin Mclean  wrote:
> 
> HI,
> 
>> This was done. The issue is that the "3.0.0 outside Apache" release should 
>> not be associated with Apache but with the previous project.
> 
> They also made a 3.1.0 release as well and it was on the Apache github site 
> (both 3.0 and 3.1 have now been removed from there).
> 
>> It looks like the original repositories have been changed to redirect to 
>> Apache. I'd suggest restoring the original 
>> https://github.com/sharding-sphere/ 
>> * repositories so 
>> they don't automatically redirect to the Apache podling git repositories. 
> 
> I’m not so sure that's OK. It’s probably not right for a PPMC to be releasing 
> software anywhere advertised to the general public that hasn’t been approved 
> for release. Could a 3rd party do it sure, could they call it Sharding Sphere 
> probably not.

To be clear, the ShardingSphere PPMC did not release anything. The group of 
people who managed the project before it became the ShardingSphere PPMC did the 
release.

The unfortunate thing is that the ShardingSphere PPMC then made the release 
available on the PPMC-managed site. This is the wrong thing that needs to be 
fixed. Removing the 3.x releases from the Apache site is part of the fix. 
Restoring the github project that existed prior to the creation of the podling 
is the other part.

I hope we can agree that there are two separate projects. One of them will be 
obsolete and will disappear once Apache ShardingSphere graduates. The old 
ShardingSphere will no longer have rights to the name. 

Regards,

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

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

[VOTE] Release Apache Dubbo OPS (Incubating) 0.1 [RC3]

[Minxuan Zhuang]

Hello Incubator Community,

The Apache Dubbo community has voted on and approved a proposal to release
Apache Dubbo OPS (Incubating) version 0.1.

We now kindly request the Incubator PMC members review and vote on this
incubator release.

Apache Dubbo™ (incubating) is a high-performance, java based, open source
RPC framework. Dubbo offers three key functionalities, which include
interface based remote call, fault tolerance & load balancing, and
automatic service registration & discovery.

Dubbo community vote and result thread:
https://lists.apache.org/thread.html/61b7e43b5813c794ef45e7d95dff9c0744ac2d70556ae7ff195405ee@%3Cdev.dubbo.apache.org%3E

The release candidates (RC3):
https://dist.apache.org/repos/dist/dev/incubator/dubbo/dubbo-ops/0.1/


Git tag for the release (RC3):
 https://github.com/apache/incubator-dubbo-ops/releases/tag/0.1

Hash for the release tag:
7e7b2c4421f54f86980dd2128fa58007f118a8d4

Release Notes:
*https://github.com/apache/incubator-dubbo-ops/releases/tag/0.1
*


The artifacts have been signed with Key :
DA2108479B0C1E71, which can be
found in the keys file:
*https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
*

The vote will be open for at least 72 hours or until necessary number of
votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Thanks,
The Apache Dubbo (Incubating) Team

[VOTE] Release Apache Doris 0.9.0-incubating-rc02

[德 李]

Hi all,

Please review and vote on Apache Doris 0.9.0-incubating-rc02 release.

Apache Doris is an MPP-based interactive SQL data warehousing for reporting
and analysis.

The Apache Doris community has voted on and approved this release:
https://lists.apache.org/thread.html/d70f7c8a8ae448bf6680a15914646005c648356
4464cfa15f4ddc2fc@%3Cdev.doris.apache.org%3E

The vote result email thread:
https://lists.apache.org/thread.html/64d229f0ba15d66adc83306bc8d7b7ccd5910ec
b7e842718ce6a61da@%3Cdev.doris.apache.org%3E

The release candidate has been tagged in GitHub as 0.9.0-rc02, available
here:
https://github.com/apache/incubator-doris/releases/tag/0.9.0-rc02

There is no CHANGE LOG file because this is the first release of Apache
Doris.
Thanks to everyone who has contributed to this release, and there is a
simple release notes can be found here:
https://github.com/apache/incubator-doris/issues/406

The artifacts (source, signature and checksum) corresponding to this release
candidate can be found here:
https://dist.apache.org/repos/dist/dev/incubator/doris/0.9.0-incubating-rc02
/

This has been signed with PGP key 33DBF2E0, corresponding to
l...@apache.org.
KEYS file is available here:
https://dist.apache.org/repos/dist/dev/incubator/doris/KEYS
It is also listed here:
https://people.apache.org/keys/committer/lide.asc

The vote will be open for at least 72 hours.
[ ] +1 Approve the release
[ ] +0 No opinion 
[ ] -1 Do not release this package because ...

To verify and build, you can refer to following instruction:

Firstly, you must be install and start docker service, and then you could
build Doris as following steps:

Step1: Pull the docker image with Doris building environment
$ docker pull apachedoris/doris-dev:build-env
You can check it by listing images, its size is about 3.28GB.

Step2: Run the Docker image
You can run image directyly:
$ docker run -it apachedoris/doris-dev:build-env

Step3: Download Doris source
Now you should in docker environment, and you can download Doris source
package.
(If you have downloaded source and it is not in image, you can map its path
to image in Step2.)
$ wget 
https://dist.apache.org/repos/dist/dev/incubator/doris/0.9.0-incubating-rc02
/apache-doris-0.9.0.rc02-incubating-src.tar.gz

Step4: Build Doris
Now you can decompress and enter Doris source path and build Doris.
$ tar zxvf apache-doris-0.9.0.rc02-incubating-src.tar.gz
$ cd apache-doris-0.9.0.rc02-incubating-src
$ sh build.sh

Best Regards,
Reed

Re: [PROPOSAL] New blockchain project: Cava

[Pierre Smits]

I suggest to do a PNS as soon as possible, and preferably before the
podling is established.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Wed, Feb 6, 2019 at 7:25 PM Antoine Toulme  wrote:

> Thanks Furkan, I’ll list you as a mentor too.
>
> > On Feb 6, 2019, at 10:18 AM, Furkan KAMACI 
> wrote:
> >
> > Hi Antonie,
> >
> > Thanks for the proposal! Feel free to ask any questions about it. By the
> > way, right along with being an initial committer, I would like to help
> as a
> > mentor too.
> >
> > Kind Regards,
> > Furkan KAMACI
> >
> > On Wed, Feb 6, 2019 at 9:10 PM Antoine Toulme 
> wrote:
> >
> >> All, thank you for your expressions of interest.
> >>
> >> I have listed all names reported here and a few more colleagues and
> >> contributors in the page:
> >>
> >> https://wiki.apache.org/incubator/CavaProposal <
> >> https://wiki.apache.org/incubator/CavaProposal>
> >>
> >> In particular, thank you for the folks stepping forward to volunteer to
> >> mentor this project. I have listed you all on the page for now.
> >>
> >> There is still a couple of TBD points on the proposal. I will address
> them
> >> in a new thread.
> >> I will also leave this proposal open until Monday next week, so we can
> >> guarantee maximum public participation. I will engage with the incubator
> >> early next week on next steps.
> >>
> >> Cheers,
> >>
> >> Antoine
> >>
> >>> On Feb 6, 2019, at 5:02 AM, Pierre Smits 
> wrote:
> >>>
> >>> Hi Antoine,
> >>>
> >>> Thank you for bringing this proposal to the Apache Incubator. So I
> gladly
> >>> give my +1.
> >>>
> >>> Having a background in accounting and being one of the Apache OFBiz
> >>> contributors I am very interested in blockchain technology, while being
> >>> very interested in applying its functionalities in an ERP setting like
> >>> Apache OFBiz is.
> >>>
> >>> While the Apache Trafodion project was in incubation I was very much
> >>> involved in helping (mentoring) that project towards graduation, which
> it
> >>> has successively done. I would like to help out as one of the mentors,
> >> and
> >>> as a contributor/committer (of the other kind).
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *Apache Trafodion , Vice President & PMC
> >>> Chair*
> >>> *Apache Directory , PMC Member*
> >>> Apache Incubator , committer
> >>> *Apache OFBiz , contributor (without
> >> privileges)
> >>> since 2008*
> >>> Apache Steve , committer
> >>>
> >>>
> >>> On Tue, Feb 5, 2019 at 11:42 PM Antoine Toulme 
> >> wrote:
> >>>
>  Hi all,
> 
>  We’d like to start a conversation around a new proposal for a set of
>  Java-based blockchain project.
> 
>  I have written a proposal available here, and reproduced below:
>  https://wiki.apache.org/incubator/CavaProposal <
>  https://wiki.apache.org/incubator/CavaProposal>
> 
>  At this time, we have a champion, Jim Jagielski (thanks Jim), and
> would
>  like to recruit additional developers and mentors.
> 
>  We have deliberately left room on the project charter to engage openly
>  with the community. That said, we would start the project with code
> >> coming
>  from ConsenSys, and we will recruit developers from there and
> elsewhere
>  actively.
> 
>  The goal of this thread is engage with the community and gather
> interest
>  for participation in the project. Please let us know what you think!
> 
>  Cheers,
> 
>  Antoine Toulme
> 
>  == Abstract ==
>  Cava is a set of libraries and other tools to aid development of
>  blockchain and other decentralized software in Java and other JVM
> >> languages.
> 
>  Please note: Cava is a contraction of "ConsenSys Java". The community
>  should consider an alternate name.
> 
>  = Proposal =
> 
>  Cava is a set of libraries and other tools to aid development of
>  blockchain and other decentralized software in Java and other JVM
> >> languages.
>  It includes a low-level bytes library, serialization and
> deserialization
>  codecs (e.g. RLP), various cryptography functions and primatives, and
> >> lots
>  of other helpful utilities.
>  Cava is developed for JDK 1.8 or higher, and depends on various other
> >> FOSS
>  libraries.
> 
>  === Background ===
> 
>  Cava was built as an open source project from the grounds up to
> >> accelerate
>  the maturation of the blockchain ecosystem, particularly in relation
> >> with
>  enterprise products predominantly built in J

Re: Tying Dockerhub into development and release management

[Roman Shaposhnik]

Hey Justin -- any chance you can take a look at the proposed policy for
*snapshot* Docker hub artifacts I proposed up-thread?

Thanks,
Roman.

On Thu, Feb 7, 2019 at 6:13 AM Justin Mclean 
wrote:

> Hi,
>
> > AFAIK everyone releasing binary convenience to dockerhub believed they
> were authorized.
>
> I didn't have a problem with them if they are based on actual released
> software, although it seem it’s now not clear that in line with policy or
> not, lets alone if a PPMC can  release tagged nightly or snapshots there.
>
> Thanks,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Apache ODF Toolkit (retired) migration to TDF

[Thorsten Behrens]

Hi Daniel,

Daniel Shahaf wrote:
> Also, you might want to update the lists' autoresponders.
> 
That would indeed be helpful - perhaps also with a pointer to
odftoolkit.org.

> What about this page:
> 
> http://odftoolkit.incubator.apache.org/odftoolkit/index.mdtext
> 
Dunno, is that prominently referenced from somewhere? If yes, then
preferably the same change as for the
https://incubator.apache.org/projects/odftoolkit.html could be
made. Should we send a patch?

All the best,

-- Thorsten


signature.asc
Description: PGP signature

Fwd: Draft incubator report

[Justin Mclean]

Sorry I meant to send this to the list but only Dave got it.

> Begin forwarded message:
> 
> From: Justin Mclean 
> Subject: Re: Draft incubator report
> Date: 6 February 2019 at 8:48:46 am AEDT
> To: Dave Fisher 
> 
> 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//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 ” 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 @sometag”
> - With docker hub, if I go "docker pull ” 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 ” 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//#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