Am 20.02.2014 02:24, schrieb Stephen J. Turnbull:
[ ... ]
Sure, but it *doesn't* help in knowing which ones are *correctly*
addressed. These *are* ambitious changes; some of the remaining bugs
may be very deep. The obvious fixes may do more harm than good. Ie,
more eyes is (a) mostly a
Antoine Pitrou writes:
On Thu, 20 Feb 2014 10:24:16 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
The argument that a read-only, no cherrypicking by committers repo
is nothing but a better tarball is valid, but as I say, AFAICS the
expected gain is pretty marginal. The
On Thu, 20 Feb 2014 10:24:16 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
The argument that a read-only, no cherrypicking by committers repo
is nothing but a better tarball is valid, but as I say, AFAICS the
expected gain is pretty marginal. The conflict here is not Larry's
process,
On Wed, 19 Feb 2014 19:20:12 -0800
Larry Hastings la...@hastings.org wrote:
As for a user beware clone: I worry about providing anything that
looks/tastes/smells like a repo. Someone could still inadvertently push
those revisions back to trunk, and then we'd have a real mess on our
Am 19.02.2014 22:18, schrieb Nick Coghlan:
and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc.
well, I think it would be wrong to restrict that for only that reason. I did
object to delay the release cycle a second time for completing a feature. If
the release has to be
On 21 Feb 2014 08:38, Matthias Klose d...@ubuntu.com wrote:
Am 19.02.2014 22:18, schrieb Nick Coghlan:
and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc.
well, I think it would be wrong to restrict that for only that reason. I
did
object to delay the release cycle a
Am 19.02.2014 01:07, schrieb Larry Hastings:
On 02/18/2014 03:54 PM, Victor Stinner wrote:
2014-02-19 0:46 GMT+01:00 Larry Hastings la...@hastings.org:
Is there *any* reason to make this branch public before 3.4.0 final?
I'm a little bit worried by the fact that buildbots will not test it.
Am 19.02.2014 03:46, schrieb Guido van Rossum:
I do think there's one legitimate concern -- someone might pull a diff from
Larry's branch and then accidentally push it back to the public repo, and then
Larry would be in trouble if he was planning to rebase that diff. (The joys of
DVCS -- we
Am 19.02.2014 00:54, schrieb Barry Warsaw:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch
private?
On Tue, 18 Feb 2014 18:54:23 -0500
Barry Warsaw ba...@python.org wrote:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why
On Tue, 18 Feb 2014 18:46:16 -0800
Guido van Rossum gu...@python.org wrote:
I do think there's one legitimate concern -- someone might pull a diff from
Larry's branch and then accidentally push it back to the public repo, and
then Larry would be in trouble if he was planning to rebase that
On 02/19/2014 01:20 PM, Antoine Pitrou wrote:
On Tue, 18 Feb 2014 18:46:16 -0800
Guido van Rossum gu...@python.org wrote:
I do think there's one legitimate concern -- someone might pull a diff from
Larry's branch and then accidentally push it back to the public repo, and
then Larry would be in
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net wrote:
Am 19.02.2014 00:54, schrieb Barry Warsaw:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but
On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote:
That's why it's RC2 and not 3.4final, right? Once Larry says it's baked,
everyone *will* have a chance to test it. What value is a preview of the
preview really going to add? Give Larry some trust and freedom to do things
in the way that makes
On Wed, Feb 19, 2014 at 4:13 AM, Antoine Pitrou solip...@pitrou.net wrote:
Agreed too. Python isn't developed in private.
That's a ridiculous accusation, bordering on malicious. Larry isn't
developing Python in private. He is simply working on something that
he'll release when he feels
On Wed, Feb 19, 2014 at 8:16 AM, Barry Warsaw ba...@python.org wrote:
On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote:
That's why it's RC2 and not 3.4final, right? Once Larry says it's baked,
everyone *will* have a chance to test it. What value is a preview of the
preview really going
Am 19.02.2014 16:50, schrieb Guido van Rossum:
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
Am 19.02.2014 00:54, schrieb Barry Warsaw:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry
Am 19.02.2014 19:00, schrieb Georg Brandl:
Give Larry some trust and freedom to do things in the way that makes him
comfortable.
I have no doubts that Larry will make 3.4 the best Python yet :) So far he
has discussed most of his procedures with us, so I don't see a reason not to
weigh in
Am 19.02.2014 19:00, schrieb Georg Brandl:
Am 19.02.2014 16:50, schrieb Guido van Rossum:
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
Am 19.02.2014 00:54, schrieb Barry Warsaw:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
On 20 Feb 2014 04:18, Georg Brandl g.bra...@gmx.net wrote:
Am 19.02.2014 19:00, schrieb Georg Brandl:
Am 19.02.2014 16:50, schrieb Guido van Rossum:
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
Am 19.02.2014 00:54, schrieb Barry
Nick Coghlan writes:
I suspect everyone is also highly aware of the fact that there are
some ambitious changes in 3.4,
Which is an argument for longer beta and RC periods than usual, or
maybe some of the ambition should have been restrained. It's not
necessarily a reason why more eyes help
On Feb 20, 2014, at 10:24 AM, Stephen J. Turnbull wrote:
But should Ubuntu desires be distorting a volunteer RE's process?
Ubuntu 14.04 final freeze is April 10[1], so I think that's the drop dead date
for getting 3.4 final into Ubuntu 14.04. Matthias may correct me, but I think
if we can hit
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:
The conflict here is not Larry's
process, it's the decision to make an ambitious release on a short
time schedule. I sympathize with Ubuntu to some extent -- they have a
business to run, after all. But should Ubuntu desires be distorting a
On 20 Feb 2014 12:26, Ethan Furman et...@stoneleaf.us wrote:
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:
The conflict here is not Larry's
process, it's the decision to make an ambitious release on a short
time schedule. I sympathize with Ubuntu to some extent -- they have a
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:
Nick Coghlan writes:
A user beware, this may be rebased without warning clone would be
fine for that purpose, and I suspect in most cases just running rc2
- final with such a clone available (preserving Larry's current
workflow until
Larry Hastings writes:
Someone could still inadvertently push those revisions back to
trunk, and then we'd have a real mess on our hands. Publishing
tarballs drops the possibility down to about zero.
Note: I see no reason for you to change your process for the 3.4.0
release. I just want
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch
private?
Matthias
___
Python-Dev mailing list
On 02/18/2014 03:38 PM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch
private?
Yes. It ensures that nobody can check something
2014-02-19 0:46 GMT+01:00 Larry Hastings la...@hastings.org:
Is there *any* reason to make this branch public before 3.4.0 final?
I'm a little bit worried by the fact that buildbots will not test it.
Cherry-picking many patches is complex. It's safe if you have a very
short list of changes.
Am 19.02.2014 00:46, schrieb Larry Hastings:
On 02/18/2014 03:38 PM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch
private?
Yes.
2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org:
You might think that anything you check in to the default branch in Python
trunk will go into 3.4.0 rc2, and after that ships, checkins would go into
3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to
default
On 02/18/2014 03:54 PM, Victor Stinner wrote:
2014-02-19 0:46 GMT+01:00 Larry Hastings la...@hastings.org:
Is there *any* reason to make this branch public before 3.4.0 final?
I'm a little bit worried by the fact that buildbots will not test it.
fact?
Am 19.02.2014 01:05, schrieb Larry Hastings:
On 02/18/2014 03:56 PM, Matthias Klose wrote:
Am 19.02.2014 00:46, schrieb Larry Hastings:
On 02/18/2014 03:38 PM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
On 02/18/2014 04:19 PM, Matthias Klose wrote:
Am 19.02.2014 01:05, schrieb Larry Hastings:
On 02/18/2014 03:56 PM, Matthias Klose wrote:
Am 19.02.2014 00:46, schrieb Larry Hastings:
On 02/18/2014 03:38 PM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch
private?
IMO, no. read-only for !larry sure, but not
I do think there's one legitimate concern -- someone might pull a diff from
Larry's branch and then accidentally push it back to the public repo, and
then Larry would be in trouble if he was planning to rebase that diff. (The
joys of DVCS -- we never had this problem in the cvs or svn days...)
Sounds like you aren't exactly a DVCS fan...
On Tue, Feb 18, 2014 at 8:46 PM, Guido van Rossum gu...@python.org wrote:
I do think there's one legitimate concern -- someone might pull a diff
from Larry's branch and then accidentally push it back to the public repo,
and then Larry would be in
On Tue, Feb 18, 2014, at 03:54 PM, Barry Warsaw wrote:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this
On 02/16/2014 03:45 PM, Paul Moore wrote:
http://bugs.python.org/issue20621 is significant enough to be
resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in?
I'm not sure how to find the revision number that contains the fix to
follow the process you outline above, so I'm just
Thanks, I see. Greg already filed a tracking issue, so it's covered anyway.
On 17 February 2014 15:33, Larry Hastings la...@hastings.org wrote:
On 02/16/2014 03:45 PM, Paul Moore wrote:
http://bugs.python.org/issue20621 is significant enough to be
resulting in a 3.3.5 release - can you make
On 02/17/2014 03:20 PM, Victor Stinner wrote:
2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org:
You might think that anything you check in to the default branch in Python
trunk will go into 3.4.0 rc2, and after that ships, checkins would go into
3.4.0 final. Ho ho ho! That's not
On 2/17/2014 6:20 PM, Victor Stinner wrote:
2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org:
You might think that anything you check in to the default branch in Python
trunk will go into 3.4.0 rc2, and after that ships, checkins would go into
3.4.0 final. Ho ho ho! That's not
Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has
been released, and the next release will be rc2.
You might think that anything you check in to the default branch in
Python trunk will go into 3.4.0 rc2, and after that ships, checkins
would go into 3.4.0 final. Ho ho
http://bugs.python.org/issue20621 is significant enough to be
resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in?
I'm not sure how to find the revision number that contains the fix to
follow the process you outline above, so I'm just mentioning it here
on the issue to make sure
For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a.
On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.mo...@gmail.com wrote:
http://bugs.python.org/issue20621 is significant enough to be
resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in?
I'm not sure how to
http://bugs.python.org/issue20651 filed to track this as larry requested.
On Sun, Feb 16, 2014 at 7:09 PM, Gregory P. Smith g...@krypto.org wrote:
For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a.
On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.mo...@gmail.com wrote:
46 matches
Mail list logo