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.
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.
I think that security fixes are important enough to justify not sticking
to a strict release schedule. Therefore, I would like to propose that if
vulnerability fixes are committed, new releases are made
as frequently as necessary and as soon as possible (i.e. possibly giving
some time for testing) rather than according to a strict schedule.
Furthermore, I think that at least for branches that are in higher level
of maintenance than security, it could make sense to actually make
security releases (e.g. 3.9.1.x) that would include only security fixes
without other changes.
--
Terry Jan Reedy
_______________________________________________
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/4S5LOTVJZUA5PQ5TRGQFCWHTGA4BOXBO/
Code of Conduct: http://python.org/psf/codeofconduct/
