Please don't commit to 3.2 branch anymore
Hi all,
with 3.2.4 being the last regular 3.2 maintenance release and the rc out of the door, the 3.2 branch should only be committed to for security releases. So please don't commit anything there anymore. To help everyone remember, I've configured the push hook to reject changesets to the 3.2 branch.
cheers, Georg
On Thu, Mar 28, 2013 at 5:55 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Hi all,
with 3.2.4 being the last regular 3.2 maintenance release and the rc out of the door, the 3.2 branch should only be committed to for security releases. So please don't commit anything there anymore. To help everyone remember, I've configured the push hook to reject changesets to the 3.2 branch.
Ah, I was waiting for that before doing the test helper discoverability improvements in 3.3 & default. I guess I just lost my excuse for procrastinating on that :)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 28/03/13 08:55, Georg Brandl wrote:
with 3.2.4 being the last regular 3.2 maintenance release and the rc out of the door, the 3.2 branch should only be committed to for security releases. So please don't commit anything there anymore. To help everyone remember, I've configured the push hook to reject changesets to the 3.2 branch.
What is the procedure for commiting security fixes?. Is it documentes anywhere?
Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQCVAwUBUVbdg5lgi5GaxT1NAQIUeQP5Afv9geQRTGzzSiYjOlG1H2Mn9NWRpP4s 2ih1z6c5kqFuksXrAh2gRjifUX53P7Ig+OlaS84uS2SbGy3NT6xPuIIVjfntoe4d f2vHa7uI9iKE4+U5KDEDKDr250rSly5NFVouFgzAo/JCQtvQ4uH7lWO+sM14qPyT IfBDMgWIVNo= =SOic -----END PGP SIGNATURE-----
On Sat, 30 Mar 2013 13:41:39 +0100, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 28/03/13 08:55, Georg Brandl wrote:
with 3.2.4 being the last regular 3.2 maintenance release and the rc out of the door, the 3.2 branch should only be committed to for security releases. So please don't commit anything there anymore. To help everyone remember, I've configured the push hook to reject changesets to the 3.2 branch.
What is the procedure for commiting security fixes?. Is it documentes anywhere?
This is the first time we've been in the situation of having a security-only branch in Mercurial (other than 2.7, which is its own head). So I don't believe we have articulated a procedure yet.
--David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 30/03/13 15:15, R. David Murray wrote:
This is the first time we've been in the situation of having a security-only branch in Mercurial (other than 2.7, which is its own head). So I don't believe we have articulated a procedure yet.
I am asking because the commit hook.
I expect patches will be few and far apart, so "somebody" could disable that hook just for committing those, when time comes. But I think would be interesting to actually think about it and document something now, even if we need to update it when we have real experience.
Something simple would be for the hook to refuse any commit in that branch UNLESS it is coming from the maintainer.
Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQCVAwUBUVcAa5lgi5GaxT1NAQKQ7gP/TZWs2pSqQs4K2Wc5jG6EZC52Ya7dGffT vhoWXhSBPCDuzzONh0BvPwVhMVGE6+IIBeUnxviCB/VnOfG7rNxcAb1GfwCWp0bY rtITu25Rgx3FemYyIROI1Bh0sdbWyEaEkgR6E+UEzO985fH7UJH24Ztc60ezyNgV Sn9KWXBdvOM= =ayOT -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 30/03/13 16:10, Jesus Cea wrote:
Something simple would be for the hook to refuse any commit in that branch UNLESS it is coming from the maintainer.
BTW, are the hooks available anywhere. I am interested in the "create patch" hook and the "be sure you merge your patches" hook :). Maybe some other nice hooks out there.
Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQCVAwUBUVcCx5lgi5GaxT1NAQJrRAP9Fmz/CxISeLrV0sh9oM3GJN/trLcmXpPU e3+qoL+9Z+xTcLJURuIH0Tur5TY6zdNF0J7G8lKmUV1IGMGpeOODt3Vlf62uYLVu eOf5xHW42RJHHH0Cof0tEI5PIE6+UaCN4XcDMRMX4fbWNC6/t+jEWc20rte3tDTu 76VY2BmEwIY= =0Niw -----END PGP SIGNATURE-----
On 03/30/2013 04:20 PM, Jesus Cea wrote:
On 30/03/13 16:10, Jesus Cea wrote:
Something simple would be for the hook to refuse any commit in that branch UNLESS it is coming from the maintainer.
BTW, are the hooks available anywhere. I am interested in the "create patch" hook and the "be sure you merge your patches" hook :). Maybe some other nice hooks out there.
They are here: http://hg.python.org/hooks -- the specific one here is "checkbranch.py".
Georg
On 03/30/2013 04:10 PM, Jesus Cea wrote:
On 30/03/13 15:15, R. David Murray wrote:
This is the first time we've been in the situation of having a security-only branch in Mercurial (other than 2.7, which is its own head). So I don't believe we have articulated a procedure yet.
I am asking because the commit hook.
I expect patches will be few and far apart, so "somebody" could disable that hook just for committing those, when time comes. But I think would be interesting to actually think about it and document something now, even if we need to update it when we have real experience.
Something simple would be for the hook to refuse any commit in that branch UNLESS it is coming from the maintainer.
Security fixes will have to be coordinated with me anyway, so that is not a problem here. For example, whoever commits them can put them in a clone on hg.python.org, and I will pull them into the main repo.
Georg
Le samedi 30 mars 2013 à 10:13 -0700, Ned Deily a écrit :
In article <20130330141534.44893250BDD@webabinitio.net>, "R. David Murray" <rdmurray@bitdance.com> wrote:
This is the first time we've been in the situation of having a security-only branch in Mercurial (other than 2.7, which is its own head).
3.1?
Or 2.6? I also don't know what "which is its own head" is supposed to mean :-)
Regards
Antoine, who isn't his own head (and it shows).
On 03/30/2013 06:14 PM, Antoine Pitrou wrote:
Le samedi 30 mars 2013 à 10:13 -0700, Ned Deily a écrit :
In article <20130330141534.44893250BDD@webabinitio.net>, "R. David Murray" <rdmurray@bitdance.com> wrote:
This is the first time we've been in the situation of having a security-only branch in Mercurial (other than 2.7, which is its own head).
3.1?
Or 2.6? I also don't know what "which is its own head" is supposed to mean :-)
Whatever :) Policy is, and always was, that security fixes are coordinated and committed to old branches by the release manager for that branch.
Georg
On Mar 30, 2013, at 06:14 PM, Antoine Pitrou wrote:
Or 2.6?
Right, but no one should really be committing to 2.6 without at least checking with me first. FWIW, I still merge from 2.6 to 2.7 if appropriate, but given that there's only one more 2.6 release planned at all, this is a very rare occurrence.
-Barry
On Sat, 30 Mar 2013 10:13:13 -0700, Ned Deily <nad@acm.org> wrote:
In article <20130330141534.44893250BDD@webabinitio.net>, "R. David Murray" <rdmurray@bitdance.com> wrote:
This is the first time we've been in the situation of having a security-only branch in Mercurial (other than 2.7, which is its own head).
3.1?
Heh, silly me. The memory is the second thing that goes.
--David
Georg Brandl <g.brandl <at> gmx.net> writes:
with 3.2.4 being the last regular 3.2 maintenance release and the rc out of the door, the 3.2 branch should only be committed to for security releases. So please don't commit anything there anymore. To help everyone remember, I've configured the push hook to reject changesets to the 3.2 branch.
I recently committed some changes to the logging cookbook, and as per your wishes only applied them to 3.3 and default, even though they would be applicable to 3.2 as well. Is the position on documentation updates the same as for code? Should it be?
Regards,
Vinay Sajip
On 03/31/2013 06:27 PM, Vinay Sajip wrote:
Georg Brandl <g.brandl <at> gmx.net> writes:
with 3.2.4 being the last regular 3.2 maintenance release and the rc out of the door, the 3.2 branch should only be committed to for security releases. So please don't commit anything there anymore. To help everyone remember, I've configured the push hook to reject changesets to the 3.2 branch.
I recently committed some changes to the logging cookbook, and as per your wishes only applied them to 3.3 and default, even though they would be applicable to 3.2 as well. Is the position on documentation updates the same as for code? Should it be?
Yes, and it should be. We can't maintain old releases indefinitely, having 3 active branches is quite enough.
Updates to the 3.2 docs wouldn't be released in any form anyway. As you might have noticed, the online 3.2 docs aren't updated daily, but only on releases (i.e. the 3.2.4 update will be the last).
Georg
participants (9)
-
Antoine Pitrou -
Barry Warsaw -
Georg Brandl -
Jesus Cea -
Ned Deily -
Nick Coghlan -
R. David Murray -
Terry Reedy -
Vinay Sajip