> Yes, that's all I meant: make it the committer's job
> to merge or block as appropriate. I just wasn't sure if
> there was some reason that this would be difficult or
> undesirable.
Ah, yes. It is indeed difficult or undesirable, or was
so in the past: Some committers don't care (didn't care)
On Sun, Mar 30, 2008 at 9:43 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 30, 2008 at 7:41 PM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On Sun, Mar 30, 2008 at 4:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > If you'd like, I can merge the
(sorry for top posting)
I haven't really had time to update the tests/documentation, but
again, I wasn't experiencing any strange test failures with
asyncore/asynchat, nor have I been able to find the buildbot failures
that you are referring to. Could someone please link the failures
that are not
On Sun, Mar 30, 2008 at 7:41 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Sun, Mar 30, 2008 at 4:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
> wrote:
> >
> > > If you'd like, I can merge the rest.
> >
> > If you have the time to figure it all out, sure.
> > I found that quite a tedi
On Sun, Mar 30, 2008 at 4:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > If you'd like, I can merge the rest.
>
> If you have the time to figure it all out, sure.
> I found that quite a tedious task, and had to spent
> on some patches quite a long time to figure out what
> they do, and wh
On Sun, Mar 30, 2008 at 6:16 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > Is there any easy way that the burden of trunk -> py3k
> > merging could be moved to the original committers of
> > the trunk patches?
>
> I'm not sure I understand the question. If the committer
> of the original pa
On Sun, Mar 30, 2008 at 5:16 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > Is there any easy way that the burden of trunk -> py3k
> > merging could be moved to the original committers of
> > the trunk patches?
>
> I'm not sure I understand the question. If the committer
> of the original pa
> Is there any easy way that the burden of trunk -> py3k
> merging could be moved to the original committers of
> the trunk patches?
I'm not sure I understand the question. If the committer
of the original patch would do the merge himself, then
certainly the burden would be on him, and that's an e
> If you'd like, I can merge the rest.
If you have the time to figure it all out, sure.
I found that quite a tedious task, and had to spent
on some patches quite a long time to figure out what
they do, and what the 3.x equivalent should be.
Regards,
Martin
On Sun, Mar 30, 2008 at 5:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> If you have the time to figure it all out, sure.
> I found that quite a tedious task, and had to spent
> on some patches quite a long time to figure out what
> they do, and what the 3.x equivalent should be.
>
Is ther
On Sun, Mar 30, 2008 at 3:51 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > I won't have time to do another svn merge before the next alphas of 2.6
> > and 3.0 are to be released. Somebody else has to do the merge.
>
> I merged a few revisions, but I'm done now (until Tuesday or so).
If you
> I won't have time to do another svn merge before the next alphas of 2.6
> and 3.0 are to be released. Somebody else has to do the merge.
I merged a few revisions, but I'm done now (until Tuesday or so).
Regards,
Martin
___
Python-Dev mailing list
Pyth
For your information:
I won't have time to do another svn merge before the next alphas of 2.6
and 3.0 are to be released. Somebody else has to do the merge.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
Amaury Forgeot d'Arc schrieb:
> The approach I used is a bit brute-force, but it may work for other
> reference leaks:
> - First write a big leaking script:
> for x in xrange(10): leaking_function()
> - Since memory usage does not increase dramatically, it's only a
> refcount problem - no n
>> Once you've pushed the branches, is there a way to remove them?
>
> Do you mean the local branches? If yes, then 'rm -rf mymergedbranch'
> does exactly what you want. :)
Notice that, unlike subversion, this will cause the entire branch
to go away, irrevocably (unless you had pushed it elsewhe
[EMAIL PROTECTED] wrote:
> Benjamin> Once you've pushed the branches, is there a way to remove them?
>
> Related question: is there a way to view the various branches in a non-local
> repository?
IIUC, conceptually, no. A branch is not *in* a repository; a branch *is*
a repository (*). So you
16 matches
Mail list logo
