On Thu, May 7, 2026 at 2:04 AM Justin Mclean <[email protected]> wrote:
> Hi, > > Thanks for the detailed responses. A few follow-up points (with help from > the Policy MCP). > > closer.lua > > The closer.lua fix on your download page needs to be applied independently > of the 0.8.0 release. Per the ASF Release Policy [1], "Project download > pages must use a closer.lua script and not link directly to the main Apache > Web site." This is a separate issue from the dist directory problem. > > Yes. My point was that currently we don't have a single file corrrectly released that the closer.lua mechanism could forward to. So we can better fix this after we release 0.8.0 and possibly also correct the previous releases to appear where they should. > dist/dev vs dist/release > > This is more serious than a ticket to file later. Per the ASF Release > Policy [1], "A release isn't 'released' until the contents are in the > project's distribution directory, which is a subdirectory of > downloads.apache.org." If previous releases were only committed to > dist/dev and never moved to dist/release, they were never validly > distributed as ASF releases. > > I agree. This is not the end of the world, as the main point of those releases was exactly to practice the ASF release process. So we can conclude we need more practice. This 0.8.0 release is the first one with significant new work in it. (very) That said, it appears the files are still in dist/dev and have passed the necessary voting procedures, so we could simply copy them to the right place. I propose a debrief discussion on dev@otava can decide to do this, since it is a bit off topic for this voting thread to discuss other releases than 0.8.0. > Incubation disclaimer on GitHub and PyPI > > The DISCLAIMER file inside your release archives satisfies the artifact > requirement, but that's not the only surface the policy covers. The > Incubator Podling Policies [2] require that podlings "include a clear > disclaimer on their website and in all documentation, releases and release > announcements." The GitHub Releases page description and the PyPI project > page both function as release announcements and public-facing documentation > and need to carry the disclaimer text as well. > > Thanks. Referring to (2) I think our interpretation and approach was to make sure the DISCLAIMER file - or contents of it, in the case of the .whl files - is properly shipped with each release artifact, and that release announcements and web pages clearly include the word "incubating". (Also file names or version strings, but it turns out this is practically prohibited by the PyPI version string guidelines.) But I see your point that the disclaimer would fit nicely below the licensing section of the PyPI landing page. In particular as it is not present in the file names nor version in that world. It should be straightforward to append, but it may turn out we need a separate release cycle for that. (Which is ok, we already established we need to practice it more.) henrik PS: I'll note that this is also a voting thread and there are a few more hours left to vote as I write this, before we hit the minimum 72 hours mark. AND there has been a sufficient number of +1 votes already, thank you very much. I will keep the vote open at minimum until it is clear that this discussion has calmed down, and list members are of course also welcome to ask for more time, should you feel it is necessary. We are in no particular hurry and appreciate the thorough review and guidance. -- *nyrkio.com <http://nyrkio.com/>* ~ *Continuous Benchmarking as a Service* Henrik Ingo, CEO [email protected] LinkedIn: www.linkedin.com/in/heingo +358 40 569 7354 Twitter: twitter.com/h_ingo
