Re: Verification of download pages and links
On Wed, 1 May 2024 at 18:14, tison wrote: > > Hi Sebb, > > I'm trying to make a reference in the next OpenDAL release, that staging > the download pages and links. > > Here is a technical issue. Before the release is out, which link should be > used? IIUC we can use the link at [1]. But it doesn't follow the INFRA > policy for formal releases. However, before the release it out, no artifact > of the specific version is available at [2] or [3]. I think the staging download page should show the intended final link values. These will not point to an actual file (apart from KEYS), but it should still be possible to check that the links have the correct format. > [1] https://dist.apache.org/repos/dist/dev/opendal/ > [2] https://www.apache.org/dyn/closer.lua/opendal/ > [3] https://downloads.apache.org/opendal/ > > This is the ongoing patch [4] where I left a TODO inline. > > [4] https://github.com/apache/opendal/pull/4565 > > Best, > tison. > > > tison 于2024年4月29日周一 08:43写道： > > > > 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 > >> > >> - 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
Hi Sebb, I'm trying to make a reference in the next OpenDAL release, that staging the download pages and links. Here is a technical issue. Before the release is out, which link should be used? IIUC we can use the link at [1]. But it doesn't follow the INFRA policy for formal releases. However, before the release it out, no artifact of the specific version is available at [2] or [3]. [1] https://dist.apache.org/repos/dist/dev/opendal/ [2] https://www.apache.org/dyn/closer.lua/opendal/ [3] https://downloads.apache.org/opendal/ This is the ongoing patch [4] where I left a TODO inline. [4] https://github.com/apache/opendal/pull/4565 Best, tison. tison 于2024年4月29日周一 08:43写道： > > 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
> 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
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
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
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
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
> 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
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
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
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: Verification of download pages and links
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: Verification of download pages and links
On the one hand, we release sources. We should ensure that the source code is released (on our platform), or else the pivotal character "open source" is challenged. On the other hand, library users do always "download" the software with a dependency manager, and thus, a heavy download page may never be used. So it's not surprising PMC members would not want to do something unhelpful for the real users. Best, tison. tison 于2024年4月26日周五 02:01写道： > Here is a new situation for projects that may not carry source releases > heavily: [1] > > [1] https://github.com/apache/datafusion/pull/10233/files#r1579895024 > > They may not even maintain a download page, but just leverage > https://downloads.apache.org/. > > I suggest we rethink the form of distribution and whether it's necessary > to have a customized download page on the website. > > Best, > tison. > > > sebb 于2024年4月23日周二 20:47写道： > >> On Tue, 23 Apr 2024 at 13:25, tison wrote: >> > >> > Thanks for starting this thread and thanks a lot for verifying the >> download >> > page for a lot of podlings! >> > >> > For previewing a staging website, with .asf.yaml config, there is a way >> [1] >> > to do so self-served by any (P)PMC. And I agree that we should spread >> such >> > practices to every project. >> > >> > [1] >> > >> https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#staging-a-web-site-preview-domain >> > >> > For example, to recommend every project's verifying release docs (like >> [2]) >> > have a check item to verify the (staged) download page. And instruct >> the RM >> > to build such a staged page. >> > >> > [2] https://opendal.apache.org/community/committers/verify >> >> VOTE emails will need to include: >> - a link to the preview site >> - checklist for reviewing the download page: >> as well as the required contents of the page itself, reviewers should >> check that it is easy to find the download page from the home page. >> >> > Best, >> > tison. >> > >> > >> > sebb 于2024年4月23日周二 19:52写道： >> > >> > > The primary mission of the ASF is to produce open SOURCE, so it seems >> > > to me that an essential part of a release is a download page with >> > > properly constituted links to the source bundle and the associated >> > > download verification files. >> > > >> > > However, no attention seems to be given to this aspect of a release, >> > > vital though it is. >> > > >> > > Obviously, the current download page cannot be updated with the >> > > details of an upcoming release, but there are ways of providing access >> > > to a staging website which shows how the page will look. >> > > >> > > Sebb >> > > >> > > - >> > > 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
Here is a new situation for projects that may not carry source releases heavily: [1] [1] https://github.com/apache/datafusion/pull/10233/files#r1579895024 They may not even maintain a download page, but just leverage https://downloads.apache.org/. I suggest we rethink the form of distribution and whether it's necessary to have a customized download page on the website. Best, tison. sebb 于2024年4月23日周二 20:47写道： > On Tue, 23 Apr 2024 at 13:25, tison wrote: > > > > Thanks for starting this thread and thanks a lot for verifying the > download > > page for a lot of podlings! > > > > For previewing a staging website, with .asf.yaml config, there is a way > [1] > > to do so self-served by any (P)PMC. And I agree that we should spread > such > > practices to every project. > > > > [1] > > > https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#staging-a-web-site-preview-domain > > > > For example, to recommend every project's verifying release docs (like > [2]) > > have a check item to verify the (staged) download page. And instruct the > RM > > to build such a staged page. > > > > [2] https://opendal.apache.org/community/committers/verify > > VOTE emails will need to include: > - a link to the preview site > - checklist for reviewing the download page: > as well as the required contents of the page itself, reviewers should > check that it is easy to find the download page from the home page. > > > Best, > > tison. > > > > > > sebb 于2024年4月23日周二 19:52写道： > > > > > The primary mission of the ASF is to produce open SOURCE, so it seems > > > to me that an essential part of a release is a download page with > > > properly constituted links to the source bundle and the associated > > > download verification files. > > > > > > However, no attention seems to be given to this aspect of a release, > > > vital though it is. > > > > > > Obviously, the current download page cannot be updated with the > > > details of an upcoming release, but there are ways of providing access > > > to a staging website which shows how the page will look. > > > > > > Sebb > > > > > > - > > > 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
On Tue, 23 Apr 2024 at 13:25, tison wrote: > > Thanks for starting this thread and thanks a lot for verifying the download > page for a lot of podlings! > > For previewing a staging website, with .asf.yaml config, there is a way [1] > to do so self-served by any (P)PMC. And I agree that we should spread such > practices to every project. > > [1] > https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#staging-a-web-site-preview-domain > > For example, to recommend every project's verifying release docs (like [2]) > have a check item to verify the (staged) download page. And instruct the RM > to build such a staged page. > > [2] https://opendal.apache.org/community/committers/verify VOTE emails will need to include: - a link to the preview site - checklist for reviewing the download page: as well as the required contents of the page itself, reviewers should check that it is easy to find the download page from the home page. > Best, > tison. > > > sebb 于2024年4月23日周二 19:52写道： > > > The primary mission of the ASF is to produce open SOURCE, so it seems > > to me that an essential part of a release is a download page with > > properly constituted links to the source bundle and the associated > > download verification files. > > > > However, no attention seems to be given to this aspect of a release, > > vital though it is. > > > > Obviously, the current download page cannot be updated with the > > details of an upcoming release, but there are ways of providing access > > to a staging website which shows how the page will look. > > > > Sebb > > > > - > > 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
Thanks for starting this thread and thanks a lot for verifying the download page for a lot of podlings! For previewing a staging website, with .asf.yaml config, there is a way [1] to do so self-served by any (P)PMC. And I agree that we should spread such practices to every project. [1] https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#staging-a-web-site-preview-domain For example, to recommend every project's verifying release docs (like [2]) have a check item to verify the (staged) download page. And instruct the RM to build such a staged page. [2] https://opendal.apache.org/community/committers/verify Best, tison. sebb 于2024年4月23日周二 19:52写道： > The primary mission of the ASF is to produce open SOURCE, so it seems > to me that an essential part of a release is a download page with > properly constituted links to the source bundle and the associated > download verification files. > > However, no attention seems to be given to this aspect of a release, > vital though it is. > > Obviously, the current download page cannot be updated with the > details of an upcoming release, but there are ways of providing access > to a staging website which shows how the page will look. > > Sebb > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Verification of download pages and links
The primary mission of the ASF is to produce open SOURCE, so it seems to me that an essential part of a release is a download page with properly constituted links to the source bundle and the associated download verification files. However, no attention seems to be given to this aspect of a release, vital though it is. Obviously, the current download page cannot be updated with the details of an upcoming release, but there are ways of providing access to a staging website which shows how the page will look. Sebb - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
