> Still, I'm in agreement with you that the repository holds the security > patches and that the tarballs are a convenience. They are an important > convenience though, so I would say that they should be released in a > timely manner after the commit of the security patches. I don't think > we need to be that exact about spelling out when that happens. > > (I personally would like to see it within "weeks" of a security patch, > not "months" or "years".) Couldn't that lead to many more 2.x.y releases in the "security fixes" period than in the "active maintenance" period? For active maintenance, we don't do roll security fixes into releases more often than every six months. I would dislike a quick succession of 2.3.7, 2.3.8, 2.3.9, etc. (also because these numbers should not grow above 10 :-) > Also, I would like to document explicit that it is the responsibility of > the PSRT (or its designate) to commit security patches to revision > control. The act of committing these patches is a public event and has > an important impact on any embargoes agreed upon by the PSRT with other > organizations. I also disagree. Regular committers should continue to do that. I haven't seen a single activity from the PSRT (or, perhaps one), so for all I can tell, it doesn't exist. If a security patch is reported to the Python bug tracker, it's as public as it can get. If PSRT members (who are they, anyway) also happen to be committers, they can commit these changes at the time the PSRT deems appropriate. If they are not committers, they need to post the patch to SF as anybody else. (you can tell that I come from a country where people are quite skeptical about the secret service). Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4