Removing GNATS categories

Removing GNATS categories

[Martin v. Loewis]

The current GCC GNATS installation has a number of categories that
haven't been used so far, despite the 145 reports that we already
have. I propose to remove them, before anybody uses them. The most
useless ones are

gc
host
profiling

I'd also like to ban the lib* categories, on the basis that they could
go with their front-ends

libf2c
libgcc
libobjc
libobjc
libstdc++

With the reduced list, people won't get so confused about how to file
a bug report. Just how often does it happen that somebody says she has
a problem with libgcc - it would rather come out as a problem with
exception handling, or a missing _divdi3 function.

Opinions? I'd take "no feedback" as "accepted unopposed" :-)

Regards,
Martin

P.S. This should not be taken as criticism of whoever originally
created these categories. It was a good starting point, and the change
now won't be the last time that we have to adjust the structure of
this based on actual user needs.

Re: Removing GNATS categories

[Jeffrey A Law]

  In message < 200003280942.LAA00686@loewis.home.cs.tu-berlin.de >you write:
  > The current GCC GNATS installation has a number of categories that
  > haven't been used so far, despite the 145 reports that we already
  > have. I propose to remove them, before anybody uses them. The most
  > useless ones are
  > 
  > gc
  > host
  > profiling
Well, I can see possibly needing these long term, but I've got no objection
to removing them until we actually need them.

  > I'd also like to ban the lib* categories, on the basis that they could
  > go with their front-ends
  > 
  > libf2c
  > libgcc
  > libobjc
  > libobjc
  > libstdc++
Actually, I would just remove libgcc.  While the runtime libraries are
associated with a front-end, they really are distinct code hunks from
the compiler itself.

jeff

Re: Removing GNATS categories

[Martin v. Loewis]

Tom,

It seems that the general consensus is that the categories gc, host,
profiling and libgcc can be removed right now; could you please remove
them from the GCC GNATS installation? I'd appreciate if you could
double-check that there are no reports in them.

I will integrate the necessary changes into gccbug; I will also take
the opportunity to document the categories and classes in gccbug.

The issue of splitting the c++ category into finer subcategories is
not sufficiently resolved, yet; when we have a technology for doing
so, I come back with a proposal of what these categories should be.
When that is done, we should also have a way of documenting the
various fields in the Web interface.

Thanks to everybody involved,

Martin

Re: Removing GNATS categories

[Tom Tromey]

Martin> It seems that the general consensus is that the categories gc,
Martin> host, profiling and libgcc can be removed right now; could you
Martin> please remove them from the GCC GNATS installation? I'd
Martin> appreciate if you could double-check that there are no reports
Martin> in them.

Done.

Martin> The issue of splitting the c++ category into finer
Martin> subcategories is not sufficiently resolved, yet; when we have
Martin> a technology for doing so, I come back with a proposal of what
Martin> these categories should be.

Maybe talk to the Gnats people about this.
The next Gnats, which we haven't yet installed, is much more
configurable.  Maybe there's already a way to do this.
I agree subcategories would be nice.  For instance, for Java we'd like
to be able to categorize on package name.  There are potentially a lot
of these.

Tom

Re: Removing GNATS categories

[Branko]

[-- Attachment #1: Type: text/plain, Size: 350 bytes --]

Martin,

here's a first try. Put the attached gnatsweb-site.pl
into cgi-bin, edit @site_admins and/or %site_category_filter,
and see what happens.

    Brane

-- 
Branko &Ccaron;ibej                 <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49     fax: (+386 1) 586 52 70
gnatsweb-site.pl


[-- Attachment #2: gnatsweb-site.pl --]
[-- Type: text/x-perl, Size: 2788 bytes --]

#!/usr/bin/perl -w
#
# Gnatsweb - web front-end to gnats

#-----------------------------------------------------------------------------
# Site-specific customization -
#

# site_callback -
#
# arguments:
#     $reason - reason for the call.  Each reason is unique.
#     @args   - additional parameters may be provided in @args.
#
# returns:
#     undef     - take no special action
#     string    - string is used by gnatsweb according to $reason

sub site_callback {
  my($reason, @args) = @_;
  if ($reason eq 'initialize') {
    return site_filter_categories();
  }

  undef;
}


#-----------------------------------------------------------------------------
# Filter the list of categories based on the current user and database.
#
# Written by Branko Cibej <branko.cibej@hermes.si>, March 2000.
#
#     Don't do anything if:
#       - there's no entry for the database in %site_category_filter; or,
#       - the current user is in @site_admins; or,
#       - the current user is in the database's `admins' list.
#     Otherwise remove names in the database's `filter' list from @category.

# site_admins -
#     List of site-wide administrators
@site_admins = ();

# site_category_filter -
#     Per-database list of admins and categories to hide from non-admins
%site_category_filter =
      # <database> => { admins => [ <username>, ... ],
      #                 filter => [ <category>, ... ] }
      ('gcc' => {admins => [],
                 filter => ['gc', 'host', 'profiling', 'libgcc']}
       );


# site_list2hash -
#     Create a hash reference from a list
sub site_list2hash {
  my $hash_ref = {};
  foreach (@_) { $$hash_ref{$_} = 1; }
  return $hash_ref;
}

# site_filter_categories -
#     Filter hidden categories from the @category list
sub site_filter_categories {
  # find the filter for the current database
  my $db_filter = $site_category_filter{$global_prefs{'database'}};
  return 'Database filter not defined'
        unless defined $db_filter;

  # Filter only if the current user isn't in the admin users list
  my $admins = site_list2hash(@{$$db_filter{'admins'}}, @site_admins);
  return 'User is administrator'
        if exists $$admins{$db_prefs{'user'}};

  # Remove filtered categories from @category
  my $filter = site_list2hash(@{$$db_filter{'filter'}});
  my @lcat = ();

  foreach (@category) {
    push(@lcat, $_)
          unless exists $$filter{$_};
  }

  @category = @lcat;
  return 'Filtered';
}

# end category filter
#-----------------------------------------------------------------------------

# end customization
#-----------------------------------------------------------------------------

# Emacs stuff -
#
# Local Variables:
# perl-indent-level:2
# perl-continued-brace-offset:-6
# perl-continued-statement-offset:6
# End:

Re: Removing GNATS categories

[Branko]

"Martin v. Loewis" wrote:

> I think modifying gnatsd is not going to work, unless you want to get
> that into gnats 4 earliest. You'd have to extend the structure of
> gnatsd.access, and perhaps a number of other files (such as
> categories).

That's what I thought, yes.

> While in principle it is a good thing that gnatsweb allows to connect
> to different databases, customizing it via gnatsweb-site.pl is ok -
> like having a function filter_categories, which gets the categories
> list and can make a decision based on the database, the access mode,
> and perhaps the user. In the specific case, it would have a narrow
> list in sending mode, and a long list in editing mode.

Oops, I completely missed the site-specific callback. It just goes to show, you
have to analyse more thoroughly before trying to fix a problem ...

Yes, it's doable that way, and I'm willing to give it a go. I'll let you know
how it goes in a day or so.


For the long term, I think getting support for this into GNATS is the way to
go.


    Brane

--
Branko &Ccaron;ibej                 <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49     fax: (+386 1) 586 52 70

Re: Removing GNATS categories

[Martin v. Loewis]

> Two solutions come to mind:
> 
>    * Filter out the "hidden" categories in gnatsweb.pl; or,
>    * Fix the GNATS server to filter the list of categories, perhaps based
>      on the name of the logged in user.
> 
> The first is probably a bad idea, since gnatsweb.pl lets you connect to
> severlal bug databases. The second means hacking GNATS itself
> (themselves?).
> 
> Which is worse? :)

I think modifying gnatsd is not going to work, unless you want to get
that into gnats 4 earliest. You'd have to extend the structure of
gnatsd.access, and perhaps a number of other files (such as
categories).

While in principle it is a good thing that gnatsweb allows to connect
to different databases, customizing it via gnatsweb-site.pl is ok -
like having a function filter_categories, which gets the categories
list and can make a decision based on the database, the access mode,
and perhaps the user. In the specific case, it would have a narrow
list in sending mode, and a long list in editing mode.

Regards,
Martin

Re: Removing GNATS categories

[Branko]

"Martin v. Loewis" wrote:

> > But, you see, there are experts that can recategorize into finer
> > detail.  I know that I have always wanted, and often used finer
> > resolution than just g++.  EH/pt/mi/rtti/vtbl and so on...  I find
> > such micro categories very useful.  It'd be nice for gnats to support
> > a subcategory, then the main one could be g++, with the minor one be
> > even more specific.
>
> I agree. What we probably could do is to add the categories, and not
> expose them to the submitter. Not adding them into the gccbug script
> is easy. Not adding them in gnatsweb.pl is more difficult, unless we
> have two cgi scripts - one for database maintainers, and one for
> submitters. Again, this is a request for perl hackers - any
> volunteers?

I took a look at cvsweb.pl. Unlike gccbug, it doesn't contain a list of
categories; it seems to read the list from the GNATS server by sending it
the `lcat' command.

Two solutions come to mind:

   * Filter out the "hidden" categories in gnatsweb.pl; or,
   * Fix the GNATS server to filter the list of categories, perhaps based
     on the name of the logged in user.

The first is probably a bad idea, since gnatsweb.pl lets you connect to
severlal bug databases. The second means hacking GNATS itself
(themselves?).

Which is worse? :)

--
Branko &Ccaron;ibej                 <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49     fax: (+386 1) 586 52 70

Re: Removing GNATS categories

[Martin v. Loewis]

> But, you see, there are experts that can recategorize into finer
> detail.  I know that I have always wanted, and often used finer
> resolution than just g++.  EH/pt/mi/rtti/vtbl and so on...  I find
> such micro categories very useful.  It'd be nice for gnats to support
> a subcategory, then the main one could be g++, with the minor one be
> even more specific.

I agree. What we probably could do is to add the categories, and not
expose them to the submitter. Not adding them into the gccbug script
is easy. Not adding them in gnatsweb.pl is more difficult, unless we
have two cgi scripts - one for database maintainers, and one for
submitters. Again, this is a request for perl hackers - any
volunteers?

Otherwise, I guess I just have to rewrite gnatsweb in Python - is
there a Python installation on sourceware? :-)

Regards,
Martin

Re: Removing GNATS categories

[Mike Stump]

> Date: Tue, 28 Mar 2000 11:42:12 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>

> The current GCC GNATS installation has a number of categories that
> haven't been used so far, despite the 145 reports that we already
> have.

When we have 10000 there will be some use for some of them.

> I'd also like to ban the lib* categories, on the basis that they could
> go with their front-ends

> libstdc++

I think this one is big enough to leave separate, but I could be
biased.  Or put another way, g++ is too big for people that want to
just maintain the library to wade through.

> With the reduced list, people won't get so confused about how to
> file a bug report. Just how often does it happen that somebody says
> she has a problem with libgcc - it would rather come out as a
> problem with exception handling, or a missing _divdi3 function.

But, you see, there are experts that can recategorize into finer
detail.  I know that I have always wanted, and often used finer
resolution than just g++.  EH/pt/mi/rtti/vtbl and so on...  I find
such micro categories very useful.  It'd be nice for gnats to support
a subcategory, then the main one could be g++, with the minor one be
even more specific.

What to do now?  Well, we can always trim them, as it doesn't hurt (if
they are not used), and later if people using the database request it,
new categories can be created to reflect their wishes on the fly.