Re: Podlings not following ASF release policy

[Justin Mclean]

HI,

> From what I can see with httpd, the issue is the same(?)

Not quite as I not see any release candidates listed.

Thanks,
Justin

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

Re: Podlings not following ASF release policy

[Daniel Gruno]

On 2/9/19 8:37 AM, Justin Mclean wrote:

Hi,


IMO either way it should be ok because


It’s not OK as it doesn’t agree with ASF release policy. You can’t provide 
release candidates to the general public and call them releases.

I do see that several ASF projects seem to avoid this issue but I’m not sure 
how they do it. (See for instance the httpd project) [1]


From what I can see with httpd, the issue is the same(?) - GitHub 
interprets a tag as a release at the time of tagging, not the time of 
releasing (github "released" 2.4.38 21 days ago, ASF released it 19 days 
ago). Short of going in and removing the tag, there's little we can do, 
it's just a bad hardcoded feature that GitHub has.




Thanks,
Justin

1. https://github.com/apache/httpd/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: Podlings not following ASF release policy

[Justin Mclean]

Hi,

> IMO either way it should be ok because

It’s not OK as it doesn’t agree with ASF release policy. You can’t provide 
release candidates to the general public and call them releases.

I do see that several ASF projects seem to avoid this issue but I’m not sure 
how they do it. (See for instance the httpd project) [1]

Thanks,
Justin

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

Re: Podlings not following ASF release policy

[Justin Mclean]

Hi,

> When I played around with maven-release-plugin today, I found out that
> Github would automatically generate the release at "
> github.com/apache/incubator-xxx/release" when we update the tag. I think
> that some projects may inadvertently create a release on Github for their
> release candidates.

That seems problematic and may not be in line with ASF release policy. Anyone 
else have any suggestions?

Perhaps you may mark it as a “prerelease”, that of course means actually 
releasing it on GitHub. :-(
 
Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Podlings not following ASF release policy

[Felix Cheung]

I’d agree- it’s a “feature” of GitHub and I didn’t see a way to turn off
“turning a git tag into a release”

I see that there is a API to edit a release to say it is “pre-release”
https://developer.github.com/v3/repos/releases/#edit-a-release

IMO either way it should be ok because
a) the tag is clearly indicating *-rc0 *-rc1 and so on (if not ok, it can
be set as a prerelease)
b) when a new RC is being rolled, the last RC git tag can be removed (which
should also eliminate the github “release”)
c) when the RC becomes the official release, the git tag can be replaced
and the final git tag is the release


On Fri, Feb 8, 2019 at 11:14 PM Seunghyun Lee  wrote:

> Hi all,
>
> I'm Seunghyun who's working on the first Apache release for Pinot project.
>
> When I played around with maven-release-plugin today, I found out that
> Github would automatically generate the release at "
> github.com/apache/incubator-xxx/release" when we update the tag. I think
> that some projects may inadvertently create a release on Github for their
> release candidates.
>
> I'm a bit confused because we need to provide the tag as part of release
> process while tagging a release candidate creates a release on Github.
>
> If you refer to the Gobblin's release page [1], you can observe that
> release candidate was added to the release page before the official release
> got updated. I have looked into Github configurations, I haven't find one
> that prevents this yet.
>
> Best,
> Seunghyun
>
> [1] https://github.com/apache/incubator-gobblin/releases
>
>
> On Fri, Feb 8, 2019 at 7:57 PM Dave Fisher  wrote:
>
> > Hi Julian,
> >
> > A perfect example!
> >
> > I think we should add a checkbox to the podling report where the podling
> > indicates when they are fully in compliance with release policy. Until
> that
> > is done we don’t worry.
> >
> > Additionally, Infra could tag and “release” with appropriate description
> > when they move a GitHub repository into the foundation.
> >
> > Regards,
> > Dave
> >
> > Sent from my iPhone
> >
> > > On Feb 8, 2019, at 5:41 PM, Julian Hyde  wrote:
> > >
> > > I’m a mentor of Druid.
> > >
> > > We allowed Druid to continue making releases outside of Apache during
> > incubation because ASF releases were not possible. There were various
> > reasons - they could not release from main line because IP transfer had
> not
> > been completed (if I recall correctly), and they also needed to make
> > bug-fix releases of existing releases. Druid is an active project with
> > large installations in production, some of them at major companies;
> pausing
> > releases for 6 - 9 months while transitioning into ASF would have been
> > hugely damaging to the project and its community.
> > >
> > > The project tried to do everything by the book: they sought permission
> > for releases outside of ASF, disclosed the non-ASF releases in its
> reports,
> > and made an official Apache release as soon as they could. If there is
> > anything they could/should have done differently, let’s discuss, and
> write
> > down guidelines for future podlings that are in a similar situation.
> > >
> > > Julian
> > >
> > >
> > >
> > >> On Feb 8, 2019, at 5:16 PM, Justin Mclean 
> > wrote:
> > >>
> > >> Hi,
> > >>
> > >> One of the issues I’ve seen is that project continues to make releases
> > in GitHub after being accepted into the incubator, in some case is this
> > because the repo hasn’t been moved over yet, in other cases it’s because
> > they believe that the code base is not Apache ready. What should we do in
> > this situations? From what I seen it usually just delays transfer of the
> > repo and encourages unapproved releases. I would would push for mentors
> > speeding up that transfer rather than allowing unapproved releases. What
> do
> > others think?
> > >>
> > >> 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
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Podlings not following ASF release policy

[Seunghyun Lee]

Hi all,

I'm Seunghyun who's working on the first Apache release for Pinot project.

When I played around with maven-release-plugin today, I found out that
Github would automatically generate the release at "
github.com/apache/incubator-xxx/release" when we update the tag. I think
that some projects may inadvertently create a release on Github for their
release candidates.

I'm a bit confused because we need to provide the tag as part of release
process while tagging a release candidate creates a release on Github.

If you refer to the Gobblin's release page [1], you can observe that
release candidate was added to the release page before the official release
got updated. I have looked into Github configurations, I haven't find one
that prevents this yet.

Best,
Seunghyun

[1] https://github.com/apache/incubator-gobblin/releases


On Fri, Feb 8, 2019 at 7:57 PM Dave Fisher  wrote:

> Hi Julian,
>
> A perfect example!
>
> I think we should add a checkbox to the podling report where the podling
> indicates when they are fully in compliance with release policy. Until that
> is done we don’t worry.
>
> Additionally, Infra could tag and “release” with appropriate description
> when they move a GitHub repository into the foundation.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Feb 8, 2019, at 5:41 PM, Julian Hyde  wrote:
> >
> > I’m a mentor of Druid.
> >
> > We allowed Druid to continue making releases outside of Apache during
> incubation because ASF releases were not possible. There were various
> reasons - they could not release from main line because IP transfer had not
> been completed (if I recall correctly), and they also needed to make
> bug-fix releases of existing releases. Druid is an active project with
> large installations in production, some of them at major companies; pausing
> releases for 6 - 9 months while transitioning into ASF would have been
> hugely damaging to the project and its community.
> >
> > The project tried to do everything by the book: they sought permission
> for releases outside of ASF, disclosed the non-ASF releases in its reports,
> and made an official Apache release as soon as they could. If there is
> anything they could/should have done differently, let’s discuss, and write
> down guidelines for future podlings that are in a similar situation.
> >
> > Julian
> >
> >
> >
> >> On Feb 8, 2019, at 5:16 PM, Justin Mclean 
> wrote:
> >>
> >> Hi,
> >>
> >> One of the issues I’ve seen is that project continues to make releases
> in GitHub after being accepted into the incubator, in some case is this
> because the repo hasn’t been moved over yet, in other cases it’s because
> they believe that the code base is not Apache ready. What should we do in
> this situations? From what I seen it usually just delays transfer of the
> repo and encourages unapproved releases. I would would push for mentors
> speeding up that transfer rather than allowing unapproved releases. What do
> others think?
> >>
> >> 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
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podlings not following ASF release policy

[Dave Fisher]

Hi Julian,

A perfect example!

I think we should add a checkbox to the podling report where the podling 
indicates when they are fully in compliance with release policy. Until that is 
done we don’t worry.

Additionally, Infra could tag and “release” with appropriate description when 
they move a GitHub repository into the foundation.

Regards,
Dave

Sent from my iPhone

> On Feb 8, 2019, at 5:41 PM, Julian Hyde  wrote:
> 
> I’m a mentor of Druid.
> 
> We allowed Druid to continue making releases outside of Apache during 
> incubation because ASF releases were not possible. There were various reasons 
> - they could not release from main line because IP transfer had not been 
> completed (if I recall correctly), and they also needed to make bug-fix 
> releases of existing releases. Druid is an active project with large 
> installations in production, some of them at major companies; pausing 
> releases for 6 - 9 months while transitioning into ASF would have been hugely 
> damaging to the project and its community.
> 
> The project tried to do everything by the book: they sought permission for 
> releases outside of ASF, disclosed the non-ASF releases in its reports, and 
> made an official Apache release as soon as they could. If there is anything 
> they could/should have done differently, let’s discuss, and write down 
> guidelines for future podlings that are in a similar situation.
> 
> Julian
> 
> 
> 
>> On Feb 8, 2019, at 5:16 PM, Justin Mclean  wrote:
>> 
>> Hi,
>> 
>> One of the issues I’ve seen is that project continues to make releases in 
>> GitHub after being accepted into the incubator, in some case is this because 
>> the repo hasn’t been moved over yet, in other cases it’s because they 
>> believe that the code base is not Apache ready. What should we do in this 
>> situations? From what I seen it usually just delays transfer of the repo and 
>> encourages unapproved releases. I would would push for mentors speeding up 
>> that transfer rather than allowing unapproved releases. What do others think?
>> 
>> 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
> 


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

Re: Podlings not following ASF release policy

[Justin Mclean]

HI,

> We allowed Druid to continue making releases outside of Apache during 
> incubation because ASF releases were not possible. There were various reasons 
> - they could not release from main line because IP transfer had not been 
> completed (if I recall correctly), and they also needed to make bug-fix 
> releases of existing releases. Druid is an active project with large 
> installations in production, some of them at major companies; pausing 
> releases for 6 - 9 months while transitioning into ASF would have been hugely 
> damaging to the project and its community.

I sympathise but it does seem it took them far too long to get out their first 
release, that is also damaging to the community. It's true the releases and 
difficulties were noted in the reports but I’m wondering this this could of 
been handled in another way without so many unapproved releases.

There is some room for improvement for instance it’s impossible to tell what is 
an official release and what is not here [1], there are also release candidates 
listed as releases. The druid website points to directly to that page for past 
releases (from the versioning page). It seems release are being listed on the 
druid.io website [2] and the main site links to that one which seem well a bit 
odd.

Thanks,
Justin

1. https://github.com/apache/incubator-druid/releases
2. http://druid.io/downloads.html
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Podlings not following ASF release policy

[???? Sheng Wu]

If we don't want the unapproved release happens in this case, I think we should 
asked them to give an exact date of joining the incubator. 
The new incubator project community should know, after the proposal accepted 
and with the date deadline, we don't allow to do unapproved release. And we 
keep this in our proposal guide document and template, also ask the new 
proposal make clear in their proposal.





Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin

From Wu Sheng 's phone.


-- Original --
From: Justin Mclean 
Date: Sat,Feb 9,2019 9:16 AM
To: general 
Subject: Re: Podlings not following ASF release policy



Hi,

One of the issues I??ve seen is that project continues to make releases in 
GitHub after being accepted into the incubator, in some case is this because 
the repo hasn??t been moved over yet, in other cases it??s because they believe 
that the code base is not Apache ready. What should we do in this situations? 
From what I seen it usually just delays transfer of the repo and encourages 
unapproved releases. I would would push for mentors speeding up that transfer 
rather than allowing unapproved releases. What do others think?

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

Re: Podlings not following ASF release policy

[Julian Hyde]

I’m a mentor of Druid.

We allowed Druid to continue making releases outside of Apache during 
incubation because ASF releases were not possible. There were various reasons - 
they could not release from main line because IP transfer had not been 
completed (if I recall correctly), and they also needed to make bug-fix 
releases of existing releases. Druid is an active project with large 
installations in production, some of them at major companies; pausing releases 
for 6 - 9 months while transitioning into ASF would have been hugely damaging 
to the project and its community.

The project tried to do everything by the book: they sought permission for 
releases outside of ASF, disclosed the non-ASF releases in its reports, and 
made an official Apache release as soon as they could. If there is anything 
they could/should have done differently, let’s discuss, and write down 
guidelines for future podlings that are in a similar situation.

Julian

 

> On Feb 8, 2019, at 5:16 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> One of the issues I’ve seen is that project continues to make releases in 
> GitHub after being accepted into the incubator, in some case is this because 
> the repo hasn’t been moved over yet, in other cases it’s because they believe 
> that the code base is not Apache ready. What should we do in this situations? 
> From what I seen it usually just delays transfer of the repo and encourages 
> unapproved releases. I would would push for mentors speeding up that transfer 
> rather than allowing unapproved releases. What do others think?
> 
> 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: Podlings not following ASF release policy

[Justin Mclean]

Hi,

One of the issues I’ve seen is that project continues to make releases in 
GitHub after being accepted into the incubator, in some case is this because 
the repo hasn’t been moved over yet, in other cases it’s because they believe 
that the code base is not Apache ready. What should we do in this situations? 
From what I seen it usually just delays transfer of the repo and encourages 
unapproved releases. I would would push for mentors speeding up that transfer 
rather than allowing unapproved releases. What do others think?

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

Podlings not following ASF release policy

[Justin Mclean]

Hi,

So I just checked the next bunch of podlings to report to see if we have any 
other issues with ASF releases policy and sadly we do and again it larger than 
I expected. Some of these are minor issues and easily fixed, some are not. In a 
couple of cases I may not of looked deeply enough into the issue and it may 
actually be fine, if so apologies in advance for listing you here. In a couple 
of cases (e.g. Zipkin) I can see it’s been discussed on the list but there’s 
more to do.

Podlings having one or more issues with ASF release policy include:
- Crail
- Daffodil
- Dlab
- Druid 
- Dubbo
- Hivemall
- Marvin-ai
- Memo
- Omid
- Openwhisk
- Pinot
- Ponymail
- Singa
- Skywalking
- Zipkin

Projects that I will be following up with include Dlab, Druid, Dubbo, 
Openwhisk, Singa, Skywalking and Zipkin.

If you are the mentors of these projects please take a look and see what you 
can do to improve the situation and educate your podling on proper release 
policy. If you can’t find the issue ping me and I’ll send an email with what I 
think it is to your private list. There is probably things I’ve missed as well, 
often were there’s one issue there’s others.

Please include something in the next podling report on this.

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

Re: Unapproved Sharding Sphere releases

[???? Sheng Wu]

I support move than copy too. 
Move is better, not just for keeping star, fork and watch. These are also 
important too.
The more important is, GitHub provides repo address auto redirect. If the user 
or article links to the old repo, it will forward to the new one(Apache one) 
automatically. 



Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin

From Wu Sheng 's phone.


-- Original --
From: Chris Lambertus 
Date: Sat,Feb 9,2019 4:34 AM
To: general 
Cc: dev 
Subject: Re: Unapproved Sharding Sphere releases





> On Feb 7, 2019, at 1:52 PM, Dave Fisher  wrote:
> 
> 
> 
>> On Feb 7, 2019, at 1:44 PM, Craig Russell  wrote:

[snip]

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


We endeavor to perform move operations wherever technically possible for the 
exact reason of retaining the stars and other metadata associated with the 
github project. It adds a few extra steps for us, but the projects always 
appreciate having that data retained. If we did a ??copy?? then there would be 
two extant repos which would cause no end of confusion, especially for people 
with forks and watches on the original repo.

-Chris
ASF Infra

Re: Renaming repos and security concerns

[Justin Mclean]

Hi,

> We need to make sure that pre-Apache releases whether source or binary are 
> treated in a fair way.

As long are they are not in after the date of incubation and clearly marked I 
see no issues.

> An über-comment - let’s be exceedingly careful with time limits for 
> “compliance”.

What do you suggest? If a podling is not following ASF release policy how long 
do we give them to fix that? IMO if the podling is dealing with it then all is 
OK, but we can’t wait for months while that is happening.

> I think it would be good to finalize proposed policies from master copies on 
> the wiki.

Here you go. Feel free to edit. [1]

Thanks,
Justin 

1. https://wiki.apache.org/incubator/DistributionGuidelines

Re: Tying Dockerhub into development and release management

[Matteo Merli]

On Wed, Feb 6, 2019 at 3:41 PM Justin Mclean  wrote:
>
> Hi,
>
> > If projects want to make convenience binaries available for installation
> > via Docker and DockerHub, then it seems like we need an official Apache
> > DockerHub repository. Do we have one of those, or are folks just publishing
> > to personal repos?
>
> A quick look shows HTTP, Maven, Tomcat, Casandra, Solr, Groovy and a number 
> of other Apache TLP using docker hub. Well they may be it’s hard to know who 
> is publishing them.
>
> All are using Apache branding and most are marked as "Docker Official Images” 
> [1]
>
> None seem to be publishing nightly there but there are binary versions of 
> released source code in all these projects.
>
> I can also see ignite [2] published under an apache ignite account and pulsar 
> [2] under an apache pulsar account and nutch [3] published under an apache 
> account.
>
> Pulsar is publishing RCs and looks like it was doing so during incubation :-(
> 4. https://hub.docker.com/r/apachepulsar/pulsar

Just a quick clarification. We have the push to DockerHub as part of the steps
performed by the release manager *after* the release is approved (in
the incubator
phase, that was after IIPMC approval). The images are simply a
repackaged version
of the official release binary tgz.

Regarding RCs tag, the only one published there was
"2.0.0-rc1-incubating" and the
reason was that this was the name of the official release (Because of
the jump from
1.x to 2.x, we wanted to communicate the stability to expect from that release).
Ref: 
https://lists.apache.org/thread.html/b40a4791d0810b6c11f4cb9630ca6a4510ac0ed27336796dee54ec1b@%3Cgeneral.incubator.apache.org%3E



>
> 1. https://hub.docker.com/search?q=Apache=image
> 2. https://hub.docker.com/r/apacheignite/ignite
> 3. https://hub.docker.com/r/apacheignite/ignite
> 4. https://hub.docker.com/r/apachepulsar/pulsar
> 5. https://hub.docker.com/r/apache/nutch
> 6. https://hub.docker.com/u/apache
> 7. https://hub.docker.com/r/apache/yetus/tags
> 8. https://hub.docker.com/r/apache/syncope/tags
> 9. https://hub.docker.com/r/apache/airflow/tags
> -
> 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: Renaming repos and security concerns

[Dave Fisher]

> On Feb 8, 2019, at 1:36 PM, Justin Mclean  wrote:
> 
> HI,
> 
> In the thread on guidelines for distributions I suggested some common naming 
> to help with trademarks, branding and be in line with release policy.
> 
> There's a possible security issue here, as people could (in theory) take over 
> the old name and put something malicious there if the old name was removed.
> 
> Can rename GitHub
> https://help.github.com/articles/renaming-a-repository/
> 
> Can’t rename docker
> https://success.docker.com/article/how-do-you-rename-a-docker-hub-repository
> 
> Can’t rename on NPM
> Can’t rename but can deprecate and point to new one
> 
> Can rename on PiPy
> Is possible but also supports deprecate. But best to use abandon feature and 
> pick a replacement.
> 
> I think we’re fine with:
> - GitHub is OK as it controlled by INFRA
> - Docker is OK as /u/apache is controlled by INFRA. Outside that space is a 
> concern.
> - NPM you can deprecate one and point to new one so no one can take the old 
> package
> - PiPy you can use abandon and point to a replacement so none can take the 
> old package
> 
> Any other concerns?

We need to make sure that pre-Apache releases whether source or binary are 
treated in a fair way.

An über-comment - let’s be exceedingly careful with time limits for 
“compliance”.

I think it would be good to finalize proposed policies from master copies on 
the wiki.

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

Renaming repos and security concerns

[Justin Mclean]

HI,

In the thread on guidelines for distributions I suggested some common naming to 
help with trademarks, branding and be in line with release policy.

There's a possible security issue here, as people could (in theory) take over 
the old name and put something malicious there if the old name was removed.

Can rename GitHub
https://help.github.com/articles/renaming-a-repository/

Can’t rename docker
https://success.docker.com/article/how-do-you-rename-a-docker-hub-repository

Can’t rename on NPM
Can’t rename but can deprecate and point to new one

Can rename on PiPy
Is possible but also supports deprecate. But best to use abandon feature and 
pick a replacement.

 I think we’re fine with:
- GitHub is OK as it controlled by INFRA
- Docker is OK as /u/apache is controlled by INFRA. Outside that space is a 
concern.
- NPM you can deprecate one and point to new one so no one can take the old 
package
- PiPy you can use abandon and point to a replacement so none can take the old 
package

Any other concerns?

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

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

[Justin Mclean]

Hi,

> - Convenience binary artifact releases need to be made from approved voted
> on approved ASF releases.

OK.

> Wait, you mean binary releases, not just source code tags?

Binary releases [1] (see step 7) and unapproved release are possible in GitHub.

Once I get some more feedback I’l put this up on a wiki page.

Thanks,
Justin

1. https://help.github.com/articles/creating-releases/


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

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

[Roman Shaposhnik]

On Fri, Feb 8, 2019 at 12:27 PM Justin Mclean 
wrote:

> Hi,
>
> > This sentence is very confusing to me. If the release is "unofficial”
> then it can't be subject to ASF's policy, no?
>
> I used the word unofficial as some of these artefacts are connivance
> binaries. I and don’t want to open up the “we only release source" can of
> worms.
>

Then why not just call them what they are "convenience binary artifacts".
IOW, how about this edit:

- Convenience binary artifact releases need to be made from approved voted
on approved ASF releases.

?


>
> > I am actually not sure why we're including GitHub in this list.
>
> Because people are placing releases there as well. Github has a release
> page which can include release notes etc and shows a history of releases,
> users can download releases from here.
>

Wait, you mean binary releases, not just source code tags?


>
> > It is unclear whether  should include incubator- prefix. I
> > honestly thing it should.
>
> Good point. None of them I’ve seen have, I was thinking not and then you
> need to rename on graduation which would be a pain.
>
> > You don't have to had a Dockerfile to publish to Docker Hub. This
> sentence
> > makes it sound like it is a requirement.
>
> Right I’ll make that optional.
>
> Thanks for the feedback.
> Justin

Re: Unapproved Sharding Sphere releases

[Chris Lambertus]

> On Feb 7, 2019, at 1:52 PM, Dave Fisher  wrote:
> 
> 
> 
>> On Feb 7, 2019, at 1:44 PM, Craig Russell  wrote:

[snip]

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


We endeavor to perform move operations wherever technically possible for the 
exact reason of retaining the stars and other metadata associated with the 
github project. It adds a few extra steps for us, but the projects always 
appreciate having that data retained. If we did a “copy” then there would be 
two extant repos which would cause no end of confusion, especially for people 
with forks and watches on the original repo.

-Chris
ASF Infra

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

[Justin Mclean]

Hi,

> This sentence is very confusing to me. If the release is "unofficial” then it 
> can't be subject to ASF's policy, no?

I used the word unofficial as some of these artefacts are connivance binaries. 
I and don’t want to open up the “we only release source" can of worms.

> I am actually not sure why we're including GitHub in this list.

Because people are placing releases there as well. Github has a release page 
which can include release notes etc and shows a history of releases, users can 
download releases from here.

> It is unclear whether  should include incubator- prefix. I
> honestly thing it should.

Good point. None of them I’ve seen have, I was thinking not and then you need 
to rename on graduation which would be a pain.

> You don't have to had a Dockerfile to publish to Docker Hub. This sentence
> makes it sound like it is a requirement.

Right I’ll make that optional.

Thanks for the feedback.
Justin

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

[Roman Shaposhnik]

Great effort getting it all documented! Would really love to see this
converge ASAP.

On Thu, Feb 7, 2019 at 11:08 PM Justin Mclean 
wrote:

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

This sentence is very confusing to me. If the release is "unofficial" then
it can't be
subject to ASF's policy, no?


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

I would also ask that if after a certain period of time the podling doesn't
respond to criticism -- IPMC reserves the right to ask INFRA to remove the
artifact.


>
> GitHub
>

I am actually not sure why we're including GitHub in this list. For all
practical purposes,
GitHub is a mirror of ASF git repo and as such doesn't warrant a dedicated
policy.

I'd like to see it removed.


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

It is unclear whether  should include incubator- prefix. I
honestly thing it should.


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

You don't have to had a Dockerfile to publish to Docker Hub. This sentence
makes it sound like it is a requirement.


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

This is a repeat of a "docker pull apache/" should not install an
artefact containing unapproved code. statement.

Thanks,
Roman.


> 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 

Re: [DISCUSS] Training (incubating) Proposal

[Christofer Dutz]

Sign me up (

Am 08.02.19, 11:55 schrieb "Lars Francke" :

One more thing: We've got three mentors. If anyone else would like to
volunteer we won't say no :)

I've used the E-Mail addresses from your mails in the proposal. Feel free
to update to an @apache.org address if you want to.

On Fri, Feb 8, 2019 at 11:05 AM Lars Francke  wrote:

> Thanks to the three of you.
>
> Those arguments make sense to me and we indeed have a few "newcomers" with
> us (that includes me in a non-committer role) so I've changed my opinion
> and think the Incubator way would be the best.
>
> I'll edit the Wiki proposal (and add Christofer whom I've forgotten,
> sorry!) to indicate this.
>
> If there are no other comments or concerns about anything we've written in
> the proposal I would "close" this discussion soon and start a vote early
> next week.
>
> Cheers,
> Lars
>
> (as a heads up: I might be slow to respond next week due to limited
> connectivity but we're in no rush as far as I'm concerned)
>
> On Fri, Feb 8, 2019 at 10:53 AM Myrle Krantz  wrote:
>
>> My initial thought was: this should go straight to TLP: Training should 
be
>> done by people who know what they're training about: whether it be the
>> Apache Way or a specific project.  All the committers will likely be
>> people
>> who've at least reached committer status in a project, and most of them
>> will probably be ASF members.
>>
>> But then I thought again: developing effective materials will require
>> contact to the users of those materials.  What better place to find 
people
>> to QA training materials and approaches than in the incubator?  I think a
>> training project would benefit from incubator participation in a 
different
>> manner than most projects do, but I do think starting in the incubator
>> (and
>> possibly, after discussion, even staying there) might be a good approach
>> for this project.
>>
>> Best Regards,
>> Myrle
>>
>> On Fri, Feb 8, 2019 at 10:34 AM Sönke Liebau
>>  wrote:
>>
>> > Hi,
>> >
>> > after spending some time thinking about this I also tend towards the
>> > Incubator route as I am sure this will help build and grow an active
>> > community and processes.
>> >
>> > Best regards,
>> > Sönke
>> >
>> > On Fri, Feb 8, 2019 at 6:38 AM Justin Mclean 
>> > wrote:
>> > >
>> > > 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
>> > >
>> >
>> >
>> > --
>> > Sönke Liebau
>> > Partner
>> > Tel. +49 179 7940878
>> > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
>> >
>> > -
>> > 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: [DISCUSS] Training (incubating) Proposal

[Lars Francke]

One more thing: We've got three mentors. If anyone else would like to
volunteer we won't say no :)

I've used the E-Mail addresses from your mails in the proposal. Feel free
to update to an @apache.org address if you want to.

On Fri, Feb 8, 2019 at 11:05 AM Lars Francke  wrote:

> Thanks to the three of you.
>
> Those arguments make sense to me and we indeed have a few "newcomers" with
> us (that includes me in a non-committer role) so I've changed my opinion
> and think the Incubator way would be the best.
>
> I'll edit the Wiki proposal (and add Christofer whom I've forgotten,
> sorry!) to indicate this.
>
> If there are no other comments or concerns about anything we've written in
> the proposal I would "close" this discussion soon and start a vote early
> next week.
>
> Cheers,
> Lars
>
> (as a heads up: I might be slow to respond next week due to limited
> connectivity but we're in no rush as far as I'm concerned)
>
> On Fri, Feb 8, 2019 at 10:53 AM Myrle Krantz  wrote:
>
>> My initial thought was: this should go straight to TLP: Training should be
>> done by people who know what they're training about: whether it be the
>> Apache Way or a specific project.  All the committers will likely be
>> people
>> who've at least reached committer status in a project, and most of them
>> will probably be ASF members.
>>
>> But then I thought again: developing effective materials will require
>> contact to the users of those materials.  What better place to find people
>> to QA training materials and approaches than in the incubator?  I think a
>> training project would benefit from incubator participation in a different
>> manner than most projects do, but I do think starting in the incubator
>> (and
>> possibly, after discussion, even staying there) might be a good approach
>> for this project.
>>
>> Best Regards,
>> Myrle
>>
>> On Fri, Feb 8, 2019 at 10:34 AM Sönke Liebau
>>  wrote:
>>
>> > Hi,
>> >
>> > after spending some time thinking about this I also tend towards the
>> > Incubator route as I am sure this will help build and grow an active
>> > community and processes.
>> >
>> > Best regards,
>> > Sönke
>> >
>> > On Fri, Feb 8, 2019 at 6:38 AM Justin Mclean 
>> > wrote:
>> > >
>> > > 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
>> > >
>> >
>> >
>> > --
>> > Sönke Liebau
>> > Partner
>> > Tel. +49 179 7940878
>> > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
>> >
>> > -
>> > 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]

Thanks to the three of you.

Those arguments make sense to me and we indeed have a few "newcomers" with
us (that includes me in a non-committer role) so I've changed my opinion
and think the Incubator way would be the best.

I'll edit the Wiki proposal (and add Christofer whom I've forgotten,
sorry!) to indicate this.

If there are no other comments or concerns about anything we've written in
the proposal I would "close" this discussion soon and start a vote early
next week.

Cheers,
Lars

(as a heads up: I might be slow to respond next week due to limited
connectivity but we're in no rush as far as I'm concerned)

On Fri, Feb 8, 2019 at 10:53 AM Myrle Krantz  wrote:

> My initial thought was: this should go straight to TLP: Training should be
> done by people who know what they're training about: whether it be the
> Apache Way or a specific project.  All the committers will likely be people
> who've at least reached committer status in a project, and most of them
> will probably be ASF members.
>
> But then I thought again: developing effective materials will require
> contact to the users of those materials.  What better place to find people
> to QA training materials and approaches than in the incubator?  I think a
> training project would benefit from incubator participation in a different
> manner than most projects do, but I do think starting in the incubator (and
> possibly, after discussion, even staying there) might be a good approach
> for this project.
>
> Best Regards,
> Myrle
>
> On Fri, Feb 8, 2019 at 10:34 AM Sönke Liebau
>  wrote:
>
> > Hi,
> >
> > after spending some time thinking about this I also tend towards the
> > Incubator route as I am sure this will help build and grow an active
> > community and processes.
> >
> > Best regards,
> > Sönke
> >
> > On Fri, Feb 8, 2019 at 6:38 AM Justin Mclean 
> > wrote:
> > >
> > > 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
> > >
> >
> >
> > --
> > Sönke Liebau
> > Partner
> > Tel. +49 179 7940878
> > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [DISCUSS] Training (incubating) Proposal

[Myrle Krantz]

My initial thought was: this should go straight to TLP: Training should be
done by people who know what they're training about: whether it be the
Apache Way or a specific project.  All the committers will likely be people
who've at least reached committer status in a project, and most of them
will probably be ASF members.

But then I thought again: developing effective materials will require
contact to the users of those materials.  What better place to find people
to QA training materials and approaches than in the incubator?  I think a
training project would benefit from incubator participation in a different
manner than most projects do, but I do think starting in the incubator (and
possibly, after discussion, even staying there) might be a good approach
for this project.

Best Regards,
Myrle

On Fri, Feb 8, 2019 at 10:34 AM Sönke Liebau
 wrote:

> Hi,
>
> after spending some time thinking about this I also tend towards the
> Incubator route as I am sure this will help build and grow an active
> community and processes.
>
> Best regards,
> Sönke
>
> On Fri, Feb 8, 2019 at 6:38 AM Justin Mclean 
> wrote:
> >
> > 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
> >
>
>
> --
> Sönke Liebau
> Partner
> Tel. +49 179 7940878
> OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Aw: Re: Tying Dockerhub into development and release management

[Jochen Theodorou]

> Gesendet: Freitag, 08. Februar 2019 um 04:58 Uhr
> Von: "Dave Fisher" 
> An: general@incubator.apache.org
> Betreff: Re: Tying Dockerhub into development and release management
[...]
> > 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?

Question: "releasing artifacts that have not been vetted through the ASF 
release policy" does also include Docker images based on official releases? (I 
know the thread also talked about nightlies and such, that is why it is not 
100% clear to me here)

bye Jochen

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

Re: [DISCUSS] Training (incubating) Proposal

[Sönke Liebau]

Hi,

after spending some time thinking about this I also tend towards the
Incubator route as I am sure this will help build and grow an active
community and processes.

Best regards,
Sönke

On Fri, Feb 8, 2019 at 6:38 AM Justin Mclean  wrote:
>
> 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
>


-- 
Sönke Liebau
Partner
Tel. +49 179 7940878
OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany

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

Re: Suitable project name search (was: [PROPOSAL] New blockchain project: Cava)

[Pierre Smits]

Hi Antoine,

First of all: thank you for the LinkedIn accept.

More information about the PNS (Podling Name Search) can be found via [1].

After having yourself familiarised with that, I suggest to register a JIRA
ticket with project 'PODLING NAME SEARCH' for the new project name, see
[2]. I
 also suggest to browse through a few of the open tickets to get a gist of
what steps to take.

[1] https://incubator.apache.org/guides/names.html
[2] https://issues.apache.org/jira/projects/PODLINGNAMESEARCH

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 Fri, Feb 8, 2019 at 3:03 AM Antoine Toulme  wrote:

> [going off-list]
>
> How should we conduct the name search?
>
> I have a few names I can submit. I can push for one if that makes sense.
>
> I am looking for previous discussions on the list, but nothing close to an
> open name search seems to have happened there.
>
> Please help?
>
> Cheers,
>
> Antoine