Along with the release of 2.5.2, I would also like to release new versions of 2.3 and 2.4. These will be security-only releases, and include a few security-relevant bug fixes that are still being finalized. As we don't have the infrastructure to produce full releases of 2.3 or 2.4 anymore, this will be a source release only. As such, it will likely see less testing than other releases, and users will have more difficulties in obtaining the software for their system - the releases will be targeted primarily at system vendors who can chose to include them as security patches in their system updates. As a consequence, I would like to roll back all changes from the 2.3 and 2.4 branches which aren't security fixes. In specific cases, the nature of a change might be debatable; clear security fixes are prevention of memory corruption and interpreter crashes, clear non-security fixes are documentation and test-suite changes. For 2.3, there are only few revisions that would be rolled back: r52798, r52803, r52824, r54342. For 2.4, the list is longer; all changes on the branch since r52382 are candidate for roll-back. I would like to prepare a white-list of patches that should be preserved; if you think any of the patches committed in the 2.4 branch is a security fix, please let me know. Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 27, 2008, at 2:27 PM, Martin v. Löwis wrote:
Along with the release of 2.5.2, I would also like to release new versions of 2.3 and 2.4. These will be security-only releases, and include a few security-relevant bug fixes that are still being finalized.
As we don't have the infrastructure to produce full releases of 2.3 or 2.4 anymore, this will be a source release only. As such, it will likely see less testing than other releases, and users will have more difficulties in obtaining the software for their system - the releases will be targeted primarily at system vendors who can chose to include them as security patches in their system updates.
If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately. I would be bummed to rollback the email package changes. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR50rxnEjvBPtnXfVAQK4UQP/Xbj6YhXAbhqdZBdirgTw3O9dqocgzgT/ 7Sky4fl0WaSTxRJc3/P0E4uR69TixZ5E7z3pt4G0QeKZCjub3l6xzKiJ7dccAWbW V8otTxCyavXN8wW99orBqgB2J+H0BFkHlPJdYOOBigBuWrSn/Ew2wrZeXRnBfz// qBvWbwlA+sE= =u/23 -----END PGP SIGNATURE-----
On Jan 27, 2008 5:11 PM, Barry Warsaw
On Jan 27, 2008, at 2:27 PM, Martin v. Löwis wrote:
Along with the release of 2.5.2, I would also like to release new versions of 2.3 and 2.4. These will be security-only releases, and include a few security-relevant bug fixes that are still being finalized.
As we don't have the infrastructure to produce full releases of 2.3 or 2.4 anymore, this will be a source release only. As such, it will likely see less testing than other releases, and users will have more difficulties in obtaining the software for their system - the releases will be targeted primarily at system vendors who can chose to include them as security patches in their system updates.
If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately.
I would be bummed to rollback the email package changes.
But which vendor would cherry-pick those changes for 2.3 or 2.4? I presume vendors are also in security-fixes-only mode. Are any of the email package fixes security fixes? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately.
It's not just vendors, also end-users who are concerned about the security of their installations.
I would be bummed to rollback the email package changes.
You don't have to - I will do it for you (although I don't understand fully what "to be bummed" means). Regards, Martin
Martin v. Löwis wrote:
If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately.
It's not just vendors, also end-users who are concerned about the security of their installations.
I would be bummed to rollback the email package changes.
You don't have to - I will do it for you (although I don't understand fully what "to be bummed" means).
It means I'd be sad. ;) The problem is that I make separate releases of the standalone email package from these branches, so that means that email 3.0.3 or 2.5.10 will have regressions. Unless you're offering to also re-apply these changes after you make the Python releases <wink>. -Barry
On Jan 28, 2008 1:47 PM, Barry Warsaw
Martin v. Löwis wrote:
If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately.
It's not just vendors, also end-users who are concerned about the security of their installations.
I would be bummed to rollback the email package changes.
You don't have to - I will do it for you (although I don't understand fully what "to be bummed" means).
It means I'd be sad. ;)
The problem is that I make separate releases of the standalone email package from these branches, so that means that email 3.0.3 or 2.5.10 will have regressions.
Unless you're offering to also re-apply these changes after you make the Python releases <wink>.
This sounds like a special case that we might consider. Though I also wonder if it wouldn't be easiest for you to just create separate branches for the email package rather than rely on the core Python branching structure and release rules. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Jan 28, 2008, at 4:47 PM, Barry Warsaw wrote:
The problem is that I make separate releases of the standalone email package from these branches, so that means that email 3.0.3 or 2.5.10 will have regressions.
Releasing the email package from the Python maintenance branches is probably insane. This kind of thing would be less of a problem if the standard library were smaller, and the email package only available separately. It's also why some of us want a smaller standard library. -Fred -- Fred Drake <fdrake at acm.org>
> Releasing the email package from the Python maintenance branches is > probably insane. People seem to use a lot of strong language lately. >From m-w.com: insane (adjective) 1. mentally disordered 3. absurd == ridiculously unreasonable > This kind of thing would be less of a problem if the standard library > were smaller, and the email package only available separately. It's > also why some of us want a smaller standard library. I see no problem with the email package being maintained in the Python trunk, per se, and I don't think it should be removed from the standard library at all. Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 28, 2008, at 4:56 PM, Fred Drake wrote:
On Jan 28, 2008, at 4:47 PM, Barry Warsaw wrote:
The problem is that I make separate releases of the standalone email package from these branches, so that means that email 3.0.3 or 2.5.10 will have regressions.
Releasing the email package from the Python maintenance branches is probably insane.
This kind of thing would be less of a problem if the standard library were smaller, and the email package only available separately. It's also why some of us want a smaller standard library.
Yep. We've solved this problem for the old releases. I still think it makes sense to use the maintenance branch for the current stable release, but as soon as 2.6 is released, I'll fiddle the sandbox to contain a separate copy, since 2.5 will be in security-only mode. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8x+dnEjvBPtnXfVAQJa3AP/VZQoT+b+tRBLLXtBZ0kLxMGwpuvTdDae aD8X3zu4SaUJOIw47NUb/Re3xTOWA0cjBfoEZLYVtNBUICUt0AhFvP7s26Or2jlM NINAqiq1gnzyVhwfhUMHoaX66PsJvA8OMq4owoKIUJDQiAnnz5/Gw2t6/0I4PPrt wunxcXvfOdg= =zf3e -----END PGP SIGNATURE-----
The problem is that I make separate releases of the standalone email package from these branches, so that means that email 3.0.3 or 2.5.10 will have regressions.
Unless you're offering to also re-apply these changes after you make the Python releases <wink>.
If they are there primarily to track any changes that you want to release in the future (i.e. they are the repository of standalone email package), then a solution must be found, I agree. Would it help if I branch branches/release23-maint/Lib/email to branches/email-2.3 ? Or should I branch the entire release23-maint to email-2.3? (branches are cheap in subversion) (*) It would mean that you have to check in future 2.3 fixes of the email package into a different branch, and if you run into security fixes, you need to commit them into two branches (email-2.3 and release23-maint). Same for 2.4. For 2.5, bug fixes could be added until that branch also goes into the security-only mode (i.e. after 2.6 is released). Please let me know what you think. Regards, Martin (*) other locations are possible as well, such as branches/email/2.3 or /email/branches/2.3
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 28, 2008, at 5:08 PM, Martin v. Löwis wrote:
Would it help if I branch branches/release23-maint/Lib/email to branches/email-2.3 ? Or should I branch the entire release23-maint to email-2.3? (branches are cheap in subversion) (*)
I just realized there's a good solution to this. The sandbox has an emailpkg directory with subdirectories for each of the email package releases. Currently, the actual code gets svn:external'd in from the Python branches, but for email 2.5 and 3.0 we should just svn copy the branches into here and remove the svn:external definitions. I'm not able to do this right now, but I should be able to do this in the next day or so if you don't beat me to it.
It would mean that you have to check in future 2.3 fixes of the email package into a different branch, and if you run into security fixes, you need to commit them into two branches (email-2.3 and release23-maint).
Using the above scenario, that would be fine.
Same for 2.4. For 2.5, bug fixes could be added until that branch also goes into the security-only mode (i.e. after 2.6 is released).
So for now, we'll leave email 4.0 external'd in from the Python 2.5 branch. When 2.6 is released, we'll svn copy that in like we did above. The only catch is that it would probably be best to rev the email package version number in Python 2.6 just to be clear it's a different branch. 4.1.0 would be a fine number even if it's mostly just a bookkeeping trick.
Please let me know what you think.
What do you think of the above? Thanks! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR558knEjvBPtnXfVAQL1vQQAmjNPN27scZ2Tl/ayEnggZOym8U1MEdgP zvBvfbCrp0V4dSF/zddYjB61+9uRP4bN10oNEbwPKUifJ/me5o6qkguLeO56qzqH fs2rTWUlRXKR27g8WDV0B/KL0F5vpd+3PglQI/TfmSbcZjzAlGIMIY/k27bCL4Hy z9XE+LOmNjU= =ZCyu -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 29, 2008, at 1:01 AM, Martin v. Löwis wrote:
What do you think of the above?
Sounds fine to me. I won't touch this then for the moment, please let me know when you are done rearranging things.
Cool, I'll try to get to this today. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR58c+nEjvBPtnXfVAQI1XgP/S9YUtkAC/x77alsmBYXtaoGZNrQ/QvtR bziE1zzQ/Luexe9nt41JEaSbVyWb1dw0KZvpoDzqhqbLfhYAXCvJVFIlbw0U94bh pf1G42L3U1YauzzUQL1Q9g0IT4jRMc3D3G8hwX4iOECEW8uHla9uAiqSl5r/V5af K8BcRtkzz0Q= =8tA5 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 29, 2008, at 1:01 AM, Martin v. Löwis wrote:
What do you think of the above?
Sounds fine to me. I won't touch this then for the moment, please let me know when you are done rearranging things.
All done! Thanks. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR5806HEjvBPtnXfVAQKGTgQAkPUgEssRQOYCEEhAshQcO3hYm7I47Tdk uY1TG7a7hKd0kVksWsRlJCDOHUrxay0EORxf++IJyht+xkSUo50Yq6nAM0cx1xWA mjupkNu4ChwLpvfI+2Q6Haz6Ws30e0M5YtZeH1XJlFXIaPmwF44HEsBmVGxf2EYO ihFY6Xt5M3A= =G22Z -----END PGP SIGNATURE-----
On Jan 27, 8:27 pm, "Martin v. Löwis"
Along with the release of 2.5.2, I would also like to release new versions of 2.3 and 2.4. These will be security-only releases, and include a few security-relevant bug fixes that are still being finalized.
As we don't have the infrastructure to produce full releases of 2.3 or 2.4 anymore, this will be a source release only. As such, it will likely see less testing than other releases, and users will have more difficulties in obtaining the software for their system - the releases will be targeted primarily at system vendors who can chose to include them as security patches in their system updates.
As a consequence, I would like to roll back all changes from the 2.3 and 2.4 branches which aren't security fixes. In specific cases, the nature of a change might be debatable; clear security fixes are prevention of memory corruption and interpreter crashes, clear non-security fixes are documentation and test-suite changes.
For 2.3, there are only few revisions that would be rolled back: r52798, r52803, r52824, r54342.
For 2.4, the list is longer; all changes on the branch since r52382 are candidate for roll-back. I would like to prepare a white-list of patches that should be preserved; if you think any of the patches committed in the 2.4 branch is a security fix, please let me know.
Regards, Martin
Don't know if this concerns 2.3 but there was a debate whether including patch #1745035 in 2.4 branch: http://groups.google.it/group/python-dev2/browse_thread/thread/33cad7b7c1cdb...
On Sun, Jan 27, 2008 at 08:27:27PM +0100, "Martin v. Löwis" wrote:
For 2.3, there are only few revisions that would be rolled back: r52798, r52803, r52824, r54342.
These changes can be reverted if you like; they were added for Jython's sake, but it looks like they've now decided to skip directly to 2.5 compatibility.
For 2.4, the list is longer; all changes on the branch since r52382 are candidate for roll-back. I would like to prepare a white-list of patches that should be preserved; if you think any of the patches committed in the 2.4 branch is a security fix, please let me know.
r55350 is a security fix for cgitb. --amk
participants (6)
-
"Martin v. Löwis" -
A.M. Kuchling -
Barry Warsaw -
Fred Drake -
Giampaolo Rodola' -
Guido van Rossum