Scanoss guide video for code duplication audit

2024-04-28 Thread Shawn Yang
Hi everyone,

I recorded a video about how to use Scanoss to audit the code.

Hope it can be useful for other people and podlings to inspect their code,
and make the release more efficient:
 Screen Recording 2024-04-29 at 12.46.08.mov

-
Best regards,
Chaokun Yang


Re: Questions about a new project entering Apache Incubator

2024-04-28 Thread rat O
Hi Justin Mclean,

As an ordinary developer outside the Apache organization, I don't know much 
about the internal management rules of Apache, so I can only say a few thoughts 
from an outsider's point of view.

My thoughts are simple:
1. Based on the long-term attention to the Apache project and the long-term 
Apache naming approach, when the project name has incubator- prefix, it allows 
me to know the fastest maturity of the project, very direct and convenient.
2. Now most of the project incubation in the project name have incubator-, 
suddenly began to no longer mandatory to write the prefix, for the emergence of 
the name of the few incubation projects without incubator-, will let most of 
the non-Apache developers like me is very confusing and skeptical, to increase 
the burden of further understanding of the situation.

Therefore, I prefer the original approach: use the incubator- prefix for the 
names of incubating projects. If my previous views were shallow, please forgive 
me and ignore this reply.



> On 2024/04/23 00:13:41 Justin Mclean wrote:

> HI,

>

> So, I had an informal chat with Infra, and they don't care which one they do, 
> but is it some work for them to change from “incubator-foo” to “foo” on 
> graduation. I’m curious as to why some people in this thread think this is a 
> big issue if the project clearly states it is an incubating project. I will 
> note that Hertzbeat put the GitHub name in their propopal, and no one said 
> anything about it.

>

> Kind Regards,

> Justin

> -

> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org

> For additional commands, e-mail: general-h...@incubator.apache.org

>

>

>> From: Sheng Wu 
>> Sent: Monday, April 22, 2024 11:46 PM
>> To: general@incubator.apache.org ; 
>> d...@armoro.apache.org ; d...@hertzbeat.apache.org 
>> 
>> Subject: Re: Questions about a new project entering Apache Incubator
>>
>> With no further update, the consensus is clear from most that.
>>
>> The podlings should have `incubator-` prefix as most other projects followed.
>>
>> Armoro and Hertzbeat PPMC team, please fix this.
>>
>> Sheng Wu 吴晟
>> Twitter, wusheng1108



Re: Verification of download pages and links

2024-04-28 Thread tison
> The link to the source download and keys and hashes is broken.

Thank you! File [1] to fix it.

[1] https://github.com/apache/opendal/pull/4547

This shows the necessity of previewing the download page. At least since we
provide it, we should ensure its correctness.

Best,
tison.


Justin Mclean  于2024年4月29日周一 08:15写道:

> Hi,
>
> > Here is a patch to cover a minimal download page [1], which is derived
> from
> > OpenDAL's download page [2]. Welcome to leave comments if you find any
> > issues or things we can improve on.
> >
> > [1] https://github.com/apache/datafusion/pull/10271
> > [2] https://opendal.apache.org/download
>
> The link to the source download and keys and hashes is broken.
>
> Kind Regards,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


Re: Verification of download pages and links

2024-04-28 Thread Justin Mclean
Hi,

> Here is a patch to cover a minimal download page [1], which is derived from
> OpenDAL's download page [2]. Welcome to leave comments if you find any
> issues or things we can improve on.
> 
> [1] https://github.com/apache/datafusion/pull/10271
> [2] https://opendal.apache.org/download

The link to the source download and keys and hashes is broken.

Kind Regards,
Justin

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



Re: Verification of download pages and links

2024-04-28 Thread sebb
On Sun, 28 Apr 2024 at 19:46, Dave Fisher  wrote:
>
>
>
> > On Apr 28, 2024, at 9:58 AM, tison  wrote:
> >
> > Thank you!
> >
> > I found there is no rationale for these links, and thus, it's quite a bit
> > challenging in memory.
> >
> > IIRC the closer.lua script is for selecting the most proper CDN for
> > source/binary bundles in use. They can, technically, work for SHASUM and
> > signatures also. Why do we use https://downloads.apache.org for the latter
> > two?
>
> Historically we had a mirror network and closer.lua picked out a mirror near 
> you. In order to be sure that the download source or binary on the mirror was 
> not altered on (or on its way to or from) the mirror, the detached signature 
> and checksums must be served from ASF controlled resources.
>
> Whether or not this still makes sense is a discussion for Infra since they 
> are charged with enforcing and supporting the release distribution policy.

As it stands, the policy requires direct links for sigs and hashes and
closer.lua for artifacts.

https://infra.apache.org/release-distribution.html#download-links

> Best,
> Dave
>
> >
> > Best,
> > tison.
> >
> >
> > sebb  于2024年4月29日周一 00:34写道:
> >
> >> On Sun, 28 Apr 2024 at 15:38, tison  wrote:
> >>>
> >>> Yeah. I support that we always need to release sources on our platform.
> >>>
> >>> Given the links to downloads.apache.org, archive.apache.org,
> >>> https://www.apache.org/dyn/closer.lua, can be unintuitive for users, I
> >>> agree that we can have a simple Download page for such library-only
> >>> projects.
> >>
> >> The download page can also be used for links to release notes, and to
> >> provide other support information.
> >>
> >>> Here is a patch to cover a minimal download page [1], which is derived
> >> from
> >>> OpenDAL's download page [2]. Welcome to leave comments if you find any
> >>> issues or things we can improve on.
> >>>
> >>> [1] https://github.com/apache/datafusion/pull/10271
> >>
> >> The closer.lua script is only intended for the source and binary bundles.
> >>
> >> The sigs and hashes (and KEYS) should link directly to
> >> https://downloads.apache.org/datafusion/...
> >>
> >>> [2] https://opendal.apache.org/download
> >>>
> >>> Best,
> >>> tison.
> >>>
> >>>
> >>> Justin Mclean  于2024年4月28日周日 10:02写道:
> >>>
>  Hi,
> 
>  Projects need to make source releases on ASF infrastructure and have a
>  download page for good reasons. Some users need a place to verify and
>  download a trusted release. Having it hosted on ASF infrastructure
> >> means
>  people can 100% trust it, unlike 3rd party providers. 3rd party
> >> providers
>  have gone rogue in the past (e.g . Source Forge), disappeared (e.g.
> >> Google
>  Code), or had multiple serious issues (e.g. NPM). Also by placing a
> >> release
>  in the ASF distribution area / a project download page gives confidence
>  that the ASF release process has been followed and that it is not a
> >> release
>  by a 3rd party or an unofficial release of some sort.  IMO, all
> >> projects
>  need to have a download page, even if it may not be used by the
> >> majority of
>  users.
> 
>  Kind Regards,
>  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
>

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



Re: Verification of download pages and links

2024-04-28 Thread Dave Fisher
Tison,

> On Apr 28, 2024, at 12:10 PM, tison  wrote:
> 
> Thank you, Dave :D
> 
> It gives a reason. I'm OK with this explanation now so that I won't bring
> it to the INFRA.
> 
> Back to the original purpose of this thread, I suggest:
> 
> 1. Go through our Incubator Guide and find if we have some references to
> this release distribution policy (maybe in [1][2]). Then, make this
> requirement clear and discoverable.
> 2. Try to implement the preview feature and add the verify items in one
> project so later we use it as a reference.
> 
> [1] https://incubator.apache.org/guides/distribution.html
> [2] https://incubator.apache.org/guides/releasemanagement.html

FYI - The incubator clutch analysis includes generated release download 
sections for all releases it finds in the incubator directory on the 
dist.apache.org svn repository:

For example: https://incubator.apache.org/clutch/streampark.html

See https://svn.apache.org/repos/asf/incubator/public/trunk/clutch2status.py:

print("== Releases",file=f)
print("",file=f)
print("=== Current",file=f)
print("",file=f)
hasKeys = False
url1 = urls['keys']
if len(url1) > 0:
hasKeys = True
print("*{0}[Signing Keys]*".format(url1),file=f)
url1 = "/".join(url1.split("/")[:-1])+"/"
print("",file=f)
print("It is essential that you verify the integrity of release 
downloads. See https://www.apache.org/dyn/closer.cgi#verify[instructions 
here]",file=f)
else:
print("*No PGP Signing Keys*",file=f)
jj = 0
fsize = 0
if len(projects[k]['releases']) > 0 and hasKeys:
j = 1
for r in sorted(projects[k]['releases']):
path = 
"{0}/{1}/{2}".format(k,projects[k]['releases'][r]['folder'],r)
print("",file=f)
print(" {0}: {1}".format(j,r),file=f)
print("",file=f)
print("| *{0}{1}[Download]* | *{2}{3}.asc[Signature]* | 
*{4}{5}.{6}[Hash]* | {7}".format(
  "https://www.apache.org/dyn/closer.lua/incubator/;, path,
  "https://downloads.apache.org/incubator/;, path,
  "https://downloads.apache.org/incubator/;, path, 
projects[k]['releases'][r]['hash'],
  r),file=f)
print("-- Filesize: 
{0}".format(humanbytes(float(projects[k]['releases'][r]['size']))),file=f)
print("-- Released: {0} by {1} in {2}".format(
  projects[k]['releases'][r]['dtm'],
  projects[k]['releases'][r]['user'],
  projects[k]['releases'][r]['revision']),file=f)
j += 1
fsize += int(projects[k]['releases'][r]['size'])
print("",file=f)
print("Total size of all downloads = 
{0}".format(humanbytes(float(fsize))),file=f)
elif hasKeys:
print(NO_RELEASES.format(projects[k]['fullName']),file=f)
print("",file=f)

And https://svn.apache.org/repos/asf/incubator/public/trunk/clutch2.py

with osPopen(['svn', 'ls', '-Rv', 
'https://dist.apache.org/repos/dist/release/incubator']) as s:
for line in s.stdout:
line = line.strip()
if line[-1:] == '/':
# skip directories  

   
continue
listing = line.split(' ')
revision = "r{0}".format(listing[0])
user = listing[1]
if listing[-6] == '':
dtm1 = datetime.datetime.strptime(" ".join(listing[-4:-2])+" 
"+str(gatherYear),"%b %d %Y")
if dtm1 > gatherDate:
dtm1 = datetime.datetime.strptime(" ".join(listing[-4:-2])+" 
"+str(gatherYear-1),"%b %d %Y")
fsize = listing[-5]
else:
dtm1 = datetime.datetime.strptime(" ".join(listing[-5:-1]),"%b %d 
%Y")
fsize = listing[-6]
dtm = dtm1.strftime("%m/%d/%Y")
line = listing[-1]
releasesListing[line] = {
'user': user,
'revision': revision,
'dtm': dtm,
'size': fsize
}
fields = line.split('/')
podling = fields[0]
distareas[podling] = True
file = fields[-1]
if file:
if re.search('KEYS(\.txt)?$', file):
keysList[podling] = 
"{0}/{1}".format("https://downloads.apache.org/incubator;, line)
if re.search('\.(asc|sig)$', file, flags=re.IGNORECASE):
path = "/".join(fields[1:])
if optionVerbose:
print("DEBUG: {0} - {1}".format(podling,path))
try:
if distributions[podling]:
distributions[podling].append(path)
except:
distributions[podling] = []
distributions[podling].append(path)
if re.search('incubat(ing|or)', file, flags=re.IGNORECASE):
releases[podling] = True
 

Re: Verification of download pages and links

2024-04-28 Thread tison
Thank you, Dave :D

It gives a reason. I'm OK with this explanation now so that I won't bring
it to the INFRA.

Back to the original purpose of this thread, I suggest:

1. Go through our Incubator Guide and find if we have some references to
this release distribution policy (maybe in [1][2]). Then, make this
requirement clear and discoverable.
2. Try to implement the preview feature and add the verify items in one
project so later we use it as a reference.

[1] https://incubator.apache.org/guides/distribution.html
[2] https://incubator.apache.org/guides/releasemanagement.html

I'll try my best to find time to work on it, but I don't declare it an
assignment.

Best,
tison.


Dave Fisher  于2024年4月29日周一 02:46写道:

>
>
> > On Apr 28, 2024, at 9:58 AM, tison  wrote:
> >
> > Thank you!
> >
> > I found there is no rationale for these links, and thus, it's quite a bit
> > challenging in memory.
> >
> > IIRC the closer.lua script is for selecting the most proper CDN for
> > source/binary bundles in use. They can, technically, work for SHASUM and
> > signatures also. Why do we use https://downloads.apache.org for the
> latter
> > two?
>
> Historically we had a mirror network and closer.lua picked out a mirror
> near you. In order to be sure that the download source or binary on the
> mirror was not altered on (or on its way to or from) the mirror, the
> detached signature and checksums must be served from ASF controlled
> resources.
>
> Whether or not this still makes sense is a discussion for Infra since they
> are charged with enforcing and supporting the release distribution policy.
>
> Best,
> Dave
>
> >
> > Best,
> > tison.
> >
> >
> > sebb  于2024年4月29日周一 00:34写道:
> >
> >> On Sun, 28 Apr 2024 at 15:38, tison  wrote:
> >>>
> >>> Yeah. I support that we always need to release sources on our platform.
> >>>
> >>> Given the links to downloads.apache.org, archive.apache.org,
> >>> https://www.apache.org/dyn/closer.lua, can be unintuitive for users, I
> >>> agree that we can have a simple Download page for such library-only
> >>> projects.
> >>
> >> The download page can also be used for links to release notes, and to
> >> provide other support information.
> >>
> >>> Here is a patch to cover a minimal download page [1], which is derived
> >> from
> >>> OpenDAL's download page [2]. Welcome to leave comments if you find any
> >>> issues or things we can improve on.
> >>>
> >>> [1] https://github.com/apache/datafusion/pull/10271
> >>
> >> The closer.lua script is only intended for the source and binary
> bundles.
> >>
> >> The sigs and hashes (and KEYS) should link directly to
> >> https://downloads.apache.org/datafusion/...
> >>
> >>> [2] https://opendal.apache.org/download
> >>>
> >>> Best,
> >>> tison.
> >>>
> >>>
> >>> Justin Mclean  于2024年4月28日周日 10:02写道:
> >>>
>  Hi,
> 
>  Projects need to make source releases on ASF infrastructure and have a
>  download page for good reasons. Some users need a place to verify and
>  download a trusted release. Having it hosted on ASF infrastructure
> >> means
>  people can 100% trust it, unlike 3rd party providers. 3rd party
> >> providers
>  have gone rogue in the past (e.g . Source Forge), disappeared (e.g.
> >> Google
>  Code), or had multiple serious issues (e.g. NPM). Also by placing a
> >> release
>  in the ASF distribution area / a project download page gives
> confidence
>  that the ASF release process has been followed and that it is not a
> >> release
>  by a 3rd party or an unofficial release of some sort.  IMO, all
> >> projects
>  need to have a download page, even if it may not be used by the
> >> majority of
>  users.
> 
>  Kind Regards,
>  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: Verification of download pages and links

2024-04-28 Thread Dave Fisher



> On Apr 28, 2024, at 9:58 AM, tison  wrote:
> 
> Thank you!
> 
> I found there is no rationale for these links, and thus, it's quite a bit
> challenging in memory.
> 
> IIRC the closer.lua script is for selecting the most proper CDN for
> source/binary bundles in use. They can, technically, work for SHASUM and
> signatures also. Why do we use https://downloads.apache.org for the latter
> two?

Historically we had a mirror network and closer.lua picked out a mirror near 
you. In order to be sure that the download source or binary on the mirror was 
not altered on (or on its way to or from) the mirror, the detached signature 
and checksums must be served from ASF controlled resources.

Whether or not this still makes sense is a discussion for Infra since they are 
charged with enforcing and supporting the release distribution policy.

Best,
Dave

> 
> Best,
> tison.
> 
> 
> sebb  于2024年4月29日周一 00:34写道:
> 
>> On Sun, 28 Apr 2024 at 15:38, tison  wrote:
>>> 
>>> Yeah. I support that we always need to release sources on our platform.
>>> 
>>> Given the links to downloads.apache.org, archive.apache.org,
>>> https://www.apache.org/dyn/closer.lua, can be unintuitive for users, I
>>> agree that we can have a simple Download page for such library-only
>>> projects.
>> 
>> The download page can also be used for links to release notes, and to
>> provide other support information.
>> 
>>> Here is a patch to cover a minimal download page [1], which is derived
>> from
>>> OpenDAL's download page [2]. Welcome to leave comments if you find any
>>> issues or things we can improve on.
>>> 
>>> [1] https://github.com/apache/datafusion/pull/10271
>> 
>> The closer.lua script is only intended for the source and binary bundles.
>> 
>> The sigs and hashes (and KEYS) should link directly to
>> https://downloads.apache.org/datafusion/...
>> 
>>> [2] https://opendal.apache.org/download
>>> 
>>> Best,
>>> tison.
>>> 
>>> 
>>> Justin Mclean  于2024年4月28日周日 10:02写道:
>>> 
 Hi,
 
 Projects need to make source releases on ASF infrastructure and have a
 download page for good reasons. Some users need a place to verify and
 download a trusted release. Having it hosted on ASF infrastructure
>> means
 people can 100% trust it, unlike 3rd party providers. 3rd party
>> providers
 have gone rogue in the past (e.g . Source Forge), disappeared (e.g.
>> Google
 Code), or had multiple serious issues (e.g. NPM). Also by placing a
>> release
 in the ASF distribution area / a project download page gives confidence
 that the ASF release process has been followed and that it is not a
>> release
 by a 3rd party or an unofficial release of some sort.  IMO, all
>> projects
 need to have a download page, even if it may not be used by the
>> majority of
 users.
 
 Kind Regards,
 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: Verification of download pages and links

2024-04-28 Thread tison
Thank you!

I found there is no rationale for these links, and thus, it's quite a bit
challenging in memory.

IIRC the closer.lua script is for selecting the most proper CDN for
source/binary bundles in use. They can, technically, work for SHASUM and
signatures also. Why do we use https://downloads.apache.org for the latter
two?

Best,
tison.


sebb  于2024年4月29日周一 00:34写道:

> On Sun, 28 Apr 2024 at 15:38, tison  wrote:
> >
> > Yeah. I support that we always need to release sources on our platform.
> >
> > Given the links to downloads.apache.org, archive.apache.org,
> > https://www.apache.org/dyn/closer.lua, can be unintuitive for users, I
> > agree that we can have a simple Download page for such library-only
> > projects.
>
> The download page can also be used for links to release notes, and to
> provide other support information.
>
> > Here is a patch to cover a minimal download page [1], which is derived
> from
> > OpenDAL's download page [2]. Welcome to leave comments if you find any
> > issues or things we can improve on.
> >
> > [1] https://github.com/apache/datafusion/pull/10271
>
> The closer.lua script is only intended for the source and binary bundles.
>
> The sigs and hashes (and KEYS) should link directly to
> https://downloads.apache.org/datafusion/...
>
> > [2] https://opendal.apache.org/download
> >
> > Best,
> > tison.
> >
> >
> > Justin Mclean  于2024年4月28日周日 10:02写道:
> >
> > > Hi,
> > >
> > > Projects need to make source releases on ASF infrastructure and have a
> > > download page for good reasons. Some users need a place to verify and
> > > download a trusted release. Having it hosted on ASF infrastructure
> means
> > > people can 100% trust it, unlike 3rd party providers. 3rd party
> providers
> > > have gone rogue in the past (e.g . Source Forge), disappeared (e.g.
> Google
> > > Code), or had multiple serious issues (e.g. NPM). Also by placing a
> release
> > > in the ASF distribution area / a project download page gives confidence
> > > that the ASF release process has been followed and that it is not a
> release
> > > by a 3rd party or an unofficial release of some sort.  IMO, all
> projects
> > > need to have a download page, even if it may not be used by the
> majority of
> > > users.
> > >
> > > Kind Regards,
> > > 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: Verification of download pages and links

2024-04-28 Thread sebb
On Sun, 28 Apr 2024 at 15:38, tison  wrote:
>
> Yeah. I support that we always need to release sources on our platform.
>
> Given the links to downloads.apache.org, archive.apache.org,
> https://www.apache.org/dyn/closer.lua, can be unintuitive for users, I
> agree that we can have a simple Download page for such library-only
> projects.

The download page can also be used for links to release notes, and to
provide other support information.

> Here is a patch to cover a minimal download page [1], which is derived from
> OpenDAL's download page [2]. Welcome to leave comments if you find any
> issues or things we can improve on.
>
> [1] https://github.com/apache/datafusion/pull/10271

The closer.lua script is only intended for the source and binary bundles.

The sigs and hashes (and KEYS) should link directly to
https://downloads.apache.org/datafusion/...

> [2] https://opendal.apache.org/download
>
> Best,
> tison.
>
>
> Justin Mclean  于2024年4月28日周日 10:02写道:
>
> > Hi,
> >
> > Projects need to make source releases on ASF infrastructure and have a
> > download page for good reasons. Some users need a place to verify and
> > download a trusted release. Having it hosted on ASF infrastructure means
> > people can 100% trust it, unlike 3rd party providers. 3rd party providers
> > have gone rogue in the past (e.g . Source Forge), disappeared (e.g. Google
> > Code), or had multiple serious issues (e.g. NPM). Also by placing a release
> > in the ASF distribution area / a project download page gives confidence
> > that the ASF release process has been followed and that it is not a release
> > by a 3rd party or an unofficial release of some sort.  IMO, all projects
> > need to have a download page, even if it may not be used by the majority of
> > users.
> >
> > Kind Regards,
> > 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: Verification of download pages and links

2024-04-28 Thread tison
Yeah. I support that we always need to release sources on our platform.

Given the links to downloads.apache.org, archive.apache.org,
https://www.apache.org/dyn/closer.lua, can be unintuitive for users, I
agree that we can have a simple Download page for such library-only
projects.

Here is a patch to cover a minimal download page [1], which is derived from
OpenDAL's download page [2]. Welcome to leave comments if you find any
issues or things we can improve on.

[1] https://github.com/apache/datafusion/pull/10271
[2] https://opendal.apache.org/download

Best,
tison.


Justin Mclean  于2024年4月28日周日 10:02写道:

> Hi,
>
> Projects need to make source releases on ASF infrastructure and have a
> download page for good reasons. Some users need a place to verify and
> download a trusted release. Having it hosted on ASF infrastructure means
> people can 100% trust it, unlike 3rd party providers. 3rd party providers
> have gone rogue in the past (e.g . Source Forge), disappeared (e.g. Google
> Code), or had multiple serious issues (e.g. NPM). Also by placing a release
> in the ASF distribution area / a project download page gives confidence
> that the ASF release process has been followed and that it is not a release
> by a 3rd party or an unofficial release of some sort.  IMO, all projects
> need to have a download page, even if it may not be used by the majority of
> users.
>
> Kind Regards,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


Re: [VOTE] Release Apache StreamPark(Incubating) 2.1.4-rc1

2024-04-28 Thread Suyan
+1 binding
Apache ID: suyanhanx

I checked:

[x] Download links are valid.
[x] Checksums and signatures.
gpg: Signature made Mon Apr 22 00:02:13 2024 CST
gpg:using RSA key B0AD51795657CF5C303FE79B5CEB5ECFD38791FF
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:  24  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 24u
gpg: next trustdb check due at 2024-05-25
gpg: Good signature from "lvshaokang (for apache StreamPark release
create at 20240421) " [ultimate]

[x] LICENSE/NOTICE files exist
[x] No unexpected binary files
[x] All source files have ASF headers
[x] Can compile from source on macOS(arm64)
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  14:28 min
[INFO] Finished at: 2024-04-28T19:31:40+08:00
[INFO] 

[StreamPark] StreamPark project build successful!
info: package mode @ mixed, scala-2.12


A small problem:

This is the build tip in your vote email template:

> How to Build:
>
> 1) clone source code:
> > git clone -b v2.1.4-rc1 g...@github.com:apache/incubator-streampark.git
>
> 2) build project:
> > cd incubator-streampark && sh ./build.sh

To verify the release here is supposed to verify the release candidate
stored at the Apache distribution, right?
Is it wrong to verify the code repo downloaded by git clone?


Sincerely,
Suyan

Shaokang Lv  于2024年4月25日周四 16:02写道:
>
> Hello Incubator Community:
>
> This is a call for a vote to release Apache StreamPark(Incubating) version
> 2.1.4-RC1.
> The Apache StreamPark community has voted on and approved a proposal to
> release Apache StreamPark(Incubating) version 2.1.4-RC1.
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> Apache StreamPark, Make stream processing easier! Easy-to-use streaming
> application development framework and operation platform.
>
> StreamPark community vote thread:
> https://lists.apache.org/thread/v4yx0f0xgmr53g795cgn4ppblytqhvqh
>
> Vote result thread:
> https://lists.apache.org/thread/f85yn1j6y6k9fcmc8qvl7ltob706twcs
>
> The release candidate:
> https://dist.apache.org/repos/dist/dev/incubator/streampark/2.1.4-RC1/
>
> Git tag for the release:
> https://github.com/apache/incubator-streampark/releases/tag/v2.1.4-rc1
>
> The artifacts signed with PGP key [D38791FF], corresponding to [
> lvshaok...@apache.org], that can be found in keys file:
> https://downloads.apache.org/incubator/streampark/KEYS
>
> The vote will be open for at least 72 hours or until the necessary number
> of votes are reached.
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> More detailed checklist please refer:
> •
> https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist
>
> Steps to validate the release, Please refer to:
> • https://www.apache.org/info/verification.html
> • https://streampark.apache.org/community/release/how_to_verify_release
>
>
> How to Build:
>
> 1) clone source code:
> > git clone -b v2.1.4-rc1 g...@github.com:apache/incubator-streampark.git
>
> 2) build project:
> > cd incubator-streampark && sh ./build.sh
>
>
> Thanks,
>
> On behalf of Apache StreamPark(Incubating) community
>
>
> Best,
> Shaokang Lv

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



Re: [ANNOUNCE] Apache Baremaps 0.7.3 (incubating) released

2024-04-28 Thread sebb
On Sun, 28 Apr 2024 at 10:48, Bertil Chapuis  wrote:
>
> Thanks a lot for taking the time to check the announcement. I cross checked 
> everything during the vote and then let my guard down for the announcement.
>
> I now fixed the template for the announcement on our GitHub repository:
> https://github.com/apache/incubator-baremaps/blob/9bb6650142a380f91f4294ed63e53df84001bef3/RELEASE.md?plain=1#L161

The link to https://www.apache.org/dyn/closer.lua/incubator/baremaps//
is not appropriate for an announce email, and is superfluous as the
link is on the download page,

> I also updated the download page to fix the copy paste error:
> https://baremaps.apache.org/download/release-0.7.3

ACK

> hopefully, our next release will go smoothly.
>
>
> > On 28 Apr 2024, at 00:33, sebb  wrote:
> >
> > On Sat, 27 Apr 2024 at 21:17, Bertil Chapuis  wrote:
> >>
> >> Hello Everyone,
> >>
> >> The Apache Baremaps community is pleased to announce the release of Apache 
> >> Baremaps 0.7.3 (incubating). Thank you to everyone who contributed to this 
> >> release.
> >>
> >> Apache Baremaps is a toolkit and a set of infrastructure components for 
> >> creating, publishing, and operating online maps. This new release 
> >> addresses most licensing concerns identified when joining the incubator, 
> >> which is a significant step for the project. In addition, there is now 
> >> support for PMTiles, which enables low-cost and low-maintenance map 
> >> applications. Finally, significant improvements were made to enable the 
> >> creation of vector tiles from the Daylight Map Distribution.
> >>
> >> We are looking to grow our community and welcome new contributors. If you 
> >> are interested in contributing to the project, please contact us on the 
> >> mailing list or on GitHub. We will be happy to help you get started.
> >>
> >> The release notes are available here:
> >> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.3
> >>
> >> The artifacts are available here:
> >> https://dist.apache.org/repos/dist/release/incubator/baremaps/0.7.3
> >
> > Sorry, but that is not a valid download page.
> >
> > The dist.apache.org host is only intended for staging a release, and
> > is not intended for general downloads.
> > Also download pages must have links to KEYS, sigs and hashes, and use
> > closer.lua for artifact links.
> >
> > It looks like the website has a suitable web page here:
> > https://baremaps.apache.org/download/release-0.7.3
> >
> > Please make sure such pages are used in release announcements!
> >
> > BTW, the download page has a copy-paste error: there are two instances
> > of the text:
> >
> > "The SHA checksum for the source distribution is available here:"
> >
> > The second instance actually relates to the binary distribution.
> > Similarly for the PGP signature.
> >
> >> The hashes of the artifacts are as follows:
> >> 3c399626c13e2fc40984d21581a747d6ad2b703c08206ceaf3bf1819551e7a99ca7cfbfae3652de8fa06ccc7a6f06f086277c5ed52574636d8b043f24d85f5cf
> >>   ./apache-baremaps-0.7.3-incubating-src.tar.gz
> >> 3c3213b8cb925eeb67734fbae55369e8c37b6c42cb62f498a62e752b969928e16db522f44e2bf0e8542175e031e9ebe64170bafd97b5cfd3e1636498bf12c15a
> >>   ./apache-baremaps-0.7.3-incubating-bin.tar.gz
> >>
> >> The repository is available here:
> >> https://github.com/apache/incubator-baremaps
> >>
> >> The documentation is available here:
> >> https://baremaps.apache.org
> >>
> >> The mailing list is available here:
> >> https://lists.apache.org/list.html?d...@baremaps.apache.org
> >>
> >> The issue tracker is available here:
> >> https://github.com/apache/incubator-baremaps/issues
> >>
> >> Best regards,
> >>
> >> Bertil Chapuis
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org
> > For additional commands, e-mail: dev-h...@baremaps.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: [ANNOUNCE] Apache Baremaps 0.7.3 (incubating) released

2024-04-28 Thread Bertil Chapuis
Thanks a lot for taking the time to check the announcement. I cross checked 
everything during the vote and then let my guard down for the announcement.

I now fixed the template for the announcement on our GitHub repository:
https://github.com/apache/incubator-baremaps/blob/9bb6650142a380f91f4294ed63e53df84001bef3/RELEASE.md?plain=1#L161

I also updated the download page to fix the copy paste error:
https://baremaps.apache.org/download/release-0.7.3

hopefully, our next release will go smoothly.


> On 28 Apr 2024, at 00:33, sebb  wrote:
> 
> On Sat, 27 Apr 2024 at 21:17, Bertil Chapuis  wrote:
>> 
>> Hello Everyone,
>> 
>> The Apache Baremaps community is pleased to announce the release of Apache 
>> Baremaps 0.7.3 (incubating). Thank you to everyone who contributed to this 
>> release.
>> 
>> Apache Baremaps is a toolkit and a set of infrastructure components for 
>> creating, publishing, and operating online maps. This new release addresses 
>> most licensing concerns identified when joining the incubator, which is a 
>> significant step for the project. In addition, there is now support for 
>> PMTiles, which enables low-cost and low-maintenance map applications. 
>> Finally, significant improvements were made to enable the creation of vector 
>> tiles from the Daylight Map Distribution.
>> 
>> We are looking to grow our community and welcome new contributors. If you 
>> are interested in contributing to the project, please contact us on the 
>> mailing list or on GitHub. We will be happy to help you get started.
>> 
>> The release notes are available here:
>> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.3
>> 
>> The artifacts are available here:
>> https://dist.apache.org/repos/dist/release/incubator/baremaps/0.7.3
> 
> Sorry, but that is not a valid download page.
> 
> The dist.apache.org host is only intended for staging a release, and
> is not intended for general downloads.
> Also download pages must have links to KEYS, sigs and hashes, and use
> closer.lua for artifact links.
> 
> It looks like the website has a suitable web page here:
> https://baremaps.apache.org/download/release-0.7.3
> 
> Please make sure such pages are used in release announcements!
> 
> BTW, the download page has a copy-paste error: there are two instances
> of the text:
> 
> "The SHA checksum for the source distribution is available here:"
> 
> The second instance actually relates to the binary distribution.
> Similarly for the PGP signature.
> 
>> The hashes of the artifacts are as follows:
>> 3c399626c13e2fc40984d21581a747d6ad2b703c08206ceaf3bf1819551e7a99ca7cfbfae3652de8fa06ccc7a6f06f086277c5ed52574636d8b043f24d85f5cf
>>   ./apache-baremaps-0.7.3-incubating-src.tar.gz
>> 3c3213b8cb925eeb67734fbae55369e8c37b6c42cb62f498a62e752b969928e16db522f44e2bf0e8542175e031e9ebe64170bafd97b5cfd3e1636498bf12c15a
>>   ./apache-baremaps-0.7.3-incubating-bin.tar.gz
>> 
>> The repository is available here:
>> https://github.com/apache/incubator-baremaps
>> 
>> The documentation is available here:
>> https://baremaps.apache.org
>> 
>> The mailing list is available here:
>> https://lists.apache.org/list.html?d...@baremaps.apache.org
>> 
>> The issue tracker is available here:
>> https://github.com/apache/incubator-baremaps/issues
>> 
>> Best regards,
>> 
>> Bertil Chapuis
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org
> For additional commands, e-mail: dev-h...@baremaps.apache.org



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