[Python-Dev] API refactoring tracker field for Python4
brian.curtin at gmail.com
Fri Jan 7 19:29:34 CET 2011
On Fri, Jan 7, 2011 at 12:14, anatoly techtonik <techtonik at gmail.com> wrote:
> On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin <brian.curtin at gmail.com>
> >> There are many API changes and proposals that were forgotten and
> >> didn't get into Python 3, although they should be, because it was the
> >> only chance to change things with backwards compatibility break. For
> >> example http://bugs.python.org/issue1559549
> > That can be added in 3.3.
> > To answer your comment on the issue: no investigation is needed. It
> > make it in yet because there was no code written for it. It's really not
> > big deal, it happens all the time.
> Don't you think that if more people were aware of this issue, the
> patch could be made faster?
Maybe, but someone still has to write the code. You could start a facebook
group for the issue and it could have 10,000 "likes", but it still doesn't
solve the problem. I'm reminded of the saying "9 women can't have a baby in
I do think it would be great if more people were involved in the issue
tracker. I don't know what it will take to get more people involved, but I
know it involves a lot more than modifying the tracker itself.
> >> This happened, because of poor bug management, where community doesn't
> >> play any role in determining which issues are desired.
> > The community absolutely plays a role in determining which issues are
> > desired. They do this by action when they want something. A patch says a
> > whole lot about desire.
> Don't you think that if people could review issues and "star" them
> then such minor issues could be scheduled for release not only by
> "severity" status as decided be release manager and several core
> developers, but also by community vote?
I'm not sure thatt's the right answer here. I'd rather people "star" or vote
on issues by completing a step of the process rather than just clicking a
thumbs up button. Writing a test case or checking that a patch applies on a
particular branch is a vote to me.
> Patch requires time, experience and approved contribution agreement,
> which you've sent using ground mail beforehand. Voting doesn't require
> any of this, but helps core developers see what user community wants.
I think the fact that it requires no "skin in the game" is a negative point.
I don't show up at government meetings and vote on things -- I don't have
that power. If I want something voted on, I go through a representative and
I tell them my story, my side of things, and show them what I want and why I
If we just let people vote on things, the first issue that would be created
would be "Remove the GIL" and it would have 10,000 votes and zero patches.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev