I just want clarity as to what we can do that is acceptable. I'm trying to avoid detractors. Sounds like no-one will be happy either way.
I'm with you PJ, that I think we should vote on everything as that makes things clearer. @Elijah is it difficult for you to add those extra packages to SVN? Cheers, Stefan On Wed, Nov 26, 2025 at 10:41 AM Ayush Saxena <[email protected]> wrote: > 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]) > > > > > > > > > > > > > > > > > > > > > > > > > > >
