Thank you for the feedback. Let me clarify a few points: 1. On Release Artifacts:
My suggestion is that the official release package will only include catalogs outside of catalogs-contrib. Regarding the binary packages: the release tool will only publish one "slim" version as the official artifact. While the build commands can generate two versions locally for convenience, only the slim one will be officially released. This should keep us fully aligned with ASF guidelines. 2. On "Relaxed Requirements": You are right, that phrasing was not accurate. I don’t mean we will lower the code standards. Instead, we plan to use "differentiated handling" for catalogs-contrib. This means we will treat them differently in terms of CI coverage and packaging, but the quality of the code itself remains a priority. Please let me know if you have any other concerns. Thanks! On 2026/01/22 09:04:35 Justin Mclean wrote: > Hi, > > This proposal generally makes sense, but I think there are a few areas where > the framing could be tightened to better align with ASF release and > governance expectations. > > The main point of concern is the distinction of released artifacts.. The > proposal currently describes two binary packages and states that the > “extended” package would not be released. From an ASF perspective, anything > produced by official release tooling, named like a release artifact, or > referenced in release documentation risks being interpreted as an release. It > would be cleaner to treat catalogs-contrib as source-built extensions, rather > than as an alternate binary distribution. > > Related to this, the phrase “relaxed requirements” may unintentionally imply > lower quality or weaker accountability. What’s really being proposed is a > change in the scope of CI enforcement, not a reduction in standards. > > In short, the direction looks reasonable, but tightening the language around > releases and CI policy, should help avoid confusion later, especially during > release reviews. > > Thanks, > Justin
