This discussion seems to be getting a bit contentious. If building the requested artifacts isn’t too difficult, can we consider including them in the vote? If the original plan was to build them after the release anyway, perhaps we can do that step beforehand so anyone who needs to validate them can do so.
My understanding is that the rule is NOT that "only the source must go up for a vote" — not that convenience binaries cannot be included. If we don’t intend to build or publish them even after the release, that is something debatable. The policies here aren't entirely black-and-white, and ultimately our decisions should be based on community consensus. I’m simply trying to understand what the main concern is. Is the hesitation primarily about the additional effort required? If the workload is too much for the Release Manager, perhaps someone else can help with the artifact build this time, and we can have a more formal discussion for future releases. Including something once doesn’t mean it must always be included going forward, assuming the PMC agrees. -Ayush On Wed, 26 Nov 2025 at 23:19, PJ Fanning <[email protected]> wrote: > > You may not find agreement on this. But I, personally, won't vote on > releases where the prospective release artifacts are not provided. I have > no inclination to go through the process of building them myself. I donate > my time. I don't need the hassle of installing build systems and running > builds. > > On Wed 26 Nov 2025, 18:33 Elijah ben Izzy, <[email protected]> wrote: > > > Uploading the wheel is not a huge amount of work. But yes, they are more > > than "source" -- I.E. they're the built package (binary). If we do this > > with java then doing it with python isn't crazy. > > > > By "bundle javascript" it's not "source" it's a minified source -- a > > static page that's served. > > > > Will await your opinions. Release is easier if we have the wheel as well, > > we can (I think) just release the same binary. > > > > On 2025/11/26 17:26:23 Stefan Krawczyk wrote: > > > > While it's not a requirement, > > > > > > From the experience releasing Hamilton & on the prior discuss thread > > there > > > was feedback that we should ONLY VOTE ON SOURCE and not on convenience > > > packages if we have the script to generate them programmatically. > > > > > > Can the Incubator management team please meet to conform to a single > > > definitive opinion on this? > > > > > > Additional complexities we have that ^ should take into consideration: > > > > > > 1. We bundle JavaScript into the convenience package (all are apache 2 > > > compatible licenses). IIRC we don't vote on binaries, right? > > > 2. There are also challenges with us because we will push two pypi > > > packages... Why should we burden everyone with validating all the > > packages? > > > > > > Please advise. > > > > > > Cheers, > > > > > > Stefan > > > > > > > > > > > > > > > On Wed, Nov 26, 2025 at 7:32 AM Jarek Potiuk <[email protected]> wrote: > > > > > > > I will review it a bit deepr later today/tomorrow, but I agree with PJ. > > > > > > > > > > > > While it's not a requirement, it's generally a good practice to prepare > > > > pypi distributions and upload them to dist as well as sources. If you > > can > > > > prepare them already in the form that they "will" work when they are > > > > promoted as final candidates (i.e. they should not have rc*) Then you > > can > > > > directly take later those and upload them to PyPI from "dist" if vote > > pass > > > > - knowing that things were verified, that signatures and checksums are > > also > > > > stored. And you do not even have to rebuild it again - you **just** > > publish > > > > what you already have in SVN. > > > > This way anyone who gets the packages from PyPI can verify if they are > > "the > > > > same" distributions (binary) and that signatures and checksums are ok - > > > > even if it's not supported by PyPI, they can do it in their pipelines. > > > > Also having **the same** files does not introduce the issue that you > > vote > > > > on something else than what you publish as public packages for end-user > > > > consumptions. > > > > > > > > This is what we do in Airflow. > > > > > > > > We do not do it (yet) with actual rc packages that we publish in PyPI > > for > > > > convenience of testing - (i.e. we only publish signatures, and > > checksums > > > > and artifacts in dist for the would-be-final-if-promoted) distributions > > > > because those are pre-release builds (main difference is that they > > have rc* > > > > version rather than final) .But we will likely do soon (though these > > are > > > > really, really, really nice-to-have - those packages are only used for > > > > testing, so it's not as important to vote on them, here we trust that > > > > release manager used the same sources for the rc PyPI pavkages). > > > > > > > > Speaking of which, it would likely be great to publish those rcs in > > PyPI > > > > for various reasons: > > > > > > > > 1) it tests the upload process, permissions and the like > > > > 2) it allows your users to test it super easily by `pip install --pre` > > or > > > > direct version specification > > > > 3) it tests if the packages fulfill PyPI criteria and won't be rejected > > > > > > > > I recommend to twine check and upload (with twine check first, and PyPI > > > > upload double check). That avoids problems where you technically > > **can** > > > > prepare .sdist, .whls from sources, but they are "not good" - we had > > it few > > > > time in the past that errors in README.md have been rejected only at > > the > > > > moment of uploading to PyPI (it even passed twine checks) - that was > > > > something about markdown formatting error in the readme as far as I > > > > remember - and really the only check is to attempt to upload it. > > > > > > > > J. > > > > > > > > > > > > On Wed, Nov 26, 2025 at 11:04 AM PJ Fanning <[email protected]> > > wrote: > > > > > > > > > Most teams provide the pypi files for review. > > > > > > > > > > I'm not involved too closely with Python projects but with Java, you > > > > > can't do an ASF release without providing staged jars for review. > > They > > > > > are part of the vote. > > > > > I don't know where this pypi exemption has come from and as I say, > > > > > other teams provide files on dist.apache.org for review of pypi > > > > > artifacts. > > > > > > > > > > On Wed, 26 Nov 2025 at 09:51, Stefan Krawczyk < > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > > Yes there's going to be a pypi release of convenience packages. > > They > > > > can > > > > > be > > > > > > created using the build script that is bundled with the source > > files. > > > > > This > > > > > > follows the recommendation from the earlier discussion thread that > > > > those > > > > > > are not voted on. > > > > > > > > > > > > On Tue, Nov 25, 2025, 11:54 PM PJ Fanning <[email protected]> > > wrote: > > > > > > > > > > > > > Is there going to be a pypi release and if so, these files > > should be > > > > > > > included with the release candidate for review? > > > > > > > > > > > > > > On Wed, 26 Nov 2025 at 08:07, Elijah ben Izzy > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > Hi all! > > > > > > > > > > > > > > > > This is a call for a vote on releasing Apache Burr > > > > 0.41.0-incubating > > > > > > > > Release Candidate 1. > > > > > > > > > > > > > > > > This release includes the following changes (see CHANGELOG for > > > > > details). > > > > > > > > See all commits since prior release: > > > > > > > > - https://github.com/apache/burr/compare/burr-0.40.2...main > > > > > > > > > > > > > > > > Key changes include: > > > > > > > > - pool-based async PG persister > > > > > > > > - multiple UI updates > > > > > > > > - Apache compatible licenses/build processes > > > > > > > > - bug fixes, typing, etc... > > > > > > > > > > > > > > > > The artifacts for this release candidate can be found at: > > > > > > > > > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/burr/0.41.0-incubating-RC1 > > > > > > > > > > > > > > > > The Git tag to be voted upon is: v0.41.0 > > > > > > > > > > > > > > > > The release hash is a95c7c3f1425db382b367b0d4f888704ea2939f9 > > > > > > > > > > > > > > > > Release artifacts are signed with the following key: > > > > > > > > BB8B72B34AB9A664A109AA17A76CF4C80E4E5355 > > > > > > > > The KEYS file is available at: > > > > > > > > https://downloads.apache.org/incubator/burr/KEYS > > > > > > > > > > > > > > > > Please download, verify, and test the release candidate. For > > > > testing > > > > > use > > > > > > > > your best judgement. The following may suffice: > > > > > > > > > > > > > > > > 1. Build/run the UI following the instructions in > > scripts/README.md > > > > > > > > 2. Run the tests in tests/ > > > > > > > > 3. Import into a jupyter notebook and play around > > > > > > > > > > > > > > > > The vote will run for a minimum of 72 hours. > > > > > > > > Please vote: > > > > > > > > > > > > > > > > [ ] +1 Release this package as Apache Burr 0.41.0-incubating > > > > > > > > [ ] +0 No opinion > > > > > > > > [ ] -1 Do not release this package because... (Please provide a > > > > > reason) > > > > > > > > > > > > > > > > Checklist for reference: > > > > > > > > [ ] Download links are valid. > > > > > > > > [ ] Checksums and signatures. > > > > > > > > [ ] LICENSE/NOTICE files exist > > > > > > > > [ ] No unexpected binary files > > > > > > > > [ ] All source files have ASF headers > > > > > > > > [ ] Can compile from source > > > > > > > > > > > > > > > > On behalf of the Apache Burr PPMC, > > > > > > > > > > > > > > > > Elijah ben Izzy ([email protected]) > > > > > > > > > > > > > > > > > > > > >
