On Thu, 2021-02-11 at 23:24 -0500, Terry Reedy wrote: > On 2/11/2021 3:23 PM, Michał Górny wrote: > > Hello, > > > > I'm the primary maintainer of CPython packages in Gentoo. I would like > > to discuss possible improvement to the release process in order to > > accelerate releasing security fixes to users. > > > > I feel that vulnerability fixes do not make it to end users fast enough. > > When we introduce a bad regression in a release, including a > severe-enough security vulnerability, and discover it soon enough, we > have sometimes made immediately releases. > > Beyond that, your proposal to add several releases per Python version, > perhaps double what we do now, runs up against the limits of volunteer > time and effort. As it is now, becoming a release manager is a 7 year > commitment, with at least one release about every other month for the > first 4. There are also the 2 people who produce the Windows and macOS > installers. I believe each has done it for at least 7 or 8 years > already. Releases are not just a push of a button. Make the release > job too onerous, and there might not be any more volunteers.
While I understand your concerns and sympathize with them, I don't think it's fair to play the volunteer card here. After all, I am a volunteer too, and many distribution packagers are as well. We also have limited time and many other duties, and it just feels unfair for you to be dumping the security work on us. The thing is, CPython upstream has the opportunity to do the central work that benefits everyone. You get the first indication of the vulnerability, you have the first fix and backport to all branches. It is only the natural next step to make a release with it. While I realize it means more work, not doing that means more work for a number of other people who are impacted by your prior work. That said, if the regular release process is too much work, then maybe a process similar to security-supported branches would work? After all, I think it reasonable to assume that a large number of CPython users are using it via distribution packages and having Python 3.8.x.y source-only release will be already a big help to people making these packages. > > For example, according to the current release schedules for 3.9 and 3.8, > > the bugfix releases are planned two months apart. While the release is > > expected to happen in the next few days, both versions are known to be > > vulnerable for almost a month! > > > > Ironically, things look even worse for security-supported versions. > > Please correct me if I'm wrong but both 3.7 and 3.6 seem to be behind > > schedule (planned for Jan 15th), and they are known to be vulnerable > > since mid-October. > > > > In my opinion, this causes three issues: > > > > 1. Users using official releases are exposed to security vulnerabilities > > for prolonged periods of time. > > > > 2. When releases happen, security fixes are often combined with many > > other changes. This causes problems for distribution maintainers who, on > > one hand, would like to deploy the security fixes to production versions > > ASAP, and on the other, would prefer that the new version remained in > > testing for some time due to the other changes. > > > > 3. Effectively, it means that distribution developers need to track > > and backport security fixes themselves. In the end, this means a lot of > > duplicate work. > > Perhaps people doing duplicate work could get together to eliminate some of > the duplication. It should be possible to filter security commits from the > python-checkins list by looking at the news entries and if need be, the bpo > issues. This makes me think of the 'systemd-stable' repository (where another maintainer is making bugfix releases to previous versions of systemd). I suppose this could work as a last resort but only if it was officially supported and endorsed by CPython. However, at this point it's not really clear why not go the one step further and make the official releases. -- Best regards, Michał Górny _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/I52QGQVA55BXF425V5IZLF3GYYPWLOKW/ Code of Conduct: http://python.org/psf/codeofconduct/
