[Python-Dev] Who's maintaining Sphinx nowadays?
Hi All, Sorry if this is considered slightly off topic, but Sphinx is the tool we use for the Python core docs so: Who's looking after Sphinx nowadays? I've hit what I consider to be a bug: https://groups.google.com/group/sphinx-dev/browse_thread/thread/197fc26ba570913d?hl=en So I forked on bitbucket and wanted to work up a fix, but running the unit tests on my fresh fork was problematic: https://groups.google.com/group/sphinx-dev/browse_thread/thread/1e1f45978a84577?hl=en The sphinx-dev group seems devoid of sphinx developers currently, so thought I'd ask here to see if anyone could point me in the right direction ;-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] feature freeze questions
>> I have a few questions about feature freeze: >> >> (1) Is increasing test coverage acceptable during feature freeze, even >> if it does not involve fixing a bug? >> >> (2) When adding new tests (e.g. in the course of fixing a bug or >> increasing test coverage), are we allowed to refactor other tests so >> that supporting test code can be shared? Or should the tests be added >> in a less DRY fashion and refactored only after the branch goes back >> to pre-alpha? > > You can do basically anything you want to tests just as long as you > don't make them less stable. > >> >> (3) What types of documentation changes are allowed during feature >> freeze? For example, are we only allowed to fix incorrect >> information, or is it acceptable to improve or add to the information >> about existing functionality? > > All documentation changes are accepted. A follow-up question: during the RC stage, do documentation & test changes require code review by an additional core dev? This also leads me to think about minor (= bugfix) releases. For example, current commits to the 3.2 branch will (presumably) go into 3.2.4 once it's out. Should these commits have the same restrictions as commits to an upcoming release that's in RC stage? Common sense would suggest they should (since any change can break existing functionality and lead to regressions in a previously stable release), but in practice I don't think this is followed. At least not to the letter, with the devguide stating: You cannot skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, everything requires peer review from a core developer. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] feature freeze questions
On Thu, Jul 26, 2012 at 6:24 PM, Eli Bendersky wrote: > You cannot skip the peer review during an RC, no matter how small! > Even if it is a simple copy-and-paste change, everything requires peer > review from a core developer. The extra restrictions during RC are more about not doing things that might force the release to be postponed while a broken change gets unwound. During normal maintenance, we have a bit more time to recover based on buildbot failures or post-checkin review. Another way of reading that paragraph is "once we hit RC, start postponing everything to the next bugfix release, *unless* at least 2 core devs agree it really needs to be in the current release" Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support
Am 25.07.2012 16:38, schrieb Guido van Rossum: > Beware, people requesting dates BC rarely know what they are asking > for. (E.g. Jesus wasn't born on 12/25/0001.) The calendrical > ambiguities are such that representing dates that far in the past is > better left to a specialized class. Read the original discussions > about the datetime type; it loses meaning for dates long ago even if > it can represent them, but the choice was made to ignore these and to > offer a uniform abstraction for 1 <= year <= . For starters. Calendars have more subtle edge cases, for example TAI has a 10 second offset from UTC plus 15 leap seconds. Or the leap year errors in Julian calendar that are handled differently in proleptic Julian calendar which has unsystematic leap years between 45 BC and 4 AD. The rotation velocity of the Earth isn't constant, too. It's a major PITB! > TBH I'm more worried about years >= 1. :-) Why life in the past? The future is ... err the future! :) Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.7 releases
Will there be more 2.7 bugfix releases, and when the next one? In other words; if I submit a patch and it is accepted, can I expect that patch be committed also to the 2.7 branch? Thanks, Thomas Been a long time that I've been here - but still using Python (2.7 now) more and more... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 releases
On Thu, Jul 26, 2012 at 10:56 AM, Thomas Heller wrote: > Will there be more 2.7 bugfix releases, and when the next one? > > In other words; if I submit a patch and it is accepted, can I > expect that patch be committed also to the 2.7 branch? > > We are still back-porting bug fixes to 2.7 branch. Which means that yes, we may definitely see a release. Benjamin might be right person to answer the question on when. Thanks, Senthil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 releases
Will there be more 2.7 bugfix releases Yes. and when the next one? That's up for Benjamin to decide. My view is that one bugfix release every year is more than enough. In other words; if I submit a patch and it is accepted, can I expect that patch be committed also to the 2.7 branch? Don't you have commit rights still? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 releases
Am 26.07.2012 20:16, schrieb [email protected]: Will there be more 2.7 bugfix releases Yes. and when the next one? That's up for Benjamin to decide. My view is that one bugfix release every year is more than enough. Ok. I expect we will still be using 2.7 next year in my company. In other words; if I submit a patch and it is accepted, can I expect that patch be committed also to the 2.7 branch? Don't you have commit rights still? I dont't know. IIRC, I have asked for them to be retracted some years ago. Anyway, I do know nearly nothing about hg and don't have time to learn it. So, I have uploaded a patch and asked for review (since I'm not 1000% sure that it is absolutely correct): http://bugs.python.org/issue15459 Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 releases
On 7/26/2012 2:50 PM, Thomas Heller wrote: Am 26.07.2012 20:16, schrieb [email protected]: Don't you have commit rights still? I dont't know. The tracker thinks you do. That is what the Python logo next to your name means. Anyway, I do know nearly nothing about hg and don't have time to learn it. I started from nothing too. TortoiseHG and its GUI Workbench makes the basics pretty easy. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who's maintaining Sphinx nowadays?
Am 26.07.2012 09:59, schrieb Chris Withers: > Hi All, > > Sorry if this is considered slightly off topic, but Sphinx is the tool > we use for the Python core docs so: > > Who's looking after Sphinx nowadays? I've hit what I consider to be a bug: > > https://groups.google.com/group/sphinx-dev/browse_thread/thread/197fc26ba570913d?hl=en > > So I forked on bitbucket and wanted to work up a fix, but running the > unit tests on my fresh fork was problematic: > > https://groups.google.com/group/sphinx-dev/browse_thread/thread/1e1f45978a84577?hl=en > > The sphinx-dev group seems devoid of sphinx developers currently, so > thought I'd ask here to see if anyone could point me in the right > direction ;-) If you're patient enough, I'll take care of your problem eventually. If not, and you're looking for a project to co-maintain, we can set something up :) Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who's maintaining Sphinx nowadays?
Hi Georg, On 26/07/2012 21:07, Georg Brandl wrote: If you're patient enough, I'll take care of your problem eventually. If not, and you're looking for a project to co-maintain, we can set something up :) I'm certainly interested in helping out where I can, Sphinx has been a fantastic tool... It's mainly the test issues I'm worried about, the change in return code is the bug I was happy to work on. Does Sphinx have any CI anywhere? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] feature freeze questions
Am 26.07.2012 10:24, schrieb Eli Bendersky: >>> I have a few questions about feature freeze: >>> >>> (1) Is increasing test coverage acceptable during feature freeze, even >>> if it does not involve fixing a bug? >>> >>> (2) When adding new tests (e.g. in the course of fixing a bug or >>> increasing test coverage), are we allowed to refactor other tests so >>> that supporting test code can be shared? Or should the tests be added >>> in a less DRY fashion and refactored only after the branch goes back >>> to pre-alpha? >> >> You can do basically anything you want to tests just as long as you >> don't make them less stable. >> >>> >>> (3) What types of documentation changes are allowed during feature >>> freeze? For example, are we only allowed to fix incorrect >>> information, or is it acceptable to improve or add to the information >>> about existing functionality? >> >> All documentation changes are accepted. > > A follow-up question: during the RC stage, do documentation & test > changes require code review by an additional core dev? Test changes: yes, doc changes: only if you think it's necessary. The thing about the docs is: we can fix them basically at any time, since most people use the online version anyway, which is rebuilt daily. > This also leads me to think about minor (= bugfix) releases. For > example, current commits to the 3.2 branch will (presumably) go into > 3.2.4 once it's out. Should these commits have the same restrictions > as commits to an upcoming release that's in RC stage? Common sense > would suggest they should (since any change can break existing > functionality and lead to regressions in a previously stable release), But that can also happen for 3.2 -> 3.3. > but in practice I don't think this is followed. At least not to the > letter, with the devguide stating: > > You cannot skip the peer review during an RC, no matter how small! > Even if it is a simple copy-and-paste change, everything requires peer > review from a core developer. That is only for RC phase, yes. Reviews are always useful, of course (calling them "peer review" sounds funny to me though), and should be always done for larger patches -- which we are quite used to nowadays. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
