Is this an opt-in or opt-out policy? We wouldn't want to do that for CVE fixed right?
Gaty On Thu, Jan 9, 2025, 07:07 Jarek Potiuk <ja...@potiuk.com> wrote: > Sorry " should be *not *to encourage the projects to make it easy for > anyone to install and test the release" -> "should be to encourage the > projects to make it easy for anyone to install and test the release" > > On Thu, Jan 9, 2025 at 1:06 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > Just a small thing to add - while we are releasing RCs, I think the right > > approach should be not to encourage the projects to make it easy for > anyone > > to install and test the release - which does not automatically mean to > > publish RC in the same way the final candidate is published. > > The key here is to let the users know that there is a candidate and > > encourage them to test it. I think it has more nuances than publishing to > > Maven/ PyPI etc. - and PMCs should choose their own ways and encourage > > their "dev community" (not end users mind you - those users might be > > misled into thinking this is the final release!) to test it. > > > > There are many ways how this can be done: > > > > * Airflow is indeed publishing RC candidates in PyPI (PyPI has a great > > distinction between pre-release and final candidates and users cannot > > mistake them for final versions, they need to explicitly install RC > > candidates) and we invite contributors to test the releases via GitHub > > issue (automated) where we mark the involved contributors: example here - > > https://github.com/apache/airflow/issues/45148 - we usually have at > > least 60% "success" rate - i.e. more than half of the users involved are > > willing to take the RCs for a spin, install it and test it (and confirm > it > > works or report issues). This sustainably works for 3-4 years now. > > > > * However, quite recently in the Python ecosystem at least where the > > Python Community standardised packaging and build backend/front-end > > approach - it is a very common practice to use GitHub branches to install > > the software. There is a way to do it it in a standard way and more often > > than not when we find and report (or comment) an issue in a dependent > > library, they create a PR and ask everyone to test it from the branch - > an > > example of it recently where we found a problem in Pygments and they > > created a PR fixing it - issue here > > https://github.com/pygments/pygments/issues/2834, PR in Airflow testing > > the change in PR here: > https://github.com/apache/airflow/pull/45416/files > > (basically replacing "pygments>=2.0.1,!=2.19.0" with "pygments @ git+ > > > https://github.com/pygments/pygments.git@a9858663ed85219ed7475f5877b22b9cb49f660f > ". > > This is a very efficient way of testing - because you can test the fix > not > > when all the burden of release preparation and rc candidate preparation > is > > done, but way before, even way before the PR with fix is merged. This is > > something we are actually going to encourage more - currently our 90+ > > providers in our monorepo are not installable via GIT URL, but we are > > implementing restructuring to make it possible - so that you can install > > any of our packages directly from our monorepo github repo - specifying > the > > package you want to install, URL and commit-ish git reference. > > > > So if we want to add something about policies/best practices - we should > > rather describe the "INTENTION" to have RC (or even PR!) candidates being > > easily available to install and test, but how PMCS turn that into > practice > > - should be up to them. > > > > J. > > > > > > >
