Hi,
FYI the faulthandler and tracemalloc were both added in a single
commit, while they added a lot of new code and modified multiple
files.
The development of faulthandler and tracemalloc started as third party
projects on PyPI.
I almost rewrote tracemalloc from scratch while its PEP was discus
On 2 April 2015 at 22:06, Jason R. Coombs wrote:
> I'm in the other camp.
>
> The way I see it, a squash of history or massive patch file loses history. It
> loses details about the thought process of the implementer. It masks mistakes
> and obscures motivations. It also masks decisions made in
On 2 April 2015 at 18:15, R. David Murray wrote:
> On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum wrote:
>> Where I come from we always squash. More detailed history is preserved in
>> the code review tool (which keeps a snapshot every time you bounce it back
>> to the reviewer). Looking at
On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum wrote:
> Where I come from we always squash. More detailed history is preserved in
> the code review tool (which keeps a snapshot every time you bounce it back
> to the reviewer). Looking at my own sub-commits when I'm working on a
> complex fea
Where I come from we always squash. More detailed history is preserved in
the code review tool (which keeps a snapshot every time you bounce it back
to the reviewer). Looking at my own sub-commits when I'm working on a
complex feature or bug fix, they are often checkpoints with no particular
signif
On Apr 02, 2015, at 12:06 PM, Jason R. Coombs wrote:
>The way I see it, a squash of history or massive patch file loses history. It
>loses details about the thought process of the implementer. It masks mistakes
>and obscures motivations. It also masks decisions made in the merge
>operation, furthe
ython-committers] Do people prefer pushing feature repos or one
massive patch?
On 2 April 2015 at 04:09, Ethan Furman wrote:
> I like one massive patch, myself. :)
Aye, I'm also in the "squash for the clean history" approach.
___
On 2 April 2015 at 04:09, Ethan Furman wrote:
> I like one massive patch, myself. :)
Aye, I'm also in the "squash for the clean history" approach (FWIW,
making this less of an either/or question is one of the benefits
Gerrit offers over other code review systems, since you can combine
posting a
I like one massive patch, myself. :)
--
~Ethan~
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
On Wed, Apr 1, 2015 at 12:56 PM Victor Stinner
wrote:
> If you choose to merge, I would prefer that you rebase your changes
> before to avoid multiple merges. IMO the best to avoid merges at all
> :-)
>
It's sounding like one massive patch is the best option for people.
>
> Did someone review
If you choose to merge, I would prefer that you rebase your changes
before to avoid multiple merges. IMO the best to avoid merges at all
:-)
Did someone review your large change?
Victor
2015-04-01 18:09 GMT+02:00 Brett Cannon :
> The implementation for PEP 488 is basically done (sans Windows ins
On Wed, Apr 1, 2015 at 12:38 PM Benjamin Peterson
wrote:
>
>
> On Wed, Apr 1, 2015, at 12:09, Brett Cannon wrote:
> > The implementation for PEP 488 is basically done (sans Windows installer
> > stuff). I did the work in a features repo at
> > https://hg.python.org/features/pep-488/ . Once I have
On Wed, Apr 1, 2015, at 12:09, Brett Cannon wrote:
> The implementation for PEP 488 is basically done (sans Windows installer
> stuff). I did the work in a features repo at
> https://hg.python.org/features/pep-488/ . Once I have addressed reviewer
> comments at http://bugs.python.org/issue23731 ,
The implementation for PEP 488 is basically done (sans Windows installer
stuff). I did the work in a features repo at
https://hg.python.org/features/pep-488/ . Once I have addressed reviewer
comments at http://bugs.python.org/issue23731 , would people prefer I
simply push the features repo to hg.py
14 matches
Mail list logo
