On Wed, Apr 2, 2008 at 7:16 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> Christian Heimes [mailto:[EMAIL PROTECTED]:
> > Trent Nelson schrieb:
> > > I think holding a developer accountable for merging or blocking to
> > py3k when they commit to trunk is a great idea. Who better to pass
> > judge
Christian Heimes [mailto:[EMAIL PROTECTED]:
> Trent Nelson schrieb:
> > I think holding a developer accountable for merging or blocking to
> py3k when they commit to trunk is a great idea. Who better to pass
> judgement on such an activity than the person closest to it?
>
> Blocking a revision mak
Trent Nelson schrieb:
> I think holding a developer accountable for merging or blocking to py3k when
> they commit to trunk is a great idea. Who better to pass judgement on such
> an activity than the person closest to it?
Blocking a revision makes my job as The Merger easier.
I'm not so sure
> > 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 (
2008/3/31, Christian Heimes <[EMAIL PROTECTED]>:
> In most cases it's easy. Usually it takes me less than 20 minutes per
> day to merge the chances from trunk -> py3k. In this particular case
> several obstacles come together. The changes in the AST and parser code
> aren't trivial, I'm not fam
Facundo Batista schrieb:
> Me for myself, I thought that the trunk -> 3k merge was easier!
>
> Sometimes I commited changes to the trunk, don't worrying about 3k at
> all, thinking it was a mostly automatic process.
>
> Now that I know this, I will start patching both trunk & 3k simultaneously..
2008/3/30, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> > 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 sho
> 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
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
19 matches
Mail list logo
