Fwd: [Python-checkins] r78923 - in python/branches/release26-maint: Doc/Makefile Doc/tools/sphinxext/download.html
I'm not necessarily saying these shouldn't go into 2.6.5, but this late in the release cycle, every change needs to be justified. My preferred way of doing so is by filing a release blocker issue stating and backing up the requested change. We can then discuss any potential impact on release testing and schedule. I'm fine with one issue if all these commits to the release26-maint branch are for the same issue. Georg, please file that bug so we can formally decide whether or not to include these in 2.6.5 final, and whether or not they require a 2.6.5 rc 3 (which as you know I really don't want to do! ;) Thanks, -Barry Begin forwarded message:
From: georg.brandl <python-checkins@python.org> Date: March 13, 2010 8:42:13 AM EST To: python-checkins@python.org Subject: [Python-checkins] r78923 - in python/branches/release26-maint: Doc/Makefile Doc/tools/sphinxext/download.html message-id: <20100313134213.9030CE3C1@mail.python.org>
Author: georg.brandl Date: Sat Mar 13 14:42:13 2010 New Revision: 78923
Log: Merged revisions 78921 via svnmerge from svn+ssh://pythondev@svn.python.org/python/trunk
........ r78921 | georg.brandl | 2010-03-13 14:39:46 +0100 (Sa, 13 Mär 2010) | 1 line
Change/fix handling of docs download location: for daily builds, put them right next to the HTML. ........
Modified: python/branches/release26-maint/ (props changed) python/branches/release26-maint/Doc/Makefile python/branches/release26-maint/Doc/tools/sphinxext/download.html
Modified: python/branches/release26-maint/Doc/Makefile ============================================================================== --- python/branches/release26-maint/Doc/Makefile (original) +++ python/branches/release26-maint/Doc/Makefile Sat Mar 13 14:42:13 2010 @@ -157,16 +157,17 @@ check: $(PYTHON) tools/rstlint.py -i tools
-# Targets for automatic doc build +# Targets for daily automated doc build
# for development releases: always build autobuild-dev: make update - make dist + make dist SPHINXOPTS='-A daily=1'
-# for stable releases: only build if not in development mode +# for stable releases: only build if not in pre-release stage (alpha, beta, rc) autobuild-stable: @case $(DISTVERSION) in *[abc]*) \ - echo "Not building; not a release version."; exit 1;; \ + echo "Not building; $(DISTVERSION) is not a release version."; \ + exit 1;; \ esac @make autobuild-dev
Modified: python/branches/release26-maint/Doc/tools/sphinxext/download.html ============================================================================== --- python/branches/release26-maint/Doc/tools/sphinxext/download.html (original) +++ python/branches/release26-maint/Doc/tools/sphinxext/download.html Sat Mar 13 14:42:13 2010 @@ -1,15 +1,14 @@ {% extends "layout.html" %} {% set title = 'Download' %} -{% set dlbase = 'http://docs.python.org/ftp/python/doc/current' %} -{% block body %} +{% if daily is defined %} + {% set dlbase = pathto('archives', 1) %} +{% else %} + {% set dlbase = 'http://docs.python.org/ftp/python/doc/' + release %} +{% endif %}
+{% block body %} <h1>Download Python {{ release }} Documentation</h1>
-{% if 'a' in release or 'b' in release or 'c' in release %} -<p>We don't package the documentation for development releases for download. - Downloads will be available for the final release.</p> - -{% else %} {% if last_updated %}<p><b>Last updated on: {{ last_updated }}.</b></p>{% endif %}
<p>To download an archive containing all the documents for this version of @@ -55,6 +54,4 @@
<p>If you have comments or suggestions for the Python documentation, please send email to <a href="mailto:docs@python.org">docs@python.org</a>.</p> -{% endif %} - {% endblock %} _______________________________________________ Python-checkins mailing list Python-checkins@python.org http://mail.python.org/mailman/listinfo/python-checkins
Am 13.03.2010 17:51, schrieb Barry Warsaw:
I'm not necessarily saying these shouldn't go into 2.6.5, but this late in the release cycle, every change needs to be justified. My preferred way of doing so is by filing a release blocker issue stating and backing up the requested change. We can then discuss any potential impact on release testing and schedule. I'm fine with one issue if all these commits to the release26-maint branch are for the same issue.
Georg, please file that bug so we can formally decide whether or not to include these in 2.6.5 final, and whether or not they require a 2.6.5 rc 3 (which as you know I really don't want to do! ;)
No need to file a new issue -- I've promoted 8111 to release blocker. I've added an explanation and a collective diff. No further RC is needed.
Sorry for directly committing this, but I felt it was within my disgression as Documentation Expert and just fair -- after all PEP 101 states you have to get my approval during the release process, which I didn't see for these RCs :)
cheers, Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Mar 13, 2010, at 07:11 PM, Georg Brandl wrote:
No need to file a new issue -- I've promoted 8111 to release blocker. I've added an explanation and a collective diff. No further RC is needed.
Thanks; I've accepted and closed the issue.
Sorry for directly committing this, but I felt it was within my disgression as Documentation Expert and just fair -- after all PEP 101 states you have to get my approval during the release process, which I didn't see for these RCs :)
This is true. :) I really appreciate the fix, and you're definitely right that it's your discretion to make these commits. I'm just being overly paranoid during rc2->final because I'm really hoping to avoid an rc3. For me, your bug report was perfect because it explained what and why you were doing it, and that you're confident an rc3 isn't needed. But I want to make sure that you're cool with the process, so let me know if you think I went too far.
-Barry
Am 14.03.2010 00:08, schrieb Barry Warsaw:
On Mar 13, 2010, at 07:11 PM, Georg Brandl wrote:
No need to file a new issue -- I've promoted 8111 to release blocker. I've added an explanation and a collective diff. No further RC is needed.
Thanks; I've accepted and closed the issue.
Sorry for directly committing this, but I felt it was within my disgression as Documentation Expert and just fair -- after all PEP 101 states you have to get my approval during the release process, which I didn't see for these RCs :)
This is true. :) I really appreciate the fix, and you're definitely right that it's your discretion to make these commits. I'm just being overly paranoid during rc2->final because I'm really hoping to avoid an rc3. For me, your bug report was perfect because it explained what and why you were doing it, and that you're confident an rc3 isn't needed. But I want to make sure that you're cool with the process, so let me know if you think I went too far.
No, I don't -- I quite understand that you want to know what's going on in "your" branch so close to the final, and I should have known that. I'll be in the same position soon for 3.2. So, thanks for bringing it up.
cheers, Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Am 14.03.2010 00:35, schrieb Georg Brandl:
Am 14.03.2010 00:08, schrieb Barry Warsaw:
On Mar 13, 2010, at 07:11 PM, Georg Brandl wrote:
No need to file a new issue -- I've promoted 8111 to release blocker. I've added an explanation and a collective diff. No further RC is needed.
Thanks; I've accepted and closed the issue.
Sorry for directly committing this, but I felt it was within my disgression as Documentation Expert and just fair -- after all PEP 101 states you have to get my approval during the release process, which I didn't see for these RCs :)
This is true. :) I really appreciate the fix, and you're definitely right that it's your discretion to make these commits. I'm just being overly paranoid during rc2->final because I'm really hoping to avoid an rc3. For me, your bug report was perfect because it explained what and why you were doing it, and that you're confident an rc3 isn't needed. But I want to make sure that you're cool with the process, so let me know if you think I went too far.
No, I don't -- I quite understand that you want to know what's going on in "your" branch so close to the final, and I should have known that. I'll be in the same position soon for 3.2. So, thanks for bringing it up.
Thinking of that a bit more: after the Hg transition, shouldn't we be able to really freeze a branch that is in pre-release approval-needed mode? It is trivial for anyone to commit a fix to their own branch, and then instead of pushing they'd have to notify the release manager to pull from them, as the only person who can push to the frozen branch.
Dirkjan, is that feasible?
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Thinking of that a bit more: after the Hg transition, shouldn't we be able to really freeze a branch that is in pre-release approval-needed mode? It is trivial for anyone to commit a fix to their own branch, and then instead of pushing they'd have to notify the release manager to pull from them, as the only person who can push to the frozen branch.
FWIW, it would be possible to freeze a branch also in subversion, today.
As for pulling from committer branches: that would require that committers host their branches somewhere.
Regards, Martin
Am 14.03.2010 00:53, schrieb "Martin v. Löwis":
Thinking of that a bit more: after the Hg transition, shouldn't we be able to really freeze a branch that is in pre-release approval-needed mode? It is trivial for anyone to commit a fix to their own branch, and then instead of pushing they'd have to notify the release manager to pull from them, as the only person who can push to the frozen branch.
FWIW, it would be possible to freeze a branch also in subversion, today.
Yes, but I'm sure we don't want to bother setting that up so close to the switch :)
As for pulling from committer branches: that would require that committers host their branches somewhere.
Yes. But that's no big deal, isn't it? They can use a public hg hoster like bitbucket, or we can have a facility on hg.python.org -- it doesn't really matter where, it is always very easy to publish a hg branch.
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Le Sun, 14 Mar 2010 01:03:00 +0100, Georg Brandl <g.brandl@gmx.net> a écrit :
As for pulling from committer branches: that would require that committers host their branches somewhere.
Yes. But that's no big deal, isn't it? They can use a public hg hoster like bitbucket, or we can have a facility on hg.python.org -- it doesn't really matter where, it is always very easy to publish a hg branch.
Or people can just use "hg out" or "hg export".
On Sun, Mar 14, 2010 at 00:40, Georg Brandl <g.brandl@gmx.net> wrote:
Thinking of that a bit more: after the Hg transition, shouldn't we be able to really freeze a branch that is in pre-release approval-needed mode? It is trivial for anyone to commit a fix to their own branch, and then instead of pushing they'd have to notify the release manager to pull from them, as the only person who can push to the frozen branch.
Sure, that should be easy. We could also contemplate Mozilla's model here: they have a hook that disallows all commits, but you can override it by having a specific keyword in the commit message (so the guy who broke the build can push his fix whoever he is, and everyone else will know not to push).
Cheers,
Dirkjan
participants (5)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Dirkjan Ochtman -
Georg Brandl