Hi everyone, [x] +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: [x] Download links are valid. [x] Checksums and signatures. [x] LICENSE/NOTICE files exist [x] No unexpected binary files [x] All source files have ASF headers [x] Can compile from source Additional comments: 1. I only briefly checked the internals by running couple of examples. 2. Convenience package and built from source behave the same. Best, Jernej ________________________________ From: Elijah ben Izzy <[email protected]> Sent: 27 November 2025 04:21 To: [email protected] <[email protected]> Subject: Re: [VOTE] Release Apache burr 0.41.0-incubating (release candidate 1) Disagreement is fair and fun. @Jarek I like the distinction. I think it make sense to: 1. Provide a utility for people to test this out without building (allowing them to verify that the source is the same) 2. Ensure that we vote on what we release So let's keep the wheel file in for the future (and hopefully other podlings can learn from us). I have attached the wheel in the same directory, signed using the same key: https://dist.apache.org/repos/dist/dev/incubator/burr/0.41.0-incubating-RC1/ You will see the following: - apache-burr-0.41.0-incubating.tar.gz - apache-burr-0.41.0-incubating.tar.gz.asc - apache-burr-0.41.0-incubating.tar.gz.sha512 - apache_burr-0.41.0-py3-none-any.whl - apache_burr-0.41.0-py3-none-any.whl.asc - apache_burr-0.41.0-py3-none-any.whl.sha512 Happy thanksgiving folks! As a follow-up, once the release is approved, I will be: 1. Writing up all instructions/processes 2. Ensuring there's a very clean process for releasing these files to the appropriate pypi package. -Elijah On 2025/11/26 23:52:57 Jarek Potiuk wrote: > Yeah, it's also quite expected that you will have people having different > opinions in ASF - including mentors :). > > That's part of the ASF way and culture, that while there are some "formal" > ways how policies can be updated, they are not describing everything in > detail - simply because there are so many variations in projects, ways of > distributing things, ways of building things, so for policies the "MUST" is > something that is absolutely not negotiable, SHOULD is something that you > have to have good reason not to follow, and all the rest is - mostly > deliberately - unspecified and left for discretion and final consensus of > the community - PPMC in this case. > > The problem is that If you make the rules strict, complete and "compilable" > - where all conditions and edge cases are described, you simply limit > variations, experimentations and simply the fact that there are different > projects, circumstances, communities, people have different preferences and > simply "use" of the projects might be different. > > Ultimately - you should decide yourself what to do by hearing those > opinions. As long as you make it consciously, knowing pros and cons - and > especially what it means to your users - almost any decision is good if it > does not violate MUST and if it provides justification why some SHOULD not > be followed (if they are not). For example you could decide to go with > source only now and plan to add distributions in the future, if you do not > have capacity now to build the automation around it (but that's one of the > options only). > > I'd say **technically** voting is definitely on sources - and they should > fulfill all the expectations. This is legally what you are voting on and > what ASF has MUST on. All the rest is just "how convenient you want to make > it for your users to install things", but also what certainty you provide > to your users that what is PyPI has not been modified vs. the sources. In > the Airflow case we don't check "sources/licences" of convenience > distributions, we mostly check if the distributions were generated from the > same sources as -source.tar.gz and we check licences on those. So > technically -1/+1 is given on "sources", rest is "derivative". > > J. > > On Wed, Nov 26, 2025 at 10:20 PM Elijah ben Izzy <[email protected]> > wrote: > > > Ashs, Stefan, more than happy to upload. Will take a small bit (hopefully > > tonight) as I want to make sure I get it right before doing so, but I have > > all the built files as well as the right scripts to make it easy to do so > > (manually, in a trusted manner). > > > > This will make testing simpler for the PMC members. > > > > On 2025/11/26 17:32:24 Elijah ben Izzy 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]) > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
