On 2011/02/02 07:32:02, techtonik wrote:
[...]
Can you PLEASE take this off python-dev and move to an issue at
bugs.python.org? At least remove python-dev from the CC, or we'll
have to temporarily block messages from codereview.
http://codereview.appspot.com/4080047/
__
On 2011/02/02 07:18:33, Martin v. Löwis wrote:
Ah. That shouldn't be done. If anything is to be done, the builtin
msilib can be
considered, instead. Given the choice of using either ctypes or an
external
package, I prefer the external package.
It is a surprise to find builtin msilib. Why is
On 2011/02/02 07:14:17, techtonik wrote:
On 2011/02/01 19:50:23, Martin v. Löwis wrote:
> On 2011/02/01 07:22:57, techtonik wrote:
> > It removes the dependency from msi.py making it easier to do the
rest in
> > subsequent patches.
>
> What rest specifically? Why are the msilib changes needed f
On 2011/02/01 19:50:23, Martin v. Löwis wrote:
On 2011/02/01 07:22:57, techtonik wrote:
> It removes the dependency from msi.py making it easier to do the
rest in
> subsequent patches.
What rest specifically? Why are the msilib changes needed for that?
The rest is to use ctypes, so that no
On 02/01/2011 09:51 AM, anatoly techtonik wrote:
So far only Georg explained what patches sent to mailing list will not
be reviewed, because there is too much volume. But bugtracker is not a
patch tracker. It doesn't allow to monitor incoming patches by module,
its search is very poor. Of cour
On Tue, Feb 1, 2011 at 2:10 AM, "Martin v. Löwis" wrote:
> Am 31.01.2011 22:13, schrieb anatoly techtonik:
>> Ok. Here is the patch. I used Orca to reverse installer tables of
>> Mercurial MSI and inserted similar entry for Python.
>
> This doesn't do uninstallation correctly.
I do not know where
On Mon, Jan 31, 2011 at 11:49 PM, Brian Curtin wrote:
> On Mon, Jan 31, 2011 at 15:43, anatoly techtonik
> wrote:
>>
>> On Mon, Jan 31, 2011 at 11:24 PM, Brian Curtin
>> wrote:
>> > On Mon, Jan 31, 2011 at 15:13, anatoly techtonik
>> > wrote:
>> >>
>> >> Ok. Here is the patch. I used Orca to re
Am 01.02.2011 16:51, schrieb anatoly techtonik:
> On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan wrote:
>> On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik
>> wrote:
>>> To me polluting tracker with the
>>> issues that are neither bugs nor feature requests only makes bug
>>> triaging process and
Am 01.02.2011 17:25, schrieb anatoly techtonik:
> On Tue, Feb 1, 2011 at 9:45 AM, Georg Brandl wrote:
>>
>> A mailing list works only if you have a small group of core developers
>> who can independently organize the incoming mails using local tools,
>> such as the read/unread marking of the email
On 2011/02/01 07:22:57, techtonik wrote:
It removes the dependency from msi.py making it easier to do the rest
in
subsequent patches.
What rest specifically? Why are the msilib changes needed for that?
http://codereview.appspot.com/4080047/
___
Pyt
On 1/31/2011 1:38 PM, Brett Cannon wrote:
> I should mention that I have considered implementing a caching finder
> and loader for filesystems in importlib for people to optionally
> install to use for themselves. The real trick, though, is should it
> only cache hits, misses, or both? Regardless,
On Tue, 01 Feb 2011 18:25:24 +0200, anatoly techtonik
wrote:
> On Tue, Feb 1, 2011 at 9:45 AM, Georg Brandl wrote:
> > It sure is more convenient to do patch review, but
> > that's why we are working on Rietveld integration in the tracker.
>
> Where is the code? What is the status? Where is the
anatoly techtonik writes:
> I'll abandon my efforts when you prove me that current "documented
> process" is a top-notch way for all interested parties to do a quality
> contributions to make Python better.
I think the product of the process speaks very well for the process.
> The most valua
On 2011-02-01, at 4:51 PM, anatoly techtonik wrote:
>
> I'll abandon my efforts when you prove me that current "documented
> process" is a top-notch way for all interested parties to do a quality
> contributions to make Python better. So that the process is open,
> straightforward, transparent an
On Tue, Feb 1, 2011 at 9:45 AM, Georg Brandl wrote:
>
> A mailing list works only if you have a small group of core developers
> who can independently organize the incoming mails using local tools,
> such as the read/unread marking of the email client. For a larger
> group this doesn't work (how
On Tue, Feb 1, 2011 at 09:51, anatoly techtonik wrote:
> On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan wrote:
> > On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik
> wrote:
> >> To me polluting tracker with the
> >> issues that are neither bugs nor feature requests only makes bug
> >> triaging p
2011/2/1 anatoly techtonik :
> we can definitely
> find a lot of ways to improve Python development process for general
> public
Definitely. And the future migration to Mercurial will certainly help as well.
But this thread started with a patch review, not with a proposal to
change the developmen
On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan wrote:
> On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik wrote:
>> To me polluting tracker with the
>> issues that are neither bugs nor feature requests only makes bug
>> triaging process and search more cumbersome.
>
> Anatoly, your constant efforts
On Tue, Feb 1, 2011 at 01:35, anatoly techtonik wrote:
> On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson
> wrote:
>
> I see no reason for b.p.o bureaucracy.
> >>>
> >>> It provides a place for discussion, and makes it easier to coordinate
> >>> multiple efforts.
> >>
> >> Code revie
W dniu 2011-02-01 01:24, "Martin v. Löwis" pisze:
As a mailing list, it was unmaintainable, since there was no tracking
of what patches still need consideration. So a web-based bug tracker
got into use (although I forgot the name of the tracker software that
was used before SourceForge).
Jitter
On Tue, Feb 1, 2011 at 5:35 PM, anatoly techtonik wrote:
> Because code cleanup patches pave road for more complex pieces of
> work. Clean code makes patches easier to review. It saves developer's
> time and as a result useful patches are integrated into codebase more
> quickly.
While I've occasi
21 matches
Mail list logo
