So is it okay to leave the .egg-info in? Or? On Mon, Sep 15, 2025, 6:55 AM Jarek Potiuk <[email protected]> wrote:
> The .egg-info files are added to .gitignore of ours and we are using > generally speaking `git archive` to build our archives - it will skip > .gitignored files > > On Mon, Sep 15, 2025 at 8:50 AM Jarek Potiuk <[email protected]> wrote: > > > Generated files do not need to include licence information. If you are > > using RAT to check licences, you can add .rat-excludes file to exclude > > those from rat check. See https://creadur.apache.org/rat/. The future > > Apache Trusted Release tool will check .rat-excludes at the top level of > > your source .tar.gz and will use it automatically. > > > > On Mon, Sep 15, 2025 at 12:21 AM Stefan Krawczyk < > > [email protected]> wrote: > > > >> > > >> > source release which is required must have 'incubating' in the name. > >> > >> ✅ > >> > >> Question: we will likely evolve the other packages differently. So I'm > >> planning on including subdirectories for the other packages to > distinguish > >> things. I assume that's okay. I see pekka does that. > >> > >> If you want to also release an sf-hamilton - then you can have 2 tar gz > >> > files. > >> > >> ✅ actually will add a third, a wheel -- since airflow-core also does > this. > >> > >> The LICENSE in the sf-hamilton file appears wrong. It mentions > >> > contrib/hamilton/contrib/user/skrawcz/customize_embeddings/__init__.py > >> > but I can't find that file in the tar.gz. > >> > >> ✅ Moving to LICENSE in `contrib` package. We'll release that package > >> later. > >> > >> I would also recommend that the directory inside the tar.gz omits the > >> > rc0 bit. You can't modify the file after the release vote so you won't > >> > be able to remove the rc0 bit when you do release. > >> > >> ✅ corrected > >> > >> > >> ./CONTRIBUTING.md > >> > > >> ✅Removed > >> > >> > ./MANIFEST.in > >> > > >> ✅Updated > >> ./PKG-INFO > >> ✅ this is autogenerated by the build process -- airflow-core does not > >> have > >> the header on this file. > >> > >> > ./README.md > >> > > >> ✅Removed > >> > >> > ./pyproject.toml > >> > > >> ✅Updated > >> > >> > ./rat.txt > >> > > >> ❓ I don't have this? > >> > >> > ./setup.cfg > >> > > >> This is autogenerated via the build process (python -m build --sdist). I > >> can post-process to remove it / add a header manually. Not sure what > >> airflow-core does because they don't include this file. > >> > >> > >> > ./hamilton/experimental/databackend.py (this is ok because it is > >> > mentioned in the LICENSE file) > >> > >> Not touching. > >> > >> ./sf_hamilton.egg-info/PKG-INFO > >> > ./sf_hamilton.egg-info/SOURCES.txt > >> > ./sf_hamilton.egg-info/dependency_links.txt > >> > ./sf_hamilton.egg-info/entry_points.txt > >> > ./sf_hamilton.egg-info/requires.txt > >> > ./sf_hamilton.egg-info/top_level.txt > >> > >> ❓ These are all generated as part of the source distribution process > >> (python -m build --sdist). It's metadata that some python tools use IIUC > >> (but, Airflow core does not have this). Not sure whether they do some > post > >> processing to remove it. *I'm guessing that we should too?* > >> > >> Will put up RC1 in a few days. > >> > >> Cheers, > >> > >> Stefan > >> > >> On Sun, Sep 14, 2025 at 10:38 AM PJ Fanning <[email protected]> > wrote: > >> > >> > These files are missing Apache License headers. > >> > > >> > ./CONTRIBUTING.md > >> > ./MANIFEST.in > >> > ./PKG-INFO > >> > ./README.md > >> > ./pyproject.toml > >> > ./rat.txt > >> > ./setup.cfg > >> > ./hamilton/experimental/databackend.py (this is ok because it is > >> > mentioned in the LICENSE file) > >> > ./sf_hamilton.egg-info/PKG-INFO > >> > ./sf_hamilton.egg-info/SOURCES.txt > >> > ./sf_hamilton.egg-info/dependency_links.txt > >> > ./sf_hamilton.egg-info/entry_points.txt > >> > ./sf_hamilton.egg-info/requires.txt > >> > ./sf_hamilton.egg-info/top_level.txt > >> > > >> > On Sun, 14 Sept 2025 at 18:35, PJ Fanning <[email protected]> > wrote: > >> > > > >> > > The LICENSE in the sf-hamilton file appears wrong. It mentions > >> > > > contrib/hamilton/contrib/user/skrawcz/customize_embeddings/__init__.py > >> > > but I can't find that file in the tar.gz. > >> > > > >> > > I would also recommend that the directory inside the tar.gz omits > the > >> > > rc0 bit. You can't modify the file after the release vote so you > won't > >> > > be able to remove the rc0 bit when you do release. > >> > > > >> > > The next vote should be for rc1. And if that fails, rc2, etc. > >> > > I would recommend that the next release starts with rc1. This is > more > >> > > usual for ASF release votes. > >> > > > >> > > On Sun, 14 Sept 2025 at 18:28, PJ Fanning <[email protected]> > >> wrote: > >> > > > > >> > > > The rule about incubating in the name is at: > >> > > > https://incubator.apache.org/guides/releasemanagement.html > >> > > > > >> > > > <snip> > >> > > > Here is a minimal set of requirements, when using the work in > >> progress > >> > > > disclaimer, a podlings release must abide by: > >> > > > > >> > > > Include the word incubating in the release file name. > >> > > > > >> > > > Include an ASF LICENSE and NOTICE file. > >> > > > > >> > > > Have valid checksums or signatures. > >> > > > > >> > > > Be placed in the correct place on the ASF’s infrastructure. > >> > > > > >> > > > Have a KEYS file to validate the release. > >> > > > > >> > > > Other issues, such as: > >> > > > > >> > > > Missing ASF headers. > >> > > > > >> > > > Missing license information. > >> > > > > >> > > > Included unexpected binary code. > >> > > > > >> > > > Including code of unknown origin. > >> > > > </snip> > >> > > > > >> > > > On Sun, 14 Sept 2025 at 18:25, PJ Fanning <[email protected]> > >> > wrote: > >> > > > > > >> > > > > I'm not sure what process is being followed. Many podlings have > a > >> > > > > document describing the release process that they follow. > >> > > > > I want to highlight one important item for podlings. The release > >> must > >> > > > > be approved by a vote in the podling mailing list. Requires at > >> least > >> > > > > 72 hours of voting and a min of 3 +1s from PPMC members. But you > >> also > >> > > > > need a 2nd vote after this on the Incubator general mailing list > >> > where > >> > > > > the IPMC members vote separately. Requires at least 72 hours of > >> > voting > >> > > > > and a min of 3 +1s from IPMC members. > >> > > > > > >> > > > > On Sun, 14 Sept 2025 at 18:19, PJ Fanning <[email protected] > > > >> > wrote: > >> > > > > > > >> > > > > > The source release which is required must have 'incubating' in > >> the > >> > name. > >> > > > > > If you want to also release an sf-hamilton - then you can > have 2 > >> > tar gz files. > >> > > > > > > >> > > > > > Here is an actual vote thread to look at. > >> > > > > > > >> https://lists.apache.org/thread/b14519zt9v2s9gvpg6jo0wzhblo7drhx > >> > > > > > > >> > > > > > It has a description of the voting rules and the checks that > are > >> > > > > > required (or suggested) for voters to perform. > >> > > > > > > >> > > > > > On Sun, 14 Sept 2025 at 18:16, PJ Fanning < > [email protected] > >> > > >> > wrote: > >> > > > > > > > >> > > > > > > Votes for releases are usually proceeded by discussion > >> threads. > >> > > > > > > I would suggest that you look at other podling mailing lists > >> to > >> > see how podlings are administered. > >> > > > > > > List of podlings > >> > > > > > > https://incubator.apache.org/clutch/ > >> > > > > > > Mailing list reading > >> > > > > > > https://lists.apache.org/ > >> > > > > > > > >> > > > > > > On 2025/09/14 16:38:18 Stefan Krawczyk wrote: > >> > > > > > > > Okay I think I find one issue. So -1. > >> > > > > > > > > >> > > > > > > > The code literally has RC in version.py. if we just > >> literally > >> > move this > >> > > > > > > > source to releases then this won't fly. I'll need to > change > >> > this. Please > >> > > > > > > > continue to verify. I am assuming there might be one or > two > >> > more things to > >> > > > > > > > correct. Will create another RC candidate and vote after > >> this > >> > one > >> > > > > > > > concludes. > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > On Sat, Sep 13, 2025, 10:26 PM Stefan Krawczyk < > >> > [email protected]> > >> > > > > > > > wrote: > >> > > > > > > > > >> > > > > > > > > Hi all, > >> > > > > > > > > > >> > > > > > > > > This is a call for a vote on releasing Apache hamilton > >> > 1.89.0-incubating, > >> > > > > > > > > release candidate 0. > >> > > > > > > > > > >> > > > > > > > > This release includes the following changes: > >> > > > > > > > > - Too many to list. Will build tooling to help automate > >> this. > >> > > > > > > > > > >> > > > > > > > > The artifacts for this release candidate can be found > at: > >> > > > > > > > > > >> > https://dist.apache.org/repos/dist/dev/incubator/hamilton/1.89.0-RC0 > >> > > > > > > > > > >> > > > > > > > > The Git tag to be voted upon is: > >> > > > > > > > > v1.89.0 (based off of this PR > >> > > > > > > > > <https://github.com/apache/hamilton/pull/1378>) > >> > > > > > > > > > >> > > > > > > > > The release hash (can use git tag) will be provided once > >> we > >> > merge a commit > >> > > > > > > > > with version 1.89.0 to main. > >> > > > > > > > > > >> > > > > > > > > Release artifacts are signed with the following key: > >> > > > > > > > > > >> > > > > > > > > 25E1C6FA3B71D486DC46BD3630C8F2B2CC329C0B > >> > > > > > > > > > >> > > > > > > > > The KEYS file is available at: > >> > > > > > > > > https://downloads.apache.org/incubator/hamilton/KEYS > >> > > > > > > > > > >> > > > > > > > > Please download, verify, and test the release candidate. > >> > > > > > > > > > >> > > > > > > > > The vote will run for a minimum of 72 hours. > >> > > > > > > > > Please vote: > >> > > > > > > > > > >> > > > > > > > > [ ] +1 Release this package as Apache hamilton > >> > 1.89.0-incubating > >> > > > > > > > > [ ] +0 No opinion > >> > > > > > > > > [ ] -1 Do not release this package because... (Please > >> > provide a reason) > >> > > > > > > > > > >> > > > > > > > > On behalf of the Apache Hamilton PPMC, > >> > > > > > > > > > >> > > > > > > > > Stefan Krawczyk > >> > > > > > > > > > >> > > > > > > > > P.S. @Mentors with our project, we literally commit the > >> > version into the > >> > > > > > > > > source code. This means that we will build releases off > of > >> > branches and > >> > > > > > > > > then if all good merge into main. Is that kosher? or > not? > >> > > > > > > > > > >> > > > > > > > > >> > > >> > > >
