[Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)

[Georg Brandl]

Am 01.02.2011 16:51, schrieb anatoly techtonik:
> On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik <techtonik at gmail.com> 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 to try to force python-dev to adapt to
>> *your* way of doing things, instead of being willing to work with the
>> documented processes are *seriously* annoying. Which is a shame, since
>> it obscures the fact that your underlying suggestions are often quite
>> reasonable.
> 
> 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.

And who or what decides what this "top-notch way" is?

> So that the process is open, straightforward, transparent

Ah.  Well, that's definitely very a concise spec.

> and doesn't waste people's time more than
> necessary to communicate a change, make it visible for all interested
> parties, get feedback, polish and finally integrate.

[...]

> The most valuable contributions are coming from professionals, and
> these people often don't have enough time to follow "documented
> process". In the era of information abundance you often have only 140
> symbols to communicate the idea,

That's a great idea for a change: report bugs by twitter.  We need to
set up a twitter search for #PythonBug, and then you simply enter

#PythonBug the process is slow

and it is converted to an issue on b.p.o.  Very open, very transparent,
and of course very straightforward.  Let's not care about how to reach
the submitter when clarification is needed, or what to do about patches.
If it doesn't fit into 140 characters, it doesn't exist!

> and instead of blaming people of
> annoying behavior, it might be more useful to make process intuitive
> and easy to follow. If that's not possible, there should always be an
> exact link to a reasonable explanation about why you need the process
> to be so complicated.

The new devguide (docs.python.org/devguide) should provide exactly that,
and in a central location.

> 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.

As I explained, it is an *issue tracker*.  And since in 99% of cases there
is an actual issue underlying a patch, it is more than justified to use
it to track issues that have patches.

> It doesn't allow to monitor incoming patches by module,
> its search is very poor. Of course mailing lists are even worse in
> this regard, but there is nothing Python community can't deal with.

Exactly, so let us continue the ongoing work in improving the tracker.

> The problem is to keep non-core people outside motivated, and the
> biggest problem with current "documented process" is that nobody even
> thinks about it.

I think others already wrote enough about that.

Georg