Now that 2.6.9 is out, I wonder if there's anything we can or should do to the Mercurial repository to explicitly prevent commits to the 2.6 branch? We have we done to older branches?
Also, can anybody think of anything in the devguide that needs to be updated?
Cheers, -Barry
2013/10/30 Barry Warsaw barry@python.org:
Now that 2.6.9 is out, I wonder if there's anything we can or should do to the Mercurial repository to explicitly prevent commits to the 2.6 branch? We have we done to older branches?
I've now disabled pushing to the 2.6 branch.
-- Regards, Benjamin
Am 30.10.13 15:13, schrieb Barry Warsaw:
Now that 2.6.9 is out, I wonder if there's anything we can or should do to the Mercurial repository to explicitly prevent commits to the 2.6 branch? We have we done to older branches?
I think closing the branch is just right; it's done through "hg commit --close-branch".
We have we done to older branches?
hg branches -c will tell:
default 86195:63a1ee94b3ed 2.7 86192:0820e8394d96 3.3 86193:249ba942a6d4 (inaktiv) 2.6 85914:6d7ae764b4f2 (inaktiv) 3.2 85752:ef90c40fe6cf (inaktiv) 3.1 85751:713d71048ab9 (inaktiv) 2.5 73244:b48e1b48e670 (geschlossen) 3.0 68249:4cd9f5e89061 (geschlossen) legacy-trunk 68241:b77918288f7d (geschlossen) 2.4 68239:ceec209b26d4 (geschlossen) 2.3 68237:364638d6434d (geschlossen) 2.2 68235:61b0263d6881 (geschlossen) 2.1 68233:e849d484029f (geschlossen) 2.0 68231:5fd74354d73b (geschlossen)
In addition, I *think* we have a hook on the master that prevents further pushes to the branch.
Also, can anybody think of anything in the devguide that needs to be updated?
Not the devguide. If anywhere, in PEP 101.
Regards, Martin
On 31 Oct 2013 00:31, Martin v. Löwis martin@v.loewis.de wrote:
Am 30.10.13 15:13, schrieb Barry Warsaw:
Now that 2.6.9 is out, I wonder if there's anything we can or should do to the Mercurial repository to explicitly prevent commits to the 2.6 branch? We have we done to older branches?
I think closing the branch is just right; it's done through "hg commit --close-branch".
We have we done to older branches?
hg branches -c will tell:
default 86195:63a1ee94b3ed 2.7 86192:0820e8394d96 3.3 86193:249ba942a6d4 (inaktiv) 2.6 85914:6d7ae764b4f2 (inaktiv) 3.2 85752:ef90c40fe6cf (inaktiv) 3.1 85751:713d71048ab9 (inaktiv) 2.5 73244:b48e1b48e670 (geschlossen) 3.0 68249:4cd9f5e89061 (geschlossen) legacy-trunk 68241:b77918288f7d (geschlossen) 2.4 68239:ceec209b26d4 (geschlossen) 2.3 68237:364638d6434d (geschlossen) 2.2 68235:61b0263d6881 (geschlossen) 2.1 68233:e849d484029f (geschlossen) 2.0 68231:5fd74354d73b (geschlossen)
In addition, I *think* we have a hook on the master that prevents further pushes to the branch.
Also, can anybody think of anything in the devguide that needs to be updated?
Not the devguide. If anywhere, in PEP 101.
There's a trick to get the PEP 0 generator to move the release PEP to the historical section, too. I'd have to look at the source code to remember what it is, though.
Cheers, Nick.
Regards, Martin
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 30/10/13 15:18, Benjamin Peterson wrote:
2013/10/30 Barry Warsaw barry@python.org:
Now that 2.6.9 is out, I wonder if there's anything we can or should do to the Mercurial repository to explicitly prevent commits to the 2.6 branch? We have we done to older branches?
I've now disabled pushing to the 2.6 branch.
Could I suggest to mark the branch as "closed" in Mercurial?. I still see it in "hg heads".
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.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQCVAwUBUnEnCJlgi5GaxT1NAQKQagP+PCtYPHZ6FmcRyva2oDT4spP4UcuNheEw faqrVe+jDdDEXx9hPiU36VLfQpSZKFHUQKAw7jBBJCYi5TSyxYq2oEGhdTwjg6JL bsQ1mbE2H/7a+uB30+fUiZmydcqD8fpeSmWwFMjDzYO6z55kmCXpFxUHnEBa3hCM LhOR20hgFVE= =wqbn -----END PGP SIGNATURE-----
On Oct 30, 2013, at 03:24 PM, Martin v. Löwis wrote:
I think closing the branch is just right; it's done through "hg commit --close-branch".
In addition, I *think* we have a hook on the master that prevents further pushes to the branch.
Looks like Benjamin updated the hook but didn't close the branch. I think we've got that all sorted out now though.
Not the devguide. If anywhere, in PEP 101.
I'll take a swing through that when I get some free time.
Cheers, -Barry
On Oct 31, 2013, at 01:28 AM, Nick Coghlan wrote:
There's a trick to get the PEP 0 generator to move the release PEP to the historical section, too. I'd have to look at the source code to remember what it is, though.
elif pep.type_ == 'Informational':
# Hack until the conflict between the use of "Final"
# for both API definition PEPs and other (actually
# obsolete) PEPs is addressed
if (pep.status == "Active" or
"Release Schedule" not in pep.title):
info.append(pep)
else:
historical.append(pep)So PEP 361 (the 2.6/3.0 release schedule PEP) actually does end up in the Historical bin. The PEP itself probably should have remained Active until yesterday.
Do we want an explicit state for Status: Final -> Historical?
(TBH, I don't care enough to do any work on it. ;)
-Barry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Oct 30, 2013, at 04:34 PM, Jesus Cea wrote:
Could I suggest to mark the branch as "closed" in Mercurial?. I still see it in "hg heads".
$ hg pull -u
/me replaces the time machine keys before Guido notices they were missing.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBCAAGBQJScSvwAAoJEBJutWOnSwa/vw0P/Anj00KegI99JiC636saN+6v xGi1YbmtvlCEiKkEBHMBfGQSgNkr0ImfgFKyT4sY8hIve9AGkoOKUzYXUFFsWjI1 G2g5Xch4eoEqfCTmFXHvPjfjCyrsE/P7BDgO3h3lSvYC2Y3DkNjrZVta3weu4kbE PpMhUTV7QUExX8k01SUEbAA5ToZu2rThy5Qp8ho9kaRZqeekTZ2Vyx2ShZUfuHxf CHQ6x0vNE0j1DuhvrqbWqzSxFsQNs0hlG7uSn/JRuWakQCKh4AkVRlAv2Y8SDlTj ZdKfRXuXfzThwFA0ya4ln8Zwd1loZyKZdn7U5oBb3VT4k0G884/l5mRxcVCW4xfw BFLKgvfYccDFEgkR4Y8g178FMpY7aLTMAN+lFiQ7z685l1ni9dm9QvU8FPPTUhlT OWI+xWws5oOnLmZriz8dC2DyC+Xx7etlyYVUx7SGfH/xVHnInhw0tI3lSs35/nNA bZiyhW/Pc8s3rU1T/pVO2lfifEk+am3OM8ubKjvYinYyVjrK3q8+dLvLG6vHy2DR CqqZEmxbeQkp8a7xDyG5scs4La1z7MoNYYzwZjjKlr3RltTLvLnexi8XMg/SYmgp BZamqJGT+yv4gdUMsODAc/B180E5EVoDDj2nBX6tNB6HZUWJC2CLagrqYRbG4laC oCsTkECKE1EYMl9iF+FK =dRg3 -----END PGP SIGNATURE-----
On 31 Oct 2013 01:54, "Barry Warsaw" barry@python.org wrote:
On Oct 31, 2013, at 01:28 AM, Nick Coghlan wrote:
There's a trick to get the PEP 0 generator to move the release PEP to the historical section, too. I'd have to look at the source code to remember what it is, though.
elif pep.type_ == 'Informational': # Hack until the conflict between the use of "Final" # for both API definition PEPs and other (actually # obsolete) PEPs is addressed if (pep.status == "Active" or "Release Schedule" not in pep.title): info.append(pep) else: historical.append(pep)So PEP 361 (the 2.6/3.0 release schedule PEP) actually does end up in the Historical bin. The PEP itself probably should have remained Active until yesterday.
Do we want an explicit state for Status: Final -> Historical?
(TBH, I don't care enough to do any work on it. ;)
Ah, you have divined the true reason why that hack is still there ;)
Cheers, Nick.
-Barry
participants (5)
-
"Martin v. Löwis" -
Barry Warsaw -
Benjamin Peterson -
Jesus Cea -
Nick Coghlan