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
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,
> 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
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
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
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
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]).
> 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,
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
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
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
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
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
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
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
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]
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
17 matches
Mail list logo
