New Comps Groups

[Jeremy Katz]

On Tue, 2006-11-28 at 01:01 +0100, Nicolas Mailhot wrote:
> Le lundi 27 novembre 2006 à 18:19 -0500, Jeremy Katz a écrit :
> > The problem is that you're using the argument of "all packages need to
> > be in comps, so we need to add groups" when comps was _never_ intended
> > to be an exhaustive list of every package.  
> 
> Well, maybe comps was not intended to be a lot of things, but when it
> was decided not to fix rpm groups and use comps as the only
> classification method of yum repositories, comps graduated to another
> level.

Who said only?  comps provides a browsing interface for things which are
"interesting"...  there are lots of other criteria that are interesting
and good to explore.  repoview gives one, for example.  And the key is
that with everything sitting on top of the same infrastructure, if
someone comes up with something that works better, it's relatively easy
to adopt it.  

comps is about browsing and finding interesting things.  Not
(fundamentally) about classification.

> > You'd be better off solving that problem with a) include it as a
> > step in the review process and b) integration with the push scripts to
> > provide notification/questioning when a new package is added to the
> > repository and isn't listed in comps.
> 
> This may scale at the redhat level but in a community context it
> doesn't. Automation is a lifesaver.

So, how do the rest of the package review steps which are manual work?
Why is it hard to hook into an automated script and send an automated
nag mail (heck, it could even auto-file a bug!)

Jeremy