Antoine Pitrou writes:
> A drop-down [list of modules] would be terribly cumbersome.
On the XEmacs tracker, we use a multilink with a checkbox list for the
modules field. This allows you to type in the text field, to check
multiple boxes, and provides input checking. In my typical usage, I
don
On Sun, 09 Jan 2011 22:52:47 +0100
Éric Araujo wrote:
> Le 07/01/2011 19:39, Brian Curtin a écrit :
> > On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote:
> >> Module split:
> >> try to get all issues for 'os' module
> > No solution for this right now, but people have suggested that we add
> Maybe that could be fixed? Then the remaining feature would be a way
> to sort issue lists by number of nosy people, and to display the
> length of the nosy list.
http://bugs.python.org/iss...@action=search&@columns=title,id,nosy_count&status=1&@sort=-nosy_count
You can create an URL like this
Le 07/01/2011 19:39, Brian Curtin a écrit :
> On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote:
>> Module split:
>> try to get all issues for 'os' module
> No solution for this right now, but people have suggested that we add
> drop-downs for each module. I'm -0 on that.
I proposed that on
On Fri, Jan 7, 2011 at 11:20 AM, anatoly techtonik wrote:
> This happened, because of poor bug management, where community doesn't
> play any role in determining which issues are desired.
> This mostly because of limitation of our tracker and desire of people
> to extend it to get damn "stars", mo
On 07/01/2011 19:22, Guido van Rossum wrote:
On Fri, Jan 7, 2011 at 11:15 AM, Michael Foord
wrote:
On 07/01/2011 19:11, Guido van Rossum wrote:
On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
wrote:
-1 on the "star system" for the tracker
The tracker on Google Code uses stars. We
On 07/01/2011 18:44, Antoine Pitrou wrote:
On Fri, 7 Jan 2011 13:36:26 -0500
Alexander Belopolsky wrote:
On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote:
..
Don't you think that if people could review issues and "star" them
then such minor issues could be scheduled for release not on
On Fri, Jan 7, 2011 at 11:18 AM, Antoine Pitrou wrote:
> I'd also mention that many bugzilla installs have a "voting" facility
> where people can vote for a limited number of issues of their choice (I
> think the number of votes also depends on the user's number of
> contributions, although I'm no
On Fri, Jan 7, 2011 at 11:15 AM, Michael Foord
wrote:
> On 07/01/2011 19:11, Guido van Rossum wrote:
>>
>> On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
>> wrote:
>>>
>>> -1 on the "star system" for the tracker
>>
>> The tracker on Google Code uses stars. We use this tracker to track
>>
On Fri, 7 Jan 2011 11:11:47 -0800
Guido van Rossum wrote:
> On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
> wrote:
> > -1 on the "star system" for the tracker
>
> The tracker on Google Code uses stars. We use this tracker to track
> external App Engine issues. It works very well to meas
On 07/01/2011 19:11, Guido van Rossum wrote:
On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
wrote:
-1 on the "star system" for the tracker
The tracker on Google Code uses stars. We use this tracker to track
external App Engine issues. It works very well to measure how
widespread a part
Am 07.01.2011 19:39, schrieb Brian Curtin:
> Tagging:
> as a tracker user, try to add tag 'easy' to some easy issue
>
>
> You probably need escalated privileges for this. If you can't change it, you
> can
> always request on the issue that a field be changed.
He *could* also behave re
On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
wrote:
> -1 on the "star system" for the tracker
The tracker on Google Code uses stars. We use this tracker to track
external App Engine issues. It works very well to measure how
widespread a particular issue or need is (even if we don't alway
> Module split:
> try to get all issues for 'os' module
> try to subscribe to all commits for 'CGIHTTPServer'
+1
I've been thinking about such a thing as well and I think it would be useful.
Every now and then I go to the bug tracker to see whether the modules
I usually maintain (mainly ftplib,
On Fri, 7 Jan 2011 12:39:34 -0600
Brian Curtin wrote:
> >
> > I haven't started using Python 3 yet, but I already know some annoying
> > API issues that are not fixed there. Unfortunately, I don't remember
> > them to give you a list. That's why I asked for a flag.
>
> If you haven't used it yet,
On Fri, 7 Jan 2011 13:36:26 -0500
Alexander Belopolsky wrote:
> On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote:
> ..
> > 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 deci
On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote:
> On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin
> wrote:
> >>
> >> This mostly because of limitation of our tracker and desire of people
> >> to extend it to get damn "stars", module split, sorting, digging and
> >> tagging options.
> >
> > I
On 2011-01-07, at 7:14 PM, anatoly techtonik wrote:
> 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?
On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote:
..
> 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 communit
On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote:
> On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin
> wrote:
> >>
> >> 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 w
On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin wrote:
>>
>> 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.
On Fri, Jan 7, 2011 at 11:20, anatoly techtonik wrote:
> 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
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
This happened, because of poor bug management, whe
23 matches
Mail list logo
