On Wed, Aug 7, 2013 at 1:12 PM, Ethan Furman wrote:
>
> Dumb question, but does he know how to publish his responses? ... (I'm
speaking of the reitvald tool.)
The patches that I reviewed: #15390 (datetime), #15848 (xxsubtype), and
#15849 (xxmodule) did not have Reitvald "review" links. I revi
On 08/07/2013 01:54 AM, Alexander Belopolsky wrote:
That's not how the history looks on the tracker. Robin submitted ~50 patches before
I suggested that "we should start
with the "xx" modules." Then he did submit patches to the example modules, but
have never responded to my reviews.
Dumb
Le Wed, 07 Aug 2013 10:09:16 +0200,
mar...@v.loewis.de a écrit :
>
> > Robin has produced many patches that seem to reach the stated goal
> > (refactor C extension modules to take advantage of the latest PEPs
> > about module initialization and extension types definition).
> > Unfortunately, tackl
On Wed, Aug 7, 2013 at 4:34 AM, wrote:
>
> Robin did exactly that: submit a few patches first, receive feedback,
> submit more patches. At the end of the project,he submitted his
> entire work.
That's not how the history looks on the tracker. Robin submitted ~50
patches before I suggested that
Zitat von Lennart Regebro :
On Tue, Aug 6, 2013 at 9:26 PM, Antoine Pitrou wrote:
What didn't produce an alarm during Robin's work is that GSoC work is
done in private.
Why is it done in private?
It wasn't really done in private, not more than any other contribution.
A PEP was accepted bef
On Wed, Aug 7, 2013 at 4:09 AM, wrote:
> ..
>> What didn't produce an alarm during Robin's work is that GSoC work is
>> done in private.
>>
>
> It wasn't really done in private. Robin posted to python-dev, anybody
> who would have been interested could have joined discussions.
True. In additio
Zitat von Eli Bendersky :
I would like to point out something that stands out in this list of issues:
such a method of producing dozens of patches simultaneously is extremely
unwise, unless there's a crucial piece of history I'm missing. It is much
more prudent to start with one or two exemplar
Zitat von Antoine Pitrou :
One cruel example is the set of PEP 3121 / PEP 384 refactorings done by
Robin Schreiber:
I personally dont consider it failed, yet. I still plan to integrate
them, hopefully for 3.4.
Robin has produced many patches that seem to reach the stated goal
(refactor C ex
On Tue, Aug 6, 2013 at 9:26 PM, Antoine Pitrou wrote:
> What didn't produce an alarm during Robin's work is that GSoC work is
> done in private.
Why is it done in private?
//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
Nick Coghlan writes:
> On 7 August 2013 05:26, Antoine Pitrou wrote:
> > I would like to point out that we currently fail at handling GSoC
> > projects and bringing them to completion.
>
> Agreed.
I have no opinion on that statement, having not looked at the
projects.
> > What didn't pro
On 7 August 2013 05:26, Antoine Pitrou wrote:
>
> Hello,
>
> I would like to point out that we currently fail at handling GSoC
> projects and bringing them to completion.
Agreed.
> What didn't produce an alarm during Robin's work is that GSoC work is
> done in private. Therefore, other core deve
On Aug 6, 2013, at 3:26 PM, Antoine Pitrou wrote:
> I would like to point out that we currently fail at handling GSoC
> projects and bringing them to completion.
In the past I have noticed the same thing with IDLE. Students and mentors act
outside of the standard Python development process then
On 8/6/2013 3:26 PM, Antoine Pitrou wrote:
I would like to point out that we currently fail at handling GSoC
projects and bringing them to completion.
One cruel example is the set of PEP 3121 / PEP 384 refactorings done by
Robin Schreiber:
http://bugs.python.org/issue?%40columns=id%2Cactivity%2
On Tue, Aug 6, 2013 at 3:51 PM, Antoine Pitrou wrote:
> I definitely agree, but this is part of our failure too.
I'd say this is strictly our failure, not the students'. This isn't
really a new problem, I don't think, though the shape of this collection
of patches makes it obvious.
I haven't be
On Tue, 6 Aug 2013 12:43:40 -0700
Eli Bendersky wrote:
> On Tue, Aug 6, 2013 at 12:26 PM, Antoine Pitrou wrote:
> >
> > Hello,
> >
> > I would like to point out that we currently fail at handling GSoC
> > projects and bringing them to completion.
> >
> > One cruel example is the set of PEP 3121 /
> It is also likely that the mentor gets overworked after the GSoC period is
> over,
> is unable to finalize the patch and push it...
Given that Python development is done using a good DVCS now, it seems
that if each manageable chunk of changes is done on a separate branch,
the likelihood of acce
On Tue, Aug 6, 2013 at 12:26 PM, Antoine Pitrou wrote:
>
> Hello,
>
> I would like to point out that we currently fail at handling GSoC
> projects and bringing them to completion.
>
> One cruel example is the set of PEP 3121 / PEP 384 refactorings done by
> Robin Schreiber:
>
> http://bugs.python
Hello,
I would like to point out that we currently fail at handling GSoC
projects and bringing them to completion.
One cruel example is the set of PEP 3121 / PEP 384 refactorings done by
Robin Schreiber:
http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%
18 matches
Mail list logo
