On Wed, Mar 16, 2011 at 10:14 PM, R. David Murray rdmur...@bitdance.comwrote:
On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea j...@jcea.es wrote:
On 17/03/11 04:41, R. David Murray wrote:
Dealing with a null merge when someone else has committed between the
time I started the merge dance
When pushed a change to 2.5 branch, I got an error, which I think has
to do with buildbot not available for 2.5 codeline.
It asked me to notify the tracker and here it is.
remote: state = method(*args, **kw)
remote: File /data/buildbot/master/master.cfg, line 87, in
perspective_addChange
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes from the noise of merges.
___
Python-Dev mailing list
Am 17.03.2011 06:14, schrieb R. David Murray:
On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea j...@jcea.es wrote:
On 17/03/11 04:41, R. David Murray wrote:
Dealing with a null merge when someone else has committed between the
time I started the merge dance (I always pull just before I start
Am 17.03.2011 09:57, schrieb Eric Smith:
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes from the noise of merges.
Even though every merge changeset mail
On 3/17/2011 6:28 AM, Georg Brandl wrote:
Am 17.03.2011 09:57, schrieb Eric Smith:
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes from the noise of merges.
On Thu, Mar 17, 2011 at 6:28 AM, Georg Brandl g.bra...@gmx.net wrote:
Am 17.03.2011 09:57, schrieb Eric Smith:
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes
On Thu, Mar 17, 2011 at 6:26 AM, Georg Brandl g.bra...@gmx.net wrote:
Uh... wouldn't using the rebase extension make this much easier?
Perhaps, but I/we haven't figured out how to get rebasing to do anything useful.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
Le 16/03/2011 18:49, Martin v. Löwis a écrit :
Having the revision of cpython to compare against is the
difficult part;
how about: 'max( ancestors(default) and not outgoing() )' ?
___
Python-Dev mailing list
Python-Dev@python.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 06:14, R. David Murray wrote:
The fun part comes if there are changesets. At this point there
are two options: go through each of the branches doing an up/merge/ci,
and then pull/push. Or, what I actually do:
hg log
hg strip the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 13:35, Jesus Cea wrote:
Tonight I was thinking about doing a merge inside the branch, to solve
the +1 branch. Something like transforming:
Another thing I was thinking about tonight was... dropping the +1 head
banning. Embrace it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/11/10 13:19, Jesus Cea wrote:
Would be acceptable to change something like:
add_library_path(/usr/local/lib)
to something similar to:
if (platform.uname()==SunOS) and (platform.architecture()[0]==64bits) :
On Thu, Mar 17, 2011 at 07:41, Jesus Cea j...@jcea.es wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 13:35, Jesus Cea wrote:
Tonight I was thinking about doing a merge inside the branch, to solve
the +1 branch. Something like transforming:
Another thing I was thinking
On Thu, 17 Mar 2011 11:26:13 +0100, Georg Brandl g.bra...@gmx.net wrote:
Am 17.03.2011 06:14, schrieb R. David Murray:
The fun part comes if there are changesets. At this point there
are two options: go through each of the branches doing an up/merge/ci,
and then pull/push. Or, what I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 14:10, Brian Curtin wrote:
On Thu, Mar 17, 2011 at 07:41, Jesus Cea j...@jcea.es
mailto:j...@jcea.es wrote:
[..]
Each developer is responsible of merging HIS heads. If somebody
forgets, nothing wrong will happens. And no patch
On Wed, 16 Mar 2011 23:21:37 -0700, Gregory P. Smith g...@krypto.org wrote:
why do you use hg diff and patch above rather than hg export and hg import?
(not implying one is better than the other, learning here...)
We're all learning, even the ones who have used Mercurial before (which
isn't
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmur...@bitdance.com wrote:
It would be great if rebase did work with share, that would make a
push race basically a non-issue for me.
rebase as well as strip destroy some history, meaning some of your
shared clones may end up having their
On Thu, 17 Mar 2011 13:35:50 +0100, Jesus Cea j...@jcea.es wrote:
On 17/03/11 06:14, R. David Murray wrote:
Clearly, this procedure is not for everyone
Clearly not :).
So you do a hg strip and start over again.
The problem with this is that your patch will be applied on top of the
On Thu, Mar 17, 2011 at 9:33 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmur...@bitdance.com wrote:
It would be great if rebase did work with share, that would make a
push race basically a non-issue for me.
rebase as well as strip
On Thu, 17 Mar 2011 01:01:30 +0100
nick.coghlan python-check...@python.org wrote:
http://hg.python.org/cpython/rev/e3fb176add41
changeset: 68628:e3fb176add41
user:Nick Coghlan ncogh...@gmail.com
date:Wed Mar 16 19:52:14 2011 -0400
summary:
Exercise crashers to ensure they
On Thu, Mar 17, 2011 at 10:03 AM, Reid Kleckner reid.kleck...@gmail.com wrote:
98% of the time, if you don't actually have merge conflicts, applying
your change over someone else's without testing will work, so I feel
like rebasing a single commit without testing is no big deal. On the
off
On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
This has broken many buildbots.
I'm pretty sure I know which one is the problem child, so I just
pushed a fix which should get that one dying reliably on more
platforms.
I also tweaked the test to provide more info as
On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmur...@bitdance.com wrote:
It would be great if rebase did work with share, that would make a
push race basically a non-issue for me.
rebase as well as
On Thu, Mar 17, 2011 at 10:39 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
This has broken many buildbots.
I'm pretty sure I know which one is the problem child, so I just
pushed a fix which should get that one dying
On Thu, 17 Mar 2011 10:03:36 -0400, Reid Kleckner reid.kleck...@gmail.com
wrote:
I don't think anyone has laid out why destroying history is considered
bad by some, so I thought I'd plug this post:
http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html
Essentially, lets
On Thu, 17 Mar 2011 10:50:24 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmur...@bitdance.com wrote:
It would be great if rebase did work with
I've thought some more about deprecations and subsequent deletions in
Python 3 (but not read the whole thread -- sorry, I've gotten sick
right after coming home from PyCon).
I think that as long as a significant number of people are still using
Python 2, it may be problematic if we start removing
On Thu, 17 Mar 2011 16:00:50 +0100, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 17 Mar 2011 10:50:24 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David
Am 17.03.11 07:30, schrieb Baptiste Carvello:
Le 16/03/2011 18:49, Martin v. Löwis a écrit :
Having the revision of cpython to compare against is the
difficult part;
how about: 'max( ancestors(default) and not outgoing() )' ?
That fails if there have been later merges with default.
Am 17.03.11 07:30, schrieb Baptiste Carvello:
Le 16/03/2011 18:49, Martin v. Löwis a écrit :
Having the revision of cpython to compare against is the
difficult part;
how about: 'max( ancestors(default) and not outgoing() )' ?
I take back what I just said: it looks good.
Regards,
Martin
2011/3/16 Thomas Heller thel...@ctypes.org:
I would like my committer rights to be retracted.
I have been contributing to Python here and there for 10 years now,
and it was a pleasant experience.
Unfortunately, since about a year I have lots more things to do, and
I won't be able to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 14:45, R. David Murray wrote:
Not if the cpython repo is in a fully merged stated. And if it
isn't, I will wait until it is. (The update notifications on the
IRC channel help with monitoring this.)
That is repository serialization.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 16:04, Guido van Rossum wrote:
I don't want to be alarmist and I don't want to start another
moratorium, but I do think that we need to be aware of people coming
in sideways into Python 3 and missing the nice deprecations. So
let's be
On 03/17/2011 03:08 PM, Jesus Cea wrote:
I would suggest to keep deprecating things in 3.x, BUT keeping the
deprecated stuff around (maybe reimplementing them using the new stuff)
until we decide is safe to axe it, instead of the regular 3.x
deprecates, 3.(x+1) cleans up.
At some point, didn't
On Mar 17, 2011, at 12:22 PM, Eric Smith wrote:
On 03/17/2011 03:08 PM, Jesus Cea wrote:
I would suggest to keep deprecating things in 3.x, BUT keeping the
deprecated stuff around (maybe reimplementing them using the new stuff)
until we decide is safe to axe it, instead of the regular 3.x
On Mar 17, 2011, at 4:07 PM, Raymond Hettinger wrote:
Agreeing with Guido is always a good move :-)
In addition, any new deprecations in Py3.x can be marked with py3k warnings
in Py2.7 point releases. That would give users the maximum chance to make
updates before porting, even if they
Nick Coghlan ncogh...@gmail.com writes:
On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
This has broken many buildbots.
I'm pretty sure I know which one is the problem child, so I just
pushed a fix which should get that one dying reliably on more
platforms.
On
On 3/17/2011 11:04 AM, Guido van Rossum wrote:
I've thought some more about deprecations and subsequent deletions in
Python 3 (but not read the whole thread -- sorry, I've gotten sick
right after coming home from PyCon).
I think that as long as a significant number of people are still using
On 3/17/2011 1:45 PM, Benjamin Peterson wrote:
2011/3/16 Thomas Hellerthel...@ctypes.org:
I would like my committer rights to be retracted.
I have been contributing to Python here and there for 10 years now,
and it was a pleasant experience.
Unfortunately, since about a year I have lots more
On Thu, 17 Mar 2011 19:23:30 -0400
Terry Reedy tjre...@udel.edu wrote:
People should retest their stuff with
each micro (bugfix) release anyway.
I'm not sure they should. The point of having micro releases is that
they don't bring any visible change in behaviour - apart from fixing
bugs, that
On Thu, Mar 17, 2011 at 8:35 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 17 Mar 2011 19:23:30 -0400
Terry Reedy tjre...@udel.edu wrote:
People should retest their stuff with
each micro (bugfix) release anyway.
I'm not sure they should. The point of having micro releases is that
On 03/17/2011 07:23 PM, Terry Reedy wrote:
As I understand it, the Pyxxx to PyCapsule CAPI warning was put in 2.7.
In 2.7, the CObject constructor PyCObject_FromVoidPtr() threw a
PendingDeprecationWarning exception. Like other warnings, these aren't
active by default. This still caused
Antoine Pitrou wrote:
On Thu, 17 Mar 2011 19:23:30 -0400
Terry Reedy tjre...@udel.edu wrote:
People should retest their stuff with
each micro (bugfix) release anyway.
I'm not sure they should. The point of having micro releases is that
they don't bring any visible change in behaviour - apart
On Wed, Mar 16, 2011 at 5:02 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 15, 2011 at 11:34 PM, Guido van Rossum gu...@python.org wrote:
Can you be specific? What is different between those RFCs?
I finally got around to trying to backport some of the additional
urljoin tests from
Nick Coghlan wrote:
The problem is that it is quite a lot of work to get fully general URI
parsing to work correctly, but the overlap with legacy URL parsing is
large enough that many (most?) use cases in practice work just fine
with the older RFC semantics.
Yes. We can have API which
On Thu, Mar 17, 2011 at 8:19 PM, Senthil Kumaran orsent...@gmail.com wrote:
Nick Coghlan wrote:
The problem is that it is quite a lot of work to get fully general URI
parsing to work correctly, but the overlap with legacy URL parsing is
large enough that many (most?) use cases in practice
46 matches
Mail list logo
