Showing content from http://mail.python.org/pipermail/python-dev/attachments/20110201/6cecc695/attachment.html below:
<div class="gmail_quote">On Tue, Feb 1, 2011 at 09:51, anatoly techtonik <span dir="ltr"><<a href="mailto:techtonik@gmail.com">techtonik@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik <<a href="mailto:techtonik@gmail.com">techtonik@gmail.com</a>> wrote:<br>
>> To me polluting tracker with the<br>
>> issues that are neither bugs nor feature requests only makes bug<br>
>> triaging process and search more cumbersome.<br>
><br>
> Anatoly, your constant efforts to try to force python-dev to adapt to<br>
> *your* way of doing things, instead of being willing to work with the<br>
> documented processes are *seriously* annoying. Which is a shame, since<br>
> it obscures the fact that your underlying suggestions are often quite<br>
> reasonable.<br>
<br>
</div>I'll abandon my efforts when you prove me that current "documented<br>
process" is a top-notch way for all interested parties to do a quality<br>
contributions to make Python better. So that the process is open,<br>
straightforward, transparent and doesn't waste people's time more than<br>
necessary to communicate a change, make it visible for all interested<br>
parties, get feedback, polish and finally integrate.</blockquote><div><br></div><div>The burden of proof should not be on us to prove to you why we do things the way we do them. I'm not even sure you are familiar with the process that you want to change so badly.</div>
<div><br></div><div>You do realize that no one else, from the people in Misc/developers.txt to the one-time patch submitters, has a monthly process gripe, correct? It's certainly working for a few of us.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
There are many ways for improvement, but if people won't try<br>
alternative approaches, they won't see them.</blockquote><div><br></div><div>This is true of just about anything in the world, but I don't think it's a bad thing. We decided on something, it works, and we use it.</div>
<div><br></div><div>I umpire college baseball in my free time and people like to propose tweaks to our on-field mechanics all the time because they think certain alternatives work better. To even get me to think about that stuff is a tall task because not only is my time on the job limited, my actual ability to practice these alternatives is more limited. I'll stick to what's in our book -- it works.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I am not sure if I can<br>
manage to get to PyCon, so I didn't do any talk preparation, but if by<br>
chance I get there and there will be an Open Space, we can definitely<br>
find a lot of ways to improve Python development process for general<br>
public.</blockquote><div><br></div><div>I could list a few ways to improve it as well. Do we need any of them to survive? No.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The most valuable contributions are coming from professionals, and<br>
these people often don't have enough time to follow "documented<br>
process".</blockquote><div><br></div><div>Sorry, but sometimes that's the cost of doing business. Just because the court system has a lengthy process for suing people doesn't mean you can skip to the end if you just want to get your money. You have to tell your story first.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In the era of information abundance you often have only 140<br>
symbols to communicate the idea, and instead of blaming people of<br>
annoying behavior, it might be more useful to make process intuitive<br>
and easy to follow.</blockquote><div><br></div><div>Thankfully Twitter is not our bug tracker.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If that's not possible, there should always be an<br>
exact link to a reasonable explanation about why you need the process<br>
to be so complicated.<br></blockquote><div><br></div><div>There's a few things the process is, and complicated it is not. In most cases it is as simple as: report a bug, provide a failing test case, provide a complete patch, review the patch, commit the patch.</div>
<div><br></div><div>To an outsider, they don't have to worry about the bug tracker fields, who's doing the commit, what branches it goes into, etc. Just write the code and it'll speak for itself.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So far only Georg explained what patches sent to mailing list will not<br>
be reviewed, because there is too much volume. But bugtracker is not a<br>
patch tracker.</blockquote><div><br></div><div>Yes it is, or at least that is one of the functions it is currently serving.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It doesn't allow to monitor incoming patches by module,<br>
its search is very poor.</blockquote><div><br></div><div>Patches are certainly welcome if you want to make it happen. I think it would be a nice addition.</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4