Mailing List Archive: Python: Dev

language summit topic: issue tracker

Index | Next | Previous | View Threaded

brett at python

Oct 22, 2009, 9:47 PM

Post #1 of 12 (257 views)
Permalink

language summit topic: issue tracker

Another summit, another potential time to see if people want to change
anything about the issue tracker. I would bring up:

- Dropping Stage in favor of some keywords (e.g. 'needs unit test', 'needs
docs')
- Adding a freestyle text box to delineate which, if any, stdlib module is
the cause of a bug and tie that into Misc/maintainers.rst; would potentially
scale back the Component box

-Brett

ben+python at benfinney

Oct 22, 2009, 10:51 PM

Post #2 of 12 (249 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

Brett Cannon <brett[at]python.org> writes:

> Another summit, another potential time to see if people want to change
> anything about the issue tracker.

It requires some coding, but I see OpenID authentication support
<URL:http://issues.roundup-tracker.org/issue2550523> to be important for
lowering the barrier to getting bug reports.

--
\ “I was once walking through the forest alone and a tree fell |
`\ right in front of me, and I didn't hear it.” —Steven Wright |
_o__) |
Ben Finney

_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Oct 23, 2009, 2:49 AM

Post #3 of 12 (246 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

Brett Cannon wrote:
> Another summit, another potential time to see if people want to change
> anything about the issue tracker. I would bring up:
>
> - Dropping Stage in favor of some keywords (e.g. 'needs unit test',
> 'needs docs')
> - Adding a freestyle text box to delineate which, if any, stdlib module
> is the cause of a bug and tie that into Misc/maintainers.rst; would
> potentially scale back the Component box

+lots on adding a module field (independent of automatically adding
maintainers to the nosy list, it would assist in "I just did a major
cleanup of module X, are there any old bugs I can kill off").

Of course, it will take a while for the field to be filled in on
existing issues, but even having it be possible would be very nice.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan[at]gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Oct 23, 2009, 5:24 AM

Post #4 of 12 (242 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

Le Thu, 22 Oct 2009 21:47:06 -0700, Brett Cannon a écrit :
>
> - Dropping Stage in favor of some keywords (e.g. 'needs unit test',
> 'needs docs')

What would it bring? We don't have a very strict process and the current
"stage" looks sufficient to me. Saying that unit tests or docs are
lacking is part of the review and doesn't need a specific indicator IMO.

Besides, the more keywords there are, the messier it is.

_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

skip at pobox

Oct 23, 2009, 6:00 AM

Post #5 of 12 (243 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

Brett> Another summit, another potential time to see if people want to
Brett> change anything about the issue tracker.

I have no idea how hard this would be to implement and won't be at the
language summit to formally present the idea, but it seems to me that some
integration between the issue tracker and Rietveld would be beneficial. If
someone attaches a patch to an issue the current next step is essentially a
code review without the benefits provided by a code review tool. I'd
envision a bit of workflow like this:

* A patch is attached to an issue.
* The user clicks the "Create Review" button. (Maybe not all patches
require review?)
* This generates a review request in Rietveld with all on the nosy list
invited as reviewers. (Or should this be a side effect of attaching a
patch?)
* The "needs review" keyword is added to the selected keywords.
* A link to the review request is added as a comment to the issue so
other people not on the nosy list can evaluate the patch.
* If an updated diff is uploaded the review request would be updated.
That might necessitate adding a "Replace Patch" button next to all
uploaded patches instead of adding a new one then deleting a previous
one.

Skip
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

stephen at xemacs

Oct 23, 2009, 7:18 AM

Post #6 of 12 (242 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

Antoine Pitrou writes:

> Besides, the more keywords there are, the messier it is.

That's what I've found in the XEmacs tracker. Keywords are a
reasonable way (in the context of the Roundup implementation) to test
new classifications before going to the effort of messing with the
page templates. But if you don't think "stage" is needed, I'd say
drop it entirely rather than demote it to keywords.

Keywords themselves are rather confusing to non-tracker-hackers,
anyway. A lot of people seem to think anything that occurs to them
should be allowed. That's not true in Roundup, you need to register a
keyword before using it.

In the XEmacs tracker I don't allow non-committers to do that. I'm
open to changing that policy, but as yet I haven't seen a keyword
suggestion from a non-committer that either (1) helps the committers
to do their work or (2) seems likely to help users find relevant bugs.
The suggestions are always of the form "it would make the interface
more complete/consistent." So I'm going to maintain editorial control
for now....

_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Nov 2, 2009, 10:39 AM

Post #7 of 12 (159 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

> +lots on adding a module field (independent of automatically adding
> maintainers to the nosy list, it would assist in "I just did a major
> cleanup of module X, are there any old bugs I can kill off").

Link (1:1) or Multilink (1:n)? What is the impact on the Component field?

Would you be willing to manage the field (in the sense of managing the
set of values)? If so, please send me a list of values.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Nov 2, 2009, 10:42 AM

Post #8 of 12 (159 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

skip[at]pobox.com wrote:
> Brett> Another summit, another potential time to see if people want to
> Brett> change anything about the issue tracker.
>
> I have no idea how hard this would be to implement and won't be at the
> language summit to formally present the idea, but it seems to me that some
> integration between the issue tracker and Rietveld would be beneficial.

See

http://psf.upfronthosting.co.za/roundup/meta/issue247

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

skip at pobox

Nov 2, 2009, 6:26 PM

Post #9 of 12 (155 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

>> ... it seems to me that some integration between the issue tracker
>> and Rietveld would be beneficial.

Martin> See

Martin> http://psf.upfronthosting.co.za/roundup/meta/issue247

Cool. I still haven't used Rietveld for anything, though I am getting
comfortable with Review Board and like the tool support for code reviews.

Skip
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg at krypto

Nov 3, 2009, 12:29 AM

Post #10 of 12 (150 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

On Fri, Oct 23, 2009 at 1:49 AM, Nick Coghlan <ncoghlan[at]gmail.com> wrote:
> Brett Cannon wrote:
>> Another summit, another potential time to see if people want to change
>> anything about the issue tracker. I would bring up:
>>
>> - Dropping Stage in favor of some keywords (e.g. 'needs unit test',
>> 'needs docs')
>> - Adding a freestyle text box to delineate which, if any, stdlib module
>> is the cause of a bug and tie that into Misc/maintainers.rst; would
>> potentially scale back the Component box
>
> +lots on adding a module field (independent of automatically adding
> maintainers to the nosy list, it would assist in "I just did a major
> cleanup of module X, are there any old bugs I can kill off").

yet another feature request or two to be lost to a mailing list thread
along those lines:

Maintainer or not i'd like to be able to setup triggers so that i'm
automatically cc'ed on any bugs matching a simple search query i
specify.

The email sent out to people cc'ed when a new bug is opened and
unassigned should have a simple links in it when cc'ed to someone who
can be assigned bugs: 'Assign to me' that if followed will assign
that bug to them without requiring a login.

>
> Of course, it will take a while for the field to be filled in on
> existing issues, but even having it be possible would be very nice.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan � | � ncoghlan[at]gmail.com � | � Brisbane, Australia
> ---------------------------------------------------------------
> _______________________________________________
> Python-Dev mailing list
> Python-Dev[at]python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Nov 3, 2009, 1:21 AM

Post #11 of 12 (145 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

Martin v. L�wis wrote:
>> +lots on adding a module field (independent of automatically adding
>> maintainers to the nosy list, it would assist in "I just did a major
>> cleanup of module X, are there any old bugs I can kill off").
>
> Link (1:1) or Multilink (1:n)? What is the impact on the Component field?

I was thinking multilink, and leaving component alone - the module field
would largely come into play when the component was just the "Lib"
catch-all.

> Would you be willing to manage the field (in the sense of managing the
> set of values)? If so, please send me a list of values.

I would suggest just using the module index from the documentation to
seed any such list of modules in the tracker:
http://docs.python.org/modindex.html

Packages could generally be left as a single entry in the list. The only
exception I think is that there should be an "xml.etree" entry separate
from the main "xml" entry, and perhaps a separate entry for "os.path".

Deprecated modules could either be left out of the list, or else moved
to appear at the end.

Regards,
Nick.

--
Nick Coghlan | ncoghlan[at]gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Nov 3, 2009, 9:51 AM

Post #12 of 12 (141 views)
Permalink

Re: language summit topic: issue tracker [In reply to]

> yet another feature request or two to be lost to a mailing list thread
> along those lines:
>
> Maintainer or not i'd like to be able to setup triggers so that i'm
> automatically cc'ed on any bugs matching a simple search query i
> specify.

Please add that to the meta tracker (if you really want it, rather
than just losing it on the mailing list :-)

Implementing it would be quite involved, I think. It should probably
go into the saved query feature. Evaluating them on every change would
might be expensive, so doing so only regularly (e.g. hourly) would
be ok?

> The email sent out to people cc'ed when a new bug is opened and
> unassigned should have a simple links in it when cc'ed to someone who
> can be assigned bugs: 'Assign to me' that if followed will assign
> that bug to them without requiring a login.

Unfortunately, this is now defeated by the fear of XSS attacks. If
such a link was possible, it would be also possible to embed it
into a XSS attack, right?

It would be possible to protect the link with a token, but then,
efficient token validation might be tricky. So this would also need
to go into the meta tracker.

If you are really interested in these, it would be best to add them
as feature requests to roundup itself (since that really is the place
where they should be provided):

http://issues.roundup-tracker.org/

[but then, roundup could also use more contributors]

Regards,
Martin

_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com