[Tracker-discuss] [issue373] Add 'module' field to tracker

anatoly techtonik metatracker at psf.upfronthosting.co.za
Thu Apr 21 23:05:27 CEST 2011


anatoly techtonik <techtonik at gmail.com> added the comment:

On Thu, Apr 21, 2011 at 7:42 PM, Éric Araujo
<metatracker at psf.upfronthosting.co.za> wrote:
>
>>> Even if knowing the module(s) related to the issue is useful, there are a
>>> number of problems that should be considered:
>>> * there are hundreds of modules;
>> How many exactly? I doubt there is more than hundred.
> More than two hundreds.

How many exactly?

>>> * several modules can be related to the issue;
>> Make them tags.
> What are tags?

Issue labels. Like GMail labels or labels in Google Code tracker. In
Google Code you can label the same issue as documentation issue and as
module issue, for example.

>>> * the list of modules must be updated when modules are added/removed/renamed;
>> Store module mapping in repository and throw warning during build
>> stage when files added or removed.
> Or maybe use the mapping in lib2to3.fixes.fix_imports (not sure the Python used for our Roundup is recent enough.)

As a quick hack, yes. But lib2to3 is underdocumented and can break at
any moment. Ideally lib2to3 should fetch information from branches of
versions it tries to convert.

>>> * a new field adds clutter to the UI and more work for the submitters and triagers;
>> Split reporting in two steps like in Gnome or Eclipse Bugzillas.
> Interesting idea.

We may need to leave an option for RDM to go directly to the second
page as he finds that the Roundup search suxx (and I totally agree).
However, if search scope is limited by module, the results will still
be useful.

>>> * searching for a specific module won't include the issues if the field is not set
>>> correctly (i.e. old issues and issues that haven't be triaged), the normal search will;
>> All issues should undergo triaging process. Opened old issues can be
>> retriaged. Closed could be left RIP. If you want to find them - use
>> module name in normal search - it will still work.
>
> “Should” is nice.  How do you propose to implement it concretely?  It could possible to add a special “untriaged” state used in queries, but I’m not sure this would help; given enough volunteers with enough free time, bug triaging happens quite effectively.  The weekly email also helps find unanswered reports.

In Google Code all issue have 'New' status by default. Triaged are
usually 'Accepted' or 'Acknowledged'. In Bugzilla new issues are
'unconfirmed'. In SCons we use 'untriaged' flag. Of course, triaging
is about priorities and without module maintainers, roadmaps and
release plans the process can be a bit pointless. So, if somebody
answers to b.p.o report, does that mean that the report is triaged?
What is the result of triage on b.p.o?

>>> Another option is looking automatically at the attached patches, figure out
>>> what files they affect, and make this information available.
> Sounds good.  I’m sure difflib can do that.

Difflib can't parse patches - it produces diffs only, but you can
download python-patch from Google Code. SVN version has a nice
diffstat capability.

>> But mind you that issues without patches may never get any, because module
>> maintainers are unaware that there are issues for them.
>
> There are triagers who use the experts list (in the devguide) to add maintainers to nosy.

You still don't allow new people to opt-in to help with module
maintenance, testing or patching.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue373>
_______________________________________________________


More information about the Tracker-discuss mailing list